IPFW SACK options

[Justin Robertson]

Chuck Swiger wrote:
> On Mar 7, 2007, at 2:35 PM, Justin Robertson wrote:
>>> The issue here is that no windows PC is compliant, and continues to 
>>> try and send SYN SACK packets until giving up entirely on the 
>>> connection - I've already tried this. I can't tell you why the bsd 
>>> stack doesn't have an issue with bare SYNs, but does on SYNs with 
>>> SACK set in the tcpoptions, but it apparently does.
>>>
>> Example - windows PC trying to connect to POP mailserver, sacks 
>> blocked (being viewed from firewall)
>>
>> 14:31:54.632444 client.52985 > server.110: S [tcp sum ok] 
>> 3734795545:3734795545(0) win 8192 <mss 1460,nop,wscale 
>> 8,nop,nop,sackOK> (DF) (ttl 115, id 12030, len 52)
>> 14:31:57.629151 client.52985 > server.110: S [tcp sum ok] 
>> 3734795545:3734795545(0) win 8192 <mss 1460,nop,wscale 
>> 8,nop,nop,sackOK> (DF) (ttl 115, id 12034, len 52)
>> 14:32:03.635511 client.52985 > server.110: S [tcp sum ok] 
>> 3734795545:3734795545(0) win 8192 <mss 1460,nop,nop,sackOK> (DF) (ttl 
>> 115, id 12046, len 48)
>>
>> You get three sack attempted retransmissions, then failure. It's not 
>> sending selective acks, it's trying to establish that selective acks 
>> are allowed for the rest of the communication between client/server.
>
> Which flavor of Windows was the sender?
>
> I seem to recall that Win2000/XP/2003 was willing to resend the SYN 
> without enabling the SACK option after a few retries, but it's been a 
> while since I've done that sort of testing...
>
>> I just want to strip the sack options from the packet and pass it on. 
>> The "issue" is that BSD can't cope with a flood of syn/sack permitted 
>> packets. All IP lags, and on 6.x stops all-together.
>
> Is the machine you're testing against the destination of this traffic, 
> or are you wanting to change this on a firewall box which lies between 
> the sender and destination?
>
> If the latter, I would agree that you'd need to hack the firewall 
> code.  But if the former, take a look into 
> /usr/src/sys/netinet/tcp_input.c for the tcp_dooptions() function, and 
> try to #ifdef out the cases for TCPOPT_SACK_PERMITTED & TCPOPT_SACK?
>
> ---Chuck
>
>
All latest windows updated XP machines, as well as all new Vista 
machines have this issue. And this is being done on a firewall box 
between sender/destination. The firewall machine itself (even in a 
transparent bridge) lags when passing SYN w/ SACK - hence the need to 
hack up ipfw to strip TCP options.



-- 
Justin