net_ratelimit issue on AC87 and 384.9

[GeneM]

So we are back to trying to see what the repeated error messages actually are, not just how many of them there are in bunches.

Good question. Took a bit, but I see I instanced it (at least) in Home Assistant's UPnP add-in.

So we are back to trying to see what the repeated error messages actually are,

I think I would, yes. Second Wemo plug in, the log started. Hoping the other 5 don't do the same...

 

[ColinTaylor]

So we are back to trying to see what the repeated error messages actually are, not just how many of them there are in bunches.

Sorry, had to edit my previous edit. It's nothing to do with music, but it is related to the Wemo's in so much as they are opening ports in the firewall. Without being able to see the actual error messages it's impossible to know what the problem is.

 

[EmeraldDeer]

So @GeneM does Colin's technique work?

/bin/echo 0 > /proc/sys/net/core/message_cost

 

[GeneM]

ok, two of my 6 units restart the logging.
Plugged one in next to me here - messages restarted

Feb 23 15:35:32 kernel: net_ratelimit: 18 callbacks suppressed
Feb 23 15:36:32 kernel: net_ratelimit: 21 callbacks suppressed
Feb 23 15:37:32 kernel: net_ratelimit: 41 callbacks suppressed
Feb 23 15:38:32 kernel: net_ratelimit: 12 callbacks suppressed
Feb 23 15:39:32 kernel: net_ratelimit: 9 callbacks suppressed​

put a <zero> in message_cost...

Nothing. No entries any longer!
A zero: means let 'em in, right?

 

[EmeraldDeer]

Yes, if it worked we would be seeing the actual errors instead of the callbacks suppressed. Not sure how to restart the syslogd on Asus.

 

[GeneM]

Not getting it:

Set cost to 0: no log entries

Set cost to 15: they're back:
Feb 23 15:39:32 kernel: net_ratelimit: 9 callbacks suppressed
Feb 23 15:44:32 kernel: net_ratelimit: 30 callbacks suppressed
Feb 23 15:45:32 kernel: net_ratelimit: 25 callbacks suppressed

Set cost to 15, burst to 70: no log entries

Given it might not need to suppress anything, is viewing the syslog from the router's ui the right place to be watching?

 

[EmeraldDeer]

The GUI should be identical to /tmp/syslog.log

 

[GeneM]

It is, tnx.
Now what! I'll need to reboot the router to see whether these cost/bust settings revert, but this isn't great for three days of investigation.

That said, you guys have been great. I wouldn't be here w/o you. I'd be re-entering in my router config until the wee-hours, with no change!

 

[EmeraldDeer]

Blind without the actual error message.
The only thing I have seen which is broken for sure is your QOS. Perhaps temporarily disable it.
By the way, DoS protection was not it, so turn it back on.

 

[GeneM]

Blind without the actual error message.
The only thing I have seen which is broken for sure is your QOS. Perhaps temporarily disable it.
By the way, DoS protection was not it, so turn it back on.

Ok, disabled QoS. I saw that earlier and am now wondering if that's on me somehow. I would like to ensure the Adaptive QoS handles our Voip.

Well, I'll play with these Wemos to see if a full reset etc helps, but if not, I need to figure out how to set those two files to zero on every boot....

 

[EmeraldDeer]

For now, you could make the logging setting survive a reboot by creating /jffs/scripts/services-start with:

#!/bin/sh
/bin/echo 0 > /proc/sys/net/core/message_cost

When the next stable firmware release comes out, then start from factory default settings.

 

[ColinTaylor]

Not getting it:

Set cost to 0: no log entries

Maybe you need to set a more aggressive syslog level to see them.

 

[EmeraldDeer]

I do not use QOS myself because I am never using 100% of my bandwidth. If I were, maybe the FreshJR approach guides you through it. My VOIP device is the only Ethernet device directly connected to my router. Everything else is trunked through a switch. Does this latency advantage act as a crude VOIP QOS? Probably not, but I have not noticed dropouts or callers saying that I have robot voice.

I just set my syslog level to All. The restart messages suggest "service restart_logger" may be how it is restarted.

 

[GeneM]

For now, you could make the logging setting survive a reboot by creating /jffs/scripts/services-start ...

Yep: Just finished adding it. Thanks.

When the next stable firmware release comes out, then start from factory default settings.

Without that nvram tool, this will be approaching prohibitive.
I can start with the built-in saves, test after the factory, and if the log messages are gone, try to just restore those saves. If they restart ....

Gentlemen: Thank you for your time today. Greatly appreciated.

 

[EmeraldDeer]

