Re: tcp over slow links broken?

: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