Locating a new device on your network

I've been working with the Pogoplug recently, and realized that people may have difficulty locating a new device on their own network.

Most networked devices get an IP address dynamically, using DHCP. That is to say, the IP address of your net device could change on a regular basis. And you have no good way of knowing what it is.

Most of the time, this won't matter to you, but if you need to log in to a network device, you'll probably need to know the IP address.

To locate the IP address, first find the MAC hardware address. Just look at the bottom of your device, or on the label with your serial number. Usually, there will be a line for  the MAC hardware address, or it may be known as the device hardware address.. This will be in the format of 16 characters, in 8 pairs, separated by a colon (":") or a dash. The characters will be 0-9 and a-f. Write this down.

Now, you'll need to look at your DHCP server and look at the client leases. One of the leases will have the MAC hardware address of your Pogoplug listed. That entry will probably not have a name, but it will have an IP address. For an IPv4 address, the address will look like 4 numbers separated by dots, like 192.168.1.101 or something similar.

For most users, the DHCP server will probably be your router. Usually, the DHCP leases are listed in a table in the "status" section of your router's web interface. If you are not sure, just do a Google search on "router-name dhcp table".

If you don't have easy access to the router's DHCP table, you can use a brute-force approach. Download an IP address scanner (I use the older version of Angry IP Scanner) and have it scan your local network. This will have the affect of populating your ARP table (which is a list of all known devices). In Angry IP, you can also display the MAC address. Look for an entry that matches your device.