I do not have any devices using UPnP IGD, but perhaps you could try out the advice in this article regarding IGMP settings.
https://zapek.com/blog/how-to-fix-upnp-igd-not-working-on-asus-rt-ac87u/
Turns out the author had posted to snbforums
https://www.snbforums.com/threads/asus-rt-ac87u-upnp-igd-not-working-because-of-igmp-problems.44721/
Although this would suggest a fix only if the Wemo devices were on 5 GHz.

 

[L&LD]

Without that nvram tool, this will be approaching prohibitive.
I can start with the built-in saves, test after the factory, and if the log messages are gone, try to just restore those saves.

​

GeneM,

A full reset to factory defaults may be daunting with the number of customizations you seem to have, but can I ask over what period of time these customizations have been implemented? And how many firmware flashes?

You may find that jumping to a new firmware requires a possible relearning of things we thought we already knew because of the features available changing too.

Some of those changes may even make it simpler to implement the features we need, even over anything custom we may have hand built in the past.

The built-in backup configuration 'saves' are great if you're flashing to the same version firmware (if you were experimenting with a new feature, for example), but more than likely not so great when you've already updated to a new firmware or when you want to update to a new firmware (and use the now obsolete 'saves').

At the very least, take a screenshot of all your setup screens (tip; use a 4K monitor or TV at 100% scale so you can take one shot of each screen) and using the images for reference, manually create text versions of your settings. This only needs to be done once, afterward, you can mostly copy/paste to a new router setup, etc. Updating your settings is easier too after this step.

See the links in my signature of why you would want to get your router, network and connected client devices to a good/known state.

Yes, a lot of work on a mature/complicated setup such as yours. Very worthwhile, IMO.

If the bugs you're seeing are self-inflicted (because of the details of your network setup and possible lack of resetting the router in the past), no one will be able to help you solve them in a consistent manner. And these bugs and glitches will only get worse over time until your network no longer functions as you need it to.

In the very near future, at least make a manual (text-based) backup of your settings. It seems like your current setup may not be the most stable anymore.

 

[GeneM]

Thank you for taking the time to pull together this post.

It seems like your current setup may not be the most stable anymore.

I agree. Though the nvram tool sounds like something I can't use to restore, browsing the backup files it created certainly provides a lot of this into in a text format, so that will also help along with the screenshots.

Not looking forward to reentering the 50 DHCP reservations with custom icons, but that's the price you pay, I guess.

Looking forward to reviewing your sig's pointers.

Much appreciated, thank you.
G

 

[EmeraldDeer]

I do not have any devices using UPnP IGD, but perhaps you could try out the advice in this article regarding IGMP settings.
https://zapek.com/blog/how-to-fix-upnp-igd-not-working-on-asus-rt-ac87u/
Turns out the author had posted to snbforums
https://www.snbforums.com/threads/asus-rt-ac87u-upnp-igd-not-working-because-of-igmp-problems.44721/
Although this would suggest a fix only if the Wemo devices were on 5 GHz.

If you are using UPnP IGD, then perhaps IGMP Proxy and IGMP Snooping are a good idea regardless.
IGMP Snooping might be on Wireless Professional settings for each band.

 

[EmeraldDeer]

Thank you for taking the time to pull together this post.



I agree. Though the nvram tool sounds like something I can't use to restore, browsing the backup files it created certainly provides a lot of this into in a text format, so that will also help along with the screenshots.

Not looking forward to reentering the 50 DHCP reservations with custom icons, but that's the price you pay, I guess.

Looking forward to reviewing your sig's pointers.

Much appreciated, thank you.
G

While wholesale nvram restore from backup across firmware levels is a bad idea, restoring the DHCP reservations is not. From a backup directory (Samba shared even better):

# nvram get dhcp_staticlist > dhcp_staticlist
# nvram get custom_clientlist > custom_clientlist

Restore:

# nvram set dhcp_staticlist="`cat dhcp_staticlist`"
# nvram set custom_clientlist="`cat custom_clientlist`"

I set and will restore my DHCP reservations for YazFi via /jffs/scripts/dnsmasq.postconf

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_delete "no-negcache" $CONFIG
pc_append "neg-ttl=3600" $CONFIG
pc_append "dhcp-script=/jffs/scripts/log-dhcp.sh" $CONFIG
pc_delete "dhcp-option=dnsf5" $CONFIG
pc_delete "dhcp-option=dnsf6" $CONFIG
pc_append "dhcp-host=00:24:e4:5f:00:00,192.168.66.110,Therm" $CONFIG
pc_append "dhcp-host=00:24:e4:5c:00:00,192.168.66.111,Scale" $CONFIG
#