Summary: | [2.6.27 regression] unable to connect to *any* TCP port at any address beyond my router | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mark Nowiasz <mark+gentoobugs> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | leio, marcus.wissmann |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=fd6149d332973bafa50f03ddb0ea9513e67f4517 | ||
Whiteboard: | linux-2.6.27-regression | ||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch to reorder TCP options |
Description
Mark Nowiasz
2008-10-18 18:47:02 UTC
same here, solved by adding following lines to my /etc/sysctl.conf ----- # broken linksys-router net.ipv4.tcp_sack = 0 net.ipv4.tcp_dsack = 0 ----- Marcus (In reply to comment #1) > same here, solved by adding following lines to my /etc/sysctl.conf > > ----- > # broken linksys-router > net.ipv4.tcp_sack = 0 > net.ipv4.tcp_dsack = 0 > ----- > > Marcus > should be: ----- # broken router net.ipv4.tcp_sack = 0 net.ipv4.tcp_dsack = 0 ----- Thanks reporting your fix Marcus. Does this solve your problem as well, Mark? (In reply to comment #3) > Thanks reporting your fix Marcus. Does this solve your problem as well, Mark? Yes :-) But It's hardly surprising since Marcus and I are using a similar model from the same vendor (Netgear with Zyxel firmware) :-) I suggest printing out a message after emerging 2.6.27 (something like "If you experience TCP problems, try ....") since this problem could potentially affect lots of users. Here is the kernel bugzilla entry with reports from other people from broken routers: http://bugzilla.kernel.org/show_bug.cgi?id=11721 It seems that the fix to restore compatibility will be coming out in a 2.6.27.x stable release, and the recommended workaround in the meantime involves disabling tcp options (possibly timestamps in addition to sack/dsack mentioned below). I agree that an einfo pointing out how to deal with broken routers seems like a good idea! *** Bug 243254 has been marked as a duplicate of this bug. *** Wormo, good find and thanks for that! We'll keep an eye on the patch and if it makes it too mainline, we can try to pull it into gentoo-sources until it exists in an office 2.6.27.X patch Created attachment 170050 [details, diff]
Patch to reorder TCP options
Can someone test this patch against gentoo-sources-2.6.27-r1 and report the results?
This bug was not present in 2.6.26, right? Yeah, similar issue here. Without net.ipv4.tcp_timestamps = 0 my (crummy) Westell router is toast. Best, Markus Markus, and this worked OK in 2.6.26 without any workaround? Just trying to fathom whether this is a 2.6.27 regression or not. (In reply to comment #11) > Markus, and this worked OK in 2.6.26 without any workaround? Just trying to > fathom whether this is a 2.6.27 regression or not. > Yes, 2.6.26 works out of the box without any problems so this definitely looks like a regression in 2.6.27. Best, Markus (In reply to comment #8) > Created an attachment (id=170050) [edit] > Patch to reorder TCP options > > Can someone test this patch against gentoo-sources-2.6.27-r1 and report the > results? That patch fixes CONNECT(2) to an embedded device successfully for me, without the workaround to disable TCP timestamps. TCP timestamps are enabled and it now works again together with them. Fixed in genpatches-2.6.27-4 / gentoo-sources-2.6.27-r2, thanks for reporting & testing |