OSC won't receive messages sent to broadcast IP

I’m building an app where a server sends messages to many Raspberry Pi clients using a broadcast address (192.168.1.255), but I can’t seem to get it working.

It’s working fine when I try using macOS and Windows on my laptop and desktop, the issue is only when the client is running on an rPi. Is there any additional config I need to do to allow this? I’m not sure if this would be Linux general or Raspbian specific…

I’m on OF master (0.10) and Raspbian Stretch.

Thanks,
Elie

That should work, what are you using? osc? udp? perhaps post how you are setting up the network

I’m using ofxOsc.

The sender code is:

ofxOscSenderSettings sendSettings;
sendSettings.host = "192.168.0.255";
sendSettings.port = 3000;
sendSettings.broadcast = true;
oscSender.setup(sendSettings);

And the receiver code is:

ofxOscReceiverSettings recvSettings;
recvSettings.port = 3000
oscReceiver.setup(recvSettings);

And this works fine on OS X and Windows, just not on Raspberry Pi. It works on Raspberry Pi if I replace the broadcast IP by the client IP…

The machines are connected using a switch (not a router) with all settings set up manually. Could this be related to the issue?

Maybe the pi is not ‘seeing’ the broadcast address. See what the ‘ifconfig’ command outputs from the pi.
Somewhere in the interface settings its should say something like. ’ broadcast 192.168.1.255’
and I think it should also say as well.

Yes that should work and as @steeley says perhaps check the network settings. in some modern linux distributions ifconfig is not there by default and you have to use ip addr which gives you the same information, perhaps when setting the ip, if you’ve set it up manually you setup a wrong subnet mask?

I think I possibly imagined this working across OS X / Windows on Friday as I’m getting the same issue on all platforms now…

I just tried another test where I plugged the switch into a router and once everything was configured, the system ran properly, with the clients receiving broadcast messages from the sender. When I unplugged the router from the network, the communication stopped again. The error message ofxOscSender: couldn't create sender to 192.168.0.255 on port 3000: unable to connect udp socket also appeared in the console.

When I try ifconfig on the server I get:

en4: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
	ether 68:5b:35:97:79:ff 
	inet6 fe80::16:cd36:8758:93ce%en4 prefixlen 64 secured scopeid 0x7 
	inet 192.168.0.100 netmask 0xffffffff broadcast 192.168.0.100
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect (100baseTX <full-duplex,flow-control,energy-efficient-ethernet>)
	status: active

but on the client the broadcast address is still 192.168.0.255.

So, I think I just need to have a router plugged into my network for this to work. Otherwise, it looks like the broadcast address gets messed up. I was hoping to just use a couple of switches but this is OK too.

The multicast is actually handled by the router. There is actually good explanation here:
https://www.quora.com/Why-does-sending-multicast-UDP-require-a-gateway

For posterity:
UDP is layer 4 protocol and IP is layer 3 protocol. That means UDP works on top of IP layer. Since there is no path in your routing table for reaching that destination, IP layer will not forward your packet. Even if there is a gateway in your network, device “X” won’t send any packet to any address outside of “X”. Once you add a default gateway, device “X” knows that if no rule is matching in the routing table, forward the packet to default gateway.
BTW, routes are not required for connection establishment. Routing table just serves one purpose: if host “X” wants to reach destination “Y”, forward the packet to “Z” (note that, “Y” and “Z” will be same if “X” is directly connected to “Y”). Point being that, IP routing is required whether you are using TCP or UDP or any other layer 4 protocol. Only scenario in which routing entry is not required is the one that destination is directly connected (same subnet) to the source.

1 Like

multicast and broadcast are different, multicast is handled by the router and works across subnet boundaries, broadcast only inside the same subnet and it’s managed by the clients so you shouldn’t need a router to do broadcasting.

I think the problem is that the subnet mask in your server is wrong when there’s no router. it’s set to 0xffffffff = 255.255.255.255 so the broadcast address is the same as the ip address which is wrong, well it’s not wrong but you are creating a subnet of only 1 ip which is not what you want.

Your subnet mask should be the same across all devices and for the ip range you are using, usually 255.255.255.0 so the broadcast address for all devices would be: 192.168.0.255