Home / server / Questions / 1064486
In Process
user3018558
Asked: 2021-05-24 13:05:47 +0800 CST

Why can't I arping the direct broadcast of the LAN to populate the arp table?

  • 772

I'm trying to write a simple network discovery for my linux 2.6 router.

I'm testing arping which is bult inot busybox. I can't work out why sending a single request to the direct broadcast is not enough.

root@router:# arping -h
BusyBox v1.32.1 (2021-03-26 15:21:46 CET) multi-call binary.

Usage: arping [-fqbDUA] [-c CNT] [-w TIMEOUT] [-I IFACE] [-s SRC_IP] DST_IP

Send ARP requests/replies

        -f              Quit on first ARP reply
        -q              Quiet
        -b              Keep broadcasting, don't go unicast
        -D              Exit with 1 if DST_IP replies
        -U              Unsolicited ARP mode, update your neighbors
        -A              ARP answer mode, update your neighbors
        -c N            Stop after sending N ARP requests
        -w TIMEOUT      Seconds to wait for ARP reply
        -I IFACE        Interface to use (default eth0)
        -s SRC_IP       Sender IP address
        DST_IP          Target IP address

So at this point I try:

root@router:# arping -c1 -w1 -I br1 -s 10.10.11.5 10.10.11.255
ARPING 10.10.11.255 from 10.10.11.5 br1
Sent 1 probe(s) (0 broadcast(s))
Received 0 response(s) (0 request(s), 0 broadcast(s))

What am I missing here? I would expect all the devices within the LAN to answer the arp request but it doens't seems to happen. The only alternative I'm left is to send one arping per possible IP but this is extremely memory consuming considering the small device.

So in a nutshell: how can I make a single arping command to request a full subnet to respond so that my arp table can be considered a reliable source of info when it comes to network mapping?

Thanks!

linux networking arp busybox

1 Answers

  1. ARP (over Ethernet networks) is used to discover the Ethernet MAC address associated to the IP address of the target. An ARP request is always for a single target at a time. It doesn't matter for the explanation, but it's done initially as an Ethernet broadcast (FF:FF:FF:FF:FF:FF) so the not-yet-known target can receive it, and once the target is known, may be sent as a targeted unicast to refresh the cache.

    In the LAN 10.10.11.0/24 there is no system with the address 10.10.11.255, because it's by convention this LAN's directed broadcast address: when an IP datagram uses this address as destination, the Ethernet frame encapsulating it automatically gets for destination the Ethernet broadcast address (FF:FF:FF:FF:FF:FF) so that all systems receive it. That means that:

    • no host will send such ARP request or it is misbehaving, because it doesn't have to resolve any unicast MAC address when it already knows what destination MAC address to use when sending to an IP broadcast address: the broadcast Ethernet address FF:FF:FF:FF:FF:FF
    • no host will have this IP address (ie: use as source) or it is misconfigured (eg of misconfiguration: this IP address could have been affected to it without being considered as a broadcast address, probably because there's a different LAN netmask, like 10.10.11.255/21)
    • thus no ARP reply will ever be seen for this IP address even if an ARP request incorrectly asks for it.

    So in a network where all systems are correctly configured, sending an ARP to the IP LAN broadcast address just makes no sense and will result in no answer because there's nothing present to answer it.

    In a nutshell: you can't with a single arping command, you'll have to loop for it.

    • 2