PrintK messages still after Broadcast on PPTP turned off

[murph2481]

Running the latest 40beta2 with a recent reset I have always had and never been able to remove these error messages:

Mar 6 16:04:31 kernel: printk: 284 messages suppressed.

I know reading back someone mentioned the Firewall settings might be tripping it but I set it to what they had and no luck

Merlin mentioned turning on PPTP broadcasting to disable and turning off SAMBA for PPTP, which I have and PPTP isn't even running I use OpenVPN.

Anyone else have any suggestions?

 

[RMerlin]

Running the latest 40beta2 with a recent reset I have always had and never been able to remove these error messages:

Mar 6 16:04:31 kernel: printk: 284 messages suppressed.

I know reading back someone mentioned the Firewall settings might be tripping it but I set it to what they had and no luck

Merlin mentioned turning on PPTP broadcasting to disable and turning off SAMBA for PPTP, which I have and PPTP isn't even running I use OpenVPN.

Anyone else have any suggestions?

All the line you posted is telling us is that the line just before it was repeated 284 times. So, without seeing that line, we can't tell what was actually suppressed.

 

[murph2481]

Alright then that makes sense and its a known issue with Comcasts IPv6 according to other posts. I didn't think it was causing an issue I was just curious what it meant. Thanks for the clarification below is a paste of more log data to confirm that its the neighborhood table overflow issue:

Mar 6 20:58:01 kernel: printk: 161 messages suppressed.
Mar 6 20:58:01 kernel: Neighbour table overflow.
Mar 6 20:58:06 kernel: printk: 389 messages suppressed.
Mar 6 20:58:06 kernel: Neighbour table overflow.
Mar 6 20:58:13 kernel: printk: 546 messages suppressed.
Mar 6 20:58:13 kernel: Neighbour table overflow.
Mar 6 20:58:17 kernel: printk: 253 messages suppressed.
Mar 6 20:58:17 kernel: Neighbour table overflow.
Mar 6 20:58:22 kernel: printk: 515 messages suppressed.
Mar 6 20:58:22 kernel: Neighbour table overflow.
Mar 6 20:58:28 kernel: printk: 548 messages suppressed.
Mar 6 20:58:28 kernel: Neighbour table overflow.
Mar 6 20:58:30 kernel: printk: 377 messages suppressed.
Mar 6 20:58:30 kernel: Neighbour table overflow.
Mar 6 20:58:35 kernel: printk: 674 messages suppressed.
Mar 6 20:58:35 kernel: Neighbour table overflow.
Mar 6 20:58:41 kernel: printk: 77 messages suppressed.
Mar 6 20:58:41 kernel: Neighbour table overflow.
Mar 6 20:58:47 kernel: printk: 296 messages suppressed.
Mar 6 20:58:47 kernel: Neighbour table overflow.
Mar 6 20:58:50 kernel: printk: 294 messages suppressed.
Mar 6 20:58:50 kernel: Neighbour table overflow.
Mar 6 20:58:57 kernel: printk: 59 messages suppressed.
Mar 6 20:58:57 kernel: Neighbour table overflow.
Mar 6 20:59:00 kernel: printk: 95 messages suppressed.
Mar 6 20:59:00 kernel: Neighbour table overflow.

26+ hours on .40 Beta2 no restarts or other error messages, signals are strong across all 23 wireless devices in my house both on 2.4 and 5 GHz. Firmware is great and thank you for your hard work and prompt replies as always!

RT-N66U

 

[RMerlin]

That's indeed the Comcast issue.

Try the following fix:

http://www.linksysinfo.org/index.php?threads/toastman-releases.36106/page-25#post-242097

 

[murph2481]

Script to remove Neighborhood Table Overflow Comcast

Sweet! Merlin as usual you rock. Just followed the link and ran the script and then added it to the startup and now all my Neighborhood Table Overflow errors are gone. Below are the steps if anyone is curious:

//first enable JFFS Partition for writing and format if needed
-To enable this option, go to the Administration page, under the System tab.

//Login SSH

//Go to JFFS Folder

cd /jffs/scripts/

//edit or create services-start file for reboot script

vi firewall-start

//Copy and paste script below

#!/bin/sh
ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i eth0 -d ff02::1:ff00:0/104 -j DROP

{press escape then :x}

//Change folder permissions for execution

