Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

IPv4/IPv6 Nightmare (No Internet Access) (Teredo)


  • Please log in to reply
8 replies to this topic

#1 eewiz

eewiz

  • Members
  • 21 posts
  • OFFLINE
  •  
  • Local time:05:42 AM

Posted 18 April 2017 - 05:34 PM

I have two almost identical Win 7 x64 boxes.

 

One works flawlessly, the other has massive Internet connectivity issues.

Both appear to have the same identical network adapter hardware.

 

The box that works I'll call WORKS and the one with the issues I'll call FAILS.

Here is equivalent information for both boxes.

 

WORKS
Asus M5A97 LE R2.0, 16GB Memory, AMD 970 chipset
Realtek PCIe GBE Family Controller on motherboard
PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09\4&2799F330&0&0020
Rt64win7.sys 7.058.0411.2012 Driver
Windows has determined that the software driver for your device is up to date.

"Teredo Tunneling Pseudo-Interface" has never been installed (it is not installed by Windows by default).
No "Teredo Tunneling Pseudo-Interface" is listed in "Admin Device Manager" with "Show Hidden Devices" ckecked and "Devices by Connection" selected.

Teredo is not enabled in windows by default.
Microsoft Windows [Version 6.1.7601]
C:\Windows\system32>netsh interface teredo show state

Teredo Parameters
---------------------------------------------
Type                    : disabled
Server Name             : teredo.ipv6.microsoft.com.
Client Refresh Interval : 30 seconds
Client Port             : unspecified
State                   : offline
Error                   : none


FAILS
Asus Sabertooth 990FX R2.0, 16GB Memory, AMD 990 Chipset
Realtek PCIe GBE Family Controller on motherboard
PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09\4&28B85F88&0&00A9
Rt64win7.sys 7.067.1226.2012 Driver
Windows has determined that the software driver for your device is up to date.

"Teredo Tunneling Pseudo-Interface" had to be installed to make this box work (it is not installed by Windows by default).
"Teredo Tunneling Pseudo-Interface" is listed in "Admin Device Manager" with "Show Hidden Devices" ckecked and "Devices by Connection" selected.

You have to enable Teredo with a netsh command to make this box work (Teredo is not enabled, nor installed, in windows by default).
Microsoft Windows [Version 6.1.7601]
C:\Windows\system32>netsh interface teredo show state

Teredo Parameters
---------------------------------------------
Type                    : client
Server Name             : teredo.ipv6.microsoft.com.
Client Refresh Interval : 30 seconds
Client Port             : unspecified
State                   : dormant

 

The net controller appears to be identical in both machines, both drivers named the same but, dissimilar driver versions.

Yet, notice that windows says that both drivers are up to date.

How can that be?

Since windows says that both drivers - one obviously newer than the other - are up to date for the same hardware on two different boxes.

Then my only conclusion can be to not trust windows when it says that a driver is up to date.

They both can't be "up to date."

 

Despite that, the FAILS box initially worked for a week or so then "No Internet Access" pops up in the tray.

I've had this happen once before on a Win 7 x86 box that I have since nuked and rebuilt.

As a matter of fact, that previously failing, nuked and rebuilt box is the WORKS machine in this example, (the M5A97 LE R2.0)

Yes, that very box that WORKS now used to have the very same issue when it was a Win 7 x86 box.

It is this networking SNAFU that caused me to nuke and rebuild the WORKS box in the first place.

The WORKS box has been running for several months now.

The FAILS box is just weeks old.

 

So, the issue goes like this. One day the dreaded "No Internet Access" message shows up in the tray.

"Control Panel\All Control Panel Items\Network and Sharing Center" has a big red X between the Network and Internet icons.

Click the red X, run the troubleshooter, and the error always is "Administrator has disabled Teredo locally", or something like that.

The only way that I have found to get rid of the red X is to install and enable the Teredo adapter.

Now that the red X is gone the Network tray icon is happy. The Network Map is as it should be.

 

But now all web pages tried in Mozilla just time out.

"Local Area Connection Status" says:

IPv4 Connectivity: Internet

IPv6 Connectivity: No Internet Access

 

Yet, some pings now return only IPv6 data despite the above "IPv6 Connectivity: No Internet Access."

I have never seen an IPv6 return from a ping until now.

 

Here are the pings from the WORKS and FAILS boxes.

 

WORKS

