If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
A Windows 8.1 PC which was set up to connect to a wifi network stopped
connecting to the internet a few days ago. On investigation, I found that it was not getting an IP address: instead IPCONFIG reported a 169.x.x.x address. This also happened with another wifi network (an Android phone with mobile-to-wifi tethering enabled) and with the original router connected by Ethernet. I tried with the router rebooted, and I forgot and re-added the wifi connection. I checked that the DHCP service was running. I couldn't find any DHCP events in any of the Event Logs, with the exception of service started/stopped events when restarting the PC. I also disabled IPV6 to force the PC to use IPV4 DHCP, but no change. I opened an elevated CMD ("run as administrator") and ran "netsh winsock reset" which appeared to complete without any error message, and I then rebooted, but this didn't solve the problem either. "ipconfig /release" appeared to succeed but "ipconfig /renew" hung and never completed and never gave an error message - this was also from elevated CMD prompt. Setting either wifi or Ethernet connection's IPV4 config to static IP/gateway/DNS worked fine. The user had already tried restoring the PC to an earlier restore point from before the problem occurred, but that failed after a long time with a bland "could not restore to earlier restore point" error (don't you just love it when that happens - probably 50% of the time I try to restore a PC to fix some problem, it fails to do so with that sort of message). I left the PC with a static IP, choosing one which was within the subnet but outside the router's DHCP scope, and warnings that it may fail if it was ever connected to another network which didn't have the same subject and gateway (ie not 192.168.1.x for IP and 192.168.1.254 for gateway and DNS). Is there anything else I should have tried before going for the pragmatic static-IP solution? |
Ads |
#2
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
"Wolf K" wrote in message
... Get a new router? If all those attempts at fixing the software failed, it looks like a hardware problem to me. IMO, a router more than a couple or years old doesn't owe you anything. Latest flyer from the local pusher showed routers specced twice as good as my ancient one for less than half its original price. So if it ever hiccups, it's in the dumpster. :-) I'd have suspected the router except for one fact: the problem exists with a different DHCP server - the tethering feature on an Android phone. I tried that early on to try to eliminate the router as the faulty component. I forgot to mention (fairly important - sorry!) that other devices (laptops, mobile phones) can connect to the existing router either by wifi or Ethernet. |
#3
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
"KenW" kenw@ noplace.com wrote in message
... If your connected via cat cable, substitute it. I know that having more than one fault is not impossible, but I *think* that my testing showed: 1. fault affects one laptop making wifi connection to router and to DHCP server and mobile-to-wifi bridge (tethering) on Android phone: two different router-like devices with two different DHCP servers 2. fault affects both wifi and Ethernet on this laptop 3. fault does not affect other computers (laptop by wifi, desktop by Ethernet using the same cable tested in 2, mobile phone by wifi) 4, affected laptop appears to work fine with a static IP address (can browse, get POP email, ping, nslookup) Seems to point to the DHCP client on this particular PC, in code which is shared between wifi and Ethernet. "ipconfig /renew" fails to complete, giving no error message - something's amiss there. Eliminated simple fixes like (re)starting DHCP service, clearing and resetting winsock config (netsh winsock reset). Task was to get PC working. After doing *some* troubleshooting, it was not worth starting on bigger fixes like reinstalling Windows or working out why System Restore was failing (as so often happens - grr). Quick fix with limitations (will fail on non-192.168.1.x network) is better than perfect fix that takes considerably longer. It would have been interesting to see what DHCP traffic is passing between laptop and router: is laptop failing to request DHCP address or is it failing to understand the router's (DHCP server's) response? Didn't have a computer with LAN trace software to look at this. From people's responses so far, it sounds as if I haven't forgotten to check anything *too* obvious. |
#4
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
NY wrote:
A Windows 8.1 PC which was set up to connect to a wifi network stopped connecting to the internet a few days ago. On investigation, I found that it was not getting an IP address: instead IPCONFIG reported a 169.x.x.x address. This also happened with another wifi network (an Android phone with mobile-to-wifi tethering enabled) and with the original router connected by Ethernet. I tried with the router rebooted, and I forgot and re-added the wifi connection. I checked that the DHCP service was running. I couldn't find any DHCP events in any of the Event Logs, with the exception of service started/stopped events when restarting the PC. I also disabled IPV6 to force the PC to use IPV4 DHCP, but no change. I opened an elevated CMD ("run as administrator") and ran "netsh winsock reset" which appeared to complete without any error message, and I then rebooted, but this didn't solve the problem either. "ipconfig /release" appeared to succeed but "ipconfig /renew" hung and never completed and never gave an error message - this was also from elevated CMD prompt. Setting either wifi or Ethernet connection's IPV4 config to static IP/gateway/DNS worked fine. The user had already tried restoring the PC to an earlier restore point from before the problem occurred, but that failed after a long time with a bland "could not restore to earlier restore point" error (don't you just love it when that happens - probably 50% of the time I try to restore a PC to fix some problem, it fails to do so with that sort of message). I left the PC with a static IP, choosing one which was within the subnet but outside the router's DHCP scope, and warnings that it may fail if it was ever connected to another network which didn't have the same subject and gateway (ie not 192.168.1.x for IP and 192.168.1.254 for gateway and DNS). Is there anything else I should have tried before going for the pragmatic static-IP solution? For my wifi cable/voice modem, resetting it wipes it back to factory defaults. That means the wifi passwords I specified for the 2.4 and 5 GHz bands were cleared. If I use a paper clip to momentarily press the modem's reset button, the unit only restarts. If I long-press its reset button (continuously for longer than 10 seconds), it resets back to factory defaults. I've had to reset a couple of times thereafter all the wifi devices could not connect. I had to go into the router's config to restore the wifi passwords. I don't recall have to re-pair. If did any other tweaking of the router beyond the wifi passwords, like using MAC or IP filtering as to which devices are allowed to connect to the router, or port forwarding, or changing the security level of its firewall, you might want to reset the router, just reenter the same wifi passwords in the router, and retest the IoTs that couldn't connect before but would now use a default config in the router. Rebooting or restarting the router is not the same as a reset of the router. |
#5
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
On Fri, 19 Jan 2018 18:27:35 -0000, "NY" wrote:
It would have been interesting to see what DHCP traffic is passing between laptop and router: is laptop failing to request DHCP address or is it failing to understand the router's (DHCP server's) response? Didn't have a computer with LAN trace software to look at this. I agree, it might have been interesting to see what's going on down at that layer. You might install WinDump and Wireshark on a working PC to get a feel for what a successful DHCP transaction looks like, if you're not already familiar. That would prepare you to do a similar test on the problem child to see what's different. From reading your description of events, I'm guessing it's not sending a DHCP request, or perhaps it's malformed in some way so that the DHCP server rejects it as invalid. Either way, after not getting a response, the laptop then does what it's supposed to do: auto assign an APIPA address (169.254.x.x/16). Is this issue something that used to work until one day it didn't, or did it never work? -- Char Jackson |
#6
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
On Fri, 19 Jan 2018 12:31:07 -0600, VanguardLH wrote:
If did any other tweaking of the router beyond the wifi passwords, like using MAC or IP filtering as to which devices are allowed to connect to the router, or port forwarding, or changing the security level of its firewall, you might want to reset the router, just reenter the same wifi passwords in the router, and retest the IoTs that couldn't connect before but would now use a default config in the router. Rebooting or restarting the router is not the same as a reset of the router. MAC filtering is a good tip. That would cause what they're seeing. -- Char Jackson |
#7
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
In message , Wolf K
writes: [] Get a new router? If all those attempts at fixing the software failed, it looks like a hardware problem to me. IMO, a router more than a couple or years old doesn't owe you anything. Latest flyer from the local pusher showed routers specced twice as good as my ancient one for less than half its original price. So if it ever hiccups, it's in the dumpster. :-) I'd say just because "better and cheaper" is available, is not a reason to ditch something that might be working - especially if the respect in which it is "better" is not relevant (e. g. router offers an [A]DSL protocol not supported by the exchange, or wifi to 802.11N when all the equipment is in the same room). [FWIW, I'm using a router that was the cheapest I could find when I bought it (which was just before the wired-only router my ISP supplied died - so you can guess how long ago that was!), and it's been powered for several years now, excluding power cuts, and touch wood never given me any trouble. (The odd reboot has been necessary, maybe once to thrice a year; those could equally be due to the exchange equipment.) It's a "Dynamode R-ADSL-C4-W-G1" according to what's printed on top.] -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Where [other presenters] tackle the world with a box of watercolours, he takes a spanner. - David Butcher (on Guy Martin), RT 2015/1/31-2/6 |
#8
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
"Char Jackson" wrote in message
... On Fri, 19 Jan 2018 12:31:07 -0600, VanguardLH wrote: If did any other tweaking of the router beyond the wifi passwords, like using MAC or IP filtering as to which devices are allowed to connect to the router, or port forwarding, or changing the security level of its firewall, you might want to reset the router, just reenter the same wifi passwords in the router, and retest the IoTs that couldn't connect before but would now use a default config in the router. Rebooting or restarting the router is not the same as a reset of the router. MAC filtering is a good tip. That would cause what they're seeing. Fair point. But the user said everything was working perfectly until a few days ago when it suddenly stopped, possibly after a Windows update. He wouldn't know how to access the router to set up MAC filtering. |
#9
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
"Char Jackson" wrote in message
... On Fri, 19 Jan 2018 18:27:35 -0000, "NY" wrote: It would have been interesting to see what DHCP traffic is passing between laptop and router: is laptop failing to request DHCP address or is it failing to understand the router's (DHCP server's) response? Didn't have a computer with LAN trace software to look at this. I agree, it might have been interesting to see what's going on down at that layer. [...] Is this issue something that used to work until one day it didn't, or did it never work? It used to work until one day (maybe after a Windows update) it stopped. |
#10
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
NY wrote:
"Char Jackson" wrote in message ... On Fri, 19 Jan 2018 12:31:07 -0600, VanguardLH wrote: If did any other tweaking of the router beyond the wifi passwords, like using MAC or IP filtering as to which devices are allowed to connect to the router, or port forwarding, or changing the security level of its firewall, you might want to reset the router, just reenter the same wifi passwords in the router, and retest the IoTs that couldn't connect before but would now use a default config in the router. Rebooting or restarting the router is not the same as a reset of the router. MAC filtering is a good tip. That would cause what they're seeing. Fair point. But the user said everything was working perfectly until a few days ago when it suddenly stopped, possibly after a Windows update. He wouldn't know how to access the router to set up MAC filtering. The point was to reset the router/modem back to factory defaults and only reenter the wifi passwords back into the router (so the IoTs don't have to each have their wifi password changed). |
#11
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
On Fri, 19 Jan 2018 15:03:46 -0600, VanguardLH wrote:
NY wrote: "Char Jackson" wrote in message ... On Fri, 19 Jan 2018 12:31:07 -0600, VanguardLH wrote: If did any other tweaking of the router beyond the wifi passwords, like using MAC or IP filtering as to which devices are allowed to connect to the router, or port forwarding, or changing the security level of its firewall, you might want to reset the router, just reenter the same wifi passwords in the router, and retest the IoTs that couldn't connect before but would now use a default config in the router. Rebooting or restarting the router is not the same as a reset of the router. MAC filtering is a good tip. That would cause what they're seeing. Fair point. But the user said everything was working perfectly until a few days ago when it suddenly stopped, possibly after a Windows update. He wouldn't know how to access the router to set up MAC filtering. The point was to reset the router/modem back to factory defaults and only reenter the wifi passwords back into the router (so the IoTs don't have to each have their wifi password changed). I believe he said he tried tethering to another access point, (a cell phone?), so if the issue isn't limited to the router I'd be inclined to rule out said router. If multiple AP's cause the issue, it's more likely to be in the client. -- Char Jackson |
#12
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
On 1/19/2018 10:27 AM, NY wrote:
2. fault affects both wifi and Ethernet on this laptop I had a strange problem where a laptop stopped connecting to a router for no apparent reason, all of the settings looked fine. I removed the hardware from the Device manager, rebooted and let Windows reinstall it, and is started working normally again. You might consider removing both the ethernet and wifi adapters then rebooting. |
#13
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
NY wrote:
"Char Jackson" wrote in message ... On Fri, 19 Jan 2018 12:31:07 -0600, VanguardLH wrote: If did any other tweaking of the router beyond the wifi passwords, like using MAC or IP filtering as to which devices are allowed to connect to the router, or port forwarding, or changing the security level of its firewall, you might want to reset the router, just reenter the same wifi passwords in the router, and retest the IoTs that couldn't connect before but would now use a default config in the router. Rebooting or restarting the router is not the same as a reset of the router. MAC filtering is a good tip. That would cause what they're seeing. Fair point. But the user said everything was working perfectly until a few days ago when it suddenly stopped, possibly after a Windows update. He wouldn't know how to access the router to set up MAC filtering. If he doesn't know how to access the router's internal web server to get at the config screens then how did the wifi passwords ever get set? If he has never configured the router then it is still using the factory default for login (probably username = "admin" & password = "password") which means anyone can hack through his router to get his intranet hosts. |
#14
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
In message , VanguardLH
writes: [] If he doesn't know how to access the router's internal web server to get at the config screens then how did the wifi passwords ever get set? If he has never configured the router then it is still using the factory default for login (probably username = "admin" & password = "password") which means anyone can hack through his router to get his intranet hosts. What you say is right, other than calling them "the wifi passwords". The wifi passwords will (in UK anyway, for ISP-provided routers at least) usually be a string of characters, and on a label on the bottom of the router. The ones you are referring to are the router control access passwords (I don't know if that's the correct phrase, if there is a "correct" phrase) - you'd still need them even if accessing the router by other than wifi. Actually, on a recent ISP-supplied router I saw, the label gave those too - and although the username _was_ admin, the password was another string of characters, so maybe that door is (slowly) closing, too. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Gravity is a myth; the Earth sucks. |
#15
|
|||
|
|||
Win 8.1: DHCP no longer getting an IP address
J. P. Gilliver (John) wrote:
VanguardLH WROTE: If he doesn't know how to access the router's internal web server to get at the config screens then how did the wifi passwords ever get set? If he has never configured the router then it is still using the factory default for login (probably username = "admin" & password = "password") which means anyone can hack through his router to get his intranet hosts. What you say is right, other than calling them "the wifi passwords". The wifi passwords will (in UK anyway, for ISP-provided routers at least) usually be a string of characters, and on a label on the bottom of the router. The ones you are referring to are the router control access passwords (I don't know if that's the correct phrase, if there is a "correct" phrase) - you'd still need them even if accessing the router by other than wifi. Actually, on a recent ISP-supplied router I saw, the label gave those too - and although the username _was_ admin, the password was another string of characters, so maybe that door is (slowly) closing, too. I was referring to TWO logins: one for the wifi passphrase(s) and the other to log into the router's internal web server to configure it. I remember finding a list of router models showing what are the default login credentials to the routers. They're publicly listed hence well known. That's why the first tweak a user should do to a router is to change its login password (the username "admin" is often fixed so all you get to change is the password string). The password should be changed to a STRONG password. It's the first portal (attack vector) that should get defended. If the low-level user hasn't a clue about doing any configuration of their router, as claimed, then it's likely the default login credentials are still defined in that router leaving it vulnerable to /easy/ attack. |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|