Though it doesn’t seem to be a Paricle issue as such, but since you guys (e.g. @bko) are my last hope for help, I do post here
I’ve been searching the web for the last month or so for a solution but could not find one.
The general useless answer is: "It should work, but if it doesn’t, it’s your hardware!"
I’ve got a C# program running on my Windows PC which multicasts in 1sec intervalls some data via UDP, which should be received by multiple Cores (once UDP works Photons) and the Particle devices should send infrequently some data back to the same multicast group.
This works quite reliably when all the devices are behind the same router and connected via WiFi. But I want to have my PC wired to the router, but I just can’t get it to work.
That’s my main problem.
Once this is solved, I’d neet to solve a similar secondary problem.
The multicast (from PC) does not make it through any switches/hubs, despite all being on the same subnet and the packets don’t hop any routers despite having set TTL to 8 hops.
My routers/switches are a Cisco EPC3925 (root, WiFi, DHCP server), a Netgear WPN824v2 (setup as switch and WiFi AP), a Netgear DGN2200v3 (as switch and WiFi AP) and a Allied Telesyn AT-FS708LE (wired switch).
Additionally, is there a way to set the TTL for UDP multicast packets on the Particle devices?
Would it be acceptable to you to use broadcast instead of multicast (remembering that lots of things are just going to flood multicast anyway, so they are likely to be broadly equivalent in practice) ?
My money is on the firmware on the router not forwarding correctly between the wifi interface and the built-in ethernet switch used for the wired connections. If you’re lucky, and really feel like busting a gut over this, you might be able to load one of the open-source variants on your AP/router; if you just want it to work, I suggest you try broadcast.
I also think you have a router problem. Consumer routers don’t forward UDP broadcast/multicast for good reasons. Enterprise and edge routers are more programmable in this regard.
Can you plug the PC directly into the downstream port on the WiFi router that the Cores are connected to? That should always work since you are on the same network.
When you say two of your WiFi routers/APs are set up as switches, do you mean bridge mode where their upstream wired port is connected to the master router/AP?
Of do you mean they are over-the-air connected to the upstream router/AP with WDS?
@AndyW, thanks fir the reply.
I’m multicasting to 225.144.0.0:14400.
Before I got involved with Particle and only had Windows/WinCE/WinMob applications communicating I did go the broadcast way, but over time I got this stupid idea that multicast was more elegant and would be better suited for traversing multiple routers - how wrong I was
I also thought of OpenWRT, but my cable modem is fw-locked (tried it once, but my ISP pulled the plug on me ;-)).
An for the Netgears I didn’t find any firmware.
You can also try using an address in the range 224.0.0.0 - 224.0.0.255 or 239.0.0.0 - 239.0.0.255 instead. Maybe that will trigger automatic forwarding code in your router, without that you might have to issue a join from every client (and even that might not work.)
Check to ensure you don’t clash with magic numbers used by common things like RIPv2, IGMP etc.
I assumed he was talking all downstream ports (wired and wifi) - my money is still on dysfunctional router firmware. There should be no leakage upstream through the NAT/firewall of multicast packets (that way lies madness.)
@bko, thanks for your answer too. @AndyW is correct. I’ve disabled the DHCP/NAT/firewall on the other routers and only use their downstream ports (Cisco root router -> Netgear routers, main PC and printer plus WiFi clients; Netgear routers AV equipment plus additional WiFi clients).
uPNP and multicast enabled/allowed on all devices.
Andy, I thought multicast IPs can be anywhere between 224.0.0.0 and 239.255.255.255.
I’ll still give another IP a try and also try to dig up a different router with OpenWRT or maybe an old enterprise router (they get dumped in regular intervalls at my work place ;-))
Some address ranges are only forwarded after a join request is made, others are forwarded by default. The two ranges I specified are good candidates for automatic handling (but for consumer-grade stuff these things are variable.) 224.0.0.x is used by bonjour and other consumer-friendly protocols, so there is a higher chance of them working out of the box on consumer equipment.
I’ve now tried 224.0.0.x & 239.0.0.x addresses and also broadcast 255.255.255.255 but to no avail.
Next I’ll have to try subnet broadcast e.g. 192.168.10.255.
I’ll also have to break out the communication from both my projects, to a bare minimum test environment.
In order to not always having to reflash the Core when altering the IP and port, I’d like to alter these settings via Spark.function().
Is there a way to free a previously used socket and reuse it to avoid running out of sockets?
AFAIK each time I call UDP.begin() a new socket will be grabbed and the previous one does not neccessarily get freed immediately.
UDP.stop(); closes the socket if it is open and returns it the “pool”. Does that not work for you?
What ports have you tried? Are you using well-known ports that your routers probably forward by default? Maybe you should try the CoAP port 5683 or the VNC port 5900.
Paricle issue as such, but since you guys (e.g. @bko) are my last hope for help, I do post here 
