Re: reopening ECN bugreport/netbase

[Craig Sanders]

On Thu, Sep 06, 2001 at 01:37:02AM -0500, Scott Dier wrote:
> * Craig Sanders <[EMAIL PROTECTED]> [010905 20:17]:
> > the correct solution is to NOT compile ECN support into the distribution
> > kernels. that's a choice that should be left up to the individual system
> 
> So, lets fix one problem by creating another problem!  ECN isn't there
> anymore!

no, that isn't a problem. the kernel works just fine without ECN being
enabled.

if you want it, you do what every other user of the linux kernel has to do
and compile a new kernel with support for it.

quite frankly, if someone doesn't know how to compile a kernel then
they're not qualified to decide whether they want to use it or not. in
that case, the correct course of action for a package maintainer is to
cause the least harm.

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. 

anyone who is running servers busy enough that they actually need ECN
should have enough of a clue to know how to compile a kernel and enable
it.

> What if some users were actually using that?

see above.

since it's only been enabled in recent kernel-image packages, very few
(if any) people will be be surprised by it being removed again.


> ECN IS NOT A USELESS RFC. ECN IS NOT A USELESS RFC.

of course it's not.  it will eventually be universal.


> some people actually like to use this stuff.

yes, i know.  i use it.

however, it's an experimental feature which isn't needed on the debian 
distributed kernel images.

it might be appropriate to have it on by default in a year or so. but
not now.

craig

ps: why is it that so many people get so upset if their pet
feature-of-the-month isn't the default in debian? debian's defaults
should conform to the principles of Least Suprise and Least Harm, not
the principle of Maximal GeeWhizzery.

it's only a default, get over it.

-- 
craig sanders <[EMAIL PROTECTED]>

Fabricati Diem, PVNC.
 -- motto of the Ankh-Morpork City Watch

Re: reopening ECN bugreport/netbase

[tpo2]

Thanks for caring Anthony!

Zitiere Anthony Towns :

> 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. We've currently had what options?
> 
>  1) Disable ECN in the kernel, and let people who want it recompile
> the kernel by hand. Pros: doesn't hurt anyone, follows the upstream
> kernel defaults.  Cons: makes it hard for people to enable, which
> in the long term damages the Internet's resiliance to DoS attacks.
> 
>  2) Leave ECN in the kernel, but disable it externally by default.
> Pros:
doesn't hurt anyone, makes it easy to change. Cons: requires
> kludging
around in other packages (boot-floppies and procps/netbase)

Cons for procps: solving it here is a techincally bad choice, since
it would require procps to decide to assign the flag based on available kernel 
options. Which is doable for this specific problem but is not a
general solution for similar problems.

Pros netbase: The message "ECN disabled: use /etc/network/options to enable"
keeps reminding the user which rises the probability that s/he will enable it 
later and so serve the purpose of ECN in the first place.

>  3) Leave ECN in the kernel, enabled by default. Pros: easy to setup,
> easy
to change after the fact. Cons: neophytes can easily be confused
> when
random sites start not working unpredictably from Debian machines
> but work fine elsewhere.

Cons: if upstream doesn't accept the changed default and include it, there
forever be a fork between Debian an the main kernel. Changing the default
upstream will cause a lot of trouble there which makes it not very probable.
IMO this would be the cleanest solution though.

> 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.
> 
> There might be other options too.

Both 1) and 3) would require action from the kernel-image maintainer, which
requires someone else than me talking to him since he's either not seeing
ECN as his problem at all:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862&msg=8

or just ignoring my reports:

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=110862&msg=14

*t

Re: reopening ECN bugreport/netbase

[Neil T. Spring]

> 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

Re: reopening ECN bugreport/netbase

[David Starner]

On Thu, Sep 06, 2001 at 01:37:02AM -0500, Scott Dier wrote:
> So, lets fix one problem by creating another problem!  ECN isn't there
> anymore!

So? Neither is a lot of options. You can recompile a kernel just
as well as anyone else.
 
-- 
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: reopening ECN bugreport/netbase

[Scott Dier]

