Initial UDP Datagrams Disappearing

---

A commonly seen behavior with UDP sockets (typically in embedded environments) consists of an initial set of UDP datagrams disappearing when communication first begins with a new peer. Typically, a set of UDP messages is emitted quickly upon boot of the TCP/IP stack, but the first few (depending upon the rate of transmission) are lost. Hooking up a trace tool shows that the packets are never actually seen being emitted from the interface (recall that UDP is an unreliable protocol).

What is happening here is a side effect of ARP, the Address Resolution Protocol. The lowest-level protocol on an Ethernet network is the Ethernet protocol. The Ethernet protocol, which provides for local communication between nodes on an Ethernet LAN, utilizes a 48-bit address that is unique across the entire world. ARP takes care of taking an IPv4 address and then identifying the Ethernet address to which datagrams should be directed. ARP is a discovery process, which commonly operates when the address is required. Therefore, when the first UDP datagram arrives for transmission, ARP sends out an ARP request to identify the Ethernet address for the given IPv4 address. This may take some number of milliseconds before the response arrives. Once the ARP reply is received, the datagram is loaded with the Ethernet address and the packet is emitted onto the wire.

During this period that ARP is awaiting a reply, our initial datagram is stalled. Now, what happens when an additional datagram is emitted on the socket while the ARP reply is still outstanding? Commonly, the UDP layer destroys the datagram and replaces it with the current. This means that all UDP datagrams that are written before the ARP response is received are destroyed, leaving only the last datagram that was provided to the stack before the ARP request was satisfied.

---