DHCP snap-in hits the fan
Well, I left Ethereal and we all went on the hours-long Christmas tree hunt. When I came back, there were almost a hundred ICMP messages and fewer, though many, DHCP messages, but after I clicked the Stop button, Ethereal must have abended. I started it again, but seems like nothing.
I was surprised that my laptop, when coming out of hibernation, does NOT keep the same IP settings and switches to the top-of-the-list wireless network, in the case “thelab.” I am now going to experiment to see if the same thing occurs when I put it into Standby after choosing the second choice “wescott” wireless network.
It does! After it comes up, the wireless System Tray icon indicates it’s on “thelab” flashes to indicate that it’s negotiating a network connection.
Hold on. It seems that it may have been due to my moving the folders (see below) I’ll try again after I get the thing up and going.
Looking through the snap-in, I see that you can move most of the DHCP folders, so I moved them to E:. It prompts you to ask if you’re ready to stop, then start the service. I say go for it.
Works well, but HOLD ON! It’s wiped out my scopes. Thanks a lot guy, that might have been a good thing to point out BEFORE I wiped ’em out. Let me put back the scopes. Wait, can I do a restore? Let’s try stopping service manually. Done, but when I try to restore it tells me the service isn’t running. So, I start it again and try the restore. It tells me it needs to stop/start the service. The original scope is NOT restored! So here goes with a manual restore.
Seems to be okay, but now what will happen with the already assigned .32 IP that the kitchen got? Will it be assigned again? Should be fun let’s see what happens when I try to do this?
It gave out .35, somehow “knowing” that .32, .33 and .34 were already leased. Hmmm. Let’s see what Ethereal shows. $%@! It shows NO packets. Tried again with NO filter, still no good. Ethereal’s broke?! Started it again and worked okay. Captured with filter and it abended. Guess I have to restart this machine. Good reason not to do sniff, etc. ON a server.
Well, I tried it on an XP machine and clearly Ethereal does not want to do the “OR” operation with port 67 or 67 or ICMP packets. Seems to capture fine, but after Stop is pressed and it needs to read from the capture file and format the packets on the screen it dies. I uninstalled it on the server. I was able to use Ethereal to capture all packets, then used the Display filter with the expression:
(udp.port == 67) (udp.port == 68) or icmp
and it shows what happens. Pretty interesting. It shows the DHCP RELEASE when I click on the other network to free up the IP on the original network. Later when I access the network again, it goes through the discovery process. Immediately, the client pings the DHCP server 4 times, then pings the DNS domain server twice. Twenty seconds later the DNS server pings the client back. The client pinged again three times over the next few minutes. Keep in mind that I had NOT turned on DHCP server Conflict Detection advanced option.