Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How do I get the MAC address of my remote equipment? I have a Windows utility called Angry IP Scanner that pings all IPs in the range I give it (e.g. to avoid ipAddresses clashing on my LAN). Angry returns a stack of info about the remote, including
- Host Name
- Computer Name
- User currently logged in
- MAC Address
Is this program running Ping or something else? I can't seem to find any details on MAC in the man pages for PING.
In short, how do I determine the MAC of a remote device, running linux at both ends.
well angry ip runs on linux too, but that mac only comes from an arp request, it's nothing "interesting" really, and is only the information that you'll have in your local arp cache anyway. you won't get it if the scan is done on a non-local network as that data doesn't persist through a router.
Thanks for your help acid_kewpie, looks like I'm SOL... My remote device is on the other end of a mobile network, so I am jumping through a VPN and several routers to get there.
To describe my original reason for wanting to get the mac: We manufacture RTUs (Remote Telemetry Units), which we configure and test in shop before we send to the customer. A customer may get 5 RTUs and 5 cellular modems in a shipment. Each modem is in the RTU box that it belongs to, but the customer still has to install them, so they sometimes get shuffled.
The devices should connect automatically, they will be assigned a static IP address from the cellular network. Once it has connected, I can log in remotely and check if it is working OK. However, if RTU#1 has been given modem #2, when I telnet to the IP address of modem #1, the password for RTU#1 will not work. If I can get the mac of the remote, I can see what RTU is actually at that IP Address, then I can start work.
Nothing malicious, but I guess again the many suffer inconvieniences brought on by the evils of the few.
To describe my original reason for wanting to get the mac: We manufacture RTUs (Remote Telemetry Units), which we configure and test in shop before we send to the customer. A customer may get 5 RTUs and 5 cellular modems in a shipment. Each modem is in the RTU box that it belongs to, but the customer still has to install them, so they sometimes get shuffled.
The devices should connect automatically, they will be assigned a static IP address from the cellular network. Once it has connected, I can log in remotely and check if it is working OK. However, if RTU#1 has been given modem #2, when I telnet to the IP address of modem #1, the password for RTU#1 will not work. If I can get the mac of the remote, I can see what RTU is actually at that IP Address, then I can start work.
Nothing malicious, but I guess again the many suffer inconvieniences brought on by the evils of the few.
Writing this up in the OP may have saved you a lot of grief.
If you can telnet to something on the same subnet, you can
$ arping 127.34.24.12
Unicast reply from 127.34.24.12 [00:50:56:10:00:FD] 1.611ms
it if the OS running on the gear supports it. You could also ping it:
$ ping 127.34.24.12
from something you do have access to, then run
$ arp
to print out the arp cache:
Code:
Address HWtype HWaddress Flags Mask Iface
127.34.24.1 ether 00:1A:A1:94:AD:41 C eth0
127.34.24.12 ether 00:50:56:10:00:FD C eth0
127.34.24.13 ether 00:50:56:10:00:FE C eth0
See the mac address is how wire level network addressing happens. The IP address is easier and more logical for humans to route, deal with and organize in a much more orderly fashion than could be done with MAC (considering how ethernet works and the intended use of the MAC).
TCP IP was created to allow routing between broadcast domains, as opposed to enlarging them (a la bridging)
Much like a sort of wire level DNS, ARP stores a IP to MAC mapping in the arp cache in the network gear and stations. Any time you connect to a device over the network, within your broadcast domain, (often your subnet) you add that remote device's MAC to your ARP cache (aka table). Once you've communicated you need only to look up the MAC in your local ARP cache to address non routed packets.
Unfortunately ARP is only maintained and available within the broadcast domain. Outside of that it's been routed and this is done with a TCP/IP (and rarely IPX) address encoded in the packet headers. The network gear at the other end sorts out the ARP and routes the packet appropriately once it reaches the destination broadcast domain. The client doesn't need to know or care about the destination MAC unless it's communicating directly with it and there are no routers involved.
This is why you can't get the remote ARP unless you communicate with a program (such as an snmpd) running on the PC(or device) that will give it to you, or with a device on the same subnet where you can get a shell.
An interesting misconception about MACs is that you can use them for security to ID a NIC. Unfortunately a lot of gear can change the MAC on the fly, so that's kind of useless as a security identifier. The fact that it's "hard" set and burned into the NIC is a little misleading.
I would be looking at what is assigning those IP addresses, initially I'd assume DHCP reservations, but even if not there would be something presumably at MAC level involved in the assignment, and that in a log file would give you what you want.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.