1

I have a peripheral device, connected via Ethernet to my Ubuntu. I would like to find out its IP, and untofetunately no it is not cached in my ARP table.

ARP broadcasts the messages to every reachable MAC-Address, right? So without a brute-force style scanning, I expect ARP protocol to be able to broadcast a request from my laptop, and I expect the peripheral to answer and show its IP.

Is there such a functionality, and if not, is there a good reason?

Improve this question
3
  • 2
    "Is there such a functionality, and if not, is there a good reason?" Network protocols are not designed for such discovery. You are supposed to know the address of a device you want to contact. The normal way to discover an unknown device is to have it subscribe to a predetermined multicast group to which you send a request, and the device responds with its information. That is how IPv6 does neighbor discovery and how properly written applications do it. Rookies write the application using broadcast (IPv6 did away with that), and companies now reject broadcast applications.
    – Ron Maupin ♦
    Jan 28, 2019 at 15:41
  • In embedded devices, legacy devices, specially when the previous team has failed to document enough.. such protocol would be really useful. I see how things 'normally' are as you describe, but i didn't read any justification. Maybe the one reason is just that not many people are facing these problems.
    – Makan
    Jan 29, 2019 at 9:40
  • 2
    But network protocols are designed to help hosts communicate, not help humans who lose track of them. What you are asking for does not facilitate the purpose of network protocols.
    – Ron Maupin ♦
    Jan 29, 2019 at 13:53

3 Answers 3

Reset to default
3

ARP broadcasts the messages to every reachable MAC-Address, right?

ARP requests are broadcast, ARP replies are normally unicast.

So without a brute-force style scanning, I expect ARP protocol to be able to broadcast a request from my laptop, and I expect the peripheral to answer and show its IP.

That's not how ARP works. ARP resolves the MAC address for a given IP address.

For the other way around (long obsolete) RARP was defined which resolved a given MAC address to one or more IP addresses (by asking a central RARP server). Its adoption was low and it was obsoleted when BOOTP and especially DHCP became popular - you can use a reservation on those to assign the desired IP address to a given MAC address.

There's also Inverse ARP, but I don't think it's ever been used.

In a nutshell: if there's no DHCP server you can ask you have to do a brute-force scan or alternatively use a higher-layer discovery method. For instance, you could craft a UDP packet addressed to 255.255.255.255 (or directed broadcast) in a unicast Ethernet frame.

As Ron Maupin has pointed out in his comment, the best practice and future-proof (IPv6) way to discover another machine is to use IP multicast. With the corresponding network configuration, multicast may even work across routers.

Improve this answer
2
  • "For the other way around RARP was defined which resolved a given MAC address to one or more IP addresses." No, RARP was to get an IP address for the requesting host. It was obsoleted by BOOTP and, most recently, DHCP. Inverse ARP is specific to things like frame relay and ATM.
    – Ron Maupin ♦
    Feb 23, 2022 at 17:31
  • @RonMaupin Yes and no - while ARP was (intended to be) used as something like DHCP or BOOTP, it was also a general MAC-to-L3-address resolution protocol. The RFC says It makes RARP a general facility that can be used for mapping hardware addresses to any higher level protocol address. Anyway, obsolete, dead and buried.
    – Zac67 ♦
    Feb 23, 2022 at 17:41
6

I expect ARP protocol to be able to broadcast a request from my laptop, and I expect the peripheral to answer and show its IP.

Not quite: You need to know the IP first. ARP is used to find the MAC address, given the IP. In effect, you ask, "What is the hardware address for IP a.b.c.d?" The computer with that IP address will answer with its MAC address. So, in order to get the MAC, you need the IP.

You can also listen for all ARP requests on the network. As various hosts send them or gratuitous ARPs, you can discover the MAC addresses of hosts on the network.

Improve this answer
2
  • 1
    ARP replies are unicast back to the requester, and listening for them would be a problem in switched ethernet, although hosts often listen to broadcast ARP requests to build their ARP tables, even though that really isn't what the RFC says hosts should do (they are supposed to update for existing table entries only, when hearing ARP requests and replies not meant for them).
    – Ron Maupin ♦
    Jan 28, 2019 at 14:12
  • Yes, I meant requests.
    – Ron Trunk
    Jan 28, 2019 at 14:27
1

Normally arp is a request-response protocol, the sender makes a arp request to translate an IP address to a MAC address. Unfortunately that doesn't help you here because you don't know the IP address.

It's worth starting the device while a packet sniffer is running to see if it tries to send anything.

Some devices will attempt to perform duplicate address detection on startup by sending an arp request for their own address.

It's also possible that during startup the device will try to communicate with some server and hence make an arp request either for the expected IP of the server or the expected IP of the default gateway.

AIUI You should be able to tell the difference between a duplicate detection arp and a regular arp by looking at the "sender address" field, it should be 0.0.0.0 for a duplicate detection arp and the sender's IP address for a regular arp.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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