Beta Asuswrt-Merlin 386.4 beta is now available

[PR3MIUM]

native ipv6:

and passtrough ipv6:

tested with a hard reset and google dns after the reset in the above post, dont see any errors.

 

[Mason]

A few days ago, I ran into the bug where AiMesh nodes would not pair with the main router when all are running Merlin firmware. Flashing the AiMesh node with the latest official firmware fixed it. This was with 386.3_2 though, so I'm not sure if this was fixed in 386.4 beta.

How are you adding the node? I noticed the initial setup wizard does not work at all. However, if I reset the router I want to add, then click "Add AiMesh Node" under AiMesh from the main router, it works.

 

[Mutzli]

Anybody running a AX series router getting the DCD Tainted logs? If you are, are you also running Diversion? Thanks I'm running the AX88U

This is caused by Trendmicro and not Diversion. When you withdraw from the Trendmicro agreement the errors are gone.

Beta - Asuswrt-Merlin 386.4 beta is now available

There seems to be a bug on network map. Internet GUI shows disconnected. But internet is up and running for the client devices. Try to turn "Internet connection" button ON/OFF

www.snbforums.com

 

[STRUZZIN]

After Flashing Latest ASUS firmware and factory reset Flash Merlin 386.4 BETA 2 Factory Reset Setup Everything From Scratch:
Before and After
Thanks @PR3MIUM

 

[Elmer]

Interesting. Wonder if this still presents an issue with a feed back loop with requests when Conditional Forwarding is enabled within Pi-Hole.

Link to Asus:

[Wireless Router] How to configure Router to use Pi-Hole?

Before starting the setup, please check the firmware version of your router.

If your router firmware version >= 3.0.0.4.386.45898

Please assign the pi-hole IP in the WAN DNS setting.

Step1: Connect your PC to ASUS router via Wi-Fi or Ethernet cable.