* Craig Sanders <[EMAIL PROTECTED]> [010905 20:17]:
> the correct solution is to NOT compile ECN support into the distribution
> kernels. that's a choice that should be left up to the individual system

So, lets fix one problem by creating another problem!  ECN isn't there
anymore!

What if some users were actually using that?

ECN IS NOT A USELESS RFC. ECN IS NOT A USELESS RFC.

some people actually like to use this stuff.

-- 
Scott Dier <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://www.ringworld.org/  [EMAIL PROTECTED]

Re: reopening ECN bugreport/netbase

[Anthony Towns]

On Wed, Sep 05, 2001 at 06:30:27PM -0700, Neil T. Spring wrote:
> 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.

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. We've currently had what options?

 1) Disable ECN in the kernel, and let people who want it recompile
the kernel by hand. Pros: doesn't hurt anyone, follows the upstream
kernel defaults.  Cons: makes it hard for people to enable, which
in the long term damages the Internet's resiliance to DoS attacks.

 2) Leave ECN in the kernel, but disable it externally by default. Pros:
doesn't hurt anyone, makes it easy to change. Cons: requires kludging
around in other packages (boot-floppies and procps/netbase)

 3) Leave ECN in the kernel, enabled by default. Pros: easy to setup, easy
to change after the fact. Cons: neophytes can easily be confused when
random sites start not working unpredictably from Debian machines
but work fine elsewhere.

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.

There might be other options too.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpqN9PKX5BBJ.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Neil T. Spring]

> 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

[Craig Sanders]

On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote:

>   if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
>   then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
>   fi
> 
> to the kernel-image-2.4.x postinst.

no, this is broken and evil. kernel-image packages should NOT override
someone who chooses to have ECN enabled.

the problem is that recent kernel-images have ECN support compiled in.

they shouldn't.

the correct solution is to NOT compile ECN support into the distribution
kernels. that's a choice that should be left up to the individual system
admin - if they want it, they can compile a kernel to support it.


craig

-- 
craig sanders <[EMAIL PROTECTED]>

Fabricati Diem, PVNC.
 -- motto of the Ankh-Morpork City Watch

Re: reopening ECN bugreport/netbase

[Steve Greenland]

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


> 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.

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

a) find out who is responsible for an arbitrary router.
b) find out how to contact said person.
c) find out how far you get when you, internet newbie, try to tell them
their equipment is broken.

It's simply not a realistic answer for most people (i.e. those without
existing contacts or a sufficiently high position/reputation.)

Steve

Re: reopening ECN bugreport/netbase

[Adam McKenna]

On Wed, Sep 05, 2001 at 03:19:01PM -0800, Ethan Benson wrote:
> On Wed, Sep 05, 2001 at 06:02:10PM +0200, T.Pospisek's MailLists wrote:
> > So since netbase does not want to be the proper place, a better
> > fix/workaround (I'm sincerely trying hard not to be ironic!) would be to
> > use debconf with a default value of "0" and to inform/ask the user about
> > it when installing a new kernel.
> 
> and store/implement it where?  /etc/sysctl.conf is unacceptable as its
> a conffile belonging to procps.
> 
> and personally i don't want /etc/sysctl.conf to become another debconf
> [mis]managed config file.

I agree -- sysctl.conf should never be touched by the distribution -- it is
for local settings, specific to each machine, and there should never be a
chance that it could possibly be overwritten automatically, as that could
result in major breakage on some systems.

--Adam

-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>

Re: reopening ECN bugreport/netbase

[Ethan Benson]

On Wed, Sep 05, 2001 at 06:02:10PM +0200, T.Pospisek's MailLists wrote:
> So since netbase does not want to be the proper place, a better
> fix/workaround (I'm sincerely trying hard not to be ironic!) would be to
> use debconf with a default value of "0" and to inform/ask the user about
> it when installing a new kernel.

and store/implement it where?  /etc/sysctl.conf is unacceptable as its
a conffile belonging to procps.

and personally i don't want /etc/sysctl.conf to become another debconf
[mis]managed config file.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpWnoX2DI0RN.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Neil T. Spring]

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

[Ethan Benson]

On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote:
> 
> ) then it's the kernel-image package that needs to make sure it's runing
> in a sane environment. So *please* can we add something like:
> 
>   if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
>   then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
>   fi
> 
> to the kernel-image-2.4.x postinst.

