Re: sysctl should disable ECN by default
Dominik Kubla [EMAIL PROTECTED] writes: On Thu, Sep 06, 2001 at 05:02:19PM +0200, Guillaume Morin wrote: RFC793 says Reserved: 6 bits Reserved for future use. Must be zero. The last statement is the cause of all confusions. s/Must/Should/ would have been better. Wrong. It is misinterpreted. Must be zero is for GENERATING conformant packages. Clearing bits is most certainly a violation of the internet standards. This knife cuts both sides. Why should someone bother to forward non-conformant packages? -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Re: sysctl should disable ECN by default
* Florian Weimer | This knife cuts both sides. Why should someone bother to forward | non-conformant packages? Because they are reserved and might be used for some useful purpose one day, which they are now. -- Tollef Fog Heen You Can't Win
Re: sysctl should disable ECN by default
On 7 Sep 2001, Florian Weimer wrote: snip This knife cuts both sides. Why should someone bother to forward non-conformant packages? Reserved bits can have any value. Routers need to _ignore_ them if they don't know what they mean (that is, if they're too old). They must _generate_ packages with the value zero at any time, but when forwarding, they must not touch them. Any implementation that does is not just broken, but was made by a braindead person (I refuse to call someone like that a programmer) -- wouter dot verhelst at advalvas dot be Human knowledge belongs to the world -- from the movie Antitrust
Re: sysctl should disable ECN by default
On Thu, 6 Sep 2001, Alex Pennace wrote: On Wed, Sep 05, 2001 at 02:37:06PM +0200, Florian Weimer wrote: Russell Coker [EMAIL PROTECTED] writes: Why should the default configuration be changed to account for the diminishing number of broken routers on the net? From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. No, such bastardization of TCP/IP, while already rampant, has no place on the Internet. While at the same time not properly functioning IMAP clients, browsers that are unable to correctly interpret HTML, SMB Machines that spew broadcasts, RIP being propagated who knows where, routes flapping etc. etc. has a place? No - you are right we have to sweep the place with a steel broom. And whoever behaves not in exact accordance with an RFC will immediately be exterminated by the Debian Intifada. Amen, *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Fri, Sep 07, 2001 at 12:47:05PM +0200, T.Pospisek's MailLists wrote: On Thu, 6 Sep 2001, Alex Pennace wrote: On Wed, Sep 05, 2001 at 02:37:06PM +0200, Florian Weimer wrote: Russell Coker [EMAIL PROTECTED] writes: Why should the default configuration be changed to account for the diminishing number of broken routers on the net? From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. No, such bastardization of TCP/IP, while already rampant, has no place on the Internet. While at the same time not properly functioning IMAP clients, browsers that are unable to correctly interpret HTML, SMB Machines that spew broadcasts, RIP being propagated who knows where, routes flapping etc. etc. has a place? No - you are right we have to sweep the place with a steel broom. And whoever behaves not in exact accordance with an RFC will immediately be exterminated by the Debian Intifada. Nazis. Hitler. Microsoft rules! (Die thread die!) -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpJ4ApmRjdrr.pgp Description: PGP signature
Re: sysctl should disable ECN by default
On Fri, Sep 07, 2001 at 10:02:48AM -0500, Nathan E Norman wrote:
Nazis. Hitler. Microsoft rules!
(Die thread die!)
You fool you!
Godwin's law is powerless when deliberately invoked...
('s' a bit like the chronicles of thomas covenant, now I think about it)
Jules
Re: sysctl should disable ECN by default
* Jaldhar H. Vyas [EMAIL PROTECTED] [010905 20:01]: whether they can deal with that or not. Debians sole responsibility is to see it is properly documented somewhere. If people don't read the *Please* dont document this in debconf. Do it in a README.Debian or the release notes. I *really dont* want to see 'important' information in debconf and not a README.Debian file. -- Scott Dier [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ringworld.org/ [EMAIL PROTECTED]
Re: sysctl should disable ECN by default
On Thu, Sep 06, 2001 at 09:47:05AM +0200, Dominik Kubla wrote: But the whole discussion here is folly. The whole thing has been discussed on linux-kernel by people far more knowlegable in this things than the average debian developer. I think we should follow the conclusions from that discussions: enable ECN by default and every non-compliant device be dammned. Assuming that defconfig reflects lkml discussions, it looks like the answer depends on the architecture. =) But it appears that Linus thinks it should be disabled by default. uhv:~/linux/linux-2.4.9-rthal5$ grep INET_ECN arch/*/defconfig arch/alpha/defconfig:CONFIG_INET_ECN=y arch/arm/defconfig:# CONFIG_INET_ECN is not set arch/cris/defconfig:# CONFIG_INET_ECN is not set arch/i386/defconfig:# CONFIG_INET_ECN is not set arch/mips/defconfig:# CONFIG_INET_ECN is not set arch/mips64/defconfig:# CONFIG_INET_ECN is not set arch/parisc/defconfig:# CONFIG_INET_ECN is not set arch/ppc/defconfig:# CONFIG_INET_ECN is not set arch/s390/defconfig:# CONFIG_INET_ECN is not set arch/s390x/defconfig:# CONFIG_INET_ECN is not set arch/sparc/defconfig:# CONFIG_INET_ECN is not set arch/sparc64/defconfig:CONFIG_INET_ECN=y uhv:~/linux/linux-2.4.9-rthal5$ dave...
Re: sysctl should disable ECN by default
Well all of this has been said on this thread here allready, but I'll repeat it never the less to get the facts straight. Zitiere Dominik Kubla [EMAIL PROTECTED]: On Wed, Sep 05, 2001 at 05:30:12PM +0200, T.Pospisek's MailLists wrote: But the whole discussion here is folly. The whole thing has been discussed on linux-kernel by people far more knowlegable in this things than the average debian developer. I think we should follow the conclusions from that discussions: enable ECN by default and every non-compliant device be dammned. However you, or whoever on the kernel lists might argue, the default in Linus' kernel sources is off! Please check it yourself. Mind you that we are only talking about firewalls here (and all of the can be fixed by firmware upgrades, or at least they should). Fact is some aren't. Ordinary routers have no business altering packets passing through and ordinary hosts have to ignore reserved bits they don't know about. Routers doing NAT are to be treated as firewalls. If they are broken: replace them. They will have more bugs that this one anyway. You are wellcome to be without a fault. Unfortunately a lot of HW/SW isn't. And often enough it's not up to the user to replace it. He just has to live with it. I think Craig Sanders and Anthony Towns said it best: Craig: the fact is that there is no possibility of harm if ECN is disabled in the kernel, while there IS possibility of harm if it is enabled. therefore it should be disabled by default. Anthony: I'm not sure what you mean by idealism but surely it's obvious the solution that's closest to ideal for the most users should be chosen as the default. *t
Re: sysctl should disable ECN by default
On Wed, 05 Sep 2001, Steve Greenland wrote: On 05-Sep-01, 16:35 (CDT), Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote: Why is it so hard to change a few lines and have the default be set to *off* and let whoever feels like it enable it? Because apparently Xu feels equally strong about not allowing someone else's irresponsability (the router firmware writer's) to force him to disable something he believes is right (or force him to change the default kernel behaviour against upstream wishes, or whatever) ? 1. The default kernel behavior is that ECN is completely disabled. Yes. However, if one wants the possibility of turning ECN on, it defaults to enabled. You know that, and so do I and everyone else (worth talking to) in this thread. Don't push the issue around. can't help but think that if someone's first experience with Debian is that the network install fails silently because ECN is enabled and some router between him and the archive is broken then we have failed to meet our (implied?)commitment in the Social Contract. All the newbie is going to know is that it doesn't work. Boy, I'm glad we've made our political point. [...] Sight. I give up. I said it THREE times that we should warn users about the issue, since Xu does not want to poke the kernel AND he wants the possibility of turning ECN on in the kernel. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: sysctl should disable ECN by default
Eric Van Buggenhaut [EMAIL PROTECTED] writes: On Wed, Sep 05, 2001 at 02:37:28PM +0200, Florian Weimer wrote: Russell Coker [EMAIL PROTECTED] writes: Why should the default configuration be changed to account for the diminishing number of broken routers on the net? From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. No it's not, you're violating RFC 793. I was indeed wrong, but not because of RFC 793. IIRC, there isn't such a required in this standard. But RFC 1812 explicitly requires routers not to check or otherwise deal with unused IP header fields, and I think this might be extended by analogy to TCP. OTOH, anyone is free to do anything with packets passing through his systems. Internet is not a right. ;-) -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Re: sysctl should disable ECN by default
On Thu, Sep 06, 2001 at 04:43:57PM +0200, Florian Weimer wrote: Eric Van Buggenhaut [EMAIL PROTECTED] writes: On Wed, Sep 05, 2001 at 02:37:28PM +0200, Florian Weimer wrote: Russell Coker [EMAIL PROTECTED] writes: Why should the default configuration be changed to account for the diminishing number of broken routers on the net? From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. No it's not, you're violating RFC 793. I was indeed wrong, but not because of RFC 793. IIRC, there isn't such a required in this standard. Yes there is. RFC 793 reserve bits 'for future use'. These bits may not be touched by a router or a firewall. The buggy hardware we are talking about zeroes those bits. Thus they violate RFC793. -- Eric VAN BUGGENHAUT Oh My God! They killed init! You Bastards! --from a /. post \_|_/ Andago \/ \/ Av. Santa Engracia, 54 a n d a g o |--E-28010 Madrid - tfno:+34(91)2041100 /\___/\ http://www.andago.com / | \ Innovando en Internet [EMAIL PROTECTED]
Re: sysctl should disable ECN by default
Dans un message du 06 Sep à 16:58, Eric Van Buggenhaut écrivait : RFC 793 reserve bits 'for future use'. These bits may not be touched by a router or a firewall. The buggy hardware we are talking about zeroes those bits. Thus they violate RFC793. RFC793 says Reserved: 6 bits Reserved for future use. Must be zero. The last statement is the cause of all confusions. s/Must/Should/ would have been better. -- Guillaume Morin [EMAIL PROTECTED] If it doesn't work, force it. If it breaks, it needed replacing anyway.
Re: sysctl should disable ECN by default
RFC793 says Reserved: 6 bits Reserved for future use. Must be zero. The last statement is the cause of all confusions. s/Must/Should/ would have been better. No; to be forward compatible, a TCP must set the bits to zero. 2481 describes the operation of those bits and augments 793, much like SACK augments it. Some TCP's have a bug where they set the bits in the SYN/ACK if they received reserved bits in the SYN, which is why ECN negotiation is asymmetric. If you want to blame routers for not implementing standards, try 791. The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. -neil
Re: sysctl should disable ECN by default
On Wed, Sep 05, 2001 at 02:37:06PM +0200, Florian Weimer wrote: Russell Coker [EMAIL PROTECTED] writes: Why should the default configuration be changed to account for the diminishing number of broken routers on the net? From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. No, such bastardization of TCP/IP, while already rampant, has no place on the Internet.
Re: sysctl should disable ECN by default
Russell Coker [EMAIL PROTECTED] writes: Why should the default configuration be changed to account for the diminishing number of broken routers on the net? From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Re: sysctl should disable ECN by default
Dans un message du 05 sep à 14:37, Florian Weimer écrivait : From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. I would not call reasonable dropping packets carrying bits of a protocol rated as Proposed Standard by IETF. -- Guillaume Morin [EMAIL PROTECTED] Oh, that is nice out there, I think I'll stay for a while (RHCP)
Re: sysctl should disable ECN by default
On Sat, Sep 01, 2001 at 04:39:30PM -0700, Neil Spring wrote: Incidentaly I'd today filled a *critical* bugreport against kernel-image-2.4.8 just because of that. It lists as Done; perhaps you're expected to file it someplace else? The first *experimental* rfc for ECN dates from 1999. That's not like ages. There's a lot of equipment online from that time. No. IP and TCP have been around a little longer. The bits that ECN uses are RESERVED. Reserved means this will be used someday not this must be zero for the packet to be valid, and certainly not set this bit to zero. Blaming ECN for faulty IP implementations is wrong. Calling a box that reaches inside your IP frame to zero a bit in the TCP header a router is just wrong (this is what the Zyxel thing does wrong). Finally, just a warning: calling it *experimental* is only going to last a little while longer. It's been approved as a Proposed Standard, and is just waiting for it's RFC number. (don't think proposed is meaningless: SACK is just a proposed standard. header compression is just a proposed standard). ECN is RFC2481 http://www.ietf.org/rfc/rfc2481.txt?number=2481 -- Eric VAN BUGGENHAUT Oh My God! They killed init! You Bastards! --from a /. post \_|_/ Andago \/ \/ Av. Santa Engracia, 54 a n d a g o |--E-28010 Madrid - tfno:+34(91)2041100 /\___/\ http://www.andago.com / | \ Innovando en Internet [EMAIL PROTECTED]
Re: sysctl should disable ECN by default
On Sun, Sep 02, 2001 at 12:56:18AM +0200, Tomas Pospisek wrote: Zitiere Eduard Bloch [EMAIL PROTECTED]: Neil Spring wrote on Sat Sep 01, 2001 um 12:34:40PM: being turned off behind my back. ECN doesn't need any more inertia slowing its deployment. It's already an experimental, off by default, addition to the kernel. Why do many people think that it is OFF by default? The fact is, it is ON (see kernel docs) and it breaks with many sites. We could live long without this experimental feature, so why _force_ the users to use the feature now and make a stable distribution with limited networking ability? Incidentaly I'd today filled a *critical* bugreport against kernel-image-2.4.8 just because of that. It's not only *sites* that do not work with ECN. It's also *routers*. That means if you have *one* router between you and your destination, that does not support ECN, then you'll get *very* strange behaveour like hanging TCP connections that somehow get halfway through but do hang never the less while ping works. Please check my bugreport #110862. And amongst the broken equipment are f.ex. (older?) Zyxel ISDN routers which are *very* popular. FYI, Zyxel 681 SDSL-Router breaks ECN by stripping 0x80 (ECN Cwnd Reduced) but not 0x40 (ECN Echo) (TOS bits) on all SYN packets. This is the last official firmware. A beta firmware is available internally which fixes this issue: (ZyXEL firmware v2.50(T.05)b6 | 03/28/2001) -- Eric VAN BUGGENHAUT Oh My God! They killed init! You Bastards! --from a /. post \_|_/ Andago \/ \/ Av. Santa Engracia, 54 a n d a g o |--E-28010 Madrid - tfno:+34(91)2041100 /\___/\ http://www.andago.com / | \ Innovando en Internet [EMAIL PROTECTED]
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Guillaume Morin wrote: Dans un message du 05 sep à 14:37, Florian Weimer écrivait : From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. I would not call reasonable dropping packets carrying bits of a protocol rated as Proposed Standard by IETF. The question is only if devices should be programmed in order to know the future and it's potential proposed stadards by the IETF. Mind you I don't know if the devices in question (websites, routers etc. droping ECN packets) *are* violating a standard that was current at *their* time. The routers in particular I think *are* wrong, since they are making decisions based on bits that at that time were reserved. But tell me, in case there's an IMAP client that has some problems with the IMAP protocol. Should a Debian box by default *refuse* to talk to it or should the default be to try to talk to it (provided that it can)? With ECN set, Debian's default is to plain *refuse* to talk to all equipment which, for whatever reason has problems with ECN. *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Eric Van Buggenhaut wrote: On Sun, Sep 02, 2001 at 12:56:18AM +0200, Tomas Pospisek wrote: It's not only *sites* that do not work with ECN. It's also *routers*. That means if you have *one* router between you and your destination, that does not support ECN, then you'll get *very* strange behaveour like hanging TCP connections that somehow get halfway through but do hang never the less while ping works. Please check my bugreport #110862. And amongst the broken equipment are f.ex. (older?) Zyxel ISDN routers which are *very* popular. FYI, Zyxel 681 SDSL-Router breaks ECN by stripping 0x80 (ECN Cwnd Reduced) but not 0x40 (ECN Echo) (TOS bits) on all SYN packets. This is the last official firmware. A beta firmware is available internally which fixes this issue: (ZyXEL firmware v2.50(T.05)b6 | 03/28/2001) So it's not only old routers. It's also new ones. Zyxel didn't get it. But until this day Debian didn't get it either. Whoever owns a Zyxel router that has this bug will be into troubles with Debian unless s/he's a netwoking nerd that knows about ECN. Go figure. And while we're at it - if you happen to stumble accross a firmware-fix for the Zyxel Prestige 2864i please point me to it. Because untill I fix that, one of our customers will be runing a broken network. *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
ECN is RFC2481 http://www.ietf.org/rfc/rfc2481.txt?number=2481 the internet draft by the same authors that supercedes rfc2481 and is a Proposed Standard instead of an Experimental Standard is draft-ietf-tsvwg-ecn-04. It is listed under working group standards track at http://www.rfc-editor.org/queue.html http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-04.txt -neil
Re: sysctl should disable ECN by default
Dans un message du 05 sep à 17:30, T.Pospisek's MailLists écrivait : The question is only if devices should be programmed in order to know the future and it's potential proposed stadards by the IETF. Mind you I don't know if the devices in question (websites, routers etc. droping ECN packets) *are* violating a standard that was current at *their* time. The routers in particular I think *are* wrong, since they are making decisions based on bits that at that time were reserved. It is not a good debate. Devices can be upgraded. Net admins should do their job. With ECN set, Debian's default is to plain *refuse* to talk to all equipment which, for whatever reason has problems with ECN. Debian default does not refuse to talk, it is the broken routers/firewalls which do. Should we stop progress because admins do not their job. I do not think so. -- Guillaume Morin [EMAIL PROTECTED] If you want the answers, you'd better get ready for the fire (System of a Down)
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Guillaume Morin wrote: Dans un message du 05 sep à 17:30, T.Pospisek's MailLists écrivait : The question is only if devices should be programmed in order to know the future and it's potential proposed stadards by the IETF. Mind you I don't know if the devices in question (websites, routers etc. droping ECN packets) *are* violating a standard that was current at *their* time. The routers in particular I think *are* wrong, since they are making decisions based on bits that at that time were reserved. It is not a good debate. Devices can be upgraded. Net admins should do their job. You will not be able to upgrade a Zyxel Prestige 2864i. And a lot of other old equipment. With ECN set, Debian's default is to plain *refuse* to talk to all equipment which, for whatever reason has problems with ECN. Debian default does not refuse to talk, it is the broken routers/firewalls which do. Yes - it does. By knowingly setting a flag which is known (!) to cause trouble. Should we stop progress because admins do not their job. I do not think so. There is no one taking your right away to: echo 1 /proc/sys/net/ipv4/tcp_ecn and march ahead on the edge of progress. It's another thing though to set this flag on default and leave the user in the dark why wondering why suddenly connectivity has ceased. Which is what Debian does. *t Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote: On Wed, 5 Sep 2001, Guillaume Morin wrote: Dans un message du 05 sep à 14:37, Florian Weimer écrivait : From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. I would not call reasonable dropping packets carrying bits of a protocol rated as Proposed Standard by IETF. The question is only if devices should be programmed in order to know the future and it's potential proposed stadards by the IETF. Mind you I don't know if the devices in question (websites, routers etc. droping ECN packets) *are* violating a standard that was current at *their* time. The routers in particular I think *are* wrong, since they are making decisions based on bits that at that time were reserved. The devices in question *are* violating the standards that existed at the time they were created. The bits that they're fiddling with are *reserved*. That means don't touch. They were in violation of the TCP/IP protocol from day one, it's just that it's only now that the IETF is making use of those bits, /as is their right/, that the problem with this equipment has come to light. But tell me, in case there's an IMAP client that has some problems with the IMAP protocol. Should a Debian box by default *refuse* to talk to it or should the default be to try to talk to it (provided that it can)? Are you joking? If someone filed a bug against my package saying I should make changes to it to accomodate a broken client (equivalent: my IMAP server sends back a valid IMAP response and this causes the client to segfault), I would immediately close the bug with a smile and a have-a-nice-day. Anyone using such broken software should do the right thing, which is one of: a) get a different IMAP client b) get an upgrade/fix for the IMAP client so that it's no longer broken c) sue the vendor for selling a product under false pretenses, with the goal of achieving either a) or b) above. The same applies to these POS Zylex routers. There's no reason that Debian should be covering their asses when they refuse to provide firmware upgrades to their customers in a timely manner, especially when everyone else on the Internet has been ready to go with ECN for some time now. Steve Langasek postmodern programmer
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Steve Langasek wrote: On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote: On Wed, 5 Sep 2001, Guillaume Morin wrote: Dans un message du 05 sep à 14:37, Florian Weimer écrivait : From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. I would not call reasonable dropping packets carrying bits of a protocol rated as Proposed Standard by IETF. The question is only if devices should be programmed in order to know the future and it's potential proposed stadards by the IETF. Mind you I don't know if the devices in question (websites, routers etc. droping ECN packets) *are* violating a standard that was current at *their* time. The routers in particular I think *are* wrong, since they are making decisions based on bits that at that time were reserved. The devices in question *are* violating the standards that existed at the time they were created. The bits that they're fiddling with are *reserved*. That means don't touch. They were in violation of the TCP/IP protocol from day one, it's just that it's only now that the IETF is making use of those bits, /as is their right/, that the problem with this equipment has come to light. That's what I was saying wasn't I? But tell me, in case there's an IMAP client that has some problems with the IMAP protocol. Should a Debian box by default *refuse* to talk to it or should the default be to try to talk to it (provided that it can)? Are you joking? If someone filed a bug against my package saying I should make changes to it to accomodate a broken client (equivalent: my IMAP server sends back a valid IMAP response and this causes the client to segfault), I would immediately close the bug with a smile and a have-a-nice-day. Good for you. And the people that *need* a working server as in it forks for *me* will move on and ignore you. That's your choice. It's the choice Debian is making now. But if care about the real world you will see that the philosophy of most software isn't I'm right have-a-nice-day but let's have something that works. Check the kernel. Check IMAP servers (that's why I was choosing this example), check well whatever, many things try to cooperate with broken stuff. Anyone using such broken software should do the right thing, which is one of: a) get a different IMAP client If you have the choice. Which is an open question. b) get an upgrade/fix for the IMAP client so that it's no longer broken. If there is one. Which still is an open question. c) sue the vendor for selling a product under false pretenses, with the goal of achieving either a) or b) above. Do *you* do that for all the things that don't work as they should? And even if, why should you force others to behave similary? The same applies to these POS Zylex routers. There's no reason that Debian should be covering their asses when they refuse to provide firmware upgrades to their customers in a timely manner, especially when everyone else on the Internet has been ready to go with ECN for some time now. There are a *lot* of places that are not reachable. Everyone else doesn't reflect any reality. But the question is if it's worth it for Debian to keep this anal I am right position, just because of a flag, whose existence aparently doesn't hurt people who're runing 2.2.x, which is *by default* disabled upstream (take a second and ask yourself, why could this be?). What's certain is, that it's going to hurt a lot of people. Maybe a quote from the kernel docu can help: Note that, on the Internet, there are many broken firewalls which refuse connections from ECN-enabled machines, and it may be a while before these firewalls are fixed. Until then, to access a site behind such a firewall (some of which are major sites, at the time of this writing) you will have to disable this option, either by saying N now or by using the sysctl. If in doubt, say N. Obviously, Debian is not in doubt about it's own users and knows better. *t PS: Since you're Cc:ing me in addition to the list, you maybe need an extra copy as well. Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, Sep 05, 2001 at 02:37:28PM +0200, Florian Weimer wrote: Russell Coker [EMAIL PROTECTED] writes: Why should the default configuration be changed to account for the diminishing number of broken routers on the net? From a technical behavior, throwing away packets with unknown protocol flags is perfectly acceptable in any case and even reasonable in some environments. No it's not, you're violating RFC 793. -- Eric VAN BUGGENHAUT Oh My God! They killed init! You Bastards! --from a /. post \_|_/ Andago \/ \/ Av. Santa Engracia, 54 a n d a g o |--E-28010 Madrid - tfno:+34(91)2041100 /\___/\ http://www.andago.com / | \ Innovando en Internet [EMAIL PROTECTED]
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote: The question is only if devices should be programmed in order to know the future and it's potential proposed stadards by the IETF. Mind you I don't know if the devices in question (websites, routers etc. droping ECN packets) *are* violating a standard that was current at *their* time. The routers in particular I think *are* wrong, since they are making decisions based on bits that at that time were reserved. The devices in question *are* violating the standards that existed at the time they were created. The bits that they're fiddling with are *reserved*. That means don't touch. They were in violation of the TCP/IP protocol from day one, it's just that it's only now that the IETF is making use of those bits, /as is their right/, that the problem with this equipment has come to light. That's what I was saying wasn't I? You appeared to be allowing the possibility that the manufacturers of these devices were in the wrong. I am stating that it is unequivocally so. In other words, the bug is theirs. If the maintainers of the Debian packages in question choose to accomodate routers that suffer from this bug, hooray for them. If they choose not to, hooray for them -- there is no great moral imperative which requires them to go to lengths to work around the bugs of proprietary vendors. You may object that this contradicts the Social Contract, because our users should be our priority. But these routers are broken; ECN will become a standard; and the affected parties will have to replace their routers with something that works, sooner or later. Is it more to our users' advantage in the long term if we give them early warning that there is a problem, or if we choose not to 'rock the boat' until it's too late and these same users wake up one day to find themselves in a world where no operating system on the world works with their router? At least this way, users who have broken routers will find out about the problem early, can easily disable the ECN behavior if they need to, and can set about finding a solution to the real problem. In addition, ECN provides some significant advantages for users who aren't afflicted with Zylex routers. But tell me, in case there's an IMAP client that has some problems with the IMAP protocol. Should a Debian box by default *refuse* to talk to it or should the default be to try to talk to it (provided that it can)? Are you joking? If someone filed a bug against my package saying I should make changes to it to accomodate a broken client (equivalent: my IMAP server sends back a valid IMAP response and this causes the client to segfault), I would immediately close the bug with a smile and a have-a-nice-day. Good for you. And the people that *need* a working server as in it forks for *me* will move on and ignore you. That's your choice. It's the choice Debian is making now. But if care about the real world you will see that the philosophy of most software isn't I'm right have-a-nice-day but let's have something that works. Check the kernel. Check IMAP servers (that's why I was choosing this example), check well whatever, many things try to cooperate with broken stuff. I don't dispute that there are many cases where software authors are willing to accomodate broken client / server behavior, whether their goal is market share or mind share. I just disagree that authors/maintainers have any *obligation* to accomodate software or hardware which is not standards-conformant. The solutions proposed to date all seem to be either contrary to policy, or contrary to the wishes of the maintainers of the affected packages. Under such circumstances, I don't see where there's cause for questioning the maintainers' decisions. c) sue the vendor for selling a product under false pretenses, with the goal of achieving either a) or b) above. Do *you* do that for all the things that don't work as they should? Yes, quite frankly. Personally, I use only Free Software and software that runs on top of Free OSes. Professionally, I work for an ISP, and we expect our vendors to live up to the promises they make. And even if, why should you force others to behave similary? Me? I'm not forcing anyone to do anything. I'm merely pointing out that users of broken equipment do have other recourses besides expecting Debian to fix everything. Steve Langasek postmodern programmer
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Steve Langasek wrote:
Do *you* do that for all the things that don't work as they should?
Yes, quite frankly. Personally, I use only Free Software and software
that runs on top of Free OSes. Professionally, I work for an ISP, and
we expect our vendors to live up to the promises they make.
If that's the case then shouldn't we disable all those kernel
compatibility hacks by default? Don't tell me your machine is clean, and
all those components are 100% protocol compliant.
Btw. since you are connected through alternet which servers you through
*Cisco* routers:
tpo2:/home/tpo/# traceroute www.netexpress.net
traceroute to shamu.netexpress.net (206.65.64.2), 30 hops max, 40 byte
packets
[...]
12 netexpress-gw.customer.ALTER.NET (157.130.101.102) 187 ms 173 ms 187 ms
13 shamu.netexpress.net (206.65.64.2) 174 ms 189 ms 170 ms
tpo2:/home/tpo/# xprobe 157.130.101.102
[...]
FINAL:[ Cisco IOS 11.x-12.x ]
please live up to your claim and sue Cisco for their bloody CiscoPPP which
in the early days wouldn't allow you to connect a standard PPP device to
it, will you?
At least this way, users who have broken routers will find out about the
problem early, can easily disable the ECN behavior if they need to, and
can set about finding a solution to the real problem.
[...]
Professionally, I work for an ISP, and we expect
Yup. So did I. And that's why I was able to find out in the first place.
But let's see how easy that is. Please take an average Debian user. Give
it a machine that run's a 2.4 kernel behind an ECN-broken router and see
how long it takes for him to figure out what's wrong.
Or in other words, please take the same default install of Debian with a
2.4 kernel and then do this:
# find / -exec grep -i ECN \{\} \;
And tell me how many pointers to ECN you'll find. Easy?
In addition, ECN provides some significant advantages for users who aren't
afflicted with Zylex routers.
Why is it that you are mixing up Zyxel and Zylex. Let me guess: you don't
have ISDN around. Now let me tell you that possibly Zyxel is the biggest
SOHO ISDN router vendor in Europe. So what? At least it's a nice exercise
for the users isn't it? It gives them deep insight into networking. So in
the end you are doing a favour to everybody, right? Where is the
semi-professional network admin that hasn't wished his whole life through
to be able to spend two days debuging a newly arived Debian box that *as
only machine* in the whole LAN isn't able to route out?
I don't dispute that there are many cases where software authors are willing
to accomodate broken client / server behavior, whether their goal is market
share or mind share. I just disagree that authors/maintainers have any
*obligation* to accomodate software or hardware which is not
standards-conformant.
The solutions proposed to date all seem to be either contrary to policy, or
contrary to the wishes of the maintainers of the affected packages. Under
such circumstances, I don't see where there's cause for questioning the
maintainers' decisions.
You are right. A package maintainer - even if it's a fundamental package
as dpkg or the kernel or whatever can go and screw his users. It's up to
him. I wouldn't go as far as saying that this is precisely happening here,
at least not consciously because I doubt anybody who's pro ECN in the
kernel has had to debug a situtation such as described above.
But you can sure tell from my enthusiasm, and I'm no networking idiot,
that I *do* feel strong about it and that's exactly because I had fun
lately with it and I don't think it's necessary for everybody who happens
to have the bad luck to find itself in the same position to forcibly
repeat that lovely experience. And you can be certain that if the
situation stays as it is, I will not be the last one.
But tell me *one* thing:
Why is it so hard to change a few lines and have the default be
set to *off* and let whoever feels like it enable it?
?!?!
*t
Tomas Pospisek
SourcePole - Linux Open Source Solutions
http://sourcepole.ch
Elestastrasse 18, 7310 Bad Ragaz, Switzerland
Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote: at least not consciously because I doubt anybody who's pro ECN in the kernel has had to debug a situtation such as described above. Don't. You will lose. But you can sure tell from my enthusiasm, and I'm no networking idiot, that I *do* feel strong about it and that's exactly because I had fun lately with it and I don't think it's necessary for everybody who happens to have the bad luck to find itself in the same position to forcibly repeat that lovely experience. And you can be certain that if the situation stays as it is, I will not be the last one. But tell me *one* thing: Why is it so hard to change a few lines and have the default be set to *off* and let whoever feels like it enable it? Because apparently Xu feels equally strong about not allowing someone else's irresponsability (the router firmware writer's) to force him to disable something he believes is right (or force him to change the default kernel behaviour against upstream wishes, or whatever) ? I think that, had you requested this as a DOCUMENTATION patch, and also for a warning to be issued in the postinst, you'd not have met too much resistance. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: sysctl should disable ECN by default
On 05-Sep-01, 16:35 (CDT), Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote: But tell me *one* thing: Why is it so hard to change a few lines and have the default be set to *off* and let whoever feels like it enable it? Because apparently Xu feels equally strong about not allowing someone else's irresponsability (the router firmware writer's) to force him to disable something he believes is right (or force him to change the default kernel behaviour against upstream wishes, or whatever) ? 1. The default kernel behavior is that ECN is completely disabled. 2. While I happen to agree that ECN is a good thing, and that routers that screw it up *are* broken and violating old RFCs (reserved is reserved, not let's zero it out 'cause we don't know what it means), I can't help but think that if someone's first experience with Debian is that the network install fails silently because ECN is enabled and some router between him and the archive is broken then we have failed to meet our (implied?)commitment in the Social Contract. All the newbie is going to know is that it doesn't work. Boy, I'm glad we've made our political point. 3. ECN-broken routers are not equivalent to non-compliant IMAP clients. I don't know about you, but I don't have control over the path my packets take over the internet. If there's a broken router in that path, there's not a whole lot I can do about it. And for that matter, there are lots of clients and servers with code to accommodate broken-but-popular servers and clients (respectively). Steve
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote: Yes, quite frankly. Personally, I use only Free Software and software that runs on top of Free OSes. Professionally, I work for an ISP, and we expect our vendors to live up to the promises they make. If that's the case then shouldn't we disable all those kernel compatibility hacks by default? Don't tell me your machine is clean, and all those components are 100% protocol compliant. Which other kernel compatibility hacks are in place to work around buggy, non-compliant implementations of IETF standards? It's one thing to include code for compatibility with unusual BIOSes, controllers, etc., which are not expected to conform with any standards other than electrical ones. It's another thing to include code for compatibility with routers that fail to conform with open, published protocol standards that date back two decades. An Internet router that can't follow the TCP/IP spec is no Internet router at all, and vendors who sell such products under the pretense that they *are* Internet routers are legally liable in most jurisdictions. please live up to your claim and sue Cisco for their bloody CiscoPPP which in the early days wouldn't allow you to connect a standard PPP device to it, will you? Erm... why? Just because we're assertive in protecting our investments doesn't mean we're in the business of frivolously suing other companies. Most vendors we work with are also willing to work with us in order to resolve technical deficiencies in their products. On occasion, we've found vendors who were not willing to work with us; in those cases, litigation was a logical choice. We don't use 'CiscoPPP', nor have we ever been negatively affected by such a creature. Suggesting that we should sue Cisco because somebody else has been is just silly. Now let me tell you that possibly Zyxel is the biggest SOHO ISDN router vendor in Europe. So what? And they haven't provided patches for their firmware? And the ISPs that have customers using these routers haven't raised a stink about it? And the end-users who have these routers don't have class-action lawsuits as a recourse? And Debian therefore has a duty to pick up the slack on behalf of everyone else who isn't taking responsibility for the problem? Why is it that you are mixing up Zyxel and Zylex. Let me guess: you don't have ISDN around. Plenty of ISDN around -- no Zyxel. (Less and less ISDN, for that matter, which is wonderful in my opinion.) Probably no Zyxel because they're as bad at creating a device that works with US ISDN signalling standards as they are at creating a device that works with IETF standards, perhaps?[1] But you can sure tell from my enthusiasm, and I'm no networking idiot, that I *do* feel strong about it and that's exactly because I had fun lately with it and I don't think it's necessary for everybody who happens to have the bad luck to find itself in the same position to forcibly repeat that lovely experience. And you can be certain that if the situation stays as it is, I will not be the last one. And if the situation changed today, you /still/ would not be the last one, because the adoption of ECN as a standard is still moving forward. If, as your message suggests, nothing is being done on a large scale about the problems with this hardware, why would the situation be any different two years from now when these same users can get out through their router fine, but can't connect to half the websites on the planet because those websites are now using ECN? I sympathize with having to debug obscure network problems, and I agree that we should not cause our users undue hardship. But as others have suggested, it's better to deal with this by documenting the problem instead of expecting that turning ECN off will make the problem go away on its own. But tell me *one* thing: Why is it so hard to change a few lines and have the default be set to *off* and let whoever feels like it enable it? Nothing difficult about it -- but it's still the maintainer's call whether or not this should be done. There are plenty of arguments both for and against enabling ECN, and no amount of discussing them in debian-devel changes the fact that it's the maintainer's decision to make. Steve Langasek postmodern programmer [1] Don't think that I'm picking on Zyxel exclusively. There are plenty of US-made ISDN routers I would rather burn than use. Zyxel just happens to be this week's poster child for bad router vendors.
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote: But tell me, in case there's an IMAP client that has some problems with the IMAP protocol. Should a Debian box by default *refuse* to talk to it or should the default be to try to talk to it (provided that it can)? Are you joking? If someone filed a bug against my package saying I should make changes to it to accomodate a broken client (equivalent: my IMAP server sends back a valid IMAP response and this causes the client to segfault), I would immediately close the bug with a smile and a have-a-nice-day. It's funny you should bring this up because this is exactly what happened yesterday. Apparently the mail client in Mac OS X doesn't handle mailbox subscriptions and changing the mailbox root like every other IMAP client in existence can. I was requested to make a change in the uw-imapd package to accomodate this and I refused. I'll make changes that will help people with problems up to a point -- the point where it negatively impacts other users. I think most Debian developers feel the same way. Good for you. And the people that *need* a working server as in it forks for *me* will move on and ignore you. That's your choice. It's the choice Debian is making now. Well that's their choice. Sometimes you can't please everyone. In this case turning on ECN is the right thing to do. Each user has to decide whether they can deal with that or not. Debians sole responsibility is to see it is properly documented somewhere. If people don't read the documentation, we needn't waste any sympathy on them. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: sysctl should disable ECN by default
#include hallo.h Neil Spring wrote on Sat Sep 01, 2001 um 06:39:58PM: http://uwsg.iu.edu/hypermail/linux/kernel/0105.1/0145.html As David noted, I'm in favor of turning ECN off-as-default. Good. The problem - it is on by default in our precompiled kernel-image packages. To disable (by default), you have to remove ECN support from kernel or either patch the kernel to make int off-as-default (*) or put in in the template of sysctl.conf. (*) I doubt Herbert Xu would like such modifications. My point is still that it should be dirt simple to turn it on again. If you're going to quote the social contract, Okay, why not just put the line into sysctl.conf and present a big warning in the baseconfig? then you should see the logic in respecting the user's wishes, and not trying to disable what they've knowingly enabled in the kernel configuration. Look, we have in general two parts of users: - administrator kind, people that _may_ need ECN (but mostly don't though). We can expect them to RTFM and remove the hook from sysctl.conf after reading the baseconfig message. - the users - the majority. People that do as less RTFM as possible, that do not need ECN and the should not be bothered with such problems. This people would ignore the warning and have an easier life without getting in touch with sysctl.conf. Is my proposal acceptable now? Gruss/Regards, Eduard. -- Der Wahnsinn hat Methode! pgpUyKf5UtMPl.pgp Description: PGP signature
Re: sysctl should disable ECN by default
Eduard Bloch [EMAIL PROTECTED] writes: Package: procps Version: 1:2.0.7-6 Severity: wishlist Tags: woody I suggest to disable ECN¹ in the default network configuration. This should be done in Woody since we don't like our users to be confused just because of the ECN support in kernel is turned on. ¹ ECN bit causes trouble on bad configured firewalls, so the fresh installed Debian box won't be able to connect some remote hosts. Gruss/Regards, Eduard. I think that should be refiled against kernel-image-2.4.x. Those, since they have the flag enabled, should warn about it and turn it off in /etc/sysctl.conf upon first install (not on update, so you can delete the option). Or just ask via debconf. MfG Goswin
Re: sysctl should disable ECN by default
Summary:
1) why not disable ECN in kernel-image? it would be cleaner.
2) why not disable ECN in /etc/network/options? it would be
more relevant and visible than sysctl.conf.
3) can we disable ECN for joe user with the default kernel
while permitting joe custom-kernel-user to enable ECN with
one checkbox?
4) more than one place to make a configuration change
reuduces ease of use, which is what we're trying to achieve
by disabling ECN in the first place.
The Director's Cut:
Good. The problem - it is on by default in our precompiled kernel-image
packages. To disable (by default), (a) you have to remove ECN support from
kernel or (b) either patch the kernel to make int off-as-default (*) or (c)
put
in in the template of sysctl.conf.
(*) I doubt Herbert Xu would like such modifications.
(*) wha? no kernel patch is required. The default
distribution of the kernel, as distributed by Linus Himself
leaves ECN off. Somewhere, someone decided to turn it on.
Can we just choose option (a) and be done with it?
If Debian isn't going to choose option (a), why are we
talking about option (c)?
I think if Herbert believes that ECN should be enabled
in the kernel, that's an intentional statement about
his confidence in ECN. A later, standard package that
reconfigures the kernel at runtime seems inelegant when
the same configuration could easily be made just once
in the kernel config.
Okay, why not just put the line into sysctl.conf and present a big
warning in the baseconfig?
I'm sorry, I'm not familiar with what a warning in
baseconfig would mean. Would I see it once? many times?
at upgrade? only on the initial install?
Would this be printed when kernel-image is installed?
when kernel-package is run? from netbase? something at
all related to networking or the kernel?
Behind a default kernel configured with ECN disabled,
I would prefer the patch that puts this behavior in
/etc/network/options, since: 1) it's clear how to print
a message describing that ECN is disabled from there,
2) that configuration file has something to do with
networking, and 3) there's apparently a precedent with
syn_cookies configuration.
then you should see the logic in respecting the user's
wishes, and not trying to disable what they've knowingly
enabled in the kernel configuration.
Look, we have in general two parts of users:
- administrator kind, people that _may_ need ECN (but mostly don't
though). We can expect them to RTFM and remove the hook from
sysctl.conf after reading the baseconfig message.
- the users - the majority. People that do as less RTFM as possible,
that do not need ECN and the should not be bothered with such
problems. This people would ignore the warning and have an easier life
without getting in touch with sysctl.conf.
It seems our difference is that you think prioritizing
users means choosing for them, and I think prioritizing
users means respecting their (possibly incorrect, possibly
ignorant) choice. These don't necessarily conflict,
but it requires care to support both.
I don't think the dichotomy between illiterate idiots and
uber-administrators is realistic: I'm an 'administrator'
who'd rather spend time playing my guitar or doing research
than reading documentation. There are users of varying
skill levels, including those who have to recompile their
own kernel and will have the opportunity to decide in the
kernel configuration whether to enable ECN.
**When one checkbox should suffice, there should not be two.**
Is my proposal acceptable now?
Big warning + ECN disabled by default = acceptable.
Who am I to complain?
All I care about is that whatever legitimate attempts
the user makes to configure his or her system are
respected whenever possible. If a user configures
a kernel and says ECN, yes! he has a reasonable
expectation that ECN will actually be enabled. If ECN
will not be enabled, this must be clear - not hidden in
/usr/share/doc/{netbase,procps,kernel-image}, not hidden
in the gobs of messages one clicks through when installing
Debian, but shown when a custom kernel is installed or
booted. Better yet, if the user has enabled it in the
kernel, it should just stay enabled.
I realize these are hard things. I will tell a short
story to try to justify the effort. My mother uses a
windows machine, and wanted to configure her printer to
print 360dpi instead of 180dpi. She found that to do this,
she would have to enter the printer options dialog every
time she wanted to print. From within an application,
the configuration is not saved; not even for future
use by that application. Only if you enter the identical
printer options dialog from the control panel are settings
saved permanently. She has every legitimate reason to
believe that the choice made in the options dialog from
an application would be as permanent as from the control
panel, but it is not. Let's not make it as difficult to
configure a Debian system.
This discussion presumes
Re: sysctl should disable ECN by default
Goswin Brederlow [EMAIL PROTECTED] wrote:
I think that should be refiled against kernel-image-2.4.x. Those,
since they have the flag enabled, should warn about it and turn it off
in /etc/sysctl.conf upon first install (not on update, so you can
delete the option).
Or just ask via debconf.
For those that weren't around here the first time this was discussed,
and are too lazy to read the archives:
1. CONFIG_INET_ECN must be turned on, otherwise the user will have to
recompile the kernel to use it.
2. The kernel will not be patched to disable it by default with INET_ECN
compiled in as the same thing can be easily achieved from user space.
3. The kernel-image postinst is not a good place to do this as installing
a kernel does not mean that you will boot it.
So do whatever you want, but please do it in the right place.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: sysctl should disable ECN by default
On Mon, 3 Sep 2001, Herbert Xu wrote: 3. The kernel-image postinst is not a good place to do this as installing a kernel does not mean that you will boot it. the postinst would be the worst place, as you can't be using that kernel already at the moment postinst is ran for the first time... -- wouter dot verhelst at advalvas dot be Human knowledge belongs to the world -- from the movie Antitrust
Re: sysctl should disable ECN by default
#include hallo.h
Neil Spring wrote on Sun Sep 02, 2001 um 02:05:57PM:
Summary:
1) why not disable ECN in kernel-image? it would be cleaner.
See mail from Herbert.
2) why not disable ECN in /etc/network/options? it would be
more relevant and visible than sysctl.conf.
Another good idea.
(*) wha? no kernel patch is required. The default
Not really true.
distribution of the kernel, as distributed by Linus Himself
leaves ECN off. Somewhere, someone decided to turn it on.
while(discussion_turns_in_circle) {
- If ECN support is compiled, it is turned on by default.
- If we wish to have support for it, we have to enable it.
- When we enable it, it will be enabled by default.
}
Can we just choose option (a) and be done with it?
If Debian isn't going to choose option (a), why are we
talking about option (c)?
See Herbert's mail. IMHO we need a good place to disable it and notify
the user.
I think if Herbert believes that ECN should be enabled
in the kernel, that's an intentional statement about
his confidence in ECN. A later, standard package that
reconfigures the kernel at runtime seems inelegant when
the same configuration could easily be made just once
in the kernel config.
All this is said before. I oppose strongly the use of such experimental
features in precompiled kernel images. If the are used, than not turned
on by default. If the kernel patching is not acceptable, we need a
runtime-solution to disable it, I don't see any other ways.
Okay, why not just put the line into sysctl.conf and present a big
warning in the baseconfig?
I'm sorry, I'm not familiar with what a warning in
baseconfig would mean. Would I see it once? many times?
at upgrade? only on the initial install?
A good question. Theoreticaly first time when a 2.4.x kernel-image is
installed. A hook in the kernel's postinst is ugly, but doable.
Would this be printed when kernel-image is installed?
when kernel-package is run? from netbase? something at
all related to networking or the kernel?
On architectures with 2.4.x default kernel from baseconfig or so, on
architectures with 2.2.x kernel in the postinst of the kernel-image.
Behind a default kernel configured with ECN disabled,
I would prefer the patch that puts this behavior in
/etc/network/options, since: 1) it's clear how to print
Why not...
Is my proposal acceptable now?
Big warning + ECN disabled by default = acceptable.
Who am I to complain?
[ shorted director's cut, thanks for contribution ;) ]
Gruss/Regards,
Eduard.
--
Definition of Windows 9x:
A 32 bit upgrade to a 16 bit extensions for an 8 bit operating system
designed to run on a 4 bit processor by a 2 bit company that doesn´t
like 1 bit of competition.
Re: sysctl should disable ECN by default
Zitiere Eduard Bloch [EMAIL PROTECTED]: Can we just choose option (a) and be done with it? If Debian isn't going to choose option (a), why are we talking about option (c)? See Herbert's mail. IMHO we need a good place to disable it and notify the user. Since the beginning of this discussion the solution is there, available, and has been presented here. I just need to find the time to ask for inclusion. Or if someone wants to do that for me please go for it. *Please* check: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862msg=4repeatmerged=yes *t
Re: sysctl should disable ECN by default
On Sun, Sep 02, 2001 at 05:56:45PM +0200, Goswin Brederlow wrote: I think that should be refiled against kernel-image-2.4.x. Those, since they have the flag enabled, should warn about it and turn it off in /etc/sysctl.conf upon first install (not on update, so you can delete the option). Or just ask via debconf. no package is permitted to modify /etc/sysctl.conf. its a conffile belonging to procps, anything (except the admin) modifying it should receive a severity serious bug report. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpNGXvwRWTuS.pgp Description: PGP signature
Re: sysctl should disable ECN by default
(*) wha? no kernel patch is required. The default Not really true. After reading Herbert's mail, I understand what you were trying to do now with the patch. Thanks for explaining the baseconfig / postinst issues. What a mess. -neil
Re: sysctl should disable ECN by default
On Mon, Sep 03, 2001 at 07:44:19AM +1000, Herbert Xu wrote: 1. CONFIG_INET_ECN must be turned on, otherwise the user will have to recompile the kernel to use it. yes, that is correct. if the user wants ECN, they should compile the kernel to enable it. [...] So do whatever you want, but please do it in the right place. which is in the kernel-image .config file. 1. stock kernel-images should only include options which are necessary for booting installing debian 2. they should not include non-essential experimental features. ECN fails on both counts. ECN is a good thing, and widespread adoption of it should be encouraged - BUT enabling it should require an informed act by the user since it is likely to result in network outages at the moment. craig -- craig sanders [EMAIL PROTECTED] Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Bug#110875: sysctl should disable ECN by default
On Sat, Sep 01, 2001 at 04:04:12PM +0200, Eduard Bloch wrote: I suggest to disable ECN? in the default network configuration. This should be done in Woody since we don't like our users to be confused just because of the ECN support in kernel is turned on. This would be an abuse of the procps package and would only work on systems that are installing procps for the first time, which is a very small minority of machines. If ECN causes so much problems, then dont enable it in the default kernel. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/[EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED]
Re: sysctl should disable ECN by default
On Sun, Sep 02, 2001 at 02:17:43AM +0200, Eduard Bloch wrote: #include hallo.h Neil Spring wrote on Sat Sep 01, 2001 um 04:39:30PM: Blaming ECN for faulty IP implementations is wrong. Come back to reality please. Or stay in your dream and (for example) and remove all workarounds in the kernel, assuming all chipsets and implementations to be bug-free. Your words can be translated to People, trow away your notebooks, motherboards, hard disks, and buy newer ones. Then you have a faulty translator. What he said was that it's not fair to blame ECN for the problems and that implemenators had plenty of warning that that bit might need to be used. He did not say that ECN should be turned on by default. Your words can be translated (very liberally) as We should never improve anything; even backward compatible extensions will break something, and so should be shunned. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg
Re: sysctl should disable ECN by default
IP is a very old standard. I don't assume that all chipsets are bug free, nor do I assume that all IP implementations are bug free. I'm going to place blame where it belongs, and be honest about whose bug this is. This is not a problem with two year old equipment. It is not the case that all IP routers made before 1999 will discard ECN traffic. Only those that reach into your TCP header and fuss with the bits will do so. So I am suggesting that you throw out your two year old zyxel piece of crap router if you have one, or pester their support people for the software patch, and follow Jamal's call for volunteers as descibed on linux-kernel at: http://uwsg.iu.edu/hypermail/linux/kernel/0105.1/0145.html As David noted, I'm in favor of turning ECN off-as-default. My point is still that it should be dirt simple to turn it on again. If you're going to quote the social contract, then you should see the logic in respecting the user's wishes, and not trying to disable what they've knowingly enabled in the kernel configuration. -neil On Sat, Sep 01, 2001 at 07:54:06PM -0500, David Starner wrote: On Sun, Sep 02, 2001 at 02:17:43AM +0200, Eduard Bloch wrote: #include hallo.h Neil Spring wrote on Sat Sep 01, 2001 um 04:39:30PM: Blaming ECN for faulty IP implementations is wrong. Come back to reality please. Or stay in your dream and (for example) and remove all workarounds in the kernel, assuming all chipsets and implementations to be bug-free. Your words can be translated to People, trow away your notebooks, motherboards, hard disks, and buy newer ones. Then you have a faulty translator. What he said was that it's not fair to blame ECN for the problems and that implemenators had plenty of warning that that bit might need to be used. He did not say that ECN should be turned on by default. Your words can be translated (very liberally) as We should never improve anything; even backward compatible extensions will break something, and so should be shunned. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
