I am trying to get either UDP broadcast or UDP multicast to work from a client connected to a Pepwave MAX AP. The host I am trying to broadcast to is on the “WAN Ethernet” network:
The host (10.240.0.210) is running a server that is listening on a UDP port.
I am trying to use UDP broadcast to 10.240.0.255 from the client, however it does not seem to work.
Do I need to configure something on the Pepwave in order to get this to work?
I have the same issue. Only it involves a different multicast group (239.255.255.250:1900). Multicast Broadcasts are meant to ONLY reside in the broadcast domain. This is an IP protocol standard.
I have been experimenting with Multicast forwarding (with little success). Here is what I have found out – I hope it helps.
The multicast address 10.240.0.210 is a device IP hosting the service. 224.0.0.0 through 239.255.255.255 is the typical range for multicast groups. I imagine what is going on is a multicast discovery that the server running the service answers to the multicast group with it’s IP information. That sounds kind of confusing - so here is an example…
Server “binds” to multicast group IP (239.253.252.253). Typically they will send out some kind of UDP announcement packet indicating that the service exists and is online, it will also send out a URL for obtaining more information about the service. This URL will be the actual IP of the device running the service, and usually some kind of xml type of path and filename - here is a fictional example. http://10.240.0.210:5353/info_config/servicename.xml. Next, a client connects to the multicast IP and sends a UDP query type of packet to the multicast address. The service responds with the URL for the service config. I have seen it done multiple ways. I have seen the service respond back to the multicast address, and I have also seen it send the response directly to the client that initiated the query (typically on the same outbound port of the original request). Once the client obtains the URL for the configuration - it initiates a TCP socket directly to the device and then uses the configuration data inside of it’s application. Now, the fun bit – there can be multiple services and multiple clients attached to each multicast address. They can join in any order and are meant to always work.
Look up DIAL protocol. It uses SSDP as a foundation. SSDP is part of UPNP. DIAL is how your phone can find secondary video output devices on the local lan (i.e. mirror content to a samsung TV from an iPhone)
First - rationale for multicast discovery. It goes hand in hand with the “Auto configuration IP space”. Multicast broadcast groups are an attempt at a “zero configuration setup” - this means the clients find the services without the need of dedicated network support. Basically, you should be able to connect a cross over cable between the client and the server and it still work. Think of a multicast address as a radio station. Think of each Vlan as a state (I am in the US). The same radio broadcast frequency can exist in multiple states; but they are very much separate. There is a geographical separation that keeps the signals from colliding for the two radio signals (and the FCC is involved as well). So, just because two radios are tuned to the same frequency – they aren’t hearing the same music. The dude in Texas is listening to a rap station, while the dude in Kentucky is listening to some hippie music. They are both listening to 99.7 – what gives?
The boundary is what gives. ALL routers are supposed to be borders for these multicast addresses – i.e. NOT forward beyond the perimeter. Most of the time these packets are marked with a TTL of 1 to insure it doesn’t cross the boundary. With the concept of VLans – each network is isolated from each other. So, if you have three VLans - you have three different multicast addresses (each with the same IP) and they cannot talk to one another.
Ultimately, what I learned is that there should be some type of “global” multicast group that is shared among the different vlans. I wasn’t able to get the discovery protocol to cross the boundaries (and work) because of the way the client was written. It is like it is by design. I ended up joining my wifi and wired networks into a single LAN. Bummer.