no you cannot.  that is a policy violation and will get a severity
serious bug report to have it removed if its ever added.

/etc/sysctl.conf is a conffile belonging to procps NO package may
modify it in maintainer scripts.  since sysctl will produce errors at
boot if this is added to the default sysctl.conf that is not
acceptable either.  

furthermore if you simply installed a 2.4 kernel but decided not to
boot it, or decided to go back to 2.2 you start getting errors at boot
again. 

since aj won't add anything to netbase the admin will simply have to
turn off ecn themselves. thats the only option.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgprCsGk5u9zP.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Remco van de Meent]

T.Pospisek's MailLists 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:

[...]

Well let's use the Linux kernel's description to start with:

CONFIG_INET_ECN
  Explicit Congestion Notification (ECN) allows routers to notify
  clients about network congestion, resulting in fewer dropped packets
  and increased network performance. This option adds ECN support to
  the Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn)
  which allows ECN support to be disabled at runtime.

  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.

One of the strong points of Debian is that it leaves the user in
control of his system. That's the main reason I'm suggesting to leave
the decision whether or not to use ECN up to the user. 

> 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"?

I'm not familiar with bootfloppies internals. Is it possible to disable
ECN during initialization using sysctl in some way? It probably is...
just to be safe.

> 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?

It's just my opinion, but I feel that this is more conservative than we
necessarely have to be. Promoting superior technologies, when
available, is not helped with a conservative default, I think.

But then again, I can live with such a message, that's for sure ;-)

Re: reopening ECN bugreport/netbase

[T.Pospisek's MailLists]

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

Re: reopening ECN bugreport/netbase

[Remco van de Meent]

Eric Van Buggenhaut wrote:
> Routers aren't forced to support ECN (although it's in their
> interest) but they aren't allowed to drop ECN-flagged TCP packets.
> 
> If you can't access a site, *they* need to fix their buggy router to be
> ECN-tolerant. If they don't do so, they're violating RFC 793.
> 
> http://www.ietf.org/rfc/rfc793.txt?number=793

I wonder how an _IP_ layer protocol can break a _transport_ (TCP) layer
specification. Also, it is up to a router whether or not to drop
packets based on their contents. It's not something you can enforce.

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.


regards,
Remco.

Re: reopening ECN bugreport/netbase

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Eric Van Buggenhaut wrote:

> Routers aren't forced to support ECN (although it's in their interest) but 
> they
> aren't allowed to drop ECN-flagged TCP packets.
>
> If you can't access a site, *they* need to fix their buggy router to be
> ECN-tolerant. If they don't do so, they're violating RFC 793.

Well possibly you can just send a site that doesn't support ECN to where
the light don't shine.

