12.3 Broadcasting Examples

How are broadcasts sent and what do routers and hosts do with broadcasts? Unfortunately this is a hard question to answer because it depends on the type of broadcast address, the application, the TCP/IP implementation, and possible configuration switches.

First, the application must support broadcasting. If we execute

 sun  % ping 255.255.255.255  /usr/etc/ping: unknown host 255.255.255.255

intending to send a broadcast on the local cable, it doesn't work. But the problem here is a programming problem in the application ( ping ). Most applications that accept either a dotted -decimal IP address or a hostname call the function inet_addr (3) to convert the dotted-decimal character string to its 32-bit binary IP address, and if this fails, assume the character string is a hostname. Unfortunately this library function returns -1 to indicate an error (such as a character other than a digit or decimal point in the string), but the limited broadcast address (255.255.255.255) also converts into -1. Most programs then assume that the character string is a hostname, look it up using the DNS (Chapter 14), and end up printing an error such as "unknown host."

If we fix this programming shortfall in the ping program, however, the results are often not what we expect. On six different systems tested by the author, only one handled this as expected and generated a broadcast packet on the local cable. Most looked up the IP address 255.255.255.255 in the routing table, applied the default route, and sent a unicast packet to the default router. Eventually the packet was thrown away.

A subnet-directed broadcast is what we should be using. Indeed, in Section 6.3 we sent datagrams to the IP address 140.252.13.63 for the bottom Ethernet in our test network (inside front cover), and got replies from all the hosts on the Ethernet. The subnet-directed broadcast address associated with each interface is the value used with the ifconfig command (Section 3.8). If we ping that address, the result is what we expect:

 sun %  arp -a   ARP cache is empty  sun  % ping 140.252.13.63  PING 140.252.13.63: 56 data bytes    64 bytes from sun (140.252.13.33): icmp_seq=0. time=4. ms    64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=172. ms    64 bytes from svr4 (140.252.13.34): icmp_seq=0. time=192. ms    64 bytes from sun (140.252.13.33): icmp_seq=l. time=1. ms    64 bytes from bsdi (140.252.13.35): icmp_seq=l. time=52. ms    64 bytes from svr4 (140.252.13.34): icmp_seq=l. time=90. ms  ^?   type interrupt key to stop  ----140.252.13.63 PING Statistics----    2 packets transmitted, 6 packets received, -200% packet loss     round-trip (ms) min/avg/max = 1/85/192    sun %  arp -a   check ARP cache again  svr4 (140.252.13.34) at 0:0:c0:c2:9b:26    bsdi (140.252.13.35) at 0:0:c0:6f:2d:40

IP looks at the destination address (140.252.13.63), determines that it is the subnet-directed broadcast address, and sends the datagram to the link-layer broadcast address.

We mentioned in Section 6.3 that this type of broadcast means all the hosts on the local network, including the sender. We see here that we do get a reply from the sending host ( sun ) in addition to the other hosts on the cable.

In this example we've also shown the ARP cache before and after the ping of the broadcast address. This is to show the interaction between broadcasting and ARP. The ARP cache is empty before we execute ping, but full afterward. (That is, there is one entry for every other host on the cable that responded to the echo request.) How did this happen when we said that the Ethernet frame is sent to the link-layer broadcast address ( 0xffffffff )? The sending of these frames by sun does not require ARP.

If we watch ping using tcpdump, we see that it is the recipients of the broadcast frames that generate an ARP request to sun, before they can send their reply. This is because the reply is unicast. We said in Section 4.5 that the receiver of an ARP request ( sun in this example) normally adds the requestor's IP address and hardware address to its ARP cache, in addition to sending an ARP reply. This is on the assumption that if the requestor is about to send us a packet, we'll probably want to send something back.

Our use of ping is somewhat special because the type of programming interface that it uses (called "raw sockets" on most Unix implementations ) always allows a datagram to be sent to the broadcast address. What if we use an application that was not designed to support broadcasting, such as TFTP? (We cover TFTP in more detail in Chapter 15.)

 bsdi %  tftp   start the client  tftp>  connect 140.252.13.63   specify the IP address of the server  tftp>  get temp.foo   and try to fetch a file from the server  tftp: sendto: Permission denied    tftp>  quit   terminate the client

Here we get an error immediately, and nothing is sent on the cable. What's happening here is that the sockets API doesn't allow a process to send a UDP datagram to the broadcast address unless the process specifically states that it plans to broadcast. This is intended to prevent users from mistakenly specifying a broadcast address (as we did here) when the application was never intended to broadcast.

With the sockets API the application must set the SO_BROADCAST socket option before sending a UDP datagram to a broadcast address.

Not all systems enforce this restriction. Some implementations allow any process to broadcast UDP datagrams, without requiring the process to say so. Others are more restrictive and require a process to have superuser privileges to broadcast.

The next question is whether directed broadcasts are forwarded or not. Some kernels and routers have an option to enable or disable this feature. (See Appendix E.)

If we enable this feature on our router bsdi and run ping from the host slip, we can see if the subnet-directed broadcasts are forwarded by bsdi. Forwarding a directed broadcast means the router takes the incoming unicast datagram, determines that the destination address is the directed broadcast for one of its interfaces, and then forwards the datagram onto the appropriate network using a link-layer broadcast.

 slip %  ping 140.252.13.63  PING 140.252.13.63 (140.252.13.63): 56 data bytes     64 bytes from 140.252.13.35: icmp_seq=0 ttl=255 time=190 ms     64 bytes from 140.252.13.33: icmp_seq=0 ttl=254 time=280 ms (DUP!)     64 bytes from 140.252.13.34: icmp_seq=0 ttl=254 time=360 ms (DUP!)     64 bytes from 140.252.13.35: icmp_seq=1 ttl=255 time=180 ms     64 bytes from 140.252.13.33: icmp_seq=1 ttl=254 time=270 ms (DUP!)     64 bytes from 140.252.13.34: icmp_seq=1 ttl=254 time=360 ms (DUP!)  ^?   type interrupt key to stop  --- 140.252.13.63 ping statistics ---     3 packets transmitted, 2 packets received, +4 duplicates, 33% packet loss      round-trip min/avg/max = 180/273/360 ms

We see that this does indeed work. We also see that the BSD ping program checks for duplicate sequence numbers and prints DUP! when this occurs. It normally means a packet was duplicated somewhere, but here we expect to see this, since we sent the requests to a broadcast address.

We can also run this test from a host much farther away from the network to which the broadcast is directed. If we run ping from the host vangogh.cs.berkeley.edu (14 hops away from our network), it still works if the router sun is configured to forward directed broadcasts. In this case the IP datagrams (carrying the ICMP echo requests) are forwarded by every router in the path as a normal datagram. None of them knows that it's really a directed broadcast. The next to last router, netb, thinks it's for the host with an ID of 63, and forwards it to sun. It is the router sun that detects that the destination IP address is really the broadcast address of an attached interface, and turns the datagram into a link-layer broadcast on that network.

Broadcasting is a feature that should be used with great care. In many cases IP multicasting will prove to be a better solution.