C:\Windows\system32>ping google.com
Pinging google.com [172.217.5.206] with 32 bytes of data:
Reply from 172.217.5.206: bytes=32 time=20ms TTL=55
Reply from 172.217.5.206: bytes=32 time=20ms TTL=55
Reply from 172.217.5.206: bytes=32 time=20ms TTL=55
Reply from 172.217.5.206: bytes=32 time=20ms TTL=55

 

Ping statistics for 172.217.5.206:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 20ms, Maximum = 20ms, Average = 20ms

C:\Windows\system32>ping arrl.org
Pinging arrl.org [184.106.62.251] with 32 bytes of data:
Reply from 184.106.62.251: bytes=32 time=90ms TTL=48
Reply from 184.106.62.251: bytes=32 time=83ms TTL=48
Reply from 184.106.62.251: bytes=32 time=84ms TTL=48
Reply from 184.106.62.251: bytes=32 time=83ms TTL=48

Ping statistics for 184.106.62.251:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 83ms, Maximum = 90ms, Average = 85ms

FAILS

C:\Users\eewiz>ping google.com
Pinging google.com [2607:f8b0:4007:80d::200e] with 32 bytes of data:
Reply from 2607:f8b0:4007:80d::200e: time=21ms
Reply from 2607:f8b0:4007:80d::200e: time=21ms
Reply from 2607:f8b0:4007:80d::200e: time=22ms
Reply from 2607:f8b0:4007:80d::200e: time=22ms

Ping statistics for 2607:f8b0:4007:80d::200e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 21ms, Maximum = 22ms, Average = 21ms

C:\Users\eewiz>ping arrl.org
Pinging arrl.org [184.106.62.251] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 184.106.62.251:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
 

The windows firewall on the FAILS box has been turned OFF throughout all.

 

This may also be very important.

If I turn OFF IPv6 support at my router, the FAILS box's pings change to this:

 

C:\Users\eewiz>ping google.com
Ping request could not find host google.com. Please check the name and try again.

C:\Users\eewiz>ping arrl.org
Pinging arrl.org [184.106.62.251] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 184.106.62.251:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

 

So, obviously, the only working Internet connectivity on the FAILS box is IPv6.

But remember that the:

"Local Area Connection Status" says:

IPv4 Connectivity: Internet

IPv6 Connectivity: No Internet Access

 

When I turned OFF IPv6 support at the router, the FAILS box went to:

IPv4 Connectivity: No Internet Access

IPv6 Connectivity: No Internet Access

The "IPv4 Connectivity" went to "No Internet Access" despite the fact that I turned OFF the IPv6 support.

 

All other boxes on my network never changed.

All of their;

"Local Area Connection Status" said:

IPv4 Connectivity: Internet

IPv6 Connectivity: Internet

even though IPv6 support was OFF at the router.

All other boxes still had functional Mozilla internet connectivity with IPv6 turned OFF at the router.

 

Please! does anyone know why internet connectivity falls down so dramatically on one box and works fine on many other boxes?

 

I realize that I will probably have to completely rip out, reset, and reinstall anything to do with networking on the FAILS box.

So, if anyone knows of a good primer on rip out, reset, and reinstall of networking, that would also be highly appreciated.

 

Of course, if anyone knows precisely why this happens and how to prevent it (preferred) or fix it after the fact I, and I think many others on the internet, would like to read that answer.

 

Thank You



BC AdBot (Login to Remove)

 


#2 JohnC_21

JohnC_21

  • Members
  • 23,976 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:42 AM

Posted 18 April 2017 - 05:58 PM

Have you tried resetting Winsock and TCP/IP?

 

http://www.velocitymicro.com/SupportArticles/Article_959.php

 

After doing the above download and install this LAN driver.

 

Win7 and Server 2008 R2 Auto Installation Program (SharedID:1152921504607149738
SID:1152921504626417159)
7.105 2017/3/23 10500k

 



#3 eewiz

eewiz
  • Topic Starter

  • Members
  • 21 posts
  • OFFLINE
  •  
  • Local time:05:42 AM

Posted 19 April 2017 - 01:30 PM

Thank you for your helpful information.

 

I removed all adapters in device manager, including the windows adapters (adapters 001 through 006) in the registry and then rebooted.

Since the windows adapters 1-6 were not actually removed from the registry I'll bet I can simply reenable them with the netsh command.

If not, they can all be reinstalled from device manager, add legacy hardware or the networking GUI.

Adapter 007 in the registry is the first adapter installed by the user. In both boxes, the hardware adapter on the motherboard.

 

I then installed the recommended driver downloaded from the link above.

 

Attached is a screenshot of where networking now stands on the FAILS box.

