What's new

Connected, with Critters

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

JT Strickland

Very Senior Member
I finally got my equipment connected to the fiber line, by getting a static IP. But now I've got Bugs.
I searched and didn't find anything really satisfactory. I have guest network 1 disabled and I have follow suggestions from the past posts.
About every 10 lines it repeats in the syslog. The protocol will vary from 0800 to 0000.
From the system log:

Jan 11 21:01:41 RT-AX86U-CB28 kernel: net_ratelimit: 59 callbacks suppressed
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0000 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0000 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0000 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0000 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0000 is buggy, dev eth0
Jan 11 21:01:41 RT-AX86U-CB28 kernel: protocol 0000 is buggy, dev eth0

Then it repeats. There are many entries.
Any ideas?
Thanks in advance!
 
Do you have IPv6 enabled? I was getting this with IPv6 enabled + NAT acceleration on AC86U. Disabling NAT acceleration stopped the error log. It's present in stock Asuswrt as well, but it's hidden. It was flooding the Remote Log Server non stop. I don't know what exactly is buggy.
 
Do you have IPv6 enabled? I was getting this with IPv6 enabled + NAT acceleration on AC86U. Disabling NAT acceleration stopped the error log. It's present in stock Asuswrt as well, but it's hidden. It was flooding the Remote Log Server non stop. I don't know what exactly is buggy.
No, I had enabled it briefly trying to connect to the ISP but turned it back off. The iPv6 firewall is enabled.
I will look into the NAT acceleration.
It may have something to do with YazFi also, so I may have to ask Jack,. I found many of the entries after boot contained the same sequence with this added:

Jan 11 21:57:15 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:18 RT-AX86U-CB28 rc_service: httpd 1350:notify_rc start_YazFiconnectedclients
Jan 11 21:57:18 RT-AX86U-CB28 custom_script: Running /jffs/scripts/service-event (args: start YazFiconnectedclients)
Jan 11 21:57:19 RT-AX86U-CB28 kernel: net_ratelimit: 9 callbacks suppressed
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0800 is buggy, dev eth0
Jan 11 21:57:19 RT-AX86U-CB28 kernel: protocol 0000 is buggy, dev eth0
Jan 11 21:57:23 RT-AX86U-CB28 rc_service: httpd 1350:notify_rc start_YazFiconnectedclients
 
According to this post I found at

https://zszsit.blogspot.com/2012/10/ratelimit-callbacks-suppressed.html

it is partially related to IPv6 not being on. The author says that his solution was
- re-enable ipv6 by commenting "options ipv6 disable=1" line in /etc/modprobe.d/hardening.conf
- prevent use of ipv6 calls by appending following line to /etc/sysctl.conf:
net.ipv6.conf.all.disable_ipv6 = 1
(Thanks to Daniel Walsh)

These resulted that:
- ipv6 module is already inserted, so programs do not want to insert it
- ipv6 remained pseudo-disabled

But he was using different hardware.
Would this work with an Asus router, and more particularly one running AsusWrtMerlin firmware?
 
According to this post I found at

https://zszsit.blogspot.com/2012/10/ratelimit-callbacks-suppressed.html

it is partially related to IPv6 not being on.
I think you are misinterpreting what the ratlelimit message means. It simply means that the log is being flooded with a repeating kernel message and the number of those messages has exceeded the ratelimit. The actual kernel message could be anything. So you have to look at the repeating message shown in the log prior to them being suppressed.

In that other post the author doesn't actually say what his error message was, only that it was caused by him disabling an IPv6 module. Also, his message was a standard kernel message. In your case the message ("protocol 0800 is buggy, dev eth0") is specifically a network message generated from here.

That's not to say that the message isn't related to IPv6, @Tech9 thinks it is. It's just that you can't draw too much of a comparison with that other post as it's a completely different situation.
 
I think you are misinterpreting what the ratlelimit message means. It simply means that the log is being flooded with a repeating kernel message and the number of those messages has exceeded the ratelimit. The actual kernel message could be anything. So you have to look at the repeating message shown in the log prior to them being suppressed.

In that other post the author doesn't actually say what his error message was, only that it was caused by him disabling an IPv6 module. Also, his message was a standard kernel message. In your case the message ("protocol 0800 is buggy, dev eth0") is specifically a network message generated from here.

That's not to say that the message isn't related to IPv6, @Tech9 thinks it is. It's just that you can't draw too much of a comparison with that other post as it's a completely different situation.

OK, thanks, I wasn't sure how much of it applied to an asus router, and I sure wasn't going to run those commands without a second opinion first.
 
What is this message about?
No idea. It's too low level for my understanding. But an EtherType of 0x0800 indicates a protocol of IPv4. If I had to guess, looking at the code, I'd say that the payload size in the Ethernet frame is too small or too large. I suspect that's a side effect of Broadcom's hardware acceleration.
 
I suspect that's a side effect of Broadcom's hardware acceleration.

The messages are coming non stop in Asuswrt when IPv6 and NAT acceleration are both enabled. One of the two disabled stops the error log. AC86U router. I may try with AC68U, NAT acceleration there is a different flavor.
 
The messages are coming non stop in Asuswrt when IPv6 and NAT acceleration are both enabled. One of the two disabled stops the error log.
The exact same message has been reported over the years on other devices/OSes, including OpenWRT, Linksys and Cisco RV's. I suspect it's Broadcom specific. I've never seen that message, but then I don't use IPv6.
 
Any noticed adverse effects as a result, except log flooding?
 
it also comes up when you use Asus' guest syncing to nodes feature on some platforms, where they implement VLANs
I believe mine started when I enabled guest network 2. I disabled it for a couple of hours yesterday but they kept coming, at the rate of over 100 per minute. It's the only guest network that I have enabled.

I haven't been able to find the syncing to nodes feature but don't think I have it enabled. I do have syncthing running on a few clients, but not the router, if that is related. I get some messages in the log "...HTTP Connection from 192.168.2.198 closed unexpectedly" due to syncthing, usually two in a row.
 
Maybe you guys can capture a sample of the "buggy" traffic for analysis using tcpdump. It might be fun to try and see what's going on, although at the end of the day I doubt there's anything we could do to fix it.
 
IPv6 disabled. NAT acceleration is needed.
 
Maybe you guys can capture a sample of the "buggy" traffic for analysis using tcpdump. It might be fun to try and see what's going on, although at the end of the day I doubt there's anything we could do to fix it.
OK, I've installed tcpdump. Where does it log to? I can't find a file on my router with "tcpdump*.*" in it.
I ran
Code:
# tcpdump -c 15
but no return
 
Last edited:
OK, I've installed tcpdump. Where does it log to? I can't find a file on my router with "tcpdump*.*" in it.
I ran
Code:
# tcpdump -c 15
but no return
By default it sends it's output to the screen. So your command should show something.
 
By default it sends it's output to the screen. So your command should show something.
That's what I thought. I don't have IPv6 turned on either, is it required? I suppose I could turn it on long enough to get a dump.
 
It doesn't matter what protocols you've enabled as it dumps everything. If you're not seeing any output at all something is wrong. Even if there's no data it should say that it's running and listening.
 
It doesn't matter what protocols you've enabled as it dumps everything. If you're not seeing any output at all something is wrong. Even if there's no data it should say that it's running and listening.
OK, I had included the prompt (#) in my code. That's why it didn't run.
I've got 100 packets now, what should I look for or post? I don't really want to air all of my dirty laundry on a public forum.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top