Re: Transfer stalls with NAT under 2.6.24.3

[Sven Riedel <sr@securenet.de>]

Hi,
we had a minor emergency here last week, so I wasn't able to test the 
old kernel. I'll see that I'll try that tomorrow.

Jozsef Kadlecsik wrote:
> On Wed, 26 Mar 2008, Patrick McHardy wrote:
> 
>>> During a run with stalls:
>>>
>>> nf_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT=
>>> SRC=100.100.100.100 DST=200.200.200.200 LEN=80 TOS=0x00 PREC=0x00 TTL=56
>>> ID=44105
>>> DF PROTO=TCP SPT=22 DPT=35858 SEQ=4160349927 ACK=596614326 WINDOW=49248
>>> RES=0x00 ACK URGP=0 OPT
>>> (0101080A4558793C1B13CE350101051A491E8751491E8CA9491E7B71491E81F9491E40A9491E5B61)
>>>
>> Thanks, can you send a binary tcpdump (... -w file) of a connection
>> that triggers these messages please?
> 
> Yes, a tcpdump of a full session which is stalled could help a lot.
Ok, I'll send one along later today.

> But it almost look like as a SACK related problem: isn't there a (new)
> device between the communicating parties which performs ISN randomization
> and fails to adjust SACK?

There are at least two devices between the communication partners: a DSL 
modem and a firewall on the remote end (outside of my control). Both 
devices have been there already and didn't create any problems with the 
old iptables setup. The only thing that changed on that communication 
path is the firewall hardware, the NIC on the firewall and the 
netfilter/iptables version used by the firewall.

Regards,
Sven


-- 
sven.riedel@securenet.de

SecureNet GmbH
Intranet & Internet Solutions
Frankfurter Ring 193a
D-80807 München
Tel: +49 89 32133-632
Fax: +49 89 32133-699
Zentrale: -600
www.securenet.de

Sitz der Gesellschaft: München
HRB München 118876
Geschäftsführer: Thomas Schreiber