ASUS-RT-AX86U kernel protocol 0800 is buggy, dev eth7

[jasonlee]

Nope. If you are tired of seeing the error message in the log set both the log settings to critical. Poof! No more error and Guest 1 and 2 works just fine.

Thanks, I am running no guest for now

 

[shauno100]

Thanks, I am running no guest for now

Was this ever causing issues with your Guest WiFi though? I have Guest Wifi enabled on my RT-AX88U and see this error often but my Guest WiFi works fine. I fail to see why this is a problem if Guest WiFi performs as it should, if your Guest WiFi works fine just ignore the error in log as annoying as it may be, certainly doesn't warrant disabling your Guest WiFi just because of a log message that appears. If it's causing "actual" problems with your Guest WiFi then sure turn it off.

 

[arewhy]

I was also getting the protocol is buggy error and experiencing intermittent connectivity issues on Guest Wifi 1 synced to AiMesh. I put all my IOT devices on Guest network and for obvious reasons do not allow intranet access. When I placed my laptop on this network, I noticed that DNS queries to 192.168.101.1 were slow or timeout altogether. So I changed the DNS address issued by DHCP to google's DNS addresses creating dnsmasq.postconf in /jffs/scripts i've provided the commands below. Since I made the change the error has gone away as well as intermittent connectivity issues.
#!/bin/sh
# dnsmasq.postconf
CONFIG=$1
source /usr/sbin/helper.sh
pc_append "dhcp-option=br1,6,8.8.8.8,8.8.4.4" $CONFIG
pc_append "dhcp-option=br2,6,8.8.8.8,8.8.4.4" $CONFIG

 

[ender84]

How about getting this error when not having the guest network enabled at all?
I dont want to use the guest network in-fact.
Still, my log is full of this error.

 

[egrigolon]

I was also getting the protocol is buggy error and experiencing intermittent connectivity issues on Guest Wifi 1 synced to AiMesh. I put all my IOT devices on Guest network and for obvious reasons do not allow intranet access. When I placed my laptop on this network, I noticed that DNS queries to 192.168.101.1 were slow or timeout altogether. So I changed the DNS address issued by DHCP to google's DNS addresses creating dnsmasq.postconf in /jffs/scripts i've provided the commands below. Since I made the change the error has gone away as well as intermittent connectivity issues.
#!/bin/sh
# dnsmasq.postconf
CONFIG=$1
source /usr/sbin/helper.sh
pc_append "dhcp-option=br1,6,8.8.8.8,8.8.4.4" $CONFIG
pc_append "dhcp-option=br2,6,8.8.8.8,8.8.4.4" $CONFIG

Hi arewhy, thanks for providing the code for us, and I'm also running guest networks for my IOT devices. Since I'm kind of new to this, I would appreciate your help on setting this up. Is there an identifier to the guest network in the dhcp-option?

I have this on my dnsmasq.postconf file:

#!/bin/sh
. /opt/share/diversion/file/post-conf.div # Added by Diversion
/jffs/scripts/uiDivStats dnsmasq & # uiDivStats

Thanks a lot!

 

[develox]

As I just got an upgrade to an AX88U, and since using Suricata still generates tons of these messages, I figured out that one way to get them out of the log file was to filter them via syslog-ng. I already use syslog-ng (and scribe was well to make things simpler) to forward my logs to a log server in my intranet, so what I did was to add a configuration file (in the syslog-ng.d directory), with something like this:

filter f_protocol_buggy {
    program("kernel") and
    message("protocol.*is buggy");
};

log {
    source(src);
    filter(f_protocol_buggy);
    flags(final);
};

since I was still seeing many of the associated:

net_ratelimit: 198 callbacks suppressed

I did the same for that message too:

filter f_netrate_limit {
    program("kernel") and
    message("net_ratelimit:.*callbacks suppressed");

};

log {
    source(src);
    filter(f_netrate_limit);
    flags(final);
};

Now I have neither of them flooding my log.

P.S. The rules might be combined into one, but for the sake of simplicity I dedicated a mini config file to each of them.

 

[Scotee]

This has been puzzled me for a long time.
I find out that it is possibly generated by a problem of wrong time zone*(ntp setting).
Everytime \protocol 0800 is buggy\ comes with it, so please check out your ntp server or, check out if there is device with a wrong time zone as AX86U does.
The tentative solution is to apply your system seting again without change anything,but this can reload the time demo.