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.
