NetScanTools Pro 11.84 Released Jan 25, 2018

The big news about release 11.84 is SMB Scanning. Back in May 2017 during Wannacry we had several people check out the Network Shares - SMB tool and ask if it scanned specific devices by IP address. It does not really do that since it uses only NetBIOS, so I set about to make a tool that does these things:

1. connect to NetBIOS Name Service and grab the 'Windows computer name' and MAC address.
2. connect to SMB port and test the SMB service for supported versions. Every supported version is shown.
3. show latency.
4. do this for a list of IPv4 addresses or hostnames. IPv6 will be added in a later version.

Here is an animated GIF showing the new SMB Scanner in action:

You can use the SMB Scanner Tool to see supported SMB versions and check for vulnerabilities based on those supported versions. It identifies SMB 1.0 support in red because we already know it is compromised. More about the SMB Scanner.

IPv6 improvements

Another important addition is the new multicast Ping button that helps you discover IPv6 neighbors in the Network Neighbors tool. What this button does is ping the link local multicast address and this forces neighbor discovery to happen. The results are then updated after 10 seconds showing all responding link local IPv6 neighbors.

How to get NetScanTools Pro 11.84

If you already have an active maintenance plan for NetScanTools Pro, click on Help/Check for New Version to login and download the full installer.

Important NetScanTools Pro v11.53 Release

NetScanTools Pro v11.53 (installed) was released on November 1, 2013. This is a very important release because of the type of fixes that are in it. These fixes affect any of the tools that use WinPcap for capturing or sending packets. The WinPcap fixes are important if you use NetScanTools Pro on a machine where the network interface does not support promiscuous mode (normally WiFi 802.11) or you have more than one network interface on the machine.

If your network interface does not support promiscuous mode, all versions prior to 11.53 will not be able to open the interface resulting in a message similar to this one: "Error: Cannot open interface for packet sending. Please exit and restart NetScanTools Pro".

This means you cannot fully utilize tools that depend on WinPcap - for example the WinPcap ICMP mode of Traceroute will not work. The change in 11.53 allows the interface to be automatically opened in non-promiscuous mode if the open in promiscuous mode fails. If an adapter can be opened in promiscuous mode, all packets passing by it are passed along to the host system, however, if it is opened in 'normal' mode, then only packets intended for the system are passed to the host system. This mostly affects WiFi adapters so now you may find that NetScanTools Pro works much better with your WiFi network interface. Error message reporting has been significantly improved at the same time.

If you have more than one network interface on the system running NetScanTools Pro, all versions prior to 11.53 will only be able to send packets to the local network associated with the secondary interface. In other words if a packet sent out the secondary interface is intended for a destination beyond the default gateway, it will not get there because the default gateway mac address was not being obtained correctly. It now is obtained correctly so packets will go out the secondary interface default gateway as intended.

The WinPcap related changes affected ARP Ping, ARP Scan, Duplicate IP Address Scanner, OS Fingerprinting, Packet Capture Playback, Packet Generator, Ping, Port Scanner, Promiscuous Mode Scanner, Traceroute, Connection Monitor, Packet Capture, Passive Discovery, SNMP Dictionary Attack and SNMP Scanner.

Other changes include:

1. The improvement of administrator privileges detection which affects TimeSync - doing a clock synchronization and DNS Tools Core Edit Hosts File. Some portions of Network Connection Endpoints are also affected.
2. Addition of a column showing the DHCP Server MAC Address to the DHCP Server Discovery Tool.
3. Packet Capture Playback now supports sending .pcap files in addition to .cap files.
4. Ping Enhance/TCP Ping now correctly send the number of packets you designate.
5. SQLite was updated to 3.8.1 and the database files were updated.

Version 11.53 is available to all those will active maintenance plans. Click on Help/Check for New Version to obtain it.

Managed Switch Port Mapping Tool v2.11 and v2.10 Released in June

This post should have been made in June. The Managed Switch Port Mapper had back-to-back releases in June to add new capabilities. Together they addressed issues with obtaining MAC addresses from the local area network and a significant problem mapping Cisco switches using SNMPv3. You can download a 30 day trial at http://www.SwitchPortMapper.com/

Changes in the two releases:

2.11 June 13, 2013

-SNMPv3 changes affecting Cisco® switches: corrected problem with context field that was not being added to the SNMPv3 queries.

-Documented changes to Cisco switch running-config that are required to use SNMPv3 and get meaningful results.

2.10 June 12, 2013

-Ping Sweep: significant internal changes to address ARP table issue reported in v2.09. These changes vastly improve collection of ARP information for all supported operating systems.

-Minor wording changes to Web Browser Summary Report. Added details about results of Ping Sweep action.

-Review History: it now remembers the last mode (Switch Lists or Manual Mappings) between successive uses of Review History within a session. If you were looking at a Switch Mapping, then come back to look at another, you do not have to reselect the mode again unless you are changing to a different mode.

-Review History: added switch alias column to Manual Switch Mappings view in the 'Switch Lists or Manual Mappings' list.

-Updated SQLite to version 3.7.17

-Updated MAC address/Manufacturer database.

IPv6 Network Neighbors in NetScanTools Pro 11.30

We introduced a new tool for IPv6 called Network Neighbors. This tool provides information similar to what the ARP Cache tool does for IPv4: a mapping of IPv6 addresses to physical addresses. Unlike the ARP Cache tool a physical address can be not only a MAC address, but it can also be an IPv4 address associated with a tunneling interface. You can see that in the image below.

Interesting things in this image are the global IPs that start with 2001: - one on those is the local address and the others are target addresses. Note also the large number of permanent multicast entries starting at the top with the ff02::c SSDP, ff02::16 All MLDv2-capable routers, ff02::1:2 All-dhcp-agents and finally the ff02::1:ffxx:xxxx solicited node address (RFC 4291).

