0

I'm writing an application to get multicast updates from a current-measuring device which is plugged into my LAN. The device sends out packets to multicast group 224.192.32.19:22600 every few minutes, and I can read them fine from one of the hosts (a raspberry pi).

The weird thing is that when I tried to add a second listener host, I couldn't find any multicast traffic from that group on its interface.

The network layout is the following: network layout

All of the network is in the same physical location, under the same 192.168.x.x subnet. Between the sender and receiver(s) there are 2 TP-Link WDR3600 routers running DD-WRT, and a "dumb" TP-Link 8-port gigabit switch (used as a port expander). Everything is wired via ethernet.

Further details:

  • "NOK" hosts include a windows 7 laptop, bridged Linux VM on the same laptop, and a different linux laptop
  • plugging a "NOK" host directly to the dumb switch where the "OK" host is has no effect
  • plugging directly to the secondary router (1 ethernet "hop" closer to the source) has no effect
  • I can't find any IGMP traffic for that group on any of the hosts, including the working one
  • snooping the network traffic for IGMP I can see 2 join requests going out to 224.0.0.22 when my application starts.

The group membership gets registered by the kernel and is displayed by

~ $ netstat -ng
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.1
eth0            1      224.192.32.19
eth0            1      224.0.0.251
eth0            1      224.0.0.1

Python code that initializes the socket from the listener application is this:

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind((self.mcast_group, self.mcast_port))
mreq = struct.pack("4sl", socket.inet_aton(self.mcast_group), socket.INADDR_ANY)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)

What am I missing here? Simply running the listener application on the working host was enough to receive the multicast traffic, why is it not the case for the additional listeners?

André Fernandes
  • 469
  • 1
  • 8
  • 20
  • If the hosts don't speak IGMP, they _should_ ­-- if anything, at least to make them future-proof when some of your switches start relying on that. – u1686_grawity Jan 29 '17 at 19:38
  • You show two routers on your diagram, but don't say what subnets are out each interface (routers need different subnets out each interface). I think you may be using routing-capable devices but you're really only using them as switches, so you have them mislabeled and it makes your diagram confusing. Can you correct your diagram? – Spiff Jan 29 '17 at 20:02
  • You're right, in this problem's context they are being used purely as layer-2 switches (everything is in the same IP subnet). It doesn't invalidate the fact that they are routers, though. That fact and them running DD-WRT could help to bring about some solution or avenue of troubleshooting. – André Fernandes Jan 29 '17 at 22:21
  • The fact that they are routers only matters if your traffic is routed. Multicast, like broadcast, isn't routed the way unicast is. Multicast routing may be able to be used, but it is very different than unicast routing. Multicast with IGMP has special problems on multi-switch LANs. A switch-to-switch connection does not pass on IGMP requests unless there is an mrouter. I have [an answer](http://networkengineering.stackexchange.com/a/28302/8499) on NESE that explains the problem and solutions for Cisco and HP switches. – Ron Maupin Jan 29 '17 at 23:47

1 Answers1

0

Turns out this was a router issue, after restarting the secondary router all of the hosts started receiving the multicast packets as expected.

I'd say it was either a DD-WRT bug, or some state corruption that compromised the multicast traffic distribution.

André Fernandes
  • 469
  • 1
  • 8
  • 20