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
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 c
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
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 ne
* 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,
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 problem
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 hac
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 in
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
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
> us
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
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 logi
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?
(f
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
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.
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
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 bro
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 perspe
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
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
20 matches
Mail list logo
