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.
* 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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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)
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
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
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
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
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
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
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
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?
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
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?
#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
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
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
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.
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...
--
#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.
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
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).
(*) 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
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
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
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
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
46 matches
Mail list logo
