ipv6: Neighbour table overflow

[RMerlin]

Who knows who it is but it seems to be specific to certain regions for Comcast. I ran ipv6 on my Ac66u for months without the table overflow errors until I moved to another state and then I saw them.

I suspect it's node-specific, which would explain why Comcast can't reproduce it on whichever node they are using for tests. My theory is that on certain nodes, Comcast isn't filtering traffic (or there are more IPv6 customers on certain nodes than others), and customers on that node are flooding one another with some type of broadcast. But that's just a theory. I've seen others that said it was a bug in the 2.6.22.19 kernel Asus uses, which was fixed in newer kernel releases.

Sure would be interesting to see how an AC56 or AC68 would work out, since it's based on 2.6.36.

What Comcast probably needs to do is actually sniff out the traffic on an affected node.

 

[teh_g]

I suspect it's node-specific, which would explain why Comcast can't reproduce it on whichever node they are using for tests. My theory is that on certain nodes, Comcast isn't filtering traffic (or there are more IPv6 customers on certain nodes than others), and customers on that node are flooding one another with some type of broadcast. But that's just a theory. I've seen others that said it was a bug in the 2.6.22.19 kernel Asus uses, which was fixed in newer kernel releases.

Sure would be interesting to see how an AC56 or AC68 would work out, since it's based on 2.6.36.

What Comcast probably needs to do is actually sniff out the traffic on an affected node.

I have an AC68, so it is not fixed in newer versions.

 

[RMerlin]

I have an AC68, so it is not fixed in newer versions.

Ok, so that kinda disproves the theory that it was an issue specific to older kernels (unless it was only recently fixed - can't remember the details as it's been a few months since I ran across that theory).

 

[teh_g]

Ok, so that kinda disproves the theory that it was an issue specific to older kernels (unless it was only recently fixed - can't remember the details as it's been a few months since I ran across that theory).

Sorry

I tried a few different DNS providers as well to see if maybe that was related, but it seems to make no difference.

Is there any way to find out why I can't echo in the higher gc_thresh values?

 

[jlake]

If you've never read the comcast thread about this issue, then you should. The Comcast engineer has tried to reproduce the issue, but can't. He's tried emailing Asus a few times but Asus doesn't even reply to his emails. Hopefully it's just a matter of him having the wrong email address, because if asus doesn't even respond to his emails, that would be pretty lame and unprofessional. IMHO.

It's not like comcast is some rinky dink ISP that asus can just ignore. But on second thought.....I guess they can and did.

 

[teh_g]

If you've never read the comcast thread about this issue, then you should. The Comcast engineer has tried to reproduce the issue, but can't. He's tried emailing Asus a few times but Asus doesn't even reply to his emails. Hopefully it's just a matter of him having the wrong email address, because if asus doesn't even respond to his emails, that would be pretty lame and unprofessional. IMHO.

It's not like comcast is some rinky dink ISP that asus can just ignore. But on second thought.....I guess they can and did.

Yeah, I read through that, it looks like nothing helpful ever happens...

Any ideas why I can't echo the values I need to workaround it at least?

 

[jlake]

Yeah, I read through that, it looks like nothing helpful ever happens...

Any ideas why I can't echo the values I need to workaround it at least?

No idea. Have you tried opening a support case with asus? I would try opening a support case with both asus and Comcast. For me personally, I wouldn't even try workaround, I would just disable IPv6 until situation is resolved or asus/comcast told me that there was nothing to worry about with those errors.

 

[jim769]

No idea. Have you tried opening a support case with asus? I would try opening a support case with both asus and Comcast. For me personally, I wouldn't even try workaround, I would just disable IPv6 until situation is resolved or asus/comcast told me that there was nothing to worry about with those errors.

I would hope these errors are not a security issue. That said it does not affect the function of v6 in any way. I have had Native v6 working here for over a year and i wont disable it, lets hope Merlins v6 firewall would stop any risk if there indeed is any risk involved with these neighbor overflows. Most people i talk to dont even know what IPV4 is let alone IPV6

 

[teh_g]

I actually think my biggest concern would be the fairly large amount of data being written to the /jffs share.

I think for now I am going to keep IPv6 disabled. There isn't a real good reason to have it on yet (beyond nerdiness).

 

[teh_g]

I was finally able to get these values to change by making an init script on the JFFS mount (which took work since the thing doesn't want to mount in Samba).

 

[jim769]

I actually think my biggest concern would be the fairly large amount of data being written to the /jffs share.

I think for now I am going to keep IPv6 disabled. There isn't a real good reason to have it on yet (beyond nerdiness).

Nerdiness LOL IPv6 is the future ipv4 addresses are used up. I understand it is in its infancy but that is changing rapidly. There are many websites that use v6 already Google,Yahoo, Netflix, Amazon just to name a few.

 

[teh_g]

I actually think that this issue caused some of my packet loss. After actually implementing the workaround, I haven't seen any lost packets.

 

[Find the Door]

How would I check if I'm losing any packets? I haven't had any issues with IPV6 on comcast so far?

I'm on their blast! tier, and have a customer owned Motorola SB6141.

 

[dutchman71]

So I stumbled upon this forum trying to figure out why I couldn't stream movies from my AC68r and attached USB drive without the movie getting interrupted and having to reconnect my TV every 20 minutes...

Turns out it is the ipv6 problem causing the issues.. Turned ipv6 off and issues solved. Neighbor table overflow errors causing the reboots.

This is crazy... Yes, my ISP is Comcast/Xfinity.

I must have factory reset 15 times and the same issue kept occurring.

Thank you. Now fix it ASUS...

 

[teh_g]

How would I check if I'm losing any packets? I haven't had any issues with IPV6 on comcast so far?

I'm on their blast! tier, and have a customer owned Motorola SB6141.

I just did ping -t Google.com from my PC.

 

[maletor]

Same issue

I'm running into the same issue. I'm using the latest build from shibby (116) on my asus rt-n66u.

I don't think the second step found in http://mydeviceinfo.comcast.net/download.php?file_id=31 is necessary anymore with dnsmasq-dhcp, but I could be mistaken.

By increasing the gc_thresh values I was able to suppress the warning, however, leaving over night my ipv6 died. Last night googling "what is my ip" revealed the ipv6 address but today it is back to ipv4.

Is the memory leak still there? My guess is yes. What is going on here? Are there any fixes for running ipv6 on tomato?

 

[teh_g]

Going to update the first post with this, but I was finally able to clear the messages by manually echoing individual lines to a jffs script (I couldn't get jffs to mount in samba). Here is the script I used:

#!/bin/sh
# Workaround IPv6 neighbour overflow
rm -rf /tmp/init-start.ran
echo 512 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv6/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv6/neigh/default/gc_thresh3

#May as well do it for IPv4 just in case
echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

#This file will be updated at reboot if this ran
touch /tmp/init-start.ran