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!
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
