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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
