Beta Asuswrt-Merlin 386.4 beta is now available

[FLA_NL]

Do you use the first guest network? That was where the "protocol is buggy" errors in previous versions came from.

 

[donat76]

Do you use the first guest network? That was where the "protocol is buggy" errors in previous versions came from.

Edit: Disabling the first guest network on the 2.4GHz radio OR enabling INTRAnet access for it also mitigates the "protocol is buggy" error messages when a device is actively using the network on ANY of the regular or guest networks. All of the other five guest networks on the 2.4GHz and 5GHz radios do not cause these error messages.

Testing further...

It may have only been coming from that interface because that was what the error triggering (older?) device was attached to at the time. The device also has to be actively using the connection otherwise you may think you fixed it and really, it wasn't showing errors because that device wasn't being used at that particular moment the module is loaded. It was very tricky and hard to track down.

If I switched between interfaces, it just changed the interface the error was showing up on. And I could change what protocol was 'buggy" by using IPv6 (86dd) or IPv4 (0800).

IEEE 802 Numbers

I can reproduce it with 100 percent confidence two different ways. I spent hours fiddling with settings and tracking down what was causing it.

I got it narrowed down to having the Trend Micro module loaded with Flow Cache and Runner hardware acceleration activated.

Turning off hardware acceleration solved the issue or at least avoided or masked it.

On further testing, having "Flow Cache" hardware acceleration disabled mitigates this issue. Disabling "Runner" hardware acceleration makes no difference.

SSH into (Asus RT-AX88U) router.

Turn off hardware acceleration.

nvram set fc_disable_force=1
nvram set runner_disable_force=1
nvram commit
service reboot

To revert changes.

nvram unset fc_disable_force
nvram unset runner_disable_force
nvram commit
service reboot

TL;DR

1.) It appears to be device OR interface specific. My computer is attached to the first LAN ethernet port and it does not trigger any error messages. My Samsung Note8 on eth6 (2.4GHz) or eth7 (5GHz) trigger the error messages.

2.) The device has to be actively using the internet (or INTRAnet?) for error messages to show up.

3.) The Trend Micro module has to be loaded. It loads temporarily when one of the GUI QoS pages are accessed and then unloads when leaving that page OR loads on router boot up and stays loaded if Adaptive QoS is enabled.

3.) Hardware acceleration (Flow Cache and Runner) has to be enabled.

4.) Might only be "fixable" by Asus or Trend Micro if it is in fact the module causing the issue rather then the source code that interfaces with it.

Issue occurs in 386.3_2 (6-Aug-2021).
Issue likely occurs in beta 386.4 (xx-xxx-2021) but can't test at the moment.

5.) Disabling the first guest network on the 2.4GHz radio OR enabling INTRAnet access for it also mitigates the "protocol is buggy" error messages when a device is actively using the network on ANY of the regular or guest WiFi networks. All the other five guest networks on the 2.4GHz and 5GHz radios do not cause these error messages.

6.) Disabling "Flow Cache" hardware acceleration also mitigates this issue. Disabling "Runner" hardware acceleration makes no difference.

syslog.txt

Dec 12 17:29:19 kernel: Init chrdev /dev/idp with major 190
Dec 12 17:29:19 kernel: tdts: tcp_conn_max = 8000
Dec 12 17:29:19 kernel: tdts: tcp_conn_timeout = 300 sec
Dec 12 17:29:21 kernel: SHN Release Version: 2.0.1 8279cad
Dec 12 17:29:21 kernel: UDB Core Version: 0.2.20
Dec 12 17:29:21 kernel: Init chrdev /dev/idpfw with major 191
Dec 12 17:29:21 kernel: IDPfw: flush fc
Dec 12 17:29:21 kernel: IDPfw: IDPfw is ready
Dec 12 17:29:21 kernel: sizeof forward pkt param = 280
Dec 12 17:29:21 BWDPI: fun bitmap = 3
Dec 12 17:29:32 kernel: protocol 86dd is buggy, dev eth7
Dec 12 17:29:32 kernel: protocol 86dd is buggy, dev eth7
Dec 12 17:29:32 kernel: protocol 86dd is buggy, dev eth7
Dec 12 17:29:32 kernel: protocol 86dd is buggy, dev eth7
Dec 12 17:29:32 kernel: protocol 86dd is buggy, dev eth7
Dec 12 17:29:32 BWDPI: force to flush flowcache entries
Dec 12 17:29:32 kernel: IDPfw: Exit IDPfw
Dec 12 17:29:32 kernel: mod epilog takes 0 jiffies
Dec 12 17:29:32 kernel: IDPfw: Exit IDPfw
Dec 12 17:29:32 kernel: Exit chrdev /dev/idpfw with major 191
Dec 12 17:29:32 kernel: Exit chrdev /dev/idp with major 190
Dec 12 17:29:32 BWDPI: rollback fc
Dec 12 17:29:33 custom_script: Running /jffs/scripts/nat-start

 

