Re: NAT stops forwarding ACKs after PMTU discovery

[Eric Dumazet <eric.dumazet@gmail.com>]

On Sun, 2013-08-18 at 23:23 +0200, Jozsef Kadlecsik wrote:

> It's a PMTU related problem, so I'd suggest to check first the next ones:
> 
> Aren't the ICMP error messages (i.e. fragmentation-needed) filtered out?
> If not, does adding an explicit TCPMSS rule to the mangle table help?

Thats totally irrelevant. tcp conntrack should not care of ICMP messages
anyway.

> Isn't there SACK options involved? Maybe there's a "smart" sequence 
> number "anonymizer" device in the path which forgets about the SEQ numbers 
> in the SACK options and thus such packets are marked as INVALID.
> 

As I understood the report, they were no SACK at all, but plain ACK
messages, and conntrack believes these ACK are outside the window
because it remembers the @end sequence of the probe, and the @maxwin of
receiver.

Lets say the probe is 2000 bytes, seq 1:2001

conntrack records end = 2001

Of course this packet is lost.

The retransmit sends a 1000 bytes packet, seq 1:1001

conntrack pass the packet.

Receiver acks it using ack 1001

conntrack drops this ack because of some confusion about the prior 2001
end, and the window (might be as small as 1000)

Code like this seems very suspect to me :

before(sack, receiver->td_end + 1)

It basically says that conntrack doesn't deal with reorders on the
network.

> So tcpdumps captured at both sides could really help to tell what goes wrong.

We probably can reproduce this bug using packetdrill.