Jason Antman’s Blog

At $WORK, the subnet we use for some of our workstations and test boxes was only recently setup with DHCP. Previously, we’d used IP-by-Whiteboard in the office. As a result, most of the recent machines use DHCP, but there are a few older ones still around using static addresses. I recently had to add a new machine, so I had to go through the process of finding out which IPs are in use and which aren’t (since some aren’t in DHCP).

I decided to be good and update DHCP with records for all machines in the subnet, whether they’re actually using DHCP or not. There’s a quick way to do this with nmap using the options for ping scan (-sP) and always resolve DNS (-R):

nmap -sP -R 172.16.43.129-159

Host ar01-hill-hill.example.com (172.16.43.129) appears to be up.
MAC Address: 00:11:BC:7D:28:0A (Cisco Systems)
Host ccf-hill019-1.example.com (172.16.43.130) appears to be up.
MAC Address: 00:00:AA:63:54:BB (Xerox)
Host ccf-hill019-2.example.com (172.16.43.131) appears to be down.
Host ccf-hill019-3.example.com (172.16.43.132) appears to be down.
Host ccf-hill019-4.example.com (172.16.43.133) appears to be down.
Host ccf-hill019-5.example.com (172.16.43.134) appears to be down.
Host ccf-hill019-6.example.com (172.16.43.135) appears to be down.
Host ccf-hill019-7.example.com (172.16.43.136) appears to be up.
Host speakeasy.example.com (172.16.43.137) appears to be up.
MAC Address: 00:17:A4:13:EB:57 (Global Data Services)
Host ccf-hill019-9.example.com (172.16.43.138) appears to be up.
MAC Address: 00:17:A4:13:E8:17 (Global Data Services)
Host ccf-hill019-10.example.com (172.16.43.139) appears to be down.
Host testmac01.example.com (172.16.43.140) appears to be down.
Host ccf-hill019-12.example.com (172.16.43.141) appears to be down.
Host ccf-hill019-13.example.com (172.16.43.142) appears to be up.
MAC Address: 00:0D:29:59:58:00 (Cisco)
Host ccf-hill019-14.example.com (172.16.43.143) appears to be down.
Host ccf-hill019-15.example.com (172.16.43.144) appears to be down.
Host ccf-hill019-16.example.com (172.16.43.145) appears to be down.
Host ccf-hill019-17.example.com (172.16.43.146) appears to be down.
Host ccf-hill019-18.example.com (172.16.43.147) appears to be up.
MAC Address: 00:1E:C2:0D:C1:98 (Unknown)
Host ccf-hill019-19.example.com (172.16.43.148) appears to be down.
Host ccf-hill019-20.example.com (172.16.43.149) appears to be down.
Host ccf-hill019-21.example.com (172.16.43.150) appears to be down.
Host lordkris.example.com (172.16.43.151) appears to be down.
Host ccf-hill019-23.example.com (172.16.43.152) appears to be down.
Host ccf-hill019-24.example.com (172.16.43.153) appears to be down.
Host ccf-hill019-25.example.com (172.16.43.154) appears to be down.
Host ccf-hill019-26.example.com (172.16.43.155) appears to be down.
Host ccf-hill019-27.example.com (172.16.43.156) appears to be down.
Host ccf-hill019-28.example.com (172.16.43.157) appears to be down.
Host ccf-hill019-29.example.com (172.16.43.158) appears to be down.
Host ccf-hill019-30.example.com (172.16.43.159) appears to be down.
Nmap finished: 31 IP addresses (7 hosts up) scanned in 0.892 seconds

As you can see, the results also (very usefully) include MAC addresses, so it’s pretty easy to update DHCP as needed.

Tech HowTos dhcp, nmap, ping, sysadmin

Two weeks ago, I wrote about the Brother HL-2170W that I got for my mother. It seemed absolutely wonderful. Until the night of March 31st, just before Conficker was supposed to strike. Being that mom’s computer is the only one at home running Windows, I finished up a long-standing project – and moved her desktop, printer, and AppleTV over to a separate VLAN that’s not routable to anything else internal (i.e. anything important, or anything of mine). I’d already had the “client” VLAN setup for a while, so it was just a matter of tweaking the firewall rules and moving the static DHCP assignments from one subnet to the other.

Well, that’s where the problems started. While her Windows XP desktop and AppleTV coped nicely, and got their new addresses in DHCP as they should, the HL2170W did not, As a matter of fact, after two hours, I hadn’t seen a single DHCP request, even though I had the lease time set to 10 minutes for both subnets. So, I tried administratively downing the switch port a few times, to no avail. After a day of waiting, I came back to the problem – and still found nothing in the DHCP logs from that printer. I emailed mom and asked her to power-cycle it a few times… still nothing! It wasn’t even requesting DHCP when rolled, let alone at a regular interval!

Fast forward a week or so, to today. I’m ready to call Brother Support, as my mother hasn’t had use of her new printer in a week and a half. I’m infuriated – I’ve rolled the printer dozens of times, and not a single event in the DHCP log. I know it’s sending traffic from the port – I’ve reset the counters and they’re changing. I tried moving it back to the original VLAN and confirmed that it still has its’ original IP. I could get into the web interface via lynx and *tell it* to refresh DHCP, but this seemed quite pointless – there’s no way it’s physically possible to send the web request and then switch the port to the new VLAN before it gets DHCP.

So, I’m ready to call Brother Support. I then notice that the printer is turned off at the moment. From the switch log, it looks as though it’s been powered off for six days. So, I turn it on. And then go about starting my prep for the Brother call, first opening up a tail on the DHCP server log, grepped for the proper interface. And, wouldn’t you know, as I get up to let the dog out, the printer starts spitting out pages!

As far as I can tell, there’s something seriously wrong with the Brother HL-2170W DHCP implementation. Specifically, it didn’t get an address on the new VLAN until it was powered off for a *long* time. Even reboots wouldn’t trigger a request, until the box had been powered off for days. More importantly, though, it seems that it only gets DHCP once when it boots, and totally disregards the lease time!

Reviews dhcp, hl2170w, printer, vlan