Andre Oppermann wrote:
On 03.04.2012 17:38, Darren Reed wrote:
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
On 01.04.2012 09:27, Darren Reed wrote:
The problem here is that it only tracks the window size as
it grows, not as it shrinks. Thus the remote end setting its
window size to 0 is ignor
On 04.04.2012 17:03, per...@pluto.rain.com wrote:
Andre Oppermann wrote:
The other side is retransmitting data we have already received
and acknowledged ... That behavior is totally non-compliant.
Any chance our ack of that data got dropped/lost enroute, and the
other side is resending after
Andre Oppermann wrote:
> The other side is retransmitting data we have already received
> and acknowledged ... That behavior is totally non-compliant.
Any chance our ack of that data got dropped/lost enroute, and the
other side is resending after timing out?
_
Andre Oppermann wrote:
On 03.04.2012 17:38, Darren Reed wrote:
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
On 01.04.2012 09:27, Darren Reed wrote:
The problem here is that it only tracks the window size as
it grows, not as it shrinks. Thus the remote end setting its
window size to 0 is ignor
On 03.04.2012 17:38, Darren Reed wrote:
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
On 01.04.2012 09:27, Darren Reed wrote:
The problem here is that it only tracks the window size as
it grows, not as it shrinks. Thus the remote end setting its
window size to 0 is ignored.
My patch is wrong
On 4/04/2012 3:17 AM, Andre Oppermann wrote:
> On 03.04.2012 17:38, Darren Reed wrote:
>> On 3/04/2012 11:45 PM, Andre Oppermann wrote:
>>> It's the other way around. remote.ssh is sending old data
>>> which freebsd82.62922 has already ack'ed. The sessions seems
>>> to be de-synchronized, perhaps
On 4/04/2012 3:17 AM, Andre Oppermann wrote:
> On 03.04.2012 17:38, Darren Reed wrote:
>> On 3/04/2012 11:45 PM, Andre Oppermann wrote:
>>> It's the other way around. remote.ssh is sending old data
>>> which freebsd82.62922 has already ack'ed. The sessions seems
>>> to be de-synchronized, perhaps
On 03.04.2012 17:38, Darren Reed wrote:
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
It's the other way around. remote.ssh is sending old data
which freebsd82.62922 has already ack'ed. The sessions seems
to be de-synchronized, perhaps some middle box mucking with
the segments trying to modula
On 3/04/2012 11:45 PM, Andre Oppermann wrote:
> On 01.04.2012 09:27, Darren Reed wrote:
>> Andre,
>>
>> Your changes bring it closer to working correctly with a
>> small change: rather than "tiwin > tp->snd_wnd", it should
>> be "tiwin != tp->snd_wnd". In this trace, the remote end
>> has set a win
On 01.04.2012 09:27, Darren Reed wrote:
Andre,
Your changes bring it closer to working correctly with a
small change: rather than "tiwin > tp->snd_wnd", it should
be "tiwin != tp->snd_wnd". In this trace, the remote end
has set a window scale factor of 5 during connection
establishment.
The sam
Andre,
Your changes bring it closer to working correctly with a
small change: rather than "tiwin > tp->snd_wnd", it should
be "tiwin != tp->snd_wnd". In this trace, the remote end
has set a window scale factor of 5 during connection
establishment.
The same change should be made in the if() a few
On 31.03.2012 12:40, Darren Reed wrote:
Darren Reed wrote:
Andre Oppermann wrote:
On 30.03.2012 16:22, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working
Darren Reed wrote:
Andre Oppermann wrote:
On 30.03.2012 16:22, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a moderate
Andre Oppermann wrote:
On 30.03.2012 16:22, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a moderate delay in it, FreeBS
Jason Hellenthal wrote:
On Sat, Mar 31, 2012 at 01:22:27AM +1100, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a mod
On 30.03.2012 16:22, Darren Reed wrote:
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a moderate delay in it, FreeBSD's
TCP ignores the othe
On Sat, Mar 31, 2012 at 01:22:27AM +1100, Darren Reed wrote:
> I've been tracking down some problems with FreeBSD's sending
> of TCP packets and seem to have come to the conclusion that
> in FreeBSD 8.2-RELEASE, when the system is working with a
> TCP connection that has a moderate delay in it, F
I've been tracking down some problems with FreeBSD's sending
of TCP packets and seem to have come to the conclusion that
in FreeBSD 8.2-RELEASE, when the system is working with a
TCP connection that has a moderate delay in it, FreeBSD's
TCP ignores the other end telling it that the window size
is n
18 matches
Mail list logo
