3

I have a service saying it is "broadcasting on 0.0.0.0" using interface eth0 with sendto().

However, when checking the traffic with tcpdump, it seems like it is broadcasting on the lo interface, and not on the network. For instance, I see messages like this on the lo interface, and nothing on the eth0 interface:

22:38:17.814047 IP localhost.14557 > localhost.14540: UDP, length 36

On the same machine as the one running the service, I can see the traffic with netcat by running:

$ netcat -l -u -p 14540

But I don't see this traffic from another machine (actually I am using docker containers).

To verify that the broadcast works between the containers, I run:

$ netcat -l -u -p 54321

on the first container, and:

$ echo "foobar" | netcat -ub 255.255.255.255 54321

I get "foobar" appearing on the terminal of the first container. As far as I understand, this means that I am broadcasting "foobar" over the zero network (0.0.0.0, same as the one claimed by my service above).

Why does my "foobar" broadcast go on the network (interface eth0) and the service broadcast messages stay local (interface lo)?

  • Do you mean that "0.0.0.0" is always equivalent to "localhost"? But what about the netcast broadcast on 255.255.255.255? Is it right to say that 255.255.255.255 is a broadcast address, but 0.0.0.0 is undefined behavior? – JonasVautherin Oct 31 '17 at 20:02
  • I see. But I was actually not using that. What I'm saying is that when I filter tcpdump on interface "lo", I see the traffic, but not on "eth0". Which suggests that broadcasting on 0.0.0.0 somehow goes to "lo", but I'm wondering if this is undefined behavior or not... – JonasVautherin Oct 31 '17 at 23:53

1 Answers1

1

As per RFC 1122, section 3.2.1.3 (a):

{ 0, 0 }

This host on this network. MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address.

One MUST NOT broadcast to 0.0.0.0.

So I guess this is undefined behavior, and it should be fixed in the service. The fact that it broadcasts on lo here is specific to this setup, but should not be generalized.