linux-kernel - Re: Unexpected Acknowledgement / Stalled Connections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070205053703.GC25760@galon.ev-en.org>
Date:	Mon, 5 Feb 2007 07:37:03 +0200
From:	Baruch Even <baruch@...en.org>
To:	Parag Warudkar <parag.warudkar@...il.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Unexpected Acknowledgement / Stalled Connections

* Parag Warudkar <parag.warudkar@...il.com> [070205 00:57]:
> On 2/4/07, Parag Warudkar <parag.warudkar@...il.com> wrote:
> >I am running 2.6.20 and have trouble with stalled connections. For
> >instance, if I try to download a debian ISO image using wget, the
> >connection runs fine for few seconds and then stalls for ever.
> >
> >In my router logs I see a ton of messages like the below -
> >
> >[INFO] Sun Feb 04 17:22:03 2007 Blocked incoming TCP packet from
> >192.168.0.174:34090 to 130.239.18.138:80 with unexpected
> >acknowledgement 3269301836 (expected 3269343453 to 3269408989)
> >
> >Where 192.168.0.174 is my laptop running FC6 and kernel 2.6.20 and
> >130.239.18.138 is whatever cdimage.debian.org resolves to atm.
> >
> >What's going on here? Any TCP/IP tunable that I can set/turn on/off to
> >prevent this from happening?
> 
> Turning tcp_sack off seems to cure it. Turning it on again makes the
> connections stall. Seems like the D-Link router doesn't like the SACKs
> linux sends?

You can also try to disable tcp_window_scaling.

Can you provide a tcpdump trace of the connection? Traces with and
without SACK would be appreciated, also a trace with SACK but without
window scaling would be useful. I only need the headers of the packet so
-s 60 (the default) will be fine.

There was a change in 2.6.20 that I put but it should only have affected
the sender side and even then only the way it interpreted the data and
not things it sent on the wire.

Trying the dl with previous kernels can also help, if only to try and
pinpoint where things went bad, assuming it is in the kernel. This
sounds like a bad implementation of ACK window checks that ICSA requires
for firewall product certification.

Baruch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/