tcp over slow links broken?
Matthew Dillon
dillon at apollo.backplane.com
Sun May 11 19:07:43 UTC 2008
:On Sat, 10 May 2008 23:33:56 PDT Julian Elischer <julian at elischer.org> wrote:
:> Bakul Shah wrote:
:...
:>
:> that is just plain wierd... B seems to have gone deaf.
:
:Yup! As if the wrong segment is being queued up.
Hmm. It looks like C has gone deaf, not B. B is retransmitting from
sequence 4744 which is the last sequence that C acked. C is then not
acking any further packets.
14:22:42.411144 IP B.55535 > C.ssh: . 7664:9124(1460) ack 2016 win 65535
14:22:42.411259 IP B.55535 > C.ssh: . 9124:10584(1460) ack 2016 win 65535
14:22:42.468350 IP C.ssh > B.55535: . ack 4744 win 65535
14:22:42.490556 IP C.ssh > B.55535: . ack 4744 win 65535
14:22:42.830171 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
14:22:43.470135 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
14:22:44.549944 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
14:22:46.509750 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
14:22:50.229210 IP B.55535 > C.ssh: . 4744:6204(1460) ack 2016 win 65535
This sounds like a packet filter state issue. My guess is that
PF running on B is getting confused. Either PF is getting confused,
or the packet is getting munged somehow to the point where PF refuses
to bridge it.
The A->C path (the one that is working) is going through PF's NAT rules.
The B->C path is probably going through a different set of PF rules.
I suggest capturing a trace on C to see if C is actually receiving
B's retransmissions.
-Matt
More information about the freebsd-current
mailing list