QoS + IPv6 Passthrough = "AC86U kernel: protocol 0800 is buggy..." spam

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

truglodite

Regular Contributor
When I enable IPv6 passthrough, IPv6 works but I get a bunch of this in my logs:

Code:
Jan  6 17:26:13 RT-AC86U kernel: protocol 0800 is buggy, dev eth0
Jan  6 17:26:13 RT-AC86U kernel: protocol 0800 is buggy, dev br0
Jan  6 17:26:17 RT-AC86U kernel: protocol 0000 is buggy, dev eth0
Jan  6 17:26:17 RT-AC86U kernel: protocol 0000 is buggy, dev eth0
I have read up on the issue, including:
https://www.snbforums.com/threads/protocol-0800-is-buggy-protocol-86dd-is-buggy.55762/#post-512906
https://www.snbforums.com/threads/384-9_alpha-builds-testing-all-variants.54050/page-9#post-457973

It appears the behavior may be related to one or more of the following when passthrough is used:
hardware acceleration (enabled)
additional vlans (yazfi)
jumbo frames (disabled)
bonded ports (? not sure)
incorrect mtu (1500)

Not sure how it all relates to the spammy logs, but it would be nice to have ipv6 finally working. Any suggestions on the best way to fix this?

Kev

[edit: changed the title, since I found below that qos triggers the bug.]
 
Last edited:

truglodite

Regular Contributor
Interesting, I though it did but I guess maybe it doesn't.

I'm running the latest release (384.14_2) of merlin and amtm scripts. All else is running well, except ipv6. Also, I haven't looked up my ONT to see if I can get in and change it to bridge mode. Forgot to mention I'm also running freshjr qos.

[edit: I disabled qos, with passthrough enabled, and the buggy logs went away.]
 
Last edited:

EmeraldDeer

Very Senior Member
In my experience, protocol is buggy has 100% been about network visibility add-ons. As soon as I removed the software, the errors went away.
 

truglodite

Regular Contributor
Yeah my understanding is this is a bug in asus firmware as in the other thread someone verified it happens on stock firmware when passthrough is combined with ANY trend micro software (qos, traffic monitor, parental controls, etc). So for now I have disabled qos. This is working fine for me since I'm only on a 50/50 connection; this may be a deal breaker though when I upgrade my service to the 100's (hopefully within a year).
 

truglodite

Regular Contributor
Just another observation I made on this issue... you don't even have to enable any trend micro stuff for this bug to kick in. If I have IPv6 passthrough enabled, merely clicking on the Adaptive QoS tab on the side of the webui (which opens up the traffic monitor page) will get the buggy protocol thing to start.
 

dsancho

Occasional Visitor
Just another observation I made on this issue... you don't even have to enable any trend micro stuff for this bug to kick in. If I have IPv6 passthrough enabled, merely clicking on the Adaptive QoS tab on the side of the webui (which opens up the traffic monitor page) will get the buggy protocol thing to start.
Hi same behaviour for me ! IPv6 configured in passthrough mode.
Just naviagte to the Adaptive QoS tab and the buggy log starts...
 

ttgapers

Senior Member
Did the same once I started using Suricata....which eventually led to Cake-QOS. Not sure how Cake plays with IPv6 as I can't test...Give it a whirl if you like.
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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