| |||||||||||||
|
| |||||||||||||
Networking change causes distribution headachesNetworking change causes distribution headachesPosted Oct 29, 2008 0:24 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: Networking change causes distribution headaches by rfunk Parent article: Networking change causes distribution headaches
the kernel always did transmit in the "right" order according to the RFCs
the problem is that it has been discovered that there are some routers out there that do not follow the RFCs and only work if things get transmitted in one specific order.
so the kernel has been changed (post 2.6.27) to transmit in the order that this batch of broken routers require.
for bonus points, what should the kernel do if another batch of broken routers is discovered that wants a different order?
(Log in to post comments)
Networking change causes distribution headaches Posted Oct 29, 2008 1:08 UTC (Wed) by jamesh (subscriber, #1159) [Link]
> for bonus points, what should the kernel do if another batch of
> broken routers is discovered that wants a different order?
Presumably, the current broken routers work with the packets generated by Windows. If a new router expected a different option order it wouldn't work with Windows, which is the kind of problem that would be noticed.
Networking change causes distribution headaches Posted Oct 29, 2008 1:29 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
so we need to reverse engineer how windows does things and never do anything different, even if the RFC allows it?
with that mindset we can never be better than windows.
yes, it is the case with doggy hardware that sometimes we do end up saying that 'windows does it this way and it works, the hardware doesn't follow the specs so we just need to do it the same way'
but to take that attitude about something that's supposed to be as generic as your network packets can be crippling.
Networking change causes distribution headaches Posted Oct 29, 2008 2:23 UTC (Wed) by corbet (editor, #1) [Link] The sad fact is that "what does Windows do?" is a question that kernel developers often have to keep in mind. Whatever Windows does is what's actually tested; it's often the only thing that works. It's a pain.
Networking change causes distribution headaches Posted Nov 1, 2008 4:32 UTC (Sat) by jbailey (subscriber, #16890) [Link]
It's not so much a matter or never so much as knowingly. Linux doing ECN
managed to make all sorts of devices on the Internet not cope with Linux, so it had to be disabled in order to work. But it's still there and an option. This thing isn't going to matter one way or the other, so it may as well be done as Windows does it to avoid any hassle.
Tks,
Networking change causes distribution headaches Posted Oct 29, 2008 3:48 UTC (Wed) by gdt (subscriber, #6284) [Link]
In the real world kernels deal with equipment which incorrectly implements specifications all of the time: ranging from hard disks to TCP. TCP itself has one option (the urgent pointer) who's current interpretation differs from the original specification due to an implementation error in early BSD.
This issue is hardly the first home router or firewall issue encountered: some break on ECN, some break on SACK, some incorrectly handle large window scale values. Some of those home routers with bugs run Linux.
It is disappointing that Ubuntu chose to limit the performance of TCP rather than ship a patched kernel.
Networking change causes distribution headaches Posted Oct 29, 2008 4:02 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
are tey limiting the performance of TCP?
I've seen many cases where doing the time calls in the TCP stack becomes the limiting factor, so disabling this should speed up TCP, it limits the features, but not the performance
Networking change causes distribution headaches Posted Oct 29, 2008 14:52 UTC (Wed) by drag (subscriber, #31333) [Link]
Well if your Ubuntu system is failing to, you know, contact the update server to download a fixed kernel because TCP is being blocked by a broken router; when every older version of Ubuntu can do it just fine, and every other OS does it just fine... then ya that's a dramatic reduction in performance.
-----------------------------------------
I can't beleive Ubuntu people are so closed minded that they can't understand that if you can't get out on the internet to download a fixed kernel, then your screwed. Your only option, as a end user, is to download the kernel fix post-installation. But if you can't contact it because your kernel is triggering a common TCP implimentation bug.. then your SOL.
There is a similar issue with DNS brokenness with Linux in general. As in; Linux behaving correctly, but getting bad results because a ISP can't get their shit straight or you have a buggy DNS proxy in some SOHO router. This is pretty common and it prevents end users from being able to reliably use some websites, which otherwise works perfectly well in any other OS. (the fix is usually to install a local DNS caching service like dnsmasq on the system)
Your bugs / my problem Posted Oct 29, 2008 18:57 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
This sort of brokenness is universal. Software has bugs. Sometimes the other guy's software has bugs, but you have to pay the price. So long as we don't have some evidence that the bugs were a result of malice, there is nothing much to do except name & shame, and then suck it up.
Prior examples include: DNS servers that silently ignore AAAA requests instead of replying that there's no matching record, causing a timeout for users who merely /enquired/ if they could use IPv6. IP "firewalls" that drop every type of ICMP packet indiscriminately by default. HTTP servers that silently accept pipelined requests, but don't pipeline the answers - so it answers all your HTTP queries, but the results are arbitrarily muddled together. Home routers that silently modify any 4 byte sequence resembling your private IP address to the 4 bytes representing the masqueraded public address? Yes, those really exist. Sometimes it seems like it'd be better to flush it away and start over - but don't make that mistake, we'd make just as many errors next time.
Although they seem to be the worst offenders, the proprietary systems aren't the only ones making these goofs. Samba's buggy attempt at early implementation of a new Windows SMB feature meant that not only could you not use the feature with Samba, but Microsoft had to disable it for Windows clients too, so everyone lost.
And let's not dwell on Debian's OpenSSL goof. To achieve a reasonable expectation of security everyone's SSL implementations should be updated to regard all the affected keys as weak, and reject them outright - but doing that means a permanent increase in the overhead of using SSL forever and for everyone in the whole world. Ouch.
|
|
||||||||||||