2

This question already has an answer here:

I'm new to advanced network administration and I would like to do some testing with UDP broadcasting, so I need a broadcast address on my loopback interface. The machine is offline, in other words, there is no network.

How can I accomplish that through ifconfig without having to buy a switch as one user in the comments suggested. In Linux all i have to do is use 127.255.255.255 and broadcasts work fine without any network or any switch. If I have a network i can just use 255.255.255.255, obviously.


Here is how you can check for yourself that it works on linux but not in os/x:

  1. Open two terminals and type on both of them:

    nc -u -l 55555

  2. Open a third terminal, install socat if necessary and type: (in case you ask netcat does NOT support broadcast)

    echo -n "TEST" | socat - udp-datagram:127.255.255.255:55555,broadcast

  3. You should see both terminals receiving the message.

If you try the same experiment with 127.0.0.1, only one terminal will get the message as expected.

Performing the same test on OS X does not exhibit the same behavior.

What I am looking for is a software workaround for broadcasts if possible.
I cannot use multicast (it has to be broadcast) and I cannot test that over a network (machine offline).

marked as duplicate by voretaq7 Nov 13 '13 at 17:01

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    You don't. ifconfig lo0 broadcast 127.255.255.255 will result in OS X ignoring your request (sudo or not). Also... you realize that 127.0.0.1/8 is a Class A network right? Are you sure you want to storm your loopback interface with >16 million UDP packets at a time? – Mathias R. Jessen Nov 12 '13 at 18:18
  • OSX is based on BSD and both use ifconfig. That's deprecated in Linux, they use ip. – Chris S Nov 12 '13 at 18:24
  • @MathiasR.Jessen I noticed that ifconfig does not work. So how do I get a broadcast ip to test? – bandodeotarios Nov 12 '13 at 18:32
  • Go out and buy the cheapest ethernet switch you can find, connect it to your ethernet adapter, configure the interface with an RFC1918 address, set a network mask of 255.255.255.0 and start sending packets to .255 in that segment and see if you receive them - this is not rocket science and I'm inclined to close vote this question as it lacks both a professional aspect and displays a minimal understanding of the issue at hand – Mathias R. Jessen Nov 12 '13 at 20:58
  • @MathiasR.Jessen For that matter you don't always need to buy a switch. On FreeBSD you should be able to use the epair device driver, which would behave line a pair of NICs connected via a crossover cable. The use cases for this sort of voodoo are limited, but this might be one of them. – voretaq7 Nov 13 '13 at 3:07
9

You do not "add" a broadcast address. You direct traffic to the broadcast address of a network.
The broadcast address is an entirely virtual concept, and should not be "added" or otherwise assigned to any host in normal practice.

The exception to the above rule is specifying the broadcast address (using ifconfig broadcast) which is done in cases where the broadcast address may be nonstandard. Generally if you nave to use the broadcast option to ifconfig you're doing something strange, and probably wrong...

If you want to send a broadcast to the 127.0.0.0/8 (local/loopback) network you would theoretically simply direct traffic to 127.255.255.255, but if you try doing that you'll find that it DOES NOT work because the loopback device does not support BROADCAST traffic.

You can check this for yourself by running ifconfig lo0 on your mac, which will produce output like:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=3<RXCSUM,TXCSUM>
    inet6 ::1 prefixlen 128 
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    inet 127.0.0.1 netmask 0xff000000 
    nd6 options=1<PERFORMNUD>

Note the lack of BROADCAST in the flags field.
Configuring the device with a broadcast option (address) specified results in the address being ignored. A BSD or Linux (Debian) box behaves similarly, and I'd expect other platforms do as well, though you may find an odd duck that allows you to set the BROADCAST flag on the loopback device if you search hard enough.

The logic behind this is discussed in this FreeBSD mailing list post. An alternate reasoning for not allowing broadcast is also discusses in the comments on this Server Fault answer, which proposes the alternative of using MULTICAST (which is typically supported by the loopback interface).


Specifically regarding your test case: What you are seeing is not expected behavior. I was able to reproduce your behavior, but only in a very narrow set of circumstances.

For a more robust test that shows that broadcasts on the loopback device in fact does not work on Linux try the following test case on a handy Linux machine (my test case: Ubuntu 13.04):

  • Configure a second address (third, fourth, fifth -- however many you want) on your loopback interface.

  • Start a netcat instance listening on each loopback address, e.g. --
    nc -u -l 127.0.0.1 5555
    nc -u -l 127.0.0.2 5555
    nc -u -l 127.0.0.3 5555
    ...etc

  • Run your broadcast test command using socat
    echo TEST | socat - udp-datagram:127.255.255.255:5555,broadcast

You will note that none of your netcat windows receive the message (Expected Behavior as the loopback interface does not advertise support for BROADCAST in its flags field), however if you address them directly (e.g. echo TEST2 | socat - udp-datagram:127.0.0.2:5555) they receive the message with no problem.

The "solution" you are asking for does not exist (or at least should not work) on any platform unless the loopback interface supports BROADCAST (as can be determined by the flags field in ifconfig) -- The platform(s) you are talking about do not advertise support for broadcasting on the loopback interface, therefore you cannot do what you're asking.

  • Nice answer. Thanks! So If I don't have a network it can`t be done. That sucks! Men is able to go to the moon and come back, but not able to support loopback broadcast in FreeBSD as Linux does? I am in really need for a workaround for that. – bandodeotarios Nov 13 '13 at 16:19
  • @bandodeotarios Read my answer again. This doesn't work on my Linux (Debian Sarge, and I just tried on Ubuntu 13.04 with the same results) as those don't support BROADCAST on the loopback (lo) device. If you've got a system where this does work you should update your question to tell us what system it is (distribution and release) and how you achieved these results, because its behavior seems to be in the minority. – voretaq7 Nov 13 '13 at 16:55
  • I tried on Ubuntu and 127.255.255.255 works very fine. – bandodeotarios Nov 13 '13 at 17:41
  • @bandodeotarios Interesting, I get no responses to a broadcast ping on Ubuntu (even with multiple addresses configured). Again I'd like you to edit your question to tell us how you accomplished this (or stop by the chat room and explain), because my ubuntu machine doesn't support the BROADCAST flag on the loopback device. (I'll be honest, unless you can show me how to repeat the behavior in my environment I think you're mistaken about the behavior you're claiming. I tried a bunch of things assuming Linux would be the white elephant, but none worked) – voretaq7 Nov 13 '13 at 17:47
  • 1
    I can be wrong here, but I believe you MUST bind to 0.0.0.0 OR the broadcast IP in order to get broadcast. Binding to a non-brodacast IP like you did won't work as expected. I agree that the loopback does not advertise the broadcast flag, but still it supports it on 127.255.255.255. If it is a hack, a bug or a feature I don't know. But it looks like it does support it. – bandodeotarios Nov 14 '13 at 18:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.