Mark Minasi's Tech Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
DennisMCSE

Senior Member
Registered:
Posts: 184
Reply with quote  #1 
It's been a while since troubleshooting network issues on a client. Have a desktop computer, no wireless,  that the network icon in the System Tray turned into a globe, which basically means that it can't detect a network. Get the 169.254.x.x IP Address. I updated the NIC drivers, uninstalled and reinstalled the NIC card drivers, checked the network cable, use a meter to check that the cable was working, etc., and it still shows the globe instead of a normal network icon. It's a Dell micro computer, which means it's small and doesn't have any extra slots to put in a new NIC card.

Anyone know of what to else to try?
0
Pieter

Avatar / Picture

Senior Member
Registered:
Posts: 300
Reply with quote  #2 
Hi, you could try with a USB NIC.
__________________
Pieter Demeulemeester
0
spam spam bacon spam

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 72
Reply with quote  #3 
Ditto Pieter.  I have a few spares for just this purpose.

Besides that, there are a few things you can do to narrow down where your issue is.
(These are in no particular order - they are just ways to isolate the cause)


  • Find out if anything changed recently.  ANYTHING.
       When I'm asking users for details, I'll usually tell them "tell me about anything you can think of... don't worry about how crazy it may sound or how unrelated it may seem... like, it only seems to happen on rainy Wednesdays or it crashes when you wear your blue corduroy pants..." 
      
They may tell you something that helps you narrow it down.


  • Give it a static IP address. 
Can you ping it's own IP?  (the one you assigned to it) If yes, the NIC card is working.
Can you ping another PC on the same network?
Can you ping the default gateway?
If yes, then your "hardware" is working... the NIC card, the cable, the switch port the cable is plugged in to, etc...
             

  • While you have an APIPA address (the 169.254.x.x address), do an ipconfig \release and then an ipconfig \renew
Can you get a dynamic IP address this way?  If yes, then DHCP is working on the DHCP server side.  (Not out of addresses, etc)  This also might indicate that you have an extended delay* during boot, in which the DHCP process times out.


  • Kill off APIPA by going to the same place you'd config a static IP and click on the 2nd tab titled "Alternate Configuration".  Uncheck "Assign Private IP Address".

Do you eventually get a dynamic IP address?  You may have to wait for some time.


  • Can you try substituting another device?  Try a laptop with an Ethernet port or if possible, run the patch to the back of a different PC nearby.

Does DHCP work with a different device?
If yes, I'd go in to Windows Services and check to ensure DHCP client is running.

  • Check the logs.

Boot up, wait for the DHCP process to fail, let it get assigned an APIPA address and then check the "last hour" log entries.  I can usually pick up the scent from log entries.  (although I'm a complete and utter spaz at trying to read them - stamp "FAIL" on ma' forehead...lol)


HTH helps maybe give you some ideas...

~spammy




*To explain a little better: 

The first thing that happens when a device's NIC comes up (or is connected to a network) is it sends a request for an IP address via DHCP.  (It broadcasts a DHCPDISCOVER message to 255.255.255.255, looking to identify any available DHCPv4 servers on the network.)

If this process takes too long, it times out and the DHCP server responds with a DHCPNACK.
 
In the past, the process would start over, with the device again sending out a DHCPDISCOVER message.  However, we now have APIPA jumping in after 60 seconds (I think it's 60 secs...brain go buh-bies at the moment... lol) and APIPA assigns a 169.254.x.x address.  Once the APIPA address is assigned, the DHCP process ends (for obvious reasons).

One reason for delay is spanning tree (on the switch).  Spanning tree, which runs only on the switch (not the computer) is designed to prevent broadcast storms.

As soon as a switch port comes up, spanning tree places it in "limbo", preventing any traffic in or out.  While the port is in limbo, spanning tree does some math, makes internal changes if needed, and then "enables" traffic to flow freely on that port.  This may 30-45 seconds.  As you can figure out, DHCP has been trying and failing all that time - and now it's almost "APIPA time!"

There are switch commands that "fix" this delay, but if DHCP has been working okay up until now, I assume that this is not a likely cause (unless something recently changed)  😃




__________________
If at first you don't succeed, destroy all evidence that you tried.

0
Pieter

Avatar / Picture

Senior Member
Registered:
Posts: 300
Reply with quote  #4 
In the past I often did a reset TCP/IP stack to solve strange IP-problems :

C:\> netsh int ip reset

__________________
Pieter Demeulemeester
0
spam spam bacon spam

Avatar / Picture

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 72
Reply with quote  #5 
Quote:
Originally Posted by Pieter
In the past I often did a reset TCP/IP stack to solve strange IP-problems :

C:\> netsh int ip reset


Pieter!!!
Sweet mother of all things awesome!!!

I didn't know about that command, and just read up on it...

https://support.microsoft.com/en-us/help/299357/how-to-reset-tcp-ip-by-using-the-netshell-utility


When you run the reset command, it overwrites the following registry keys, both of which are used by TCP/IP:
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 
SYSTEM\CurrentControlSet\Services\DHCP\Parameters
This has the same effect as removing and reinstalling TCP/IP. To run the manual command successfully, you must specify a name for the log file in which the netsh actions will be recorded. (This log file is referred to as "resetlog.txt" in the manual procedures earlier in this section.)

 


Interestingly, they mention this:

When the TCP/IP registry keys have not been altered from their original configuration, there might be no actions logged in the file.

If I understand that correctly, then you can use the log file as a way to "test" to see if changes were made - like, you wouldn't have to already know what an original config looks like.


Cool.

Cool, Pieter!!!!!!

You rock.  [thumb]

~spam


__________________
If at first you don't succeed, destroy all evidence that you tried.

0
DennisMCSE

Senior Member
Registered:
Posts: 184
Reply with quote  #6 
Spammy and Pieter, thanks for the suggestions. I had tried most of them and used a meter to check the network cable is connecting to the switch, the meter pulled up an IP Address so the cable and switch were good, but nothing else worked. I totally forgot about trying netsh to reset the network. That I will try next time I'm at the computer.


0
wobble_wobble

Avatar / Picture

Associate Troublemaker Apprentice
Registered:
Posts: 937
Reply with quote  #7 
Try restarting the network location awareness service (NlaSvc)


__________________
Have you tried turning it off and walking away? The next person can fix it!

New to the forum? Read this
0
cspanburgh

Avatar / Picture

Senior Member
Registered:
Posts: 264
Reply with quote  #8 
Windows 10 update disabled some 4G based Wireless network cards.

I would see if that NIC is based on that.


__________________
Curt Spanburgh
0
Mafervus

Grumpy Old Men
Registered:
Posts: 41
Reply with quote  #9 
Piggy backing on Curt's comment, also double check chipset drivers.

fyi here is my old batch to reset ip and winsock. I used to use it a lot to clean up hiujacked machines.

netsh winsock reset
netsh winsock reset catalog
netsh int ip reset 


__________________
The problem with troubleshooting is that trouble shoots back. ~Author Unknown
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.