[RFC IPv6] Disabling IPv6 autoconf
Hi,
we had bug reports from people seeing lots of spurious messages
like the following:
kernel: peth0: received packet with own address as source address.
and
xenbr0: duplicate address detected!
This is on a Xen enabled machine, with lots of Xen machines on the
same network.
When the Xen code configures the bridge device, this will do IPv6
autoconfiguration for the interface, and since they use synthetic MAC
addresses, there will be DAD collisions.
When the Xen people looked for a way to disable IPv6 autoconf of the
bridge, they didn't find any way to do it without bringing up the
device first (and thereby triggering DAD).
The attached tentative patch makes IPv6 autoconf depend on the
availability of IFF_MULTICAST. This is admittedly a bit of a hack, but
it makes sense, since DAD and router solicitation do rely on multicast.
Any comments?
Thanks,
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
Summary: Allow to bring up network interface w/o ipv6 autoconf
When bringing up a xen bridge device, it will always be configured to
use a MAC address of ff:ff:ff:ff:ff:fe. This greatly confuses IPv6 DAD,
which starts logging lots and lots of useless messages to syslog.
We really want to disable IPv6 on these interfaces, and there doesn't
seem to be a reliable way to do this without bringing the interface
up first (and triggering IPv6 autoconf).
This patch makes autoconf (DAD and router discovery) depend on the
interface's ability to do multicast. Turning off multicast for an
interface before bringing it up will suppress autoconfiguration.
Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]>
net/ipv6/addrconf.c |2 ++
1 files changed, 2 insertions(+)
Index: build/net/ipv6/addrconf.c
===
--- build.orig/net/ipv6/addrconf.c
+++ build/net/ipv6/addrconf.c
@@ -2462,6 +2462,7 @@ static void addrconf_dad_start(struct in
spin_lock_bh(&ifp->lock);
if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
+ !(dev->flags&IFF_MULTICAST) ||
!(ifp->flags&IFA_F_TENTATIVE)) {
ifp->flags &= ~IFA_F_TENTATIVE;
spin_unlock_bh(&ifp->lock);
@@ -2546,6 +2547,7 @@ static void addrconf_dad_completed(struc
if (ifp->idev->cnf.forwarding == 0 &&
ifp->idev->cnf.rtr_solicits > 0 &&
(dev->flags&IFF_LOOPBACK) == 0 &&
+ (dev->flags & IFF_MULTICAST) &&
(ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
struct in6_addr all_routers;
Re: [RFC IPv6] Disabling IPv6 autoconf
In article <[EMAIL PROTECTED]> (at Tue, 29 Aug 2006 10:24:35 +0200), Olaf Kirch <[EMAIL PROTECTED]> says: > When the Xen code configures the bridge device, this will do IPv6 > autoconfiguration for the interface, and since they use synthetic MAC > addresses, there will be DAD collisions. : > The attached tentative patch makes IPv6 autoconf depend on the > availability of IFF_MULTICAST. This is admittedly a bit of a hack, but > it makes sense, since DAD and router solicitation do rely on multicast. I disagree. The node MUST NOT assign live address on that interface. Further analysis is needed, but one idea is to skip addrconf_dev_config() if !(dev->flags & IFF_MULTICAST). --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Tue, 29 Aug 2006 18:34:26 +0900 (JST) > Further analysis is needed, but one idea is to skip > addrconf_dev_config() if !(dev->flags & IFF_MULTICAST). Yes, it is logical because without multicast IPV6 cannot work correctly. But from another perspective (I assume these bridged Xen devices use ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared IFF_MULTICAST flag seems potentially problematic. How many other things break over such a device? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
David Miller <[EMAIL PROTECTED]> wrote:
>
> But from another perspective (I assume these bridged Xen devices use
> ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared
> IFF_MULTICAST flag seems potentially problematic. How many other
> things break over such a device?
Netfilter is broken for a different reason. It breaks because packets
pass through it twice, once going through brigde netfilter and once
through the Xen netloop interface. So ideally they'd get rid of the
netloop device in which case they won't have to disable multicasting
on the bridge device anymore.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
On Tue, Aug 29, 2006 at 08:39:53PM +1000, Herbert Xu wrote: > Netfilter is broken for a different reason. It breaks because packets > pass through it twice, once going through brigde netfilter and once > through the Xen netloop interface. So ideally they'd get rid of the > netloop device in which case they won't have to disable multicasting > on the bridge device anymore. I agree, this would be the right long-term fix. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
On Tue, Aug 29, 2006 at 06:34:26PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > The attached tentative patch makes IPv6 autoconf depend on the > > availability of IFF_MULTICAST. This is admittedly a bit of a hack, but > > it makes sense, since DAD and router solicitation do rely on multicast. > > I disagree. The node MUST NOT assign live address on > that interface. I'm not sure I understand. The Xen bridge devices get fe:ff:ff:ff:ff:ff as MAC address. Which is a bit hackish, but that seems to be the way the Xen folks want to do it. OTOH they do not want to do any IPv6 autoconfiguration with these addresses, because they generate DAD warnings, and cause one random machine to obtain fe80::::feff: as link-local address. > Further analysis is needed, but one idea is to skip > addrconf_dev_config() if !(dev->flags & IFF_MULTICAST). That should work just as well. Do you want me to submit an updated patch? Thanks, Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
On Tue, 29 Aug 2006, David Miller wrote: From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Tue, 29 Aug 2006 18:34:26 +0900 (JST) Further analysis is needed, but one idea is to skip addrconf_dev_config() if !(dev->flags & IFF_MULTICAST). Yes, it is logical because without multicast IPV6 cannot work correctly. But from another perspective (I assume these bridged Xen devices use ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared IFF_MULTICAST flag seems potentially problematic. How many other things break over such a device? It's not obvious that IFF_MULTICAST is good enough. IMHO, you should be able to run addrconf on non-multicast interfaces as well (e.g., point-to-point interfaces, tunnels in particular). It seems that current code already excludes IFF_NOARP interfaces though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
On Tue, Aug 29, 2006 at 01:55:28PM +0300, Pekka Savola wrote: > It's not obvious that IFF_MULTICAST is good enough. IMHO, you should > be able to run addrconf on non-multicast interfaces as well (e.g., > point-to-point interfaces, tunnels in particular). So would it work to use this? (flags & (IFF_MULTICAST|IFF_POINTOPOINT)) == 0 > It seems that current code already excludes IFF_NOARP interfaces > though. I looked at that - it doesn't help because it just disables DAD, but still does router solicitation, and I think it also sends a MLD listener report with the bogus link-layer address. I tend to agree that it's incorrect to assign an address at all in this case. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
Pekka Savola schrieb: > On Tue, 29 Aug 2006, David Miller wrote: >> From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> >> Date: Tue, 29 Aug 2006 18:34:26 +0900 (JST) >> >>> Further analysis is needed, but one idea is to skip >>> addrconf_dev_config() if !(dev->flags & IFF_MULTICAST). >> >> Yes, it is logical because without multicast IPV6 cannot >> work correctly. >> >> But from another perspective (I assume these bridged Xen devices use >> ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared >> IFF_MULTICAST flag seems potentially problematic. How many other >> things break over such a device? > > It's not obvious that IFF_MULTICAST is good enough. IMHO, you should be > able to run addrconf on non-multicast interfaces as well (e.g., > point-to-point interfaces, tunnels in particular). Hmm, at least on RHEL4 (2.6.9): 1: lo: mtu 16436 qdisc noqueue 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 4: sit0: mtu 1480 qdisc noop 5: [EMAIL PROTECTED]: mtu 1480 qdisc noqueue 6: ppp0: mtu 1492 qdisc pfifo_fast qlen 3 8: [EMAIL PROTECTED]: mtu 1480 qdisc noqueue And contributed from FC5: 5: vmnet8: mtu 1500 qdisc pfifo_fast qlen 1000 7: tun0: mtu 1500 qdisc pfifo_fast qlen 100 ppp0, tun0 has IFF_MULTICAST set, so not an issue. > It seems that current code already excludes IFF_NOARP interfaces though. So 6-in-4 tunnels are already except. Don't wonder about Flag "1", missing support in "ip", already reported https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202199 and fixed in rawhide. Just my 2 cents, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto:[EMAIL PROTECTED] Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ OpenBChttp://www.openbc.com/hp/Peter_Bieringer/ Personal invitation to OpenBC http://www.openbc.com/go/invita/3889 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
Olaf Kirch wrote: > When the Xen people looked for a way to disable IPv6 autoconf of the > bridge, they didn't find any way to do it without bringing up the > device first (and thereby triggering DAD). Because no /proc/sys/net/ipv6/conf/ exist (yes, I know it's user visible effect)? This is just odd IMHO. I asked why it was changed and how userspace should behave now regarding this, but got no answer. Simple scenario with GNU/Debian: Computer is booted with no ethernet link. Ethernet interface should get address via autoconf. No link => no IPv6 addresses on interface => no /proc/sys/net/ipv6/conf/. Bootup scripts (procps.sh reading sysctl.conf existing in most of distributions AFAIK) can't set/get anything in /proc/sys/net/ipv6/conf/ because it doesn't exist. How userspace should behave now? Mandating daemon which listens interface events via netlink? regards, -- Hasso Tepper - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
Hasso Tepper schrieb: > Olaf Kirch wrote: >> When the Xen people looked for a way to disable IPv6 autoconf of the >> bridge, they didn't find any way to do it without bringing up the >> device first (and thereby triggering DAD). > > Because no /proc/sys/net/ipv6/conf/ exist (yes, I know it's > user visible effect)? This is just odd IMHO. I asked why it was changed > and how userspace should behave now regarding this, but got no answer. > > Simple scenario with GNU/Debian: > > Computer is booted with no ethernet link. Ethernet interface should get > address via autoconf. No link => no IPv6 addresses on interface => > no /proc/sys/net/ipv6/conf/. Bootup scripts (procps.sh reading > sysctl.conf existing in most of distributions AFAIK) can't set/get > anything in /proc/sys/net/ipv6/conf/ because it doesn't exist. > > How userspace should behave now? Mandating daemon which listens interface > events via netlink? BTW: this is also the reason why autoconf or accept_ra cannot be disabled by e.g. initscripts *per* interface before bringing one up. This issue was discussed some time ago with Pekka and reported in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809 There is still no solution for that afaik. Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto:[EMAIL PROTECTED] Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ OpenBChttp://www.openbc.com/hp/Peter_Bieringer/ Personal invitation to OpenBC http://www.openbc.com/go/invita/3889 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
Peter Bieringer <[EMAIL PROTECTED]> wrote:
>
>> anything in /proc/sys/net/ipv6/conf/ because it doesn't exist.
>>
>> How userspace should behave now? Mandating daemon which listens interface
>> events via netlink?
>
> BTW: this is also the reason why autoconf or accept_ra cannot be
> disabled by e.g. initscripts *per* interface before bringing one up.
You can disable it in /proc/sys/net/ipv6/conf/default/... and then
reenable it on the interfaces that you actually want.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
Herbert Xu wrote: > Peter Bieringer <[EMAIL PROTECTED]> wrote: > > BTW: this is also the reason why autoconf or accept_ra cannot be > > disabled by e.g. initscripts *per* interface before bringing one up. > > You can disable it in /proc/sys/net/ipv6/conf/default/... and then > reenable it on the interfaces that you actually want. You can't do that either (ie. reenable) in initscripts before link is up. regards, -- Hasso - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
On Tue, 29 Aug 2006 12:44:18 +0200 Olaf Kirch <[EMAIL PROTECTED]> wrote: > On Tue, Aug 29, 2006 at 06:34:26PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ > wrote: > > > The attached tentative patch makes IPv6 autoconf depend on the > > > availability of IFF_MULTICAST. This is admittedly a bit of a hack, but > > > it makes sense, since DAD and router solicitation do rely on multicast. > > > > I disagree. The node MUST NOT assign live address on > > that interface. > > I'm not sure I understand. The Xen bridge devices get fe:ff:ff:ff:ff:ff > as MAC address. Which is a bit hackish, but that seems to be the way > the Xen folks want to do it. They should be using random_ether_addr() or putting some per instance specific info into the address. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
Hello! > Yes, it is logical because without multicast IPV6 cannot > work correctly. This is not quite true. IFF_BROADCAST is enough, it will work just like IPv4. Real troubles start only when interface is not IFF_BROADCAST and not IFF_POINTOPOINT. > IFF_MULTICAST flag seems potentially problematic. How many other > things break over such a device? Nothing should break. IFF_MULTICAST is an advisory flag, saying mostly "You do not want to stream high bandwidth multicast video here". So that, it can be used to block autoconfiguration. It does not change the fact that Xen device makes something profoundly wrong. IPv6 autoconfiguration is _auto_configuration. It is triggered only for a few of media types, for which autoconfiguration is prescribed by corresponding RFCs. Ethernet is one of them. If Xen does not support the things, which are required for each ethernet device, it should not be ARPHRD_ETHER. If it wants to pretend to be ARPHRD_ETHER, it must support basic ethernet functions, which IMHO is so _easy_, that the question does not even makes sense. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
* Olaf Kirch <[EMAIL PROTECTED]> 2006-08-29 10:24 > we had bug reports from people seeing lots of spurious messages > like the following: > > kernel: peth0: received packet with own address as source address. > > and > > xenbr0: duplicate address detected! > > This is on a Xen enabled machine, with lots of Xen machines on the > same network. > > When the Xen code configures the bridge device, this will do IPv6 > autoconfiguration for the interface, and since they use synthetic MAC > addresses, there will be DAD collisions. > > When the Xen people looked for a way to disable IPv6 autoconf of the > bridge, they didn't find any way to do it without bringing up the > device first (and thereby triggering DAD). They didn't find any because there is no need to disable it. I hardly think that the network stack should fix things that Xen got wrong. Setting dev_addr to -1 is just plain wrong, other virtual ethernet devices call random_ether_addr(), it's not a new problem at all. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
On Tue, Aug 29, 2006 at 08:10:21PM +0200, Thomas Graf wrote: > > When the Xen people looked for a way to disable IPv6 autoconf of the > > bridge, they didn't find any way to do it without bringing up the > > device first (and thereby triggering DAD). > > They didn't find any because there is no need to disable it. I Well, as a global statement that may merit a separate debate. In this specific case, maybe. First off, I do agree that the use of a constant MAC address across the board is a bad move :) OTOH, there are good reasons why you want to turn off autoconf on specific devices; and the current method of first bringing up the device and then disabling it doesnt quite cut it. One could also argue that there's a good reason to not assign addresses to pure bridge devices at all, regardless of their brokenness. We don't want to assign IPv4 addresses to a pure bridge, and I think it's a reasonable expectation that there should be a way to tell the IPv6 stack to keep its hands off that device, too. > got wrong. Setting dev_addr to -1 is just plain wrong, other > virtual ethernet devices call random_ether_addr(), it's not a > new problem at all. Okay, fine with me - maybe we can convince them to use that instead. Thanks for the feedback, Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
Hasso Tepper <[EMAIL PROTECTED]> wrote:
>
>> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
>> reenable it on the interfaces that you actually want.
>
> You can't do that either (ie. reenable) in initscripts before link is up.
As soon as you do ifconfig ethX up it'll appear in /proc/sys and
you can reenable it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
In article <[EMAIL PROTECTED]> (at Wed, 30 Aug 2006 10:12:10 +1000), Herbert Xu
<[EMAIL PROTECTED]> says:
> Hasso Tepper <[EMAIL PROTECTED]> wrote:
> >
> >> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> >> reenable it on the interfaces that you actually want.
> >
> > You can't do that either (ie. reenable) in initscripts before link is up.
>
> As soon as you do ifconfig ethX up it'll appear in /proc/sys and
> you can reenable it.
The point is:
- Until we have live address(es), we do not create inet6_dev{} for that
device.
- We do NOT run DAD until the link is ready (netif_carrier_ok()).
This means, we do NOT have any addresses until the link is once up,
and thus, because the sysctl entries live in inet6_dev{}, we do not
install net.ipv6.conf.ethX from values of net.ipv6.conf.default until
then.
Maybe, we can install inet6_dev{} without any IPv6 addresses when we
are bringing up the device before we start DAD.
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC IPv6] Disabling IPv6 autoconf
Herbert Xu wrote: > Hasso Tepper <[EMAIL PROTECTED]> wrote: > >> You can disable it in /proc/sys/net/ipv6/conf/default/... and then > >> reenable it on the interfaces that you actually want. > > > > You can't do that either (ie. reenable) in initscripts before link is > > up. > > As soon as you do ifconfig ethX up it'll appear in /proc/sys and > you can reenable it. Only if you have addresses on it. Point is that you haven't any if autoconf is used (no manually configured addresses) and carrier is down (no cable or smth). Even link-local address is created after first carrier up event. And problem isn't specific to IPv6, there is same problem with IPv4. For example if carrier aware network configuration method is used (as nowadays common Networkmanager is). regards, -- Hasso Tepper - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
