I came back from the Wireshark Sharkfest '11 Conference excited to try some of the things I had learned. Imagine my dismay when I fired up my Windows 7-64 test box only to find that certain parts of NetScanTools Pro 11 that are IPv6 aware ceased working. Immediately I was able to see that it was the parts of the program that depended on the getaddrinfo function call that were failing. How did I know that? I used the other 'home-grown' NetScanTools resolver functions to talk with DNS (they bypass Windows resolver entirely and talk directly to any DNS) and by using Wireshark I could see the AAAA records coming back from DNS. I could see that the getaddrinfo function was not getting and reporting the IPv6 AAAA records. Very strange.
So I looked at a couple of things. First I did a cursory check of the network settings with ipconfig. All appeared normal. Then I spent some time recompiling NetScanTools Pro while playing around with various options in the addrinfo hints structure passed into getaddrinfo. That was not fruitful. Nothing I did could make the getaddrinfo function return the AAAA record. I was seeing the 11004 WSANO_DATA error. So I put that aside and looked more carefully at the IPv6 networking subsystem.
Next I tried to see if it was NetScanTools failing or something deeper. So I tried using command line "ping -6 ipv6.google.com". This failed with a message effectively admitting that it couldn't resolve the hostname to an IPv6. Good - sort of. Next I tried the other way doing a "ping -6 2001:4860:b006::69". That came back with even more ominous wording "Ping transmit failed. General Failure.". But I could use both command line ping and NetScanTools Pro IPv6 Ping to contact Link-Local IPv6 addresses on my local network - as I should be able to do. The IPv6 routing table didn't yield any real clues either.
Using both NetScanTools Pro, ipconfig and various netsh command line things I was able to see that while isatap was active, I was not seeing teredo - I had seen it before when using command line ping and when using NetScanTools Pro. Teredo was what I wanted to try decoding with Wireshark. NetScanTools Pro showed me that Teredo was there but it had an admin status of 'Down'. So I tried various netsh commands to reactivate Teredo. They all appeared to work, but Teredo never reappeared in the list of hidden devices in Device Manager. I tried the solutions floating around on the internet for making sure IPv6 was active and getting Teredo to show up in Device Manager, but still no luck.
A little history might help. I had recently installed VMware Workstation 7.1.4 on that machine because it's a test machine and I needed lots of OS's available. Could it be that? I don't know for sure because I spent time on VMware forums looking for similar problems - but didn't see any. It could have been a Windows Update patch that turned off Teredo, but I just don't know for sure. The two VMware Virtual Ethernet Adapters both had link-local fe80 IPv6 addresses, so IPv6 wasn't entirely dead. AND of all things, I could start Windows Server 2008 in a virtual machine with all of it's IPv6 functions working perfectly including NetScanTools Pro. I did find this page dealing with firewall settings for Teredo and found that everything was OK: http://support.microsoft.com/kb/968510
So today I spent lots of time with the netsh commands. I used "netsh interface IP show config" to see all the interfaces similar to ipconfig. By doing a "netsh interface ipv6 show interface" I could see all the active connections. What was missing was Teredo. I used "netsh interface set interface teredo set state default" to make sure it was there and it answered OK. But still no Teredo. Then I found this interesting command "netsh interface IPv6 show teredo". It said the State was 'offline' and the Error value was "client is in a managed network". Progress. Big progress.
So I put that error string into google and found a reference to this blog: http://blogs.msdn.com/b/p2p/archive/2007/03/22/teredo-and-the-pnrp-global-cloud.aspx
Essentially Teredo detected (incorrectly) that the machine was in a corporate environment - this is probably due to multiple OS's and several switches being active with all their chatter. So the fix was to use "Netsh interface teredo set state enterpriseclient". Once I did that, there was no need for rebooting or anything. "netsh interface IPv6 show teredo" now showed the correct info like Local Mapping and External NAT Mapping. And all of a sudden both command line ping and NetScanTools Pro IPv6 enabled tools began to work again.
I guess the thing that bugs me is this: why is there this huge dependency on Teredo for IPv6 in Windows 7? If I ask for a name resolution using getaddrinfo with a hint of AF_INET6 I EXPECT a response if AAAA records are coming back from the default dhcp assigned system DNS. It shouldn't matter that IPv6 is fully enabled on the system using Teredo or anything else. So my workaround will be to write EXTRA CODE to resend an AAAA or PTR record request from my own private resolver on failure of getaddrinfo because I can't trust it. I hope someone at Microsoft reads this and helps me understand why it was behaving this way.
All I wanted to do was try to decode Teredo traffic with Wireshark...
Kirk Thomas
NetScanTools Developer and Sharkfest '11 attendee
Showing posts with label ARP Ping. Show all posts
Showing posts with label ARP Ping. Show all posts
Tuesday, June 21, 2011
Wednesday, October 28, 2009
How to use ARP Ping to Detect Duplicate IP Addresses
Update January 2014: there is a dedicated Duplicate IP Address Scanning Tool in NetScanTools Pro.
I've mentioned before how due to past problems with online games sites I have my son use a Linux distribution called Knoppix 6.0.1 that runs from a CD inside a Microsoft Virtual PC 2007 virtual machine. Well due to a problem with a DHCP server, I found that Knoppix was taking the same IP address as an HP Laser Printer. I had been having trouble with the printer on the weekend - it decided on it's own to change it's fixed IP address.
So I decided to use the situation as a real world demonstration of how to find a duplicate IP address. This can be done from NetScanTools Pro using the ARP Ping Tool. Since I had my suspicions about the printer, I used the printer IP. The video shows the results quite clearly.
http://www.netscantools.com/videos/duplicateipdetect/duplicateipdetect.html
In NetScanTools Pro v11 we will be introducing a tool to scan the whole subnet for duplicate IPs, not just one at a time.
I've mentioned before how due to past problems with online games sites I have my son use a Linux distribution called Knoppix 6.0.1 that runs from a CD inside a Microsoft Virtual PC 2007 virtual machine. Well due to a problem with a DHCP server, I found that Knoppix was taking the same IP address as an HP Laser Printer. I had been having trouble with the printer on the weekend - it decided on it's own to change it's fixed IP address.
So I decided to use the situation as a real world demonstration of how to find a duplicate IP address. This can be done from NetScanTools Pro using the ARP Ping Tool. Since I had my suspicions about the printer, I used the printer IP. The video shows the results quite clearly.
http://www.netscantools.com/videos/duplicateipdetect/duplicateipdetect.html
In NetScanTools Pro v11 we will be introducing a tool to scan the whole subnet for duplicate IPs, not just one at a time.
Friday, January 23, 2009
Pinging a MAC Address
Twice in the last month I've picked up the phone to answer a presales tech support call and I had to gently answer this question: "Can your software help me find my laptop? someone stole it, but I know it's MAC address. Your software has something called ARP Ping. I want to use it to ping my lost laptop!"
What they really wanted was to do some kind of trace or ping to the laptop's MAC address and get a response back if it happened to be online somewhere on the internet. Since our software has ARP Ping, they thought it could be used to ping their computer's MAC address. I had to go through an explanation where I basically told them that although their MAC address may be (or may not be) unique, the system of routing packets on the internet has no way to sending a packet to the MAC address of their lost laptop. I told them that the MAC address is a hardware address of the ethernet card and it is only used within the local network (on his side of his DSL router). The packets leaving his network through the router are on a higher level protocol and do not retain the MAC address of the devices on his side of the DSL router. That's the simple explanation. I told them next time they buy a laptop to get software that periodically "phones home" like LoJack.
The more detailed explanation has to do with how packets are transmitted on a network. To send a packet between two computers on the same ethernet network you need two types of addresses: Layer 2 (L2) -- the OSI model link layer and Layer 3 (L3) -- the OSI model network layer. L2 addresses are local in scope which means that two devices may have the same L2 address (this does happen) as long as they are not on the same network segment or subnet. An L3 address must also be unique within the scope of the network it is connected to. On an ethernet network a MAC address is a L2 address and an IPv4 address is L3.
In order to deliver a packet between two computers on an ethernet network, L2 addresses need to be mapped to L3 addresses. This mapping can be either dynamic (usual method) or static. The ARP protocol (RFC 826) is used to build and maintain this mapping. It is a simple protocol intended to find the L2 hardware address of a device given a known L3 IP address on an (usually but not limited to ethernet) network. A device does this by sending an ARP Request packet to all the devices on the network segment asking for the L2 address given a known L3 address.
A typical ARP conversation looks like this:
"All devices! (255.255.255.255) -- who has IP address 192.168.1.29? My IP address is 192.168.1.44 and my MAC address is 00:11:22:22:33:ef" (ARP Request)
"Device 192.168.1.29 replies -- I do! I do! and my MAC address is 00:22:44:66:ab:cd" (ARP Reply)
Now the ARP cache on each device has the IP address and MAC address of the other and they can exchange packets. Each device keeps a transient ARP cache locally showing those mappings based on previous packet exchanges.
When you need to send a packet to an IPv4 address outside your network segment, it sends them through the Default Gateway or router. How does your computer know when to send a packet through the gateway? by looking at the destination IP address and subnet mask . When your computer sees that the packet has to leave the network segment, it finds the L2 and L3 address of the gateway/router, then sends the packet there. The router sees that the IP address is not for the local network segment and uses its routing table to forward it on to the next network. The IP packet does not retain the network L2 address of your computer once it goes through the router just as ARP Request packets are not sent through the router. The networks on the other side of the router will most likely have different L2 Link Layer addresses that are not necessarily MAC addresses as you know them.
So back to the original question: can ARP Ping be used to send a packet to some MAC address outside your network?
No. Because ARP Ping is simply sending the normal ARP Request packet while monitoring the timing. If you try to send a strange ARP Request packet with the destination IP address 0.0.0.0 in it but containing a valid local destination MAC address, it won't work because no computer on your segment will respond. The ARP service on all the listening computers is looking for the IP address of the device that received it, not a MAC address. When the ARP packet hits the router, it is ignored if it does not have the IP address of the router in it. And similarly, if you send a packet with IP 0.0.0.0 and a random MAC address, it too will not leave your network.
What they really wanted was to do some kind of trace or ping to the laptop's MAC address and get a response back if it happened to be online somewhere on the internet. Since our software has ARP Ping, they thought it could be used to ping their computer's MAC address. I had to go through an explanation where I basically told them that although their MAC address may be (or may not be) unique, the system of routing packets on the internet has no way to sending a packet to the MAC address of their lost laptop. I told them that the MAC address is a hardware address of the ethernet card and it is only used within the local network (on his side of his DSL router). The packets leaving his network through the router are on a higher level protocol and do not retain the MAC address of the devices on his side of the DSL router. That's the simple explanation. I told them next time they buy a laptop to get software that periodically "phones home" like LoJack.
The more detailed explanation has to do with how packets are transmitted on a network. To send a packet between two computers on the same ethernet network you need two types of addresses: Layer 2 (L2) -- the OSI model link layer and Layer 3 (L3) -- the OSI model network layer. L2 addresses are local in scope which means that two devices may have the same L2 address (this does happen) as long as they are not on the same network segment or subnet. An L3 address must also be unique within the scope of the network it is connected to. On an ethernet network a MAC address is a L2 address and an IPv4 address is L3.
In order to deliver a packet between two computers on an ethernet network, L2 addresses need to be mapped to L3 addresses. This mapping can be either dynamic (usual method) or static. The ARP protocol (RFC 826) is used to build and maintain this mapping. It is a simple protocol intended to find the L2 hardware address of a device given a known L3 IP address on an (usually but not limited to ethernet) network. A device does this by sending an ARP Request packet to all the devices on the network segment asking for the L2 address given a known L3 address.
A typical ARP conversation looks like this:
"All devices! (255.255.255.255) -- who has IP address 192.168.1.29? My IP address is 192.168.1.44 and my MAC address is 00:11:22:22:33:ef" (ARP Request)
"Device 192.168.1.29 replies -- I do! I do! and my MAC address is 00:22:44:66:ab:cd" (ARP Reply)
Now the ARP cache on each device has the IP address and MAC address of the other and they can exchange packets. Each device keeps a transient ARP cache locally showing those mappings based on previous packet exchanges.
When you need to send a packet to an IPv4 address outside your network segment, it sends them through the Default Gateway or router. How does your computer know when to send a packet through the gateway? by looking at the destination IP address and subnet mask . When your computer sees that the packet has to leave the network segment, it finds the L2 and L3 address of the gateway/router, then sends the packet there. The router sees that the IP address is not for the local network segment and uses its routing table to forward it on to the next network. The IP packet does not retain the network L2 address of your computer once it goes through the router just as ARP Request packets are not sent through the router. The networks on the other side of the router will most likely have different L2 Link Layer addresses that are not necessarily MAC addresses as you know them.
So back to the original question: can ARP Ping be used to send a packet to some MAC address outside your network?
No. Because ARP Ping is simply sending the normal ARP Request packet while monitoring the timing. If you try to send a strange ARP Request packet with the destination IP address 0.0.0.0 in it but containing a valid local destination MAC address, it won't work because no computer on your segment will respond. The ARP service on all the listening computers is looking for the IP address of the device that received it, not a MAC address. When the ARP packet hits the router, it is ignored if it does not have the IP address of the router in it. And similarly, if you send a packet with IP 0.0.0.0 and a random MAC address, it too will not leave your network.
Friday, September 26, 2008
ARP Ping
Here is a topic ripped from our September 2008 newletter.
The most popular search term bringing people to our website is ARP Ping. What does ARP Ping do?
If you have the purchased or even the demo version of NetScanTools Pro, you can access the tool by selecting Tools/ARP Ping. Once there, you can see that it has three options or modes. The first two are for sending an ARP Ping and the third is for searching for duplicate IP addresses. Let’s concentrate on ARP Ping first and learn what ARP Ping does and does not do.
ARP request packets are fairly simple in construction. In Ethernet networks, ARP is used to obtain the MAC address of the target given the target IP address. Our ARP packets contain the required target IP address. The broadcast MAC address is placed in the target MAC field. The Interface IP and MAC address are used in the packet to identify to the target device the sender of the ARP packet. When the target device with the IP address identified in the ARP request packet sees the ARP request packet, it fills in the target interface MAC address and sends an ARP reply packet back to the sender. The target IP is a requirement because the receiver will not reply unless it sees its own IP address in the packet. In our implementation, the act of sending an ARP request and receiving a reply is known as an ARP Ping and the timing of the packets gives us the Response Time. The timing is similar to what you would see with a command line PING, ie. packet round-trip-time milliseconds.
What about the broadcast and unicast options? The broadcast option means all ARP request packets we send are to the broadcast MAC address. The unicast option means the first packet uses the broadcast MAC address and all subsequent packets use the discovered MAC address of the target.
Can you input a target MAC address with the IP address blank in order to find the target’s IP address? No, because the ARP protocol does not work that way. If you were to send such a packet, it will not be responded to by any device because the IP address in the packet does not match the IP address of any receiving device.
Can you use this tool to get the MAC address of a device NOT on the same subnet as the computer running NetScanTools Pro? No, because none of the devices on the subnet will not recognize the target IP address and they will not respond. EXCEPT if the router that accepts packets destined for locations outside the subnet is set up to do proxy ARP. If so, it will see that the target IP is not within the subnet and respond to you with the MAC address of the router interface on your side of the subnet.
For more information on how ARP works, see RFC 826.
How to use the ARP Ping tool to search for duplicate IP addresses. A variation on ARP is to use it to detect duplicate IP addresses by the method outlined in RFC 5227. To do this you first select Search for Duplicate IP Addresses, then you select the source IP address to place in the ARP request packet (0.0.0.0 is preferred in the RFC, but we also provide an option for placing the Interface IP in there instead), then you enter the target IP address and press Send ARP. The target IP address is the one you want to find duplicates for. All devices using that IP address will respond to your request along with their MAC address and they will be shown in the results grid.
That's a taste of some of the tips and explanations you will be seeing in this blog. It might bore you if you haven't got the faintest idea what I'm talking about...but enough people have wanted to know about ARP Ping for us to talk about it in more detail.
By the way, did you know I own four miniature herefords?
The most popular search term bringing people to our website is ARP Ping. What does ARP Ping do?
If you have the purchased or even the demo version of NetScanTools Pro, you can access the tool by selecting Tools/ARP Ping. Once there, you can see that it has three options or modes. The first two are for sending an ARP Ping and the third is for searching for duplicate IP addresses. Let’s concentrate on ARP Ping first and learn what ARP Ping does and does not do.
ARP request packets are fairly simple in construction. In Ethernet networks, ARP is used to obtain the MAC address of the target given the target IP address. Our ARP packets contain the required target IP address. The broadcast MAC address is placed in the target MAC field. The Interface IP and MAC address are used in the packet to identify to the target device the sender of the ARP packet. When the target device with the IP address identified in the ARP request packet sees the ARP request packet, it fills in the target interface MAC address and sends an ARP reply packet back to the sender. The target IP is a requirement because the receiver will not reply unless it sees its own IP address in the packet. In our implementation, the act of sending an ARP request and receiving a reply is known as an ARP Ping and the timing of the packets gives us the Response Time. The timing is similar to what you would see with a command line PING, ie. packet round-trip-time milliseconds.
What about the broadcast and unicast options? The broadcast option means all ARP request packets we send are to the broadcast MAC address. The unicast option means the first packet uses the broadcast MAC address and all subsequent packets use the discovered MAC address of the target.
Can you input a target MAC address with the IP address blank in order to find the target’s IP address? No, because the ARP protocol does not work that way. If you were to send such a packet, it will not be responded to by any device because the IP address in the packet does not match the IP address of any receiving device.
Can you use this tool to get the MAC address of a device NOT on the same subnet as the computer running NetScanTools Pro? No, because none of the devices on the subnet will not recognize the target IP address and they will not respond. EXCEPT if the router that accepts packets destined for locations outside the subnet is set up to do proxy ARP. If so, it will see that the target IP is not within the subnet and respond to you with the MAC address of the router interface on your side of the subnet.
For more information on how ARP works, see RFC 826.
How to use the ARP Ping tool to search for duplicate IP addresses. A variation on ARP is to use it to detect duplicate IP addresses by the method outlined in RFC 5227. To do this you first select Search for Duplicate IP Addresses, then you select the source IP address to place in the ARP request packet (0.0.0.0 is preferred in the RFC, but we also provide an option for placing the Interface IP in there instead), then you enter the target IP address and press Send ARP. The target IP address is the one you want to find duplicates for. All devices using that IP address will respond to your request along with their MAC address and they will be shown in the results grid.
That's a taste of some of the tips and explanations you will be seeing in this blog. It might bore you if you haven't got the faintest idea what I'm talking about...but enough people have wanted to know about ARP Ping for us to talk about it in more detail.
By the way, did you know I own four miniature herefords?
Subscribe to:
Posts (Atom)