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@xxxxxxxxxxxx
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
--
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