But if *your* (as in your universities, your lan's, your workplace,
your client's etc.) router is broken then what?

Then you can not ignore it. But they can ignore *you*!

And there is equipment that *can not* be fixed (check the thread why not).

And so what do you expect a user (possibly a newby!!! mind you, there are
newbies that start with Debian) with a 2.4 Debian kernel to do? To start
debuging the network to find out what the hell is wrong? To look around
and think gee, all the machines around me are working *only mine* not.

What would *you* think at that moment? I would maybe think that the
networking card is broken. So you are telling me you want to send
(your!) Debian users runing around expecting them to go debug whatever
place they might find themselves at that moment?

Or do you expect to change the world to change at your will just because
Debian has decided to set a flag which is *off* by default?

*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: reopening ECN bugreport/netbase

[Peter S Galbraith]

I, for one, am very thankful for this thread.  I could no longer
connect to some sites which I used in daily work collaborations
for some time now.  Turns out it's since an upgrade from 2.2 to
2.4.  I have now disabled this option in the 2.4 kernel and now
connect again.

Thanks!

(Yes, it's info that users should be made aware of)

Peter

Re: reopening ECN bugreport/netbase

[Eric Van Buggenhaut]

On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote:
> On Wed, 5 Sep 2001, Anthony Towns wrote:
> 
> > severity 110892 wishlist
> > thanks
> >
> > On Wed, Sep 05, 2001 at 02:42:23PM +0200, Tomas Pospisek wrote:
> > > # On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
> > > # > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
> > > # > > I don't know if this is the right place to assign the bug.
> >
> > It's not a bug at all really, and it's certainly not a "critical" one.
> 
> >From the docu:
> 
> critical   makes unrelated software on the system (or the whole system)
>break, [...]
> 
> This is *exacly* what happens after an update from a vanilla 2.2.x kernel
> to a 2.4. Some sites plain disapear from the internet, which is not a
> catastrophy. What's worse is that with some routers you will *completely*
> loose TCP network connectivity. If you happen to be using your box as a
> firewall it's the whole LAN that'll be dropped.
> 
> How does this differ from the phrasing ".. or the whole system) break"?
> Does there need some physical violence be involved to fullfill the
> requirements for a critical bugreport?
> 
> > If
> > you happen not to like ECN on your systems add "sys/net/ipv4/tcp_ecn=0"
> > to /etc/sysctl.conf (which is a much better place for such things than
> > /etc/network/options) and be done with it.
> 
> I couldn't care less about ECN or whatever acronym. The problem is that
> "the whole system) break"s. That's a problem. And this will happen at
> every single site that f.ex. is using an mildly old Zyxel router.

Routers aren't forced to support ECN (although it's in their interest) but they
aren't allowed to drop ECN-flagged TCP packets.

If you can't access a site, *they* need to fix their buggy router to be
ECN-tolerant. If they don't do so, they're violating RFC 793.

http://www.ietf.org/rfc/rfc793.txt?number=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: reopening ECN bugreport/netbase

[Tomas Pospisek]

On Wed, 5 Sep 2001, Scott Dier wrote:

> working fine.  The really broken part is firewalls and tcp/ip stacks on
> the internet that do things to TCP that they shouldn't and break your
> experience.
>
> Go bugreport those instead.

Never mind the users: they will be happy to spend two days debuging the
network to find out that "Ahhh, Debian is defending the flag of the true
IP compliance", where as *all* the other box he knows just work.

And yes, Debian can be proud to be right.
*t

---
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: reopening ECN bugreport/netbase

[T.Pospisek's MailLists]

On Wed, 5 Sep 2001, Tomas Pospisek wrote:

> So *please* can we add something like:
>
>   if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
>   then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
>   fi
>
> to the kernel-image-2.4.x postinst.

Which of course will set up people who are stil runing potato, have a 2.4
kernel and *do* want/need ECN, since it will *silently* disable ECN.

So since netbase does not want to be the proper place, a better
fix/workaround (I'm sincerely trying hard not to be ironic!) would be to
use debconf with a default value of "0" and to inform/ask the user about
it when installing a new kernel.

*t


 Tomas Pospisek
 SourcePole   -  Linux & Open Source Solutions
 http://sourcepole.ch
 Elestastrasse 18, 7310 Bad Ragaz, Switzerland
 Tel: +41 (81) 330 77 11

Re: reopening ECN bugreport/netbase

[Scott Dier]

> critical   makes unrelated software on the system (or the whole system)
>break, [...]

The user experience is broken, not the software.  The software is
working fine.  The really broken part is firewalls and tcp/ip stacks on
the internet that do things to TCP that they shouldn't and break your
experience.

Go bugreport those instead.

-- 
Scott Dier <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://www.ringworld.org/  [EMAIL PROTECTED]

Re: reopening ECN bugreport/netbase

[Branden Robinson]

On Wed, Sep 05, 2001 at 04:32:42PM +0200, Tomas Pospisek wrote:
> >From the docu:
> 
> critical   makes unrelated software on the system (or the whole system)
>break, [...]
> 
> This is *exacly* what happens after an update from a vanilla 2.2.x kernel
> to a 2.4. Some sites plain disapear from the internet, which is not a
> catastrophy.

PUT THE CRACK PIPE *DOWN*.

-- 
G. Branden Robinson| Suffer before God and ye shall be
Debian GNU/Linux   | redeemed.  God loves us, so He
[EMAIL PROTECTED] | makes us suffer Christianity.
http://people.debian.org/~branden/ | -- Aaron Dunsmore


pgpSvcK8mo3Dw.pgp
Description: PGP signature

Re: reopening ECN bugreport/netbase

[Tollef Fog Heen]

* Tomas Pospisek 

| ) then it's the kernel-image package that needs to make sure it's runing
| in a sane environment. So *please* can we add something like:
| 
|   if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
|   then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
|   fi
| 
| to the kernel-image-2.4.x postinst.

This is not allowed.  /etc/sysctl.conf is a conffile and a package
must not modify other packages' conffiles.

And the reason why this breaks with Zyxel routers is that the routers
are broken.  Reassign the bugs against zyxel or something. ;)

-- 

Tollef Fog Heen
You Can't Win

Re: reopening ECN bugreport/netbase

[Tomas Pospisek]

On Wed, 5 Sep 2001, Anthony Towns wrote:

> severity 110892 wishlist
> thanks
>
> On Wed, Sep 05, 2001 at 02:42:23PM +0200, Tomas Pospisek wrote:
> > # On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
> > # > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
> > # > > I don't know if this is the right place to assign the bug.
>
> It's not a bug at all really, and it's certainly not a "critical" one.

>From the docu:

critical   makes unrelated software on the system (or the whole system)
   break, [...]

This is *exacly* what happens after an update from a vanilla 2.2.x kernel
to a 2.4. Some sites plain disapear from the internet, which is not a
catastrophy. What's worse is that with some routers you will *completely*
loose TCP network connectivity. If you happen to be using your box as a
firewall it's the whole LAN that'll be dropped.

How does this differ from the phrasing ".. or the whole system) break"?
Does there need some physical violence be involved to fullfill the
requirements for a critical bugreport?

> If
> you happen not to like ECN on your systems add "sys/net/ipv4/tcp_ecn=0"
> to /etc/sysctl.conf (which is a much better place for such things than
> /etc/network/options) and be done with it.

I couldn't care less about ECN or whatever acronym. The problem is that
"the whole system) break"s. That's a problem. And this will happen at
every single site that f.ex. is using an mildly old Zyxel router.

> AFAIC, the default settings'll remain exactly as they are in the kernel.

There's a problem and no one feels responsible. Well, so I reiterate from
the begining. If netbase is not responsible and that setting has to be
set through /etc/sysctl.conf and since the procps package is not supposed
to know what possible kernel-feature-configuration combinations are
possible/allowed (check this output:

error: '/proc/sys/net/ipv4/tcp_ecn' is an unknown key
(when starting from a 2.2.x kernel)

) then it's the kernel-image package that needs to make sure it's runing
in a sane environment. So *please* can we add something like:

if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null;
then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf
fi

to the kernel-image-2.4.x postinst.

*t

---
 Tomas Pospisek
 sourcepole-   Linux & Open Source Solutions
 http://sourcepole.com
 Elestastrasse 18,  7310 Bad Ragaz,  Switzerland
 Tel:+41 (81) 330 77 13,  Fax:+41 (81) 330 77 12

Re: reopening ECN bugreport/netbase

[Anthony Towns]

severity 110892 wishlist
thanks

On Wed, Sep 05, 2001 at 02:42:23PM +0200, Tomas Pospisek wrote:
> # On Sun, 2 Sep 2001 06:31:19 +1000, Herbert Xu wrote:
> # > On Sat, Sep 01, 2001 at 12:33:35PM +0200, Tomas Pospisek wrote:
> # > > I don't know if this is the right place to assign the bug. 

It's not a bug at all really, and it's certainly not a "critical" one. If
you happen not to like ECN on your systems add "sys/net/ipv4/tcp_ecn=0"
to /etc/sysctl.conf (which is a much better place for such things than
/etc/network/options) and be done with it. AFAIC, the default settings'll
remain exactly as they are in the kernel.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpAOsq3spfIm.pgp
Description: PGP signature