The TCP options are:
No-Operation
No-Operation
SACK option(10): 3439172895:3439174275(1380)
So it looks like SACK issue - you can verify it by disabling SACK support
(/proc/sys/net/ipv4/tcp_sack, preferably at both sides) and running your
original rule sets. Does the ssh connection still hang?
doing a better tcpdump shows packets like this:
21:00:14.553927 IP (tos 0x0, ttl 64, id 60074, offset 0, flags [DF], proto TCP (6), length 68) warp.phas.ubc.ca.45084 > spider.phas.ubc.ca.ssh: ., cksum 0x6227 (correct), 401537117:401537117(0) ack 2834113458 win 24840 <nop,nop,sack 3 {147619638:147629298}{147615498:147618258}{147607218:147612738}>
where the SACK numbers appear (to me) to be completely bogus.
It appears that I see a hang right at the first packet using SACK.
This is a very short path, just a single hop, tracepath shows:
1: 142.103.235.177 0.039ms pmtu 1500
1: 142.103.236.11 1.053ms reached
1: 142.103.236.11 0.980ms reached
Resume: pmtu 1500 hops 1 back 255
I can't capture the other end of that connection, but connecting to
another machine (several hops farther away) where I can capture both sides
shows that somewhere along the way, the sequence numbers and ack values
are being translated, but the sack numbers aren't. This sounds like what
is discussed here:
http://lkml.indiana.edu/hypermail/linux/kernel/0707.3/2402.html
and I'm 99% sure there is a Pix firewall in the building...
Thanks for the help!
Carl
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
