TCP RST+data!

[Ian FREISLICH]

Mike Silbersack wrote:
> 
> On Sun, 25 Nov 2007, Ian FREISLICH wrote:
> 
> >>> I see.  Playing around with net.inet.tcp sysctls, disabling delayed_ack
> >>> fixes the problem with this phone.  Do you think that this is a bug
> >>> in the phone's TCP stack?
> >>>
> >>
> >> Is there a proxy involved or is this session end-to-end?  Not sure if
> >> you described the setup but it might be useful (e.g. is the phone using
> >> wireless).
> >
> > There the one connecting side was wireless, but it made no difference
> > connecting over wired ethurnet end to end.  There is no proxy
> > involved.  Both host and the phone are on the same subnet.
> 
> Can you post a tcpdump of a successful connection with delayed_ack 
> disabled and then the same attempted (unsuccessful) connection with 
> delayed_ack reenabled?  Please use -s 0 (to catch the entire packet) and 
> use -w to write the binary dump data to a file.  That'll allow us to look 
> at the entire data payload.  It's probably best to post those dumps on a 
> server somewhere and just post the urls to the list.

net.inet.tcp.delayed_ack=0
net.inet.tcp.rfc1323=1
http://www.freislich.nom.za/phone.nodelayedack

net.inet.tcp.delayed_ack=1
net.inet.tcp.rfc1323=1
http://www.freislich.nom.za/phone.delayedack

net.inet.tcp.delayed_ack=1
net.inet.tcp.rfc1323=0
http://www.freislich.nom.za/phone.delayedack+norfc1323

All: this host is on the other end of *very* limited bandwidth
connection, so don't hit it at once.

Ian

--
Ian Freislich