"Adam J. Richter" [EMAIL PROTECTED] writes:
I am surprised that anyone is seriously considering denying
service to sites that do not implement an _experimental_ facility
and have firewalls that try to play things safe by dropping packets
which have 1's in bit positions that in the RFC
[EMAIL PROTECTED] (Rogier Wolff) writes:
If the firewall operator is sufficiently paranoid, they can say: "We
don't trust the ECN implementation on our hosts behind the firewall,
so we want to disable it.".
In which case would the "correct" action not be to zero the ECN bits
of packets
Matti Aarnio [EMAIL PROTECTED] writes:
... and immediately I have been able to verify a bunch of
domains/servers which won't get thru when incoming connection
has ECN.
As a matter of interest, are you also noting how many actually
negotiate ECN rather than simply responding with a plain SYN
David Ford [EMAIL PROTECTED] writes:
There are a -lot- of large sites that give us issues like this.
What is the best way to handle sites which block connections using
ECN? Is it best for everyone who detects this to write individually to
each site which they find can be accessed with "echo 0
"David S. Miller" [EMAIL PROTECTED] writes:
The authors of rfc793 probably, in all honesty, really meant
"must be set to zero by current implementations".
I agree, to me it seems obvious that the reason is so that these bits
could be used at some time in the future for some, then unknown,
Using net-tools 1.57 (which I think is the latest) and kernel
2.4.0-test7/8 (I think it was OK with -test6) 'netstat -s' displays
the message "error parsing /proc/net/snmp: Success" rather than
displaying the counters.
I notice that kernel/Documentation/Changes no longer lists the version
of
i810_rng.c does not compile when not a module. It fails at line 384,
which looks as though it should only be included when being built as a
module.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
"Mohammad A. Haque" [EMAIL PROTECTED] writes:
making a patch means you've modfied the source which you are not allowed
to do. The most you can do is report the bug through normal channels
(you dont even have priority in reporting bugs since you have the code).
Does making a patch necessarily
Peter Samuelson [EMAIL PROTECTED] writes:
[Andrew Stubbs]
Has anyone implemented a /proc device or user program to interrogate
the enviromental attirbutes (temp, voltage etc) that many
motherboards provide via their bios's ?
Do a search on 'lm_sensors'.
Does this work with the latest
Byron Stanoszek [EMAIL PROTECTED] writes:
I narrowed the problem down to a subset of patches from the MM set in
test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for
i386), but I'm not yet sure why. test13-pre2 and up work without any problems
on an Intel cpu
Keith Owens [EMAIL PROTECTED] writes:
Boot the kdb enhanced kernel and cat /proc/interrupts to see if NMI is
non-zero.
NMI is zero, so that did not help.
However, I think I have solved the problem. During boot, I saw a
message about ACPI failing to initialise so I removed ACPI from the
Mohammad A. Haque [EMAIL PROTECTED] writes:
Traceroute is working fine here. You sure you didn't inadvertantly turn
on ECN w/o knowing it?
Will ECN have any effect on Traceroute? Does ECN not only affect TCP
connections?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Jim Roland [EMAIL PROTECTED] writes:
What some people don't realize is that Microsoft *DID* do Unix a long time
ago, they were even into OS/2 Development. :-)
And they annoyed not just a few application vendors when just a few
months after giving the message Go with OS/2, it is the way
Keith Owens [EMAIL PROTECTED] writes:
Basically, that symlink should not be a symlink. It's a symlink for
historical reasons, none of them very good any more (and haven't been
for a long time), and it's a disaster unless you want to be a C
library developer. Which not very many
Keith Owens [EMAIL PROTECTED] writes:
This has all been thrashed out before. Read the threads
http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html
I don't think that these address my
"H. Peter Anvin" [EMAIL PROTECTED] writes:
Con: people behind broken firewalls can't connect.
Are you sure that is correct? "Servers" normally listen for incoming
connections from clients rather than establish them[1]. So, if the
server implements ECN then it will respond appropriately to
Matti Aarnio [EMAIL PROTECTED] writes:
I just verified this particular aspect of VGER's MTA
configurations. It has been unmodified since 21-Mar-2000,
that is, over a year...
On the subject of vger configuration, the FAQ states that vger "will"
start using ECN as of 22 Feb
There were multiple changes to the char/sx.c driver in kernel 2.6.20. In
kernels 2.6.19 and earlier, the SX multiport serial card works OK, but
in 2.6.20 and later the driver does not seemt to detect the presence of
the card.
I have enabled sx_debug=-1 and added some printk statements to try and
Jiri Slaby [EMAIL PROTECTED] writes:
In switched ids. Could you try the patch below?
Thanks. That fixed the problem - the card works again now.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeffrey V. Merkey [EMAIL PROTECTED] writes:
This already exists -- it just not open sourced, and you could spend
years trying to create it. Trust me, once you start dealing with the
distributed issues with this, its gets very complex. I am not meaning
to discourage you, but there are
Daniel Hazelton [EMAIL PROTECTED] writes:
The second:
I buy a DSL modem. Until I want to actually connect to the internet it can
have whatever settings I want it to have. The second I want to connect to the
internet it has to be configured the way that the ISP wants.
But only those
Matti Aarnio <[EMAIL PROTECTED]> writes:
> ... and immediately I have been able to verify a bunch of
> domains/servers which won't get thru when incoming connection
> has ECN.
As a matter of interest, are you also noting how many actually
negotiate ECN rather than simply responding with a
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> I am surprised that anyone is seriously considering denying
> service to sites that do not implement an _experimental_ facility
> and have firewalls that try to play things safe by dropping packets
> which have 1's in bit positions that in
[EMAIL PROTECTED] (Rogier Wolff) writes:
> If the firewall operator is sufficiently paranoid, they can say: "We
> don't trust the ECN implementation on our hosts behind the firewall,
> so we want to disable it.".
In which case would the "correct" action not be to zero the ECN bits
of packets
"Mohammad A. Haque" <[EMAIL PROTECTED]> writes:
> Traceroute is working fine here. You sure you didn't inadvertantly turn
> on ECN w/o knowing it?
Will ECN have any effect on Traceroute? Does ECN not only affect TCP
connections?
-
To unsubscribe from this list: send the line "unsubscribe
"Mohammad A. Haque" <[EMAIL PROTECTED]> writes:
> making a patch means you've modfied the source which you are not allowed
> to do. The most you can do is report the bug through normal channels
> (you dont even have priority in reporting bugs since you have the code).
Does making a patch
David Ford <[EMAIL PROTECTED]> writes:
> There are a -lot- of large sites that give us issues like this.
What is the best way to handle sites which block connections using
ECN? Is it best for everyone who detects this to write individually to
each site which they find can be accessed with
"David S. Miller" <[EMAIL PROTECTED]> writes:
> The authors of rfc793 probably, in all honesty, really meant
> "must be set to zero by current implementations".
I agree, to me it seems obvious that the reason is so that these bits
could be used at some time in the future for some, then unknown,
Using net-tools 1.57 (which I think is the latest) and kernel
2.4.0-test7/8 (I think it was OK with -test6) 'netstat -s' displays
the message "error parsing /proc/net/snmp: Success" rather than
displaying the counters.
I notice that kernel/Documentation/Changes no longer lists the version
of
"Jim Roland" <[EMAIL PROTECTED]> writes:
> What some people don't realize is that Microsoft *DID* do Unix a long time
> ago, they were even into OS/2 Development. :-)
And they annoyed not just a few application vendors when just a few
months after giving the message "Go with OS/2, it is the
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Andrew Stubbs]
> > Has anyone implemented a /proc device or user program to interrogate
> > the enviromental attirbutes (temp, voltage etc) that many
> > motherboards provide via their bios's ?
>
> Do a search on 'lm_sensors'.
Does this work with
i810_rng.c does not compile when not a module. It fails at line 384,
which looks as though it should only be included when being built as a
module.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
Byron Stanoszek <[EMAIL PROTECTED]> writes:
> I narrowed the problem down to a subset of patches from the MM set in
> test13-pre2. Reversing the attached 'context.patch' fixes the problem (only for
> i386), but I'm not yet sure why. test13-pre2 and up work without any problems
> on an Intel cpu
My 2.4.0-prerelease freezes solid on certain serial port events. The
ones I have seen (and are both repeatable) are when powering off the
modem and powering it on causes the system to hang solid. Also if an
incoming call is received on the telephone, the system hangs ( I
assume that this is when
Keith Owens <[EMAIL PROTECTED]> writes:
> Boot the kdb enhanced kernel and cat /proc/interrupts to see if NMI is
> non-zero.
NMI is zero, so that did not help.
However, I think I have solved the problem. During boot, I saw a
message about ACPI failing to initialise so I removed ACPI from the
Mathieu Chouquet-Stringer <[EMAIL PROTECTED]> writes:
> 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
Keith Owens <[EMAIL PROTECTED]> writes:
> Basically, that symlink should not be a symlink. It's a symlink for
> historical reasons, none of them very good any more (and haven't been
> for a long time), and it's a disaster unless you want to be a C
> library developer. Which not very
Keith Owens <[EMAIL PROTECTED]> writes:
> This has all been thrashed out before. Read the threads
>
> http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html
I don't think that these address
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Con: people behind broken firewalls can't connect.
Are you sure that is correct? "Servers" normally listen for incoming
connections from clients rather than establish them[1]. So, if the
server implements ECN then it will respond appropriately to
Matti Aarnio <[EMAIL PROTECTED]> writes:
> I just verified this particular aspect of VGER's MTA
> configurations. It has been unmodified since 21-Mar-2000,
> that is, over a year...
On the subject of vger configuration, the FAQ states that vger "will"
start using ECN as of 22
"Jeffrey V. Merkey" <[EMAIL PROTECTED]> writes:
> This already exists -- it just not open sourced, and you could spend
> years trying to create it. Trust me, once you start dealing with the
> distributed issues with this, its gets very complex. I am not meaning
> to discourage you, but there
Daniel Hazelton <[EMAIL PROTECTED]> writes:
> The second:
> I buy a DSL modem. Until I want to actually connect to the internet it can
> have whatever settings I want it to have. The second I want to connect to the
> internet it has to be configured the way that the ISP wants.
But only those
Jiri Slaby <[EMAIL PROTECTED]> writes:
> In switched ids. Could you try the patch below?
Thanks. That fixed the problem - the card works again now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
There were multiple changes to the char/sx.c driver in kernel 2.6.20. In
kernels 2.6.19 and earlier, the SX multiport serial card works OK, but
in 2.6.20 and later the driver does not seemt to detect the presence of
the card.
I have enabled sx_debug=-1 and added some printk statements to try and
44 matches
Mail list logo