Step2: Open a web browser and navigate to Web GUI (http://router.asus.com).

Enter your login username and password on the login page and then click [Sign In].

View attachment 37854

Note: Please refer to [Wireless Router] How to enter the router's GUI to learn more.

Step3: Go to [WAN] > [Internet Connection] tab.

Step4: Set Connect to DNS Server automatically as [No]

Step5: Enter device IP address on DNS server and click [Apply] to save.

View attachment 37853

These instructions are wrong, at least for the majority of us. There is no way you are going to reboot with a WAN local pihole address unless your isp is providing multiple static addresses and your pihole is routed to an upstream network switch to allow that WAN connection. You must use an internet WAN DNS (like 8.8.8.8). On the LAN DNS page you place your pihole IPs (make sure they are static of course), and then DO NOT check the "Advertise router's IP in addition to user-specified DNS" because this causes circularity. Now on the DNS Filter tab use ROUTER (forces the LAN DNS) and add your piholes to the client list with 'no filtering'.

 

[RMerlin]

There's no issues at all with any of these, although I am still using Asuswrt-Merlin 386.3_2 firmware,

The issues are related to the new DDNS code that Asus added in the GPL merged in this beta. Which is the focus in this beta thread.

 

[RMerlin]

This is caused by Trendmicro and not Diversion.

dcd crashes when it tries to process the virtual network interface added by pixelserv-tls. It does not appear when you disable the Trend Micro engine because dcd is a component of it - disabling it means that daemon doesn't get run at all.

 

[doodlenoodle]

AX86U here
Updated from 386.3_2 to 386.4 beta 2
From a casuals point of view, everything is running smooth and stable now.

I did experience an issue on my android tv box (nvidia shield) which I hadn't encountered before and that was that the wired network on my streaming box kept disconnecting, it was like a gradual decline as my streaming apps would ultimately stop streaming. After a few reboot attempts of android tv box or router, the wired connection would be restored again but only temporarily, ultimately I switched the wired connection from port 1 (gaming port) to port 3 and for some reason that worked and connection continues to remain stable.

I don't have anything fancy and didn't introduce anything new:
- 2 VPN clients running
- IPv6 (clients that support IPV6 are getting an IPV6 address including android tv box)
- YazFi with guest network
- QOS Type - Cake
- Some basic IPTable rules to forward through VPN tunnel
- External USB with swap file
- Ram hovers around 45% consistently
- Game consoles all working well PS/ Xbox / Switch
- All my IOT devices connected and working well
- 40+ clients

With the exception of that 1 anomaly, I feel things are responsive and running extra buttery smooth. Still kicking the tires, but so far so good.

 

[Ubimo]

Since beta2 on my AC86U, I'm getting this in syslog:

Dec 26 23:57:45 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc013c5e968 next ffffffc013f8c420 prev ffffffc013f8c420 rep_entry->list ffffffc013f8c420 next ffffffc013c5e968 prev ffffffc013c5e968

Is this a problem?
I have a second AC86U as an AIMesh node.

 

[learning_curve]

The issues are related to the new DDNS code that Asus added in the GPL merged in this beta. Which is the focus in this beta thread.

This was a reply to my longer post: http://www.snbforums.com/threads/asuswrt-merlin-386-4-beta-is-now-available.76258/post-731534 which was confirmation (for reference) of everything working as expected, including IPv6 / DDNS IPv6 on the 'previous' firmware release, unlike some of the other posters that were having issues with one or both of these items on either of the Beta firmware releases after upgrading.

So, spurred on by this, plus other poster's seemingly never ending problems with IPv6 / DDNS IPv6 after upgrading to the Beta 1 and/or Beta 2 release, I dirty flashed my own router onto 386_4 Beta 2 and.......

It runs perfectly Super smooth / No IPv6 or DDNS IPv6 or any other issues at all - so far anyway, for me. Everything works, just as expected. I'll re-check in 24 hours or so just in case but, thanks again @RMerlin

 

[pat2]

Hi RT-AC86U here.
Installed 386.4_beta2.

It seems all working fine. Interesting that RAM usage remain about 297/512 MB (for old firmware normaly usage increased along the time passing).
Only issue in log messages is repeated:

Dec 27 12:41:54 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc01425a1e8 next ffffffc012120b20 prev ffffffc012120b20 rep_entry->list ffffffc012120b20 next ffffffc01425a1e8 prev ffffffc01425a1e8
Dec 27 13:10:27 pptp[16717]: pppd 2.4.7 started by michele, uid 0
Dec 27 13:10:27 pptp[16717]: Connect: pptp0 <--> pptp (78.128.113.66)
Dec 27 13:10:28 pptp[16717]: appear to have received our own echo-reply!
Dec 27 13:10:28 pptp[16717]: No CHAP secret found for authenticating a
Dec 27 13:10:28 pptp[16717]: Peer a failed CHAP authentication
Dec 27 13:10:28 pptpd[16716]: CTRL: EOF or bad error reading ctrl packet length.
Dec 27 13:10:28 pptpd[16716]: CTRL: couldn't read packet header (exit)
Dec 27 13:10:28 pptpd[16716]: CTRL: CTRL read failed
Dec 27 13:10:34 pptp[16717]: Connection terminated.
Dec 27 13:10:34 pptp[16717]: Modem hangup

but the router is working fine.
thanks

 

[ColinTaylor]

Hi RT-AC86U here.
Installed 386.4_beta2

It seems all working fine. Interesting that RAM usage remain about 297/512 MB (for old firmware normaly usage increased along the time passing).
Only issue in log messages is repeated:

Dec 27 12:41:54 kernel: bcm_mcast_mld_add:833 mc_fdb->rep_list ffffffc01425a1e8 next ffffffc012120b20 prev ffffffc012120b20 rep_entry->list ffffffc012120b20 next ffffffc01425a1e8 prev ffffffc01425a1e8
Dec 27 13:10:27 pptp[16717]: pppd 2.4.7 started by michele, uid 0
Dec 27 13:10:27 pptp[16717]: Connect: pptp0 <--> pptp (78.128.113.66)
Dec 27 13:10:28 pptp[16717]: appear to have received our own echo-reply!
Dec 27 13:10:28 pptp[16717]: No CHAP secret found for authenticating a
Dec 27 13:10:28 pptp[16717]: Peer a failed CHAP authentication
Dec 27 13:10:28 pptpd[16716]: CTRL: EOF or bad error reading ctrl packet length.
Dec 27 13:10:28 pptpd[16716]: CTRL: couldn't read packet header (exit)
Dec 27 13:10:28 pptpd[16716]: CTRL: CTRL read failed
Dec 27 13:10:34 pptp[16717]: Connection terminated.
Dec 27 13:10:34 pptp[16717]: Modem hangup

but the touter is working fine.
thnaks

You have two unrelated messages. The pptp messages are normal port scanning attempts that you should expect because you have enabled the PPTP server.

 

[expor]

Flashed beta2 and working fine. IPv6 works fine for me generally but one issue I have is that I have to manually restart dnsmasq after reach reboot for it to apply the IPv6 DNS settings as configured in the GUI. Without doing so it will use the ISP DNS rather than the configured Cloudflare DNS. Would love to know how to workaround that. Note btw that I'm using a VLAN, which is needed by ISP.

Still have one issue where one device (my phone) can no longer connect to the 5ghz network. It simply fails to connect no matter the signal strength. Once in many attempts it might connect but I will get <1mbps speed and it drops pretty much nonstop (remains connected but internet connection gone). Note this also happens after going back to stock FW (and factory reset, as well as resetting my phone), so not sure what's happening there

 

[bbunge]

AX86U here
Updated from 386.3_2 to 386.4 beta 2
From a casuals point of view, everything is running smooth and stable now.

I did experience an issue on my android tv box (nvidia shield) which I hadn't encountered before and that was that the wired network on my streaming box kept disconnecting, it was like a gradual decline as my streaming apps would ultimately stop streaming. After a few reboot attempts of android tv box or router, the wired connection would be restored again but only temporarily, ultimately I switched the wired connection from port 1 (gaming port) to port 3 and for some reason that worked and connection continues to remain stable.

I don't have anything fancy and didn't introduce anything new:
- 2 VPN clients running
- IPv6 (clients that support IPV6 are getting an IPV6 address including android tv box)
- YazFi with guest network
- QOS Type - Cake
- Some basic IPTable rules to forward through VPN tunnel
- External USB with swap file
- Ram hovers around 45% consistently
- Game consoles all working well PS/ Xbox / Switch
- All my IOT devices connected and working well
- 40+ clients

With the exception of that 1 anomaly, I feel things are responsive and running extra buttery smooth. Still kicking the tires, but so far so good.

Interesting that you had the same experience with port 1 that I've been having. Could it be that we are being "gamed?"

My main desktop is connected to the router with Ethernet and it is usually connected to router LAN port 1. Beta 2 was running very well after my initial panic of no internet connection. Then near the end of last week I got sick. Fearing COVID and a hospital stay I flashed back to Asus 386.45934 so the family would have no issues should I not come home for a while. After a default reset on the Asus firmware I had the same no internet issue I had with Merlin while the PC was connected to LAN port 1. Switching to another port for a while then back to port 1 seemed to solve the issue.
I have my NAS connected to the 2.5 GB port and a 100 MB switch connected to port 2 for my PoE cams and both of these connections have not had problems with either Merlin or Asus firmware.
Turned out we just had colds and spent the holiday weekend at home with a box of tissues at our elbow. We are making plans to visit our remote family later this week. And I flashed back to beta 2, added a USB3 thumb drive and added Diversion Standard. Working very well!

I've wondered if the LAN port 1 problem is router hardware related. As my Dell desktop is second hand I have not ruled out PC hardware issues. I have not reported it to Asus, yet, but if two of us are having issues then maybe it is an Asus hardware issue.

 

[kernol]

1) Do you use Asus's DDNS? It's the only one that supports IPv6 at this time.
2) I'm confused as to why many of you get an error about ppp not having an IPv6 yet. Are you actually on native IPv6, or some other connection type? My test setup is IPv6 native, with a /64 prefix delegated to my router (out of my primary /48).
3) Getting an error about "interface has no valid IPv6" does not mean a permanent failure. It means the watchdog service will try again later, as your router might simply be taking too long to obtain a valid IPv6 from your ISP after boot. You have to check further down your log for future ddns retries. Also test your DDNS hostname by querying it (make sure to specify a AAAA type when you query it).