To make sure it IS really your device, try to ping the IP address. (Yes, Google it if you don't know how.) Once you have managed to ping the IP address successfully, examine your ARP table for the MAC hardware address. The command to type is "arp -a". If you find a MAC address in the ARP table that matches up to your device, you should have the right IP address.

Worried about Conficker?

Are you worried about Conficker? It's set to go off on April 1st.

It only affects Windows computers, so if you're running Macs or Linux machines, don't worry about it. (Mac users, don't feel too smug, as the recent PWN to OWN demonstrated an exploit of a fully updated Mac in mere seconds).

There's a fairly detailed analysis at Windows Secrets. If you think you might have Conficker, try visiting http://www.symantec.com/ or http://www.mcafee.com/; if you cannot, you may have it.

To remove Conficker, visit http://www.bdtools.net/ and download BitDefender's single-PC conficker removal tool. If that doesn't work on the infected PC, download it from another and run it on the infected PC.

If you are a network admin, go get Nmap (see also this) and run the following command:

nmap -PN -T4 -p139,445 -n -v --script=smb-check-vulns --script-args safe=1 [subnet]

where subnet is something like 192.168.1.0/24 -- you can thank Doxpara for that.

I would also suggest that you use OpenDNS. They have been blocking conficker since February, and there's more detail here. Seriously, sign up for OpenDNS if you are not using it yet; it's free and does more than just provide DNS. I've talked about them before, but not enough.

Ran into an interesting Windows Server 2003 problem today. There was very high CPU utilization by lsass.exe and svchosts.exe (NETWORK SERVICE), and an inability to create outbound network connections. The client has previously rebooted this server to resolve the issue in the past, but wanted an explanation.

This client runs our application from that server using Terminal Services. Our application would not run and was given a cryptic message with the error code 10055. That five-digit code looked like a Microsoft TCP error to me, and sure enough it was. A quick Google searched turned this up:

10055 WSAENOBUFS -- No buffer space available.

Since that is a TCP error, that would mean no network resources are available. I ran "netstat -n" but saw very few established sockets.

Task Manager showed high CPU usage by lsass.exe and one svchosts.exe running as NETWORK SERVICE. I tried to download Process Explorer but Internet Explorer could not get to any websites; the bottom of the page said there was a DNS error.

I opened a command prompt (CMD) and was able to ping www.yahoo.com, so DNS works. I figured I would just FTP the file, so I ran FTP from their server to our web site and got another error:

> ftp: connect :No buffer space is supported

So, another error that points to TCP resources being unavailable.

I tried asking the great Google for answers about TCP resources and error 10055 but mostly found people who rebooted to make the problem go away. There were some Microsoft Articles about increasing the maximum TCP/IP socket buffers, but this is not our server, so I do not want to make changes requiring a reboot without knowing if it would even solve the problem.

Naturally, I examined Event Viewer and saw some error messages that suggested more socket errors which Microsoft's KB indicates a group policy not being able to execute. Probably not the root problem.

I decided to figure out which service was killing the CPU and see if it was also tying up the network resources.

LSASS sustains a bunch of services, including HTTP SSL, IPSEC, Kerberos, NetLogon, NT LM, Protected Storage, Security Accounts Manager, and maybe a couple others. It seems to manage TCP sockets rather than use them, so though CPU is high I figured I could safely ignore LSASS.EXE

OK, svchosts.exe is starts up services, so I ran the Services.MMC (or go to Control Panel > Administrative Tools > Services) to examine services. I went through all the listed services and looked at the details for each. Where the command line included svchosts.exe, I looked for the "-k NETWORK" to determine which svchosts.exe service was running as NETWORK SERVICE. I restarted each one and watched Task Manager to see if the high-CPU instance of svchosts.exe disappeared briefly. When I got to the "Server" service, both svchost.exe and lsass.exe freed up their resources. The Server service also restarted Net Logon, DFS, and Computer Browser.

Ta-dah! I was able to browse the web, FTP, and of course our application worked again. Since this was not our Windows Server 2003 machine, I passed the information along. But, that certainly beats rebooting completely.

Vista Wireless DHCP Problems with SonicWall TZ170w

The title bar link will not work for you if you do not have a SonicWall forum login. Nonetheless, here's an interesting problem I ran into and the solution.

I've been running Vista with various wireless access points just fine; Vista's WiFi stack seems OK to me. Then, we had a client running Vista who could not connect wirelessly to the firewall/access point we sold to them. That was a problem.

The Problem:
This Vista laptop was not able to obtain an IP address via DHCP from the SonicWall TZ 170w. It was able to associate itself (it showed up in the mac/ARP table) to the access point, but instead of getting an IP adress it kept reporting an IP address conflict. The same Vista laptop acquired a DHCP address just fine when connected through wired Ethernet.

Other symptoms included the laptop mac address showing up multiple times in the DHCP lease table on the SonicWall, the event viewer recording DHCP errors on differing IP addresses all reporting conflicts, and finally the wireless NIC falling back to an automatically assigned private IP address. I think that, if our DHCP pool has been small, this single laptop would have used up every available IP address in the DHCP pool.

The Solution:
According to Microsoft, a network trace revealed that Vista client is doing gratuitous ARP while losing the IP.

One of the usages of ARP is to provide duplicate IP address detection through the transmission of ARP Requests known as gratuitous ARPs. A gratuitous ARP is an ARP Request for a node’s own IP address. In the gratuitous ARP, the SPA and the TPA are set to the same IP address.

If a node sends an ARP Request for its own IP address and no ARP Reply frames are received, the node can assume that its assigned IP address isn’t being used by other nodes. If a node sends an ARP Request for its own IP address and an ARP Reply frame is received, the node can determine that its assigned IP address is already being used by another node.

After obtaining an IP address from the SonicWall TZ 170w firewall, the Vista client issues an auto-ARP to assure no conflict; in doing so it expects an answer from the DHCP server confirming the IP address. Without the confirmation the client will decline the IP address received via DHCP.

The core of the issue seems to be the ARP request sent out by the Vista client. The wireless Vista client issues out a Version A ARP request with a source IP address of 0.0.0.0. This is non-standard behavior (whatever that means). Future SonicWall TZ 170w firmware will address the issue.

The Resolution:
The ArpRetryCount registry setting sets the number of times that a gratuitous ARP is sent when initializing IP for a specific IP address. If no ARP Reply is received after sending ArpRetryCount gratuitous ARPs, IP assumes the IP address is unique on the network segment.

In the mean time, runas REGEDIT as administrator, then go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and add a new REG_DWORD named “ArpRetryCount” with a value of 0 and reboot.

Again, according to Jean-Marc of SonicWall (as of May 2007), a future firmware will address the issue.