IPV6 addresses losing connectivity

[gwoverholt]

I'm having a couple, I believe to be, related issues with IPV6. Anyhow at first everything seems to work great but after an amount of time all ipv6 addresses seem to stop working. When I ping6 them I either get destination unreachable errors or I get 100% packet loss. If I reboot my router everything works again for an undetermined amount of time (usually only a few minutes). This problem occurs with the stateless auto configuration option. I would prefer the stateful option however all IPs i've received using the stateful option have always given me a destination not reachable error when pinging them.

I'm using version 378.46_1. I would have upgraded to version _3 but I didn't see any ipv6 related changes in the change log. Also I'm using the Native connection type and DHCP-PD enabled option.

Anyone have any ideas?

Thanks in advance.

 

[charlie2alpha]

Since you are using DCHP-PD you are probably suffering from this. I had the same problem but I created that script to fix it (I'm the one who posted those radvd.postconf scripts in the bug report).

 

[gwoverholt]

Thanks but it doesn't appear to be the same issue. The post you linked to speaks about a problem with the router's LAN prefix not being correct if the prefix is not 64 bits. In my case all prefixes appear to be the same but I am getting a 64 bit prefix not a 56 bit one. Mind you I'm only going off of what I see in the IPV6 information in the Merlin GUI. I see there's a log in the post you directed me to. Do you know how I can view logs for this device?

 

[gwoverholt]

Please disregard the question about where to find the log. I can't believe I didn't spot the System Log option before. Anyhow It seems I'm experiencing different behaviors with different machines. I'm going to dig into this a bit more and repost what I discover. One thing that is consistent so far is the Stateful Auto Configuration option seems to issue IPs that I can't reach when I ping them; However, I haven't tested that on a windows machine yet. Anyhow, I'll let you know.

 

[gwoverholt]

Alright, It seems that only one computer would lose connectivity and only when connected using wireless in the stateless configuration. The non pingable ip addresses received when using the stateful configuration only occurs with computers connected through my 24 port switch. When I connect those same computers directly to the router the IPs they receive work just fine. I thought that the switch was suppose to be agnostic to the IP version I was using but it appears at least in my case it isn't.

Anyhow, I have one remaining issue. The IP received on my laptop only, whether wireless or wired, connected directly or through the switch, shows a 128 bit prefix. The IP is correct showing the correct prefix and a proper remaining portion but the prefix length shows 128 bit. This only happens on Ubuntu 14.04 LTS. All other computers on my network, even Ubuntu installations, get the correct prefix lenght of 64 bits. The 128 bit prefix length has the effect of allowing me to ping anything that resolves to my local network but if I ping6 something like ipv6.google.com I get 100% packet loss. When discussing this with my buddy he checked his and discovered that his Ubuntu 14.04 LTS had the same issue even though he's using a completely different router; However, he can ping external IPv6 addresses. I'm guessing his router is ignoring the prefix length from Ubuntu and using the prefix it is already aware of. Another server with an older version of Ubuntu didn't have this problem. So it appears that the Merlin firmware is working just fine and I have an Ubuntu issue. I'm going to dig into the Ubuntu community and post my findings here in case anyone else is interested in my outcome.

 

[gwoverholt]

Will it looks like I'm all set. The issues I was having were due to my 24 port switch and a single network cable. The network cable issues turned out to be indeterministic in nature. The /128 I was seeing in the IP information on my Ubuntu systems is normal and indicates the number of bits that are specified in the IP. It does not refer to the subnet. The fact that none of the /128 IPs were not able to connect to external ips was indeterministic behavior. In the end even the /64 bit IPs were having the same problem. Swapping the network cable for another corrected this problem.