Recommended Posts

i have a weird network issue wherein my two network adapters get both an address via DHCP and also a Link Local IP address. (see screenshot). the two adapters are connected to two different networks with different dhcp servers. i have a feeling that this is a remnant from creating a bridge connections between the two adapters. this is an issue as in certain software that checks the IP address it detects and uses the link local ip address.

 

post-42710-0-99103300-1407170650.png

 

i have tried resetting network settings, resetting winsock. uninstalling the network adapter and adding it again but the problem seems to persists. i wanted to know if anyone has any clue on removing this link local address. it seems to only occur on the two network cards that i had created a bridge on earlier and deleted it.

 

any help is greatly appreciated 

 

do you have anything configured in your alternate configuration tab in the ipv4 properties within that adapter?

 

I believe this outlines your issue.  The default is automatic private ip address

http://www.eightforums.com/tutorials/29241-ip-address-enable-alternate-configuration.html

Another possible cause is that there is another computer with that ip address on the network.  If that is the case, you will need to change the static ip of that computer or reserve that ip in your dhcp for that other computer. 

I recall someone else having this issue awhile back and don't recall the exact cause - but this seems like a repeated problem. Hopefully the details will come to me here in a bit.

So what is this nic, its not dual port? is this the built in nic?

Arrggh its going to drive me nuts until I recall this previous thread now ;)

@sc302 the DHCP ip address 192.168.104.81 is reserved for the computer on the DHCP server so there is no conflict as far as i can tell. 

 

@budman the computer is laptop (Dell Precision M4700). one network is the built intel 82xx and the other one is via a USB3 to gigabit ethernet adapter (TRENDNet TU3-ETG). the issue is on both these cards. these were the two cards i tried to set the bridge on which i later deleted. 

 

could it be an issue related to how long windows waits before detecting wether DHCP server is present on the network. whats funny though is that the DHCP ip address shows up first and after a few mins the private IP also shows up. 

So I found the thread I was thinking about

https://www.neowin.net/forum/topic/1163160-each-nic-has-2-ip-addresses-cannot-work-out-why/

His was a VM.. He never came back to the thread - so not sure what happened with this.

You could try reset of your stack.. I have never ran into this before that last thread I linked too, have never seen it - so not exactly sure what could be causing your problem. I doubt it has anything to do with the attempted bridge. Did you actually remove the bridge?

http://support.microsoft.com/kb/299357

if you go to ipv4 properties, advanced do you see anything under IPs?

example

post-14624-0-77841400-1407185113.png

I've had that happen to a couple client machines. Reset the network stack, removed all network adapters and reinstalled them with new drivers. No static IP, the DHCP server was giving out the correct address. Still the problem would persist. Unfortunately the fastest thing for me to do was reimage the machine. Hopefully you won't have to resort to that.

If your ok with it - wouldn't mind setting up a Team viewer session to look into this a bit more.

Did you read the other thread about deleting the reg key for the guid that has that other IP On it?

Can you post the output of your ipconfig /all and also this section in device manager - making sure you set show hidden.

post-14624-0-88011900-1407196710.png

another area to look would be:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\

 

 

here are a few other things to try, there are a few in this thread:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/8acb7cd1-7028-4ffe-86c9-eb43041cf8b3/how-do-i-get-rid-of-second-169254xx-ipv4-address-on-windows-server-2008-sp2-x86?forum=winservergen

 

 

apparently there are a lot of causes and not one silver bullet to fix it.  you are going to have to try different things until you find the fix for you. 

I would take budman up on doing a teamviewer session...I wouldn't mind doing it either. 

Attached is the output from ipconfig/all 

 

i added the IPAutoConfigurationEnabled to 0 on all the interfaces but it still shows up as autoconfiguration enabled in ipconfig output. i have attached the registry of the interfaces module also

post-42710-0-37437800-1407226595.png post-42710-0-55559100-1407226626.png

 

 

ipconfig.txtFetching info...   interfaces.txtFetching info...

which of those guid shows 169.x address if any - don't have the time to convert the hex ;) Also look in registry if bridge is still there?

Do you have bridge left in the registry - should be here

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Bridge and BridgeMP

post-14624-0-91121900-1407238269.png

Did you reset the stack with netsh?

you could try removing those reg entries - they are not there unless a bridge has been created. I would have to test if they should be removed when you remove the bridge.

searching for the ip address in the registry did not yield any hits. 

 

as suggested by sc302 deleting the address works but it comes back at next bootup. this might be decent temporary solution until i can get around to doing a clean install. 


post-42710-0-39465700-1407253169.png

i use the MS disable IPv6 utility to disable IPv6 http://support.microsoft.com/kb/929852

 

SVGigE filter driver is the driver for a SVS Vistek GigE  camera. this was installed prior to the problem showing up. just to try i have removed it and problem is still there.

I disable ipv6 in the registry with simple command

reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255

But I would then unbind the interface for sure as well.. Try unchecking that reboot to see if your apipa address is still there.

This topic is now closed to further replies.