Opened 9 years ago

Last modified 9 years ago

#6527 new defect

Mesh does not forward multicast packets (most of the time)

Reported by: gnu Owned by: dwmw2
Priority: normal Milestone:
Component: wireless Version: Development build as of this date
Keywords: Cc:
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no


I found this bug while trying to reproduce #4616 on modern hardware and software.


  • 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.

Attachments (1) (75 bytes) - added by jcardona 9 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 9 years ago by dwmw2

tcpdump from both ends would be useful. Also a raw 802.11 packet capture if you can. Can you do unicast ping between these machines? Can you show the contents of /proc/net/igmp6?

comment:2 Changed 9 years ago by dwmw2

  • Component changed from kernel to wireless
  • Owner changed from dilinger to dwmw2

comment:3 Changed 9 years ago by jcardona

I run the attached script that pings a multicast address on 1 laptop, with 9 other laptops active on the same mesh channel. I was consistently getting 9 (+self) responses.

Changed 9 years ago by jcardona

comment:4 Changed 9 years ago by dwmw2

Also note the contents of /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

comment:5 Changed 9 years ago by gregorio

  • Milestone Never Assigned deleted

Milestone Never Assigned deleted

Note: See TracTickets for help on using tickets.