I want to find the MAC address of a device. Example: Plug a network cable from my linux mashine to the target device, send some command, receive MAC.
The best solution I have now is to connect a router to the device, wait for it to give out a dhcp lease, connect to the router via ssh and read out the lease table.
I understand that dhcp servers wait for a request from the device and then give out a lease but I would like to actively send some request to the device and get the MAC from the answer directly.
The biggest problem seems to be that without running a dhcp server I can't communicate with the device. Can this be done through a lower layer? Maybe an ARP request?
Thanks!
Ping the other device first and the run the command
arp -a
You can see the MAC address of the device you just pinged.
If you don't know the MAC address of a device the only way to communicate with it is via some sort of broadcast. This implies that there is some software active on the host listening for such a broadcast that will reply. This is how hosts (using ARP) resolve MAC addresses on the local network from an IP address. ARP won't work for you unless you know the IP address.
If you just have a device with no protocol support you're stuck.
If you're using linux, there is wireshark (or the CLI version tshark):
sudo apt-get install tshark
sudo tshark -i eth0
You will see every packet your laptop or the attached device is sending over that ethernet interface. Assuming the device is powered on, you will probably see the MAC address you are looking for somewhere in all of the low level network protocol spew. If you aren't getting much spew, try re-plugging the ethernet cable. (Sorry; I came here looking for a better answer myself)
We solved this by listening for packets from the target mashine and extracting the mac address from the first packet we get.
Thanks for all the answers though!
Related
If I connect a device via ethernet onto a switch, and do not receive an IP address via DHCP, how do I determine what the correct settings for that network should be, i.e. how do I choose a static IP address, subnet mask and gateway?
The specifics in my case are that I have an NVR with an 8 port POE switch that has 3 cameras plugged into it. I plugged my Windows 10 PC into the switch, expecting to be issued an IP address from the NVR via DHCP, but my PC was not given an IP. Perhaps the NVR assigns IPs via BOOTP? I want to get onto the network, probably by assigning a static IP that's not already used, then determine the IPs of the cameras so I can stream video from them directly using VLC.
Can I use tcpdump? There should be plenty of traffic from the cameras to the NVR.
how do I choose a static IP address, subnet mask and gateway?
The short answer - this should be done by your network administrator. If you are the network administrator - you should. But seems that you are connecting to the network you know nothing about.. Anyway here are some points that perhaps can help you.
There is a special thing called ARP Duplicate Address Detection (DAD). In Linux you can check if the particular IP is occupied in your broadcast segment with help of arping utility. From MAN page:
-D
Duplicate address detection mode (DAD). See RFC2131, 4.4.1.
Returns 0, if DAD succeeded i.e. no replies are received.
So if IP address is occupied you will see something like:
-bash-4.4# arping -D 10.0.99.99 -I eth0
ARPING 10.0.99.99 from 0.0.0.0 eth0
Unicast reply from 10.0.99.99 [DE:AD:BE:EF:00:8D] 1.274ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
If this IP address is vacant, you'll see no responses. Read about ARP ping in Windows.
Also you can inspect the network through the tcpdump (to see some IP addressing info at least in broadcast packets), nmap and some other scanning utilities, but this topic is too broad (and at the same time it's well disclosed on the Internet). Btw you have to consider network architecture difficulties: vlan and so on.
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
I'm trying to get Age of Empires II (AoE2) to work on my LAN. AoE2 is notorious for it's connectivity problems on modern systems, probably because it used a now deprecated network framework called DirectPlay (in DX9) and the code probably wasn't robust back in the day either.
When I host a LAN game on a computer (win7) for AoE2, Wireshark shows my computer sending a couple packets via SSDP protocol to the multicast address 239.255.255.250. This actually goes to my router (for forwarding I assume) and my router returns a packet using ICMP protocol that says "Destination unreachable (Port unreachable)". Because nothing is forwarded to the other computers on the network, they can't see the game that the host has created.
I think I need to get the application/windows7 to send the packet as something like a broadcast, or I need to get the router to broadcast packets going to that multicast address. Does anyone have thoughts or suggestions on how to do this?
My router/gateway is running DD-WRT firmware v24-sp2.
My first guess is you're using wifi, by default most systems disable multicast on wifi because it can have a detrimental effect on the time slicing that wifi uses. however for just a couple machines it shouldn't be an issue.
here's how to disable multicasting but it should point you in the right direction for enabling it: ddwrt multicast
Secondly make sure they are all in the same VLAN a VLAN is defined as a "broadcast domain" meaning machines on separate VLANs will NEVER get broadcast or multicast from other VLANs without some trickery.
Lastly make sure you've enabled multicasting between LAN ports I believe the option is "multicast forward"
Edit: Just a few things to add to the list in case others have this issue. Broadcasting doesn't exist in ipv6, also a machine running ipv6 MAY NOT see broadcasts from a machine on ipv4 and a machine on ipv4 WILL NOT see multicasts to an ipv6 multi-cast address.
Have you tried LogMeIn Hamachi?
Is not a LAN client itself but it creates a fake Online-LAN and gives you a working IP that will allow you to play with who have it.
I am trying to send data using the AsyncUDPSocket class. And I can send data using the iPhone simulator over the wire to another machine that is running a simple C-coded listening server. I can also receive data over the wire using a client connected to the simulator(server). However, when I tried the same over Wifi, using the simulator, I could only send data but not receive any data.
I read on another post, that unicast data makes this possible. How can I acheive this using AsyncUDPSocket?
Thanks,
Angelo.
Ok, I figured this out. A newbie kind of thing, really.
When I set my Mac network preferences to Ethernet, I get an IP for me to communicate. However, when I turn Airport(Wi-Fi for more newbies) ON, and ethernet cable disconnected, I checked my network preferences, and sure enough my IP address was a different one.
Spoke to a friend (an ace in networking) and the thing clicked immediately: On WiFi networks a DHCP server allocates an IP address. This IP address has to be reserved, at the very least, at the DHCP server. Since my IP was not reserved, I had to change the IP address, in my udp_client.c file, recompile and run the client to connect.
BTW, I can now communicate between my iPhone and my PC using my local WiFi (office) network.
For any who might face the same problem, do not be assured that the IP address of your mchine is the same, when you switch from LAN to Wifi, and use the device mostly for WiFi reated testing. :)
How do I discover the MAC address of machines in a network?
I need to discover the machines that are available just with only BIOS installed (no operating system present). And I need to find the MAC address of machines that are up.
I won't have physical access to the machines. This is for baremetal discovery!
You can use WinPcap to monitor the Ethernet traffic on your network in the same collision domain. So you could learn all the MAC addresses just as a switch does. You could also fake some DHCP messages in order to create some traffic. But this only works with PXE (which is actually made for this scenario) and in your own collision domain.
Since the machines probably don't have IP addresses, I don't think you have a chance to actively query them. They would need to answer packets sent to the broadcast MAC and for e.g. ICMP echo requests, they'd need to send packets with something like 0.0.0.0 as a source IP. This is common and allowed for BOOTP/DHCP, but I haven't seen anything like this implemented by BIOSes yet.
Maybe just logging all MACs that go over the wire with a tool like arpwatch would help? If the machines have PXE booting enabled, you should at least see some DHCP DISCOVERs, before they leave into eternal silence.
A just-not-as-"nice" solution as the ones suggested above (working over a network is just comfortable):
If you have physical access to the machines: Plug in a monitor and look the MAC address up in the BIOS. If for some reason the MAC address isn't listed in the BIOS, you could enable PXE. After reboot, when PXE is initializing, you're going to see the MAC address.
Try the arp command. I am not sure it will be really helpful for you as it might only work for PC with an IP address (and likely to have an OS).
If your computers are connected to a switch I guess you can have this information from it. Many "modern" switches are able to provide you with that information, should you know which PC is connected to which port on the switch.