[tasmansaroha]

It's possible these two files that were different from 45987 were incorrect in my archive (or the AC3100/AC5300 archives contained incorrect versions).

EDIT: nope, all three models had the same version, which is different from the one I extracted from 45987

merlin@ubuntu-dev:~$ md5sum asuswrt.386-45958-ac88/release/src/router/bwdpi_source/prebuild/tdts_udbfw.ko
d2f1650dac3c246298adb54331f06399  asuswrt.386-45958-ac88/release/src/router/bwdpi_source/prebuild/tdts_udbfw.ko
merlin@ubuntu-dev:~$ md5sum asuswrt.386-45958-ac3100/release/src/router/bwdpi_source/prebuild/tdts_udbfw.ko
d2f1650dac3c246298adb54331f06399  asuswrt.386-45958-ac3100/release/src/router/bwdpi_source/prebuild/tdts_udbfw.ko
merlin@ubuntu-dev:~$ md5sum asuswrt.386-45958-ac5300/release/src/router/bwdpi_source/prebuild/tdts_udbfw.ko
d2f1650dac3c246298adb54331f06399  asuswrt.386-45958-ac5300/release/src/router/bwdpi_source/prebuild/tdts_udbfw.ko
merlin@ubuntu-dev:~$ md5sum amng/release/src/router/bwdpi_source/prebuild/RT-AC88U/tdts_udbfw.ko
7a10949aedb1d04ffc6fd9b46f7f615c  amng/release/src/router/bwdpi_source/prebuild/RT-AC88U/tdts_udbfw.ko

There is a slight difference in the file /release/src/router/bwdpi_source/asus_sql/prebuild/arm_7114/libbwdpi_sql.so

 

[spykos]

The wireless code is unchanged from upstream. I have never seen these messages before however, so I don't know if it's specific to your model, or specific to your configuration.

The model is RT-AX86U. There is no specific configuration. This is with default wireless settings. Only changes were the SSID and password. These messages appear every time a client is disconnects/reconnects. The strange thing is also the RADIUS line as I am not using it. Tried restore to factory default with "Initialize all the settings, and clear all the data log for AiProtection, Traffic Analyzer, and Web History." but messages are still there.

Could it be that you have enabled extra debug logging for hostapd ?

 

[ColinTaylor]

@RMerlin

Are the below messages because I am running the current beta or they exist in normal builds too ?

Dec 17 11:04:47 hostapd: eth7: STA (MAC address deleted) IEEE 802.11: disassociated
Dec 17 11:04:47 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind (MAC address deleted), status: 0, reason: Unspecified reason (1)
Dec 17 11:04:47 wlceventd: wlceventd_proc_event(534): eth7: Assoc (MAC address deleted), status: Successful (0)
Dec 17 11:04:47 hostapd: eth7: STA (MAC address deleted) IEEE 802.11: associated
Dec 17 11:04:47 hostapd: eth7: STA (MAC address deleted) RADIUS: starting accounting session E5CD0694AE224076
Dec 17 11:04:47 hostapd: eth7: STA (MAC address deleted) WPA: pairwise key handshake completed (RSN)
Dec 17 11:05:00 rc_service: service 3046:notify_rc restart_letsencrypt

Is there a way to filter the above ?

Those are perfectly normal messages for the RT-AX86U. They're in stock firmware to. The wlceventd messages are at notice level and the hostapd are at info level. You could try suppressing them by changing "Log only messages more urgent than" under System Log - General Log but then you'd be suppressing other messages as well.

 

[agbommarito]

The problem identified in this post also seems to exist in this beta:

https://www.snbforums.com/threads/syslog-client-needs-a-push.75644/

Remote logging doesn't work even after a reboot. The "Apply" button on the System Log -> General Log page needs to be pressed after which remote logging starts immediately.

If the router reboots, remote logging stops again until the "Apply" button is pressed.

I'm logging to a Synology NAS using a port other than the standard 514.

 

[Elmer]

> RT-AX88U_386.4_beta1_cferom_ubi.w
Issues:
Major: No ipv6 - understand this is out of your control
Minor: Internet Disconnected Screen is displayed and yes, dns_probe_host=dns.msftncsi.com

Oh, and here's and interesting one (multiple entries):

dnsmasq[1377]: possible DNS-rebind attack detected: time.nist.gov

Sigh

 

[PR3MIUM]

dirty upgrade from 386.4_alpha2 -> 386.4_beta1, works fine so far

 

[saleanddeki]

RT-AX56U, dirty upgrade from 386.3_2, everything is ok, aiprotection, parental, dlna, smb, etc.

 

[shabbs]

Dropped the Beta's on all my APs today... filthy upgrades from 386.3_2. No issues encountered during the upgrade. Devices all re-connected. Will keep an eye on the Nest Cameras... they don't like change.

EDIT: Nest cameras were not happy for some reason. Kept disconnecting and could not get a stable connection. Have rolled the APs back to Release branch. Will try again when Beta 2 drops. Did not have the patience or time right now to start fiddling with settings to find a new stable config. Ugh.

 

[jsbeddow]

Hi jsbeddow,

Would you mind sharing how you've setup your OpenVPN Server? I've cleared the JFFS partition and done a full factory reset of the router. Apart from setting up an internet connect (PPPoE) and the OpenVPN Server I've made no other configuration changes or installed any add-ons. Still no dice with being able to route to LAN clients using OpenVPN Connect on my android phone. Internet access is fine via VPN.
My current settings below (Advertise DNS and IP range 10.13.13.0 are my only changes).

View attachment 37864

Looks almost identical to mine, but maybe you also made some changes to the Data Ciphers? And on the General tab, you have the "Client will use VPN to access" radio button set to "Both", right?
Beyond that, I don't know what else it could be, given that you have done a full reset and jffs format. You didn't re-import any settings, right? It's a pain, but it really makes a difference to fully re-configure manually page by page.

 

[ColinTaylor]

Rebooting the router erases (or overwrites) the current System Log file (/jffs/syslog).

Once rebooted the System Log - General Log does not prepend the previous log file (/jffs/syslog-1) to the output shown in the GUI. Manually restarting the logger (service restart_logger) causes the previous log file to appear in the GUI.

 

[Yota]

Report a "problem?". I am using RT-AC86U, when the Accept DNS Configuration is set to Exclusive in the OpenVPN client, any custom configuration of dnsmasq will not be used to connect to the VPN device, such as a custom domain name, or just DNS logs.

Maybe this is by design, because I think DNS traffic is routed directly Instead of routing through dnsmasq?

Thank you very much again.

 

[ColinTaylor]

Maybe this is by design, because I think DNS traffic is routed directly Instead of routing through dnsmasq?

Yes this is the intended behaviour of Exclusive.

 

[Yota]

Yes this is the intended behaviour of Exclusive.

I see. thanks for the quick reply.

 

[Yota]

OpenVPN server now supports IPv6, both for incoming connections, and for routing access to the LAN clients over IPv6.

I am very happy to see that Asuswrt-Merlin finally supports IPv6 on ovpn. I think your ISP now officially supports IPv6? @RMerlin

edit:
Sorry i didn't see this

I was only able to do limited testing using an HE tunnel.

I am very grateful for the addition of this feature, I can expect this will be the best new feature of 386_4.

 

[ColinTaylor]

I see. thanks for the quick reply.

This exception may still apply (I haven't tried it myself).

Policy based routing

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[GWater]

Looks almost identical to mine, but maybe you also made some changes to the Data Ciphers? And on the General tab, you have the "Client will use VPN to access" radio button set to "Both", right?
Beyond that, I don't know what else it could be, given that you have done a full reset and jffs format. You didn't re-import any settings, right? It's a pain, but it really makes a difference to fully re-configure manually page by page.

Thanks for the response, yes I have "Client will use VPN to access" radio button set to "Both". No changes to ciphers and all config is manual page by page. I export the ovpn file directly from the server page and import into the Android client. Okay, now that I know this config "should work" I'll keep playing....very strange. As I said, this use to work without issue for me so not sure why it doesn't anymore

 

[Yota]

This exception may still apply (I haven't tried it myself).

Policy based routing

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

This wiki is very helpful, thank you very much.

By the way, do you know anything about IPv6? Can you help me? https://www.snbforums.com/threads/how-to-prevent-lan-devices-from-obtaining-ipv6-addresses.76285/

 

[umd325]

Going from 386.3 to 386.4 beta on two AC68Us, the 'disable LEDs' setting seems to only be working with power, wifi, and usb LEDS. The lan and wan LEDs remain on.