Ticket #6527 (new defect)
Mesh does not forward multicast packets (most of the time)
Description
I found this bug while trying to reproduce #4616 on modern hardware and software.
Setup:
- Two XO's, MP G1G1s. One is using build 656, the other update.1-691.
- In NetworkManager screen, put both on "Mesh Network 1". Wait a few minutes for things to settle down. Go to donut screen, make sure both of them say "Mesh Network 1, Connected to a Simple Mesh".
- Start a terminal on each laptop. Become root.
- "ping6 -I msh0 ff02::1" on each laptop.
- This will ping the all-nodes multicast address. The laptop that sends this should get back a unicast IPv6 ping response from each node on the network. Keep moving the mouse on the update.1-691 laptop to avoid suspending.
- On each laptop, it can see itself (btw, ping6 prints its own address on its first line of output). It prints a very low latency response (e.g. 0.154 ms) packet from its own kernel. It seldom or never sees a ping response from the other laptop.
- Bizarrely, every once in a while, the Build 656 laptop will see ping responses from the update.1-691 laptop. For about 10 seconds. Then they will go away again. They say "(DUP!)" because it's the second response packet from a single outgoing ping packet. Perhaps these happen after it suspends and I resume it with mouse motion.
If I stop the pings, go back into NetworkManager, and associate both XO's with a local access point (TrendNET TEW432-BRP), replace "msh0" with "eth0" in the ping6 command, and rerun the test, then the test works. Each laptop can see the other's multicast ping packets.
This could be a kernel problem, or could be a Libertas firmware problem. I'm starting reporting it as kernel problem (partly because there's no category for mesh or Libertas bugs). It should be possible to produce a smoking gun in kernel logs, that show whether the chip ever gives the kernel the missing packets.