You can see the lone fe80:: link local address attached to the only real physical network interface (NIC) in the computer. And you can even see the VMware player interfaces.

What you cannot see in the image is the interface alias, type and ifIndex (Scope ID).

This is new in NetScanTools Pro v11.30.

NetScanTools Pro NetScanner/Ping Sweep Tips

These comments apply to NetScanTools Pro 10.98.1 and earlier. NetScanner/Ping Sweep uses ICMP ping packets to find active computers in the IP range or list of IPs.

1. If you are scanning a range of IPs that include Windows computers with active NetBIOS or SMB Windows computer name access - please - -please - please make sure that the checkbox labeled "Delete NetScanner Temporary Files on Exit" is checked. See NetScanner/Ping Sweep Setup.

2. If you see what you know is the wrong hostname for an IP, first press the Edit Hosts File button and see if the IP is in there. If it is, edit it out and make sure the Add Responding IPs to Hosts File box is unchecked. If the hosts file is not the problem, you need to review DNS. NetScanner uses the builtin resolver in Windows to resolve IPs to hostnames using DNS queries, if those fail a node status request is sent directly to the target to try to get the Windows hostname. Switch to the DNS Tools - Core tool and enter the IP that has the wrong hostname. Then press Test Default DNS. This tool does a direct PTR query to all the DNS's used by your computer. Look for two or more PTR records showing different hostnames. If you see it here, then the problem is in DNS. If the IP does not have PTR records in DNS, then go back to NetScanner and double click on the IP in question to view the NetBIOS/SMB information returned during the scan. You may see the incorrect hostname in the NetBIOS response. If so, then make sure #1 above is implemented - if not, exit the program, restart and rescan.

3. Keep Add responding IPs to hosts file unchecked. It is an artifact of an earlier version of NetScanTools and is no longer relevant in today's systems.

4. If you are looking for MAC addresses, please make sure Retry Send ARP is checked and Get NetBIOS Info is checked. The first one uses ARP to get MAC addresses if you are on the same subnet. The second one queries Windows computers throught the NetBIOS/SMB protocol to obtain MAC addresses. Remember MAC addresses in an IPv4 network are not routed.

5. If you want to ping a set of non-contiguous, random IPs, please create a list of IPv4 address, one per line and save it to a text file. There can be no other information in this file, only the IP addresses. On NetScanner/Ping Sweep, press Load Targets, then Load Text File. Navigate to the IP text file and open it. Now press Start NetScan and answer Yes to the question about scanning the list. You may want to go into Setup and uncheck the box labeled Enable Post-Sweep Delete of Nonresponding IPs - it's up to you.

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.

New Freeware Tool and other ramblings

It's Friday. Finally. It's been a difficult couple of weeks watching the market news and Congress try to bailout Wall Street and fix the credit crisis. Funny, but they never talk about bailing out small businesses...

I saw the BLS summary of the unemployment report for September and I can directly attest to things I saw in it: every time we send out a newsletter announcement or a new program version announcement we see new bounces. Some of those may be due changes in server level email filtering, but I think more and more of them are people who have lost their jobs. In fact some of them are long time users of our software which is even more disturbing.

Speaking of the newsletter, we are sending it out once a month. Usually during the third week of the month. If you are on our list (or you think you are on it), please whitelist email from netscantools.com both on your workstation or laptop AND on your email server. We know that the word "netscantools" sometimes triggers spam filters, so please whitelist us if you want email from us. In case you missed one, the newsletter archive here.

Back to reality.

On October 1, I released a little tool as freeware that I originally made a couple years ago. This tool takes as input an IPv4 address of a device on your local subnet, then when you press the Get MAC Address button, it uses ARP to get the MAC address of the device. If the device is on and it can communicate over the network, it must respond. It must respond even if it is protected by a firewall like Windows Firewall. So it can't hide. Since ARP packets are not routed, you cannot use it to get the MAC address of some computer halfway around the world. The tool does this one IP at a time and it only works on your local subnet. If you need to scan a whole subnet with ARP to find every active device, we have that in NetScanTools Pro.

The freeware tool is called IPtoMAC and it runs on Windows Vista/2003/XP/2000 (it is codesigned for your protection) and you can download it here. It was also my first serious use of the new Visual Studio 2008 VC++ compiler. More on the new compiler in another post.

Tech Support call about 169.254.x.x

I had an interesting call today from someone trying out the NetScanTools Pro 10 Demo. He wanted to know if it could help him figure out why his laptop was getting a 169.254.x.x IP (255.255.0.0 subnet mask) when he plugged it into his work network. He was aware of the Microsoft Windows XP default action of using Automatic Private IP Addressing (APIPA) to assign an IP in that range whenever DHCP failed. But he wanted to confirm that DHCP was not working and just talk to someone about it I guess.

As a way of confirming my suspicions, I had him use the DHCP Discover Tool in NetScanTools Pro 10 Demo. When he pressed the Discover button, the DHCP server returned no data and the tool timed out. I had him do this a couple of times. The tool sends out a DHCP_DISCOVER message and looks for responses much like ipconfig does -- and there were no responses.

So either his physical network connection was bad or the DHCP server was dead. He was pretty sure his network cable was OK, so that left the DHCP server itself. I had him confirm this using ipconfig /release, then ipconfig /renew, then confirmed his computer was set up to use DHCP by looking at the results of ipconfig /all. Now that he was pretty sure of the program, he had a call into whoever was responsible for the DHCP server.

I also had him go to Network Statistics to check to make sure there was only one network interface in his system and he could see all the parameters for the single interface like IP, mask and MAC address. That way he could be sure that there were no other conflicts like a wireless and a wired interface.

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?