Broadcasting Udp Packet to 255.255.255.255

How to receive a UDP broadcast sent to 255.255.255.255 using boost asio?

I finally discovered why my code was never seeing the broadcast packets even though tcpdump proved that they were being received. After finding this StackOverflow question:

Disable reverse path filtering from Linux kernel space

it seems that I just needed to disable Reverse Path Filtering on both hosts like this:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

and then my code worked perfectly with no modifications. Hopefully this will help other people wondering why they can't get UDP broadcasts to the network broadcast address (255.255.255.255) to work.

Sending packets to 255.255.255.255 by Java DatagramSocket fails

While using broadcasting you need to enable it

socket.setBroadcast(true);

Another thing is that you have to make sure that your router is configured right if the two computers are in two different nets. Broadcasts are usually by default not routed. Further if you have a router having a wirless interface and a wired interface these broadcasts may not work either if broadcasts are not enabled(There may be hardware which forward broadcasts between those two interfaces by default).

Receiving broadcast packet addressed to 255.255.255.255 in C++

From the wireshark output its seen that the special device is using broadcast to communicate and will use the same port number as source and destination.

Normal socket communication will require using matching port numbers but broadcast messages cannot be exchanged over the same socket, especially when the port numbers do not match as seen with wireshark.

Binding on 255.255.255.255 (INADDR_BROADCAST) should generally work but may be limited by your OS privileges and permissions.

You may try to solve the problem by using two sockets - one for receiving and one for sending. Of course the listening socket have to be setup first and bound to 0.0.0.0 (INADDR_ANY) and port 4930. In this case there is no easy way to filter by destination address (as I wrongly written in my comment) because most standard socket APIs do not provide a way to get the destination addess from the socket. On Linux there is an exception - IP_PKTINFO at SOL_IP...

By using recvfrom you will get the source unicast address of the responding device(s). You have to note that if you have more that one such device on your network you will get more than one response.

Computers on LAN do not consistently receive a UDP broadcast to 255.255.255.255 using boost::asio C++

UDP is not guaranteed to deliver. That's part of the properties of the protocol.

The fact that you can observe the behaviour with Wireshark confirms that it has little to do with Boost.

Using 255.255.255.255 is a blunt weapon and it is limited:

Setting all the bits of an IP address to one, or 255.255.255.255, forms the limited broadcast address. Sending a UDP datagram to this address delivers the message to any host on the local network segment. Because routers never forward messages sent to this address, only hosts on the network segment receive the broadcast message.

You can be more targeted by using the subnet mask:

Broadcasts can be directed to specific portions of a network by setting all bits of the host identifier. For example, to send a broadcast to all hosts on the network identified by IP addresses starting with 192.168.1, use the address 192.168.1.255.

This heightens the chance that the router will know where to send the packet (I'm not a network engineer, so I'm not sure about the implementation details).

Enter Multicast Groups:

Unlike broadcast transmission (which is used on some local area networks), multicast clients receive a stream of packets only if they have previously elect to do so (by joining the specific multicast group address). Membership of a group is dynamic and controlled by the receivers (in turn informed by the local client applications).

(source: http://www.erg.abdn.ac.uk/users/gorry/course/intro-pages/uni-b-mcast.html)

This is more likely to fit your application. You'll have to select a good group endpoint depending on the network configuration, so it's slightly more involved.

Yet, you'll have support of all modern router hardware/software to ensure delivery to the interested parties (only).

Receive broadcast packets from IP 255.255.255.255 in ruby

Thanks for your help. During checking the router configuration I noticed that I had a wrong vlan configuration that result in this behavior.

how to read udp packets sent to 255.255.255.255

This is the C# code for a simple listener, it should be fine but I wrote this on my Mac so I can't test it.

using System;
using System.Net;
using System.Net.Sockets;
using System.Text;

public class UDPListener
{
    public static int Main()
    {
        var done = false;
        var listener = new UdpClient(31337);
        var ipe = new IPEndPoint("255.255.255.255", 31337);
        var data = String.Empty;

        byte[] rec_array;
        try
        {
            while (!done)
            {
                rec_array = listener.Receive(ref ipe);
                Console.WriteLine("Received a broadcast from {0}", ipe.ToString() );
                data = Encoding.ASCII.GetString(rec_array, 0, rec_array.Length);
                Console.WriteLine("Received: {0}\r\rn", data);
            }
        }
        catch (Exception e)
        {
            Console.WriteLine(e.ToString());
        }

        listener.Close();
        return 0;
    }
}