IPv6 is explicitly disabled

John DeDourek dedourek at unb.ca
Fri May 25 10:54:24 UTC 2007

Steve Hill wrote:
> On Thu, 24 May 2007, David Woodhouse wrote:
>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241281
>> Use tcpdump on your machine and on some other machine on the network --
>> observe the packets you're missing.
>> Often, observe that when tcpdump puts the interface into promiscuous
>> work it actually starts working because you suddenly _do_ receive the RA
>> packets :)
> No, I think the problem is that the NIC isn't filtering the 
> transmitted packets from being received, so the IPv6 stack is seeing 
> it's own packets and thinking something else is already using the same 
> address. (This is kind of all conjecture though - I've not done any 
> real debugging on the problem).
> I noticed yesterday evening that eventually it does sometimes manage 
> to assign itself an IPv6 address, but you have to wait a lonnng time 
> for that to happen.
Not sure that this is related to your problem, but it may be
useful to readers of this list:

We have found that when using some wireless interfaces in infrastructure
mode (hosts using an access point), the following occurs.

Assume host A and host B are communicating with the same access point
and are within range of each other.

Now ping to B from A.  All is well.

Now put the wireless interface on host A into promiscuous mode, say
by running tcpdump, wireshare, or arpwatch.

The interface on host A no longer filters wireless frames by MAC address.
As a result, it returns to tcpdump, etc. AND to the IP stack all
frames it hears.  This will include two copies of the ping request:
the FRAME going from host A to the access point AND the FRAME
going from the access point to host B. 

Both frames contain the SAME IP packet.  Thus you will receive
the packets that you transmit.  Likewise, you will see two copies
of the packet from host B to host A (from the frame from B to
the access point and from the frame from the access point to A).

Researchers often refer to tcpdump as a "passive" tool; it's not
quite so in some circumstances, i.e. running it changes the
characteristics of the network!

More information about the fedora-devel-list mailing list