IPv6 is explicitly disabled

John DeDourek dedourek at unb.ca
Fri May 25 10:58:53 UTC 2007

John DeDourek wrote:
> 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!
Ooops.  Sorry.  Meant to say:
"Now ping from A to B"
"Now ping from B to A"

More information about the fedora-devel-list mailing list