chmod a+rx /jffs/scripts/*

 

[murph2481]

Scripts not automatically running?

So why isn't my script automatically running when it restarts? Did I miss something in my directions from above?

 

[RMerlin]

When manipulating the firewall, it's often best to use firewall-start or nat-start instead.

 

[RocketJSquirrel]

How do you know it's not running?

Did you make sure the ip6tables command was all on one line? It won't work split into 2 lines.

 

[murph2481]

Adding it to firewall-start worked

I knew it wasn't running because the neighborhood tables error would show up after restart until i manually logged in SSH or went to run CMD and ran the command again.

Using Merlin's suggestion of tieing it to firewall-start seems to have solved the problem because after the reboot I do not see any neighborhood tables overflow error messages.

Thanks!

 

[condor]

I'm having the same issue, but related to IPv4, not IPv6 (I'm Italian and Comcast is not even available here). I got rid of all the "neighborhood tables overflow" messages adding the following script to init-start:

#!/bin/sh
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/default/arp_announce
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

but the script just posted seems a more elegant solution to the issue. Can someone please adapt it to IPv4?

 

[RMerlin]

I'm having the same issue, but related to IPv4, not IPv6 (I'm Italian and Comcast is not even available here). I got rid of all the "neighborhood tables overflow" messages adding the following script to init-start:



but the script just posted seems a more elegant solution to the issue. Can someone please adapt it to IPv4?

That wouldn't work, as it applies specifically to a type of IPv6 traffic that is causing the tables to be filled up.

 

[condor]

Thanks! I'll stick with my script then, unless someone has any better suggestion

 

[neil0311]

Can someone please clarify exactly what steps I need to take to fix this? I am not that savvy with scripting or custom startup scripts, so if you can provide me a step by step, I'd greatly appreciate it.

 

[RogerSC]

For a script like firewall-start, a good thing to do is to put something like this in your script:

touch /tmp/firewall-start.ran

Then to see if it ran after your router is rebooted, you can just do an "ls /tmp", and look for the marker file. If the marker file is there, and the script isn't doing what it's supposed to do, then you know that it's a problem in the script, not in whether the script was run. This has been heloful to me.

I've also experienced a lot of neighborhood table overflow problems, and have it at bay using the script that re-writes the gc_thresh* files, just for ipv6. I'd rather just use the ip6tables command, but haven't tried it yet.

Edit: Has anyone gotten this ip6tables solution to the neighbor table overflow problem to work? If so, can you please mention which script you used, firewall-start, nat-start, or ?

 

[cmillar6]

Can someone please clarify exactly what steps I need to take to fix this? I am not that savvy with scripting or custom startup scripts, so if you can provide me a step by step, I'd greatly appreciate it.

Merlin, is this something you could add to the ipv6 tables in a future release? I'm also not completely comfortable with implementing start-up scripts. It seems to be a solution to a long standing issue with running ipv6 with Comcast.

 

[RogerSC]

Just tried this script:

#!/bin/sh
ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor solicitation -i `nvram get wan_iface` -d ff02::1:ff00:0/104 -j DROP
touch /tmp/firewall-start.ran

Get this error:

Bad argument `ff02::1:ff00:0/104'

I'm not familiar enough with ip6tables to see what the problem is...older/different implementation of ip6tables? Guess I need equivalent syntax that's acceptable to the RT-N66U ip6tables implementation? Odd...

 

[RMerlin]

Merlin, is this something you could add to the ipv6 tables in a future release? I'm also not completely comfortable with implementing start-up scripts. It seems to be a solution to a long standing issue with running ipv6 with Comcast.

I'm considering it, but haven't taken any decision yet. I need to be sure this won't introduce a different issue.

 

[RMerlin]

Just tried this script:

#!/bin/sh
ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor solicitation -i `nvram get wan_iface` -d ff02::1:ff00:0/104 -j DROP
touch /tmp/firewall-start.ran

Get this error:

Bad argument `ff02::1:ff00:0/104'

I'm not familiar enough with ip6tables to see what the problem is...older/different implementation of ip6tables? Guess I need equivalent syntax that's acceptable to the RT-N66U ip6tables implementation? Odd...

Asuswrt uses a different nvram setting for WAN, since it has to be able to handle DualWAN.

ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i `nvram get wan0_ifname` -d ff02::1:ff00:0/104 -j DROP

 

[RogerSC]

Asuswrt uses a different nvram setting for WAN, since it has to be able to handle DualWAN.

ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i `nvram get wan0_ifname` -d ff02::1:ff00:0/104 -j DROP

For interest's sake, the command "ip6tables -t mangle -L -v" on the router (or using "RunCmd" on the web interface) shows the entry added from the script, so I know that it's been added. From the ip6tables man page I see that "ip6tables -L -v" only shows the default table, the "filter" table.

Should know tomorrow morning if this works for me...can't wait *smile*.

Update: Yes, this did work last night. The router shows about 21,000 packets were dropped by this rule overnight. That's a lot of dropped packets, no wonder there's an overflow. Still, I never see these neighbor table overflows with the R7000, so I'm guessing that both the stock and dd-wrt firmware allocate a large enough neighbor table initially to handle this number, or just don't log these, or use a rule similar to this, or maybe even a kernel fix somehow. Anyways, nice to see that there's an alternative to using extra memory.