Thanks to all for their suggestions. For the life of me, I did not see the line in ipconfig that showed where the DHCP server was. Now that I have that, I can hunt it down, next time it appears. It's gone, now... Thanks again for all the ideas. --STeve Andre Political Science On Tuesday 30 August 2005 17:50, George J. Perkins wrote: > On Tue, 30 Aug 2005, STeve Andre' wrote: > > A user told me they couldn't get on the net after lunch today. > > When they booted up they wern't on the net. > > > > Looking at the machines IP address I see 192.168.1.x. Doing > > a release and then renew usually, but not always results in getting > > the proper 35.10 address. > > > > I'll bet that its a student machine, or someone installed a wireless > > access point backwards, etc. My question is, whats the best way > > to hunt it down? > > > > Thanks, STeve Andre' > > Political Science > > It depends on what OS the mis-directed system is running. > > If it is Windows XP, open a text window (Start > Run > "cmd", if it's not > in a menu somewhere) and type "ipconfig /all" -- along with the bogus IP > address it's received, there will be an entry for "DHCP Server" -- the IP > address of the system which gave it that IP address. You may then possibly > be able to ping that IP address, and if it responds, the MAC address may be > in your arp table ("arp -a", both under WinXP and Linux/ Unix). Doug > Nelson or other ACNS network folks might then be able to tell where in your > building (plus or minus) this MAC address is connected. This won't always > work for various reasons, but it works often enough to be worth a try. > > I think Windows 2000's "ipconfig /all" also lists "DHCP Server" but I have > no readily available test system just now. > > There are DHCP tools available under Linux, one of which, "dhclient", has > a debugging mode, set by command line flags, where it will send out a DHCP > request and then lists the responses it gets without actually acting upon > them. There may be other similar tools for Linux and for the various other > BSD and Unix flavors. I found this handy once in a case where the campus > DHCP server _usually_ beat the rogue DHCP server to issuing the address, > so the false IP assignments were really rare and random, but this tool > allowed me to see both responses, quick (campus) and slow (rogue), for a > given DHCP request.