Is it possible to check if host with secific MAC address are 'alive' ?
I do NOT want to use 3-rd layer ISO/OSI and ICMP ping message
You can do an ARP Ping. This only works when you are physically on the same network segment. Read more about this on Wikipedia's ARP Ping article.
Note that there are two different implementations of arping, one which can ping MAC addresses to resolve them to IP addresses and one that doesn't. The implementation in the iproute2 package does not do what you want, but Thomas Habets implementatation does. This is also explained in the Wikipedia ARP Ping article
Related
I'm currently learning about ARP and L2/L3 networking - would someone be able to help out? If I use an ethernet cable to connect my laptop (A) to another laptop (B), it could use ARP to find out B's MAC address based on B's IP address. Then, any ethernet frames could be sent and accepted by B.
But how does A know B's IP address in the first place? What if there is a switch (L2 device) in between A and B? Does this change the answer? What if there was a router in between (an L3 device)?
Usually, a switch/Router will assign an IP.
The question is unclear -
find out B's MAC address based on B's IP address.
B's MAC address is not based on B's IP.
A MAC is associated to the hardware (but somewhat assignable/cloneable) where as an IP is assigned. Either by DHCP or statically by an admin.
Effectively, you need a switch/router to make what you're defining work.
EDIT:
you can connect two computers direct, but you still need to give each a static IP address so they can find each other - this would likely not be ona network so the IP sub-network doesn't matter.
It still has very little to do with MAC.
If two PC's hand-shake, they'll see each others MAC.
It sends out a broadcast packet to the broadcast MAC address asking "who has the IP address x.x.x.x" which goes to all computers on that broadcast domain. If a computer sees that packet that owns the IP address "x.x.x.x" it will send a unicast reply back to the MAC address of the original requestor with its MAC address which will then be cached for further communication.
It doesn't know the IP unless you tell it. You say "the default gateway is 192.168.1.1" and it will start trying to talk to 192.168.1.1 etc.
If there is a router in between, all traffic to the remote device would go to the MAC of the router and your computer wouldn't be doing any ARP lookups other than that router.
Switches wouldn't matter for this, all they do is make the broadcast domain bigger. With a cable the broadcast domain is just you and the remote device. With a switch, it expands that to all devices connected to the same switch (or VLAN in the switch)
But how does A know B's IP address in the first place?
It doesn't know. At least there's no general method to find out.
The IP address of any resource needs to be supplied by "something else". You need to either provide the address yourself, resolve it from a (also provided) DNS name, read it from a file, ... Alternatively, you need to provide some kind of auto discovery between the nodes (broadcast, multicast, LLDP, ...) or provide a commonly known discovery service, registration server or similar.
What if there is a switch (L2 device) in between A and B?
That changes nothing but excludes link-level discovery (unless it's a "dumb" switch that simply forwards those frames).
What if there was a router in between (an L3 device)?
That eliminates broadcast and multicast from the picture. (Multicast could be routed but that is unlikely for discovery and I won't dive into that.)
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.
I recently found that packets are encapsulated within ethernet frames. Packets use IP addresses, frames use MAC addresses.
Why aren't IP addresses used in ethernet frames for routing? I understand that when trying to access a basic website, the computer goes to a DNS to find the IP address relevant to the user-entered domain name. How do computers find the correct MAC address?
Really, how are MAC addresses used in routing internet traffic?
Thanks
IP packets aren't always encapsulated in Ethernet frames. There are other physical media such as ISDN, etc. When packets are routed, IP addresses are used to determine the next hop and the physical address is used to physically identify the interface serving as the next hop. Only the former (determining next-hop) is usually called routing.
To answer your second part, MAC addresses are discovered through ARP (Address Resolution Protocol) in IPv4 & ND6 (Neighbor Discovery) in IPv6.
Update:
The destination IP address in the IP header is the final destination. In the process of routing (at each hop), you get the next hop's IP address to (eventually) reach the final destination from the routing table (this could be a default gateway's IP address). To send the packet to the next hop, you need its MAC address. While hopping through intermediate links, the IP address in the IP header don't change - only the MAC addresses change.
Bit late but still here is my answer :) ...
To send data you need two address, the MAC address and the IP address.
Basically the sending host will ARP for a MAC address, this occurs when the local host doesn't know the MAC address of the host it has an IP address for or it will ARP for the default gateway MAC address (if it doesn't already know it) if the IP address in on a different subnet/ network. Once it obtains a MAC address the IP packet is encapsulated in a L2 frame and sent across the media. If the IP packet is meant for a host on a different subnet/ network, it will be sent to the default gateway, this router will de-encapsulate the L2 frame (remove and discard it) check the IP address and will forward it. For the router to do this it needs a MAC address to send it over the media, It will look up the next hop in it's routing table, encapsulate the IP packet with the same source and destination IP address that was sent from the original host into a new L2 frame. This time the MAC address for the source address will be that of the forwarding interface of the router, and the receiving interface of the next hop will be the destination MAC address. This will continue from hop to hop until it reaches the final host, each time the MAC addresses will change, but the original IP address will remain the same.
Here's the key point -- there can be more types of packets than INTERNET traffic. You could be using IPX, which is non-routable. How do clients identify each other? By the MAC address.
Routing != Addressing, which is really where the MAC comes into play.
In order to be routed, the OSI model adds a layer to allow for path discovery to the next gateway. This layer is responsible for routing, but knows nothing about the MAC address.
As a side note, at the hardware level, MAC addresses ARE used by switches, but not for routing. From How Stuff Works:
The switch gets the first packet of data from Node A. It reads the MAC
address and saves it to the lookup table for Segment A. The switch now
knows where to find Node A anytime a packet is addressed to it. This
process is called learning.
In this way, a switch can make sure that traffic is only outputted to the correct port. This isn't accomplishing routing so much as reducing network congestion. Only broadcasts and traffic destined specifically for that MAC address should be sent out the port.
Recently I have been thinking about the same and came upon this question. Here is my answer to this question. Actually MAC address is needed for correctly sending the packet to right destination. This is specially true when packet is needed to sent over a VLAN. There can be multiple switches/routes connected on that VLAN over multiple physical interfaces. However IP Routing is unaware of these physical interface. It only knows about the logical connectivity. For example, route 10.10.10.0/24 is reachable via VE/VIF0.10(logical VLAN interface) and/or nexthop neighbor is 20.20.20.1. There could be multiple interfaces under VLAN 10. Then to which interface packet is sent out? This is where ARP comes in the picture. ARP helps to discover the MAC address associated with the next-hop IP address. When switch/router learns the nexthop MAC. along with that it learns the physical interface also via which that MAC is reachable. Hence while routing packet, firstly MAC corresponding to the destination IP is searched and then the physical interface associated with that MAC is searched. Finally packet is sent out via that physical interface. The MAC corresponding to that destination IP is used as destination MAC. In absence of this, routed packets will always be flooded in the outgoing VLAN.
Hope this helps.
Thanks.
Answer: MAC addresses are not used in the process of routing of a packet.
segment -> transport layer (TCP ports)
packets -> network layer (IP addresses)
frame -> data link layer (MAC addresses)
bits -> physical layer (electric/optical signals)
Create your own packet/segment visit http://wirefloss.com/wireit/
There are 2 models (TCP/IP and ISO/OSI)
In detail:
Your app has some data. This is encapsulated by mentioned layers. Encapsulation means that a header with fields is added at each layer. If your data never leave the local network the MAC address will be the same. Once your data needs to be delivered outside your network the frame header is stripped by router and is replaced by router fields.
UPDATE 2021: Some people seems never heard of ISO OSI model and put this answer as incorrect.
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 looking for some Linux code to find an IP address from an Ethernet address. I suppose I have to do some inverse ARP trickery but I don't find any example...
http://compnetworking.about.com/od/networkprotocolsip/f/convertipmacadd.htm
Try sending an IP broadcast (e.g. ping 192.168.1.255 if your subnet is 192.168.1.0/24) to prime your ARP cache, followed by arp -a to spit it all out.
For computers that you have communicated with, you can look at their arp entry. This is available in text format in /proc/net/arp for example. Finding an IP address for a MAC that you know but haven't communicated with is significantly more difficult. The closest match, protocol-wise, would be RARP but that's hardly ever in use so your are not likely to get a response.
You can always scan your local subnet to make sure you get a full view in your arp table. See for example fping for an efficient way to do this. Note that hosts don't actually need to respond to the pings in question to appear in the ARP table, so this is useful even in the presence of local firewalls etc.
Take a look at Thomas Habet's Arping. I've not tried it, but the basic idea is to send an ICMP Ping network packet to the MAC address in question using a broadcast destination IP address in the IP header. Only the host with the specified MAC address will reply and the reply will (usually) contain its IP address. It won't always work but it might be good enough for you. See the project readme for limitations.