Re: TCP RST+data!

Ian FREISLICH wrote:
> "Kip Macy" wrote:
>   
>> On Nov 22, 2007 12:14 PM, Ian FREISLICH <ianf_at_clue.co.za> wrote:
>>     
>>> Hi
>>>
>>> I have a device (sip/iax phone) that has a web interface and a
>>> poorly documented CLI.  The only thing is it sends a RST with its
>>> last data packet.  "Stevens" seems to indicate an RST should discard
>>> buffered data and I suspect that's what's happening when I try to
>>> browse to it.
>>>
>>> However, Windows and MacOs both pull up the web page.  Is this a
>>> bug in our TCP implimentation or in theirs?
>>>
>>> Here's a tcpdump of seamonkey trying to retrieve the document index:
>>>
>>> 22:07:53.728516 IP (tos 0x0, ttl 64, id 24507, offset 0, flags [DF], proto 
>>>       
> TCP (6), length 60) 196.7.162.28.50118 > 196.7.162.30.80: S, cksum 0xdbdd (corr
> ect), 2746220400:2746220400(0) win 65535 <mss 1460,nop,wscale 3,sackOK,timestam
> p 16267181 0>
>   
>>> 22:07:53.731512 IP (tos 0x0, ttl 64, id 36, offset 0, flags [DF], proto TCP
>>>       
>  (6), length 60) 196.7.162.30.80 > 196.7.162.28.50118: S, cksum 0xbdba (correct
> ), 2416404465:2416404465(0) ack 2746220401 win 8192 <mss 1460,nop,wscale 0,nop,
> nop,timestamp 2333 16267181>
>   
>>> 22:07:53.731543 IP (tos 0x0, ttl 64, id 24508, offset 0, flags [DF], proto 
>>>       
> TCP (6), length 52) 196.7.162.28.50118 > 196.7.162.30.80: ., cksum 0xe8f5 (corr
> ect), 1:1(0) ack 1 win 8326 <nop,nop,timestamp 16267184 2333>
>   
>>> 22:07:53.731593 IP (tos 0x0, ttl 64, id 24509, offset 0, flags [DF], proto 
>>>       
> TCP (6), length 428) 196.7.162.28.50118 > 196.7.162.30.80: P 1:377(376) ack 1 w
> in 8326 <nop,nop,timestamp 16267184 2333>
>   
>>> 22:07:53.770545 IP (tos 0x0, ttl 64, id 37, offset 0, flags [DF], proto TCP
>>>       
>  (6), length 52) 196.7.162.30.80 > 196.7.162.28.50118: ., cksum 0xe948 (correct
> ), 1:1(0) ack 377 win 7867 <nop,nop,timestamp 2333 16267184>
>   
>>> 22:07:54.004963 IP (tos 0x0, ttl 64, id 38, offset 0, flags [DF], proto TCP
>>>       
>  (6), length 61) 196.7.162.30.80 > 196.7.162.28.50118: P, cksum 0xcdea (correct
> ), 1:10(9) ack 377 win 8192 <nop,nop,timestamp 2334 16267184>
>   
>>> 22:07:54.018027 IP (tos 0x0, ttl 64, id 39, offset 0, flags [DF], proto TCP
>>>       
>  (6), length 638) 196.7.162.30.80 > 196.7.162.28.50118: RP 10:608(598) ack 377 
> win 8192 [!RST+ 200 OK\015\012Server: Rapid Logic/1.]
>   
>> Looking at your later trace, data with the RST is a red herring. The
>> only thing that stands out to me as being odd and perhaps is the
>> issue, is that the window size for the SYN and the ack are
>> inconsistent on FreeBSD but are consistent on OS X. I'm not sure off
>> hand where the number 8326 comes from. It could be that when the SIP's
>> stack is generating the ack for the GET it concludes that the window
>> accounting state is incorrect.
>>
>> Perhaps Mike can shed some light when he gets back online.
>>     
>
> 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).

    Sam