Recently upgraded to the new 0.4.5 firmware which finally brings Multicast support to the Photon, (thanks btw!) however noticed a weird issue with it.
Will first start with the example of the code I’m using with WiFi controlled lights (NeoPixel ring kit + Photon) which is part of our Mediaportal AtmoOrb project:
I use this sketch and change:
client.joinMulticast(IPAddress(239, 15, 18, 2));
to:
client.joinMulticast(IPAddress(239, 16, 18, 2));
to use that on another Photon as to control them separately from each other (different multicast groups), however when I send a UDP command to multicast group 239.15.18.2 the other one at 239.16.18.2 also responds to the same command.
Anyone can explain why that is as I thought the idea of the different multicast groups was to control them in their own controlled group?
I was able to reproduce this. Really weird. Currently my photons lost the ability to receive multicast at all (maybe the router is confused) so I cannot retest.
However, I looked at the code (again). There is really not much going on except conversion of IP addresses. Either the conversion is wrong and all multicast addresses are basically reduced to the same - or there is a bug in the WICED code.
I would be surprised if it was the reduction to the same multicast address but I will try to debug this.
There should be even one more filter: The receiver should check if the MAC of the multicast address on which the packet was received matches the MAC of a joined multicast address.
I am not sure exactly what you are saying here, but my experience with working with multicast hardware is that on Linux/PC boxes, "joining" a multicast group turns off the hardware MAC address filtering for multicast MACs so that the software driver "sees" multicast packets. The driver then does the IP/MAC filtering as required and it is subject to iptable rules etc. so it is easy to not get the packets.
So I am wondering if that is the way the broadcom device works too, putting the IP level filtering on you. Maybe @mdma knows something here.
Thanks for the reply guys, seems like a missing key feature in multicast but here’s hoping some of you can debug it further as I’m not that well experienced with the Photons in this area.
@mdma checked the UDP.remoteIP() method however that will only return the local IP (10.1.2.100) of the sender and not the multicast IP so I can’t tell if it was send from the proper multi-cast group.
Btw for those interested here’s a small demo of the ambilight project in action, was using TCP / UDP without multicast before:
@bko: I my experience even the cheapest Ethernet cards have more than one hardware MAC filter. 16 was a typical lower limit I saw. If you join up to 16 multicast address, the MAC for that multicast address will be used to configure one of the filters. Only if you join more than 16 multicast addresses, the flood gate will be opened and all multicast packets will pass through the NIC. Maybe they omitted the MAC filters from the Ethernet functionality embedded in some of the mainboard chipsets?
But you are right, the OS needs to have the capability of filtering based on the MAC as well. I could well imagine that the Broadcom chipset does not have the hardware filters and that the WICED code does not do the filtering, either.
I will take some time to recheck the joinMulticast code. Just to be sure.
@RickDB: In the meantime you could of course still work with what’s there: Start each of your UDP packets with the multicast address in the data. Then filter out the ones not matching. If @bko is correct that there are no hardware filters (and I think he is), then this is not so much different than what would happen in the software filtered case.
Included the unique Orb / Lamp ID in the UDP request so that I can validate it that way, also has the benefit of easily identifying them without the need for multiple multicast groups
I think, having scanned through this, that this is related to how multicast is propagated at Layer 2.
Every Multicast IP has a corresponding Multicast MAC.
The Multicast MAC address has the following structure…
01.00.5e.xx.xx.xx
The 24th bit is always 0.
The last 23 bits of the address are the last 23 bits of the IP address.
For example:
with IP: 239.131.11.65
so in binary that’s: 11101111.10000011.00001011.01000001
Take the last 24 bits: 10000011.00001011.01000001
Zero out the first bit: 00000011.00001011.01000001
Convert to hex: 03.0b.41
Prepend the multicast OUI: 01.00.5e.03.0b.41
So packets to the Multicast IP 239.131.11.65 are sent to the MAC address 01.00.5e.03.0b.41
NICs listening to that MAC will receive the traffic.
So, as the astute among you will have realised already, there are more multicast IP than multicast MAC, which means there is the possibility of mashing up the streams at layer 2 (e.g. Ethernet). This would normally be filtered out by the receiver, but generally it’s considered better to carefully choose your multicast IP to avoid this issue.
Anyway, this doesn’t actually resolve the issue as this shouldn’t happen for the two IP’s listed at the top of this thread.
e.g. the first clashes with:
224.15.18.2
224.143.18.2
225.15.18.2
225.143.18.2
226.15.18.2
226.143.18.2
227.15.18.2
227.143.18.2
228.15.18.2
228.143.18.2
… etc… etc…
So, I’m wondering if the stack is being a little lazy and just using a broadcast address for the multicast, instead of properly setting a multicast MAC, or if there’s a little bug in there…
I’ve had a dig through the firmware source on git, but I’ve not been able to find the code that actually generates the packet, I think it’s in socket_send in the WICED stack but I can’t find it… is that a broadcom bit???