I also attached an HTML file detailing the differences in the HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318} subkey from both boxes.

The base file is the WORKS box which was compared to the FAILS box.

The struck through green text is present in the WORKS box and not present in the FAILS box.

The yellow highlighted text is present in the FAILS box and not present in the WORKS box.

 

The screenshot says it all. I am down to 1 physical adapter with almost no other clutter and all I get is IPv6 connectivity.

 

The WORKS box has adapters from four sources; Windows, VMWare, VirtualBox and the hardware.

The FAILS box has had all adapters removed except for the hardware.

Also, the FAILS box no longer uses a static IP. It is now set to DHCP from the router.

You may also notice that my router (TP-Link WR841N) has the google DNS servers 8.8.8.8 and 8.8.4.4 set for both IPv4 and IPv6.

The router's DNS settings have been that way for a long time, so it's not likely to be the issue. Besides, all failed IPv4 pings show that an IPv4 DNS address is obtained but then all IPv4 communication times out.

 

Here is the ipconfig /all for the FAILS box.

 

C:\Windows\system32>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : MUFF
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : D0-17-C2-95-E1-F2
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2600:8800:3280:3c0:6515:1e8a:eb85:2a64(Preferred)
   Temporary IPv6 Address. . . . . . : 2600:8800:3280:3c0:d467:7429:78ef:dd87(Preferred)
   Link-local IPv6 Address . . . . . : fe80::6515:1e8a:eb85:2a64%14(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.2.100(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, April 18, 2017 6:35:21 PM
   Lease Expires . . . . . . . . . . : Thursday, April 20, 2017 6:35:21 PM
   Default Gateway . . . . . . . . . : fe80::f6f2:6dff:fe40:dea2%14
                                       192.168.2.1
   DHCP Server . . . . . . . . . . . : 192.168.2.1
   DHCPv6 IAID . . . . . . . . . . . : 248518594
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-77-D5-FA-D0-17-C2-95-E1-F2
   DNS Servers . . . . . . . . . . . : 2001:4860:4860::8888
                                       2001:4860:4860::8844
                                       192.168.2.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

 

 



#4 eewiz

eewiz
  • Topic Starter

  • Members
  • 21 posts
  • OFFLINE
  •  
  • Local time:05:42 AM

Posted 19 April 2017 - 01:40 PM

Well, since I am looking at my last post and I see nothing attached, I will try to attach again.

It said something about attachment failed requires flash9 or something similar.

So I did the basic attachment option which appears to not have worked.

So here goes again.

Click browse and select LAN_Status.zip

LAN_Status.zip shows next to the browse button.

Now I click Add Reply and hope that I will be able to back around a view my own post and be able to find the attachment.

 



#5 eewiz

eewiz
  • Topic Starter

  • Members
  • 21 posts
  • OFFLINE
  •  
  • Local time:05:42 AM

Posted 19 April 2017 - 02:09 PM

Well, since I can't seem to be able to attach, let's try pasting.

Here's the screenshot.

First try JPG.

You are not allowed to use that image extension on this community.

Second try BMP.

You do not have permission for that action.

Third try PNG.

You are not allowed to use that image extension on this community.

I give up. I'm sorry but I guess I just can't do anything but type.

 

 

 

 

And here's the registry difference data.

 

NOT!

I pasted it in but it was just too much text and for some unknown reason the strike through and highlighting from the HTML file disappeared, making the data essentially worthless.

 

For now the pasted screenshot is the best I can do.

Well, I guess I can't even do that.



#6 JohnC_21

JohnC_21

  • Members
  • 23,976 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:42 AM

Posted 19 April 2017 - 02:20 PM

If disabling ipv6 doesn't solve the problem download Windows Repair and only check the Network Repair box. Reboot. Other than that I am out of ideas and it may be a better option to post in the Networking forum.

 

http://www.tweaking.com/content/page/windows_repair_all_in_one.html

 

To rule out a hardware problem you could boot a live linux disk and see if you have any connection issues. I would recommend Linux Mint Cinnamon. 

 

https://linuxmint.com/rel_serena_cinnamon_whatsnew.php

 

https://linuxmint.com/edition.php?id=226



#7 eewiz

eewiz
  • Topic Starter

  • Members
  • 21 posts
  • OFFLINE
  •  
  • Local time:05:42 AM

Posted 19 April 2017 - 07:13 PM

To your first point. IPv6 is the only thing that does work. It's IPv4 that has no internet access.

 

I downloaded as recommended. After running Network Repair and rebooting, all of the windows network adapters as well as the hardware adapter were back in device manager in pristine fashion.

 

Still no IPv4 internet access.

 

I shut down FAILS, rebooted Mint Live and similarly had no internet in Mint's Mozilla.

I went to the router (192.168.2.1) to find myself (Linux Mint) in the router's DHCP client table (.100 to .199). The only thing there was my two Roku boxes.

Mint did not appear. Yet, It was Mint I used to go to the router (192.168.2.1). I don't know if Mint is capable of reaching 192.168.2.1 if it had not already received a DHCP lease.

While there, I noticed that the DHCP settings page had boxes for fixed DNS's, marked optional, which have always both been set to 0.0.0.0 (unused).

I set them to 8.8.8.8 and 8.8.4.4 like I've had the ISP and IPv6 Support pages set to for some time now, and saved the changes.

The routers ISP page has always had 8.8.8.8 and 8.8.4.4 set to be used instead of the ISP's DNS servers.

Hence all the static IP setups in the house set only one DNS address of 192.168.2.1 (the router).

A static IP example is; IP 192.168.2.5, mask 255.255.255.0, gateway 192.168.2.1, DNS 192.168.2.1, WINS 192.168.2.1,

All boxes in the house are set up like this and this has worked for me through half a dozen routers over several decades.

In a workgroup type network you don' have DHCP, WINS and/or DNS servers. So it makes sense to me why routers do DHCP, WINS and DNS.

 

Anyway, after the change on the DHCP page, the router said it had to reboot for the new DNS settings to be applied.

So I rebooted the router and waited a minute.

Mint now had connectivity to the internet and it now showed in the router's DHCP client list.

 

I rebooted FAILS and it also now had IPv4 connectivity restored.

At this point FAILS is running on a DHCP lease (.100) from the router.

Here is the ipconfig /all:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : MUFF
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : D0-17-C2-95-E1-F2
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2600:8800:3280:40c:6515:1e8a:eb85:2a64(Preferred)
   Temporary IPv6 Address. . . . . . : 2600:8800:3280:40c:530:a59d:6bed:cd84(Preferred)
   Link-local IPv6 Address . . . . . : fe80::6515:1e8a:eb85:2a64%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.2.100(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, April 19, 2017 1:28:33 PM
   Lease Expires . . . . . . . . . . : Friday, April 21, 2017 1:28:33 PM
   Default Gateway . . . . . . . . . : fe80::f6f2:6dff:fe40:dea2%11
                                       192.168.2.1
   DHCP Server . . . . . . . . . . . : 192.168.2.1
   DHCPv6 IAID . . . . . . . . . . . : 248518594
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-77-D5-FA-D0-17-C2-95-E1-F2
   DNS Servers . . . . . . . . . . . : 2001:4860:4860::8888
                                       2001:4860:4860::8844
                                       8.8.8.8
                                       8.8.4.4
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{D0E30EB6-CA31-4A0E-91F1-89292BE502DA}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

 

Notice at this point that the DNS data has changed.

Before:

   DNS Servers . . . . . . . . . . . : 2001:4860:4860::8888
                                       2001:4860:4860::8844
                                       192.168.2.1

After:
   DNS Servers . . . . . . . . . . . : 2001:4860:4860::8888
                                       2001:4860:4860::8844
                                       8.8.8.8
                                       8.8.4.4

 

As far as I know, both should work and the former has been working on all other boxes in the house forever.

 

Also notice that since windows was rebooted, after the router reboot, a new adapter has appeared.

Tunnel adapter isatap.{D0E30EB6-CA31-4A0E-91F1-89292BE502DA}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

 

Wikipedia says that the ISATAP driver is:

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is an IPv6 transition mechanism meant to transmit IPv6 packets between dual-stack nodes on top of an IPv4 network.

Since IPv6 has been working throughout, the appearance of an adapter that makes IPv6 work over IPv4 proves inconclusive.

It does make me wonder about the appearance of this adapter once IPv4 started working again.

 

Also, another interesting fact. In the past, when the WORKS box was in the same, no IPv4 connectivity situation, it was a different (Netgear) router.

That box, now the WORKS box, was the reason I got the ((TP-Link) router. The WORKS box, back when it would not work also had an incorrect Network Map.

So, a new router and a couple of new switches and my Network Map issues were solved. But that would not make the WORKS box work back then when it was a Win 7 x86 box.

 

I am starting to get a sneaking suspicion that something I am doing or some software that I am using or configuring in a certain way corrupts windows networking.

Windows then starts adding adapters to try to fix the issue ultimately driving the IPv4 capabilities of the router for that MAC address off the deep end.

Now the router stops doing IPv4 for that MAC address.

Now that IPv4 support is gone. Windows goes into a whirling dervish every time it boots, adding adapter after adapter, with longer and longer boot times each boot.

Now windows networking is hosed and it won't matter if you reboot your router.

 

So, now that FAILS is working, I can only wait for it fall down again.

Then, a quick reboot of the router will settle any question about the router being the culprit.

For now, I will start to rebuild the FAILS box's ripped out networking guts with backups at each and every stage until it breaks again.

By then maybe I will be able to figure out how to move this thread to the Networking Forum as suggested.

 

Thank You



#8 JohnC_21

JohnC_21

  • Members
  • 23,976 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:08:42 AM

Posted 19 April 2017 - 07:27 PM

Thanks for the comprehensive update. If possible please post another update on how thing hash out.



#9 eewiz

eewiz
  • Topic Starter

  • Members
  • 21 posts
  • OFFLINE
  •  
  • Local time:05:42 AM

Posted 27 April 2017 - 06:03 AM

First, let me thank JohnC_21 for his critical help.

 

Second, I have the answer.

 

As I concluded my last post, I was down to the hardware adapter and one malfunctioning ISATAP adapter, as should be visible in the following screenshot

Also notice the negative IPv4 connectivity in both of these screenshots.

Attached File  LAN_Status.jpg   285.82KB   0 downloads

 

The Tweaking.com Network Repair utility did a fine job of repairing all of the windows networking that I ripped out.

Attached File  LAN_Status_2.jpg   156.14KB   0 downloads

 

The screenshots above, which I'm sorry to say I could not figure out how to attach earlier, thank you medab1, were shot before I discovered that the issue stemmed from the router.

 

With the typical compliment of adapters returned to duty, and the router rebooted, I was back to good IPv4 connectivity.

I reinstalled all the networking related applications and utilities I had ripped out previously.

Lots of backups, restore points and reboots later, I was done.

I was back to where It all blew up the week prior.

 

I started Vuze to work on a large file that I've been whittling on a piece at a time.

I got this feeling of deja vu. I've been here before. Late one night last week before my IPv4 blew up.

Remember, the FAILS box was cloned from the WORKS box so, I had spent several weeks before the IPv4 blew up, continuously checking every shortcut, batch file and program's settings to make sure I didn't have something cross coupled to the other box by some hard coded something or another.

Early on, booting the FAILS box with the WORKS box turned off, would take a long time while windows tried to find things it couldn't.

 

Late that one sleepy evening, since Vuze was running, I thought I would give it's settings a turn under the cloned machine microscope.

On the Connection page, I noticed the Network selections.

I unchecked the one labeled "Public IP network" just to see what happens.

I don't know what the other networks are but, at that time, I was curious to see what would happen.

When I finished my review of Vuze's settings I noticed that my file had stopped downloading.

This was too much at the end of a long day. I thought that I would pick up where I left off that next morning.

 

I woke that next morning to find the dreaded No Internet Connectivity message that started this whole mess.

So here I am again, in Vuze's settings, with my file downloading.

I uncheck "Public IP network" and hit the save button.

My file stops downloading again.

Then it hits me, BOOM, I have the answer.

 

I suppose you might expect that Vuze's settings would only affect Vuze. Not so.

I do not know whether this is intentional or accidental.

Unchecking the "Public IP network" setting causes my TP-Link WR481N router to go offline to IPv4 WAN traffic only for the specific MAC address of the box involved.

As you can see from the previous ipconfig output. Ipv4 DNS works. Ping arrl.com returns the dotted IP address but all packets time out.

 

The router provides no indication of what might be the cause of the this condition.

First off, there is no selection to disable IPv4 on this router. You can disable IPv6 but not IPv4.

I found no entries added to any kind of exclusion list like, Forwarding, Security, Parental Control, Access Control, Advanced Routing nor IP and MAC Binding.

Of course, all of those exclusion type entries would be stored in flash to remain through a reboot of the router.

Rebooting the router appears to be the only way to erase the condition.

 

Also, rechecking Vuze's "Public IP network" setting did not restore IPv4.

Restart Vuze, remove and reinstall Vuze, restart windows, remove and reinstall all of windows networking.

Nothing will bring the router back. It has to be rebooted.

 

Rebooting my router is the only way I have found to regain IPv4 connectivity.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users