1) - Yes - Asus's DDNS
2) - Yes - Actually on Native IPv6
3) - I guess a wait of 8 hours from 1st DDNS fail [at 9:25am my time] to the last DDNS fail when my patience ran out today [17:25pm] means it is - in my case at least - "a permanent failure".

All I can say - and have said in prior posts in this thread - is that if I revert to stock 386-45934 - the RT-AX86U gets its IPv6 address without delay and DDNS works a treat.
I have a shortened extract from my beta2 log if it helps ...

Spoiler: Syslog Extract

Jan 1 00:00:02 kernel: ubi2: attaching mtd10
Jan 1 00:00:02 kernel: ubi2: scanning is finished
...
Jan 1 00:00:05 kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 1 00:00:05 kernel: IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready
...
May 5 05:05:07 kernel: eth0 (Int switch port: 3) (Logical Port: 3) (phyId: c) Link Up at 1000 mbps full duplex
May 5 05:05:07 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
...
May 5 05:05:07 kernel: IPv6: ADDRCONF(NETDEV_UP): eth4: link is not ready
May 5 05:05:07 kernel: device eth4 entered promiscuous mode
May 5 05:05:07 kernel: IPv6: ADDRCONF(NETDEV_UP): eth3: link is not ready
May 5 05:05:07 kernel: device eth3 entered promiscuous mode
May 5 05:05:07 kernel: IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
May 5 05:05:07 kernel: device eth2 entered promiscuous mode
May 5 05:05:07 kernel: IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
May 5 05:05:07 kernel: device eth1 entered promiscuous mode
...
May 5 05:05:08 kernel: IPv6: ADDRCONF(NETDEV_UP): dpsta: link is not ready
May 5 05:05:08 kernel: IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready
...
May 5 05:05:08 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready
...
May 5 05:05:08 kernel: IPv6: ADDRCONF(NETDEV_UP): eth4.501: link is not ready
...
May 5 05:05:08 kernel: IPv6: ADDRCONF(NETDEV_UP): eth3.501: link is not ready
...
May 5 05:05:08 kernel: IPv6: ADDRCONF(NETDEV_UP): eth2.501: link is not ready
...
May 5 05:05:08 kernel: IPv6: ADDRCONF(NETDEV_UP): eth1.501: link is not ready
...
Dec 27 09:25:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 09:26:11 RT-AX86U-D850 rc_service: httpds 1685:notify_rc restart_ddns_le
Dec 27 09:26:11 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart ddns_le)
Dec 27 09:26:11 RT-AX86U-D850 start_ddns: ppp0 has not yet obtained an ipv6 address
Dec 27 09:30:00 RT-AX86U-D850 rc_service: service 15689:notify_rc restart_letsencrypt
Dec 27 09:30:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 09:30:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 09:35:00 RT-AX86U-D850 rc_service: service 19016:notify_rc restart_letsencrypt
Dec 27 09:35:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 09:35:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 09:40:00 RT-AX86U-D850 rc_service: service 22124:notify_rc restart_letsencrypt
Dec 27 09:40:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 09:40:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 09:45:00 RT-AX86U-D850 rc_service: service 25241:notify_rc restart_letsencrypt
Dec 27 09:45:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 09:45:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 09:50:00 RT-AX86U-D850 rc_service: service 27878:notify_rc restart_letsencrypt
Dec 27 09:50:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 09:50:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 09:55:00 RT-AX86U-D850 rc_service: service 30996:notify_rc restart_letsencrypt
Dec 27 09:55:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 09:55:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
...
Dec 27 17:25:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 17:30:00 RT-AX86U-D850 rc_service: service 13884:notify_rc restart_letsencrypt
Dec 27 17:30:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 17:30:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 17:35:00 RT-AX86U-D850 rc_service: service 16534:notify_rc restart_letsencrypt
Dec 27 17:35:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 17:35:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.
Dec 27 17:39:45 RT-AX86U-D850 kernel: httpds (1685): drop_caches: 1
Dec 27 17:40:00 RT-AX86U-D850 rc_service: service 19785:notify_rc restart_letsencrypt
Dec 27 17:40:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec 27 17:40:00 RT-AX86U-D850 Let's_Encrypt: Err, DDNS update failed.

I have no clue what is different between the stock 386-45934 GPL and what you have been provided with - but I'm sure you will figure it out. Just really sorry that your time gets chewed up on Asus issues that have zero to do with your own code :-(
This issue may well be model specific or behave differently from one ISP to the next? - but stock works for me and beta2 doesn't.

The only other fairly serious issue left in beta2 [in my humble view] is the fact that on the RT-AX86U ... any factory reset after installing beta2 [and at any time thereafter] will break the ability to add an Aimesh Node. Have to revert to stock to get it back - and then dirty upgrade to beta2. Once again - this is no fault of your code - closed source.

I fully appreciate your efforts to provide rock steady releases - thank you.

 

[doodlenoodle]

Interesting that you had the same experience with port 1 that I've been having. Could it be that we are being "gamed?"

My main desktop is connected to the router with Ethernet and it is usually connected to router LAN port 1. Beta 2 was running very well after my initial panic of no internet connection. Then near the end of last week I got sick. Fearing COVID and a hospital stay I flashed back to Asus 386.45934 so the family would have no issues should I not come home for a while. After a default reset on the Asus firmware I had the same no internet issue I had with Merlin while the PC was connected to LAN port 1. Switching to another port for a while then back to port 1 seemed to solve the issue.
I have my NAS connected to the 2.5 GB port and a 100 MB switch connected to port 2 for my PoE cams and both of these connections have not had problems with either Merlin or Asus firmware.
Turned out we just had colds and spent the holiday weekend at home with a box of tissues at our elbow. We are making plans to visit our remote family later this week. And I flashed back to beta 2, added a USB3 thumb drive and added Diversion Standard. Working very well!

