Re: reopening ECN bugreport/netbase
Wow. Somebody makes a one line suggestion (which seems like a good idea) and you twist it into: 1. An incorrect statement. "ecn is a routing protocol." rotfl. Find a computer science textbook before you post to the list again. 2. A configuration option, when you know concensus on this list is that there will be none; and that the default will be on. 3. A statement that blames ECN, when the broken equipement is your moronic Zyxel router. The idiot user you're designing the message for is just as likely to think that ECN will cause his modem to explode. C'mon. If you want a message, start with Documentation/Configure.help. If you really want to help, pick a fight you stand a chance of winning and suggest places for messages and documentation. Debian users who have broken equipment will just have to be clueful enough to disable ECN if they find that their router violates RFC 791. Help them have a clue. -neil On Wed, Sep 05, 2001 at 11:14:47PM +0200, T.Pospisek's MailLists wrote: > On Wed, 5 Sep 2001, Remco van de Meent wrote: > > > But anyway - I agree that Debian should not be too conservative with > > regard to new networking technologies, so disabling ECN by default is > > not something I'd like to see happen. Give the user some short > > explanation and let him make the decision himself, I'd say. > > OK. How exactly should this be worded: > > "ECN is a routing protocol. Some equipment doesn't support ECN > yet. Switching it on can break your networking and it will make some > internet sites unreachable. If you want to disable ECN then select "No". > > Do you want to enable ECN: "Yes" "No"" > > And the default will be on "Yes". Would you say "Yes"? Or how exaclty do > you want to phrase this to let the user make an informed decison? > > Moreover, what about bootfloppies. In case there will be bootfloppies, do > you want to bother the user with such questions? Or do you want to > have two versions of the kernel - one for the bootfloppies and one for > the "maintree"? > > And what is *exactly* the problem of displaying: > > "ECN Disabled - Edit /etc/network/options to enable it" > > in the bootmessages and let the user switch it on if he wants? > *t > > > Tomas Pospisek >SourcePole - Linux & Open Source Solutions >http://sourcepole.ch >Elestastrasse 18, 7310 Bad Ragaz, Switzerland >Tel: +41 (81) 330 77 11 > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reopening ECN bugreport/netbase
> On 05-Sep-01, 18:14 (CDT), "Neil T. Spring" <[EMAIL PROTECTED]> wrote: > > 2. A configuration option, when you know concensus on this > > list is that there will be none; and that the default will > > be on. > No, I don't think that's the concensus. I agree that the kernel package > can't change another packages conffile, but that doesn't mean the issue > cannot be worked around Fair enough. perhaps I was expressing my expectation that if we asked Herbert, Craig, and Anthony, none of them would add a configuration option. Certainly not Herbert or Craig (irrelevant to kernel-package and procps). My point is: the maintainers have spoken. If we're going to make progress in helping users behind broken equipment, we're going to have to find another way that doesn't offend Herbert, Craig, and Anthony's sense of idealism. > The problem is not Debian user's with broken equipment. The problem is > that if any router between them and the target system is broken, they > get screwed. What do you suggest they do? And before you say "contack the > admin of the broken router", I suggest you try to No. Arbitrary routers along the packet's path are not the problem. See http://gtf.org/garzik/ecn/ Real routers in the middle of the network don't have time to screw with the payload of an IP packet. We're talking zealous firewalls, unpatched cisco local director, and the Zyxel "router that zeroes TCP bits". At the end hosts, we're talking about what nmap thinks are old AIX and IRIX. > a) find out who is responsible for an arbitrary router. This is easy, as above; it's either your zyxel or the server's cisco redirector, firewall, or operating system. > b) find out how to contact said person. Since (a) is easy, (b) is fairly easy. webmaster@, root@, [EMAIL PROTECTED] > c) find out how far you get when you, internet newbie, try to tell them > their equipment is broken. (c) will be easy when corporate web servers that want to sell you something realize that they're turning away connections that might represent business. I don't see what's so hard about a user writing [EMAIL PROTECTED]: Hi, I tried to access your webserver today and it said connection timed out. I can connect to yahoo just fine. Is it because I'm using konqueror? Please let me know when your web server is back up. > It's simply not a realistic answer for most people (i.e. those without I do not presume to say what most people would be capable of doing. It was your suggestion, not mine, that joe user "contack the admin". If they feel sufficiently capable, great, everyone should at least try to submit bug reports. If you feel it is your responsibility to make the world safe for these users, I suggest you take it upon yourself to write the admins of webservers that don't respond to ECN negotiating SYN packets as listed at: http://www.aciri.org/tbit/ecn_test3A.html (some of these may have been fixed since April) -neil
Re: reopening ECN bugreport/netbase
> Another option, which would require a minor patch to the kernel, would be > to have ECN default to disabled even when compiled into the kernel (and > thus require an explit 'echo 1 >/proc/sys/net/ipv4/tcp_ecn' to enable). > This'd be analagous to the current behaviour with IP forwarding. Eduard Bloch suggested this on 9/2, though it took me a while to understand what he meant: 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. And Herbert replied on 9/3: 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. It could be a nice solution that would satisfy my insane desire that enabling ECN should be a one-step process - either in kernel configuration or by manually editing sysctl.conf. -neil