I've wondered if the LAN port 1 problem is router hardware related. As my Dell desktop is second hand I have not ruled out PC hardware issues. I have not reported it to Asus, yet, but if two of us are having issues then maybe it is an Asus hardware issue.

After reading your post, I was curious so I switched from LAN Port 3 back to the LAN Port 1 and to my surprise things remained stable, no disconnects. Yesterday, it was a different story where LAN port 1 would continue to disconnect no matter if I rebooted the asus router or affected streaming box just after a short while. So in response, I rebooted the router today and expected LAN Port 1 to give me the same disconnect issues I experienced yesterday, but yet no disconnects were present, so then rebooted the streaming box and again no disconnects.

I do have to say that I do have a netgear gigabit switch between the asus router and streaming box. I never powered off the netgear switch, still haven't so maybe there was some sorta switch loop happening up until I changed ports *shrug*. Whatever the case, I can't seem to get back into that LAN Port 1 disconnect state anymore.

As a side note, I'm utilizing my 2.5 GB as my WAN port and LAN 4 for my NAS but no other switches in the mix other than the one described above. So.... so far so good. For now I'll leave on LAN Port 1 and keep an eye out.

Stay healthy and safe out there. Happy Holidays.

 

[geobernd]

Running Beta 2 for 3 days 4 hours on my RT-AC68P and WiFi just gave up.
Both 5GHz and 2.4GHZ show full signal strength but all devices in house lost connection and are stuck on 'connecting' message.

Nothing in the log on the router to explain what happened - temperatures are in my normal range (53/53/80).

Wired connectivity is working just fine

Rebooting now...

Reboot complete - all is connected again (this never happened to me before - Router is on UPS - no power problems either...). Will post again if it happens again - or if there is any additional data I can provide in that case let me know and I'll do before I reboot next time....

 

[SomeWhereOverTheRainBow]

After Flashing Latest ASUS firmware and factory reset Flash Merlin 386.4 BETA 2 Factory Reset Setup Everything From Scratch:
Before and After
Thanks @PR3MIUM
View attachment 38019View attachment 38020

Here is mine when I tested the first beta..

After switching to Beta 2

 

[PR3MIUM]

first had some wired issues with connecting to the vpn client,
thought the config has changed again because of the new openvpn 2.5.x.
currently just having a dns leak when ipv6 is activated (killswitch and all traffic over).
disable ipv6 and just using ipv4 all fne and no dns leak.

 

[Tech9]

I don't know why you guys bother running dual stack on a home network. What isn't working with IPv4 only?