Release [Beta] Asuswrt-Merlin 384.19 beta is now available

  • 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.
Status
Not open for further replies.

FLA_NL

Regular Contributor
Dirty flashed from 384.19_alpha4 to 384.19_beta1 and lost my internet connection. Dirty flashed back to 384.19_alpha4 and my internet connection was available again. Bit short on time now to look at the logs. Router model RT-AC86U.
Hi, to correct my issue. First of all I noticed no code changes between alpha4 en beta1 so that it was weird that I run into problems. Finally I went back to 384.18 and restored a backup of my configuration before I went to alpha4. There I noticed that all my static IP configuration dissapeared. So I reconfigured that and got stuff running again and made a config backup. Today I also backup up jffs, updated to 384.19_beta1 and I run into the same problem as before but now I did let it settle for a bit and my internet connection recovered. After that I did need to load the backup of jffs partition again. Now everything is running on 384.19_beta1. So to make a long story short my first issue was my impatience, but I did need to recover the jffs partition :)
 

Sonyrolfy

Regular Contributor
Cannot reproduce here. I just tested all modes. I have one OpenVPN client configured with DNS set in Exclusive mode.

I set Force Internet Traffic through Tunnel to Yes, and dnsleaktest.com reports the VPN's DNS.

Then I switched to Policy Mode, added my test laptop to the VPN, and dnsleaktest still reports the tunnel VPN.

Switched to Force Internet Traffic to No, tested again: still reporting the VPN's DNS.

Turned tunnel off, tested one last time: back to ISP DNS.

Please post the content of /etc/openvpn/client1/dns.sh, /etc/openvpn/client1/config.ovpn, as well as the system log entries during the client connection.
I think when you to throw the whole lan in vpn 192.168.1.0/24 you will find dns leaks.
 

QuikSilver

Very Senior Member
Why would the issue be unique to me?

If the logic check is wrong it is wrong for everybody...
The error clearly states only alphanumeric characters allowed and my username is only alphanumeric. Furthermore it was set by the webui once and a leading numeric digit was allowed at one time.

The error seems generic to the webUI code!!

and the cross post is because it is not unique to ver .19
Good luck then.
 

peepsnet

Regular Contributor
Good luck then.
So what happens if you press "SAVE" on the Administration->System page?

Does it say username exists??

If it does this would mean you could not change any other settings on that page...
 

Luizlp10

Occasional Visitor
My AC86U is functioning well after upgrade coming from 384.18 but the following messages are flooding my log:



kernel: jffs2: Data CRC 5ba9bbc6 != calculated CRC 9ed68165 for node at 02510618
kernel: jffs2: read_cache_page() returned error: -5
kernel: jffs2: Error garbage collecting node at 02510618!


Is this something to worry about since overall performance is good?
 

JohnSmith

Regular Contributor
Here is what "top" shows ...

View attachment 25120

so like Merlin stated it seems to be the nt_center reorg going on - I'll let it settle over night ...
This is exactly what happened to me, as well as my GUI became unresponsive to logging into it, via many different browsers, even clearing their caches, etc. I noticed this when I upgraded originally to one of the alpha versions, restored back to V384.18 Final via nuke method & restored backups to get back a working RT-AX88U.

Upgrade RT-AX88U & RT-AC3100 from V384.18 Final to V384.19 Beta 1 via dirty firmware upgrade. 30+ devices (includes gaming, streaming, downloads, etc.) and all appears to be working for main AX88U & backup AC3100 routers (RT-AX88U required the nt_center reorg to happen, which took over 40 mins on my RT-AX88U before being able to login to the GUI interface)

Issues present on RT-AX88U are:

1. Network Map Clients List still changes dynamically on its own, which in turn dynamically changes clients shown on Adaptive QOS | Bandwidth Monitor
2. Under Guest Network | 2.4GHZ | 2nd Network setup for IOT devices, which they used to show up under Adaptive QOS | Bandwidth Monitor, but now none of them are showing up, yet they show up under connected devices under System Log | Wireless Log as before.
3. Under Traffic Analyzer | Traffic Monitor | Last 24 Hours the "Show By" by default is blank, and if you choose KB/MB/GB/TB, scaling does not change, but by default it shows KB/s, and the scaling is out to lunch
4. Adaptive QOS | Bandwidth Monitor When leaving open this TAB for long periods of time, the graphs disappear, and are left with just the needles and the UL/DL Speeds
5. Adaptive QOS | Bandwidth Monitor the "Show by" status when changed to "1 Gbps", it changes it sometimes back to "10 Gbps", not sure why?
 
Last edited:

yobocuruyo

Occasional Visitor
My next router will be a RT-AX86U, I guess i'll have to wait longer to test merlin build. I thought that because AX88U was supported that it will be the same for AX86U
 

det721

Part of the Furniture
My next router will be a RT-AX86U, I guess i'll have to wait longer to test merlin build. I thought that because AX88U was supported that it will be the same for AX86U
Wait for wifi 6E don't waste your money right now. None of the current AX routers will support this very important new wifi band making them obsolete down the near road.
 

Xentrk

Part of the Furniture

Xentrk

Part of the Furniture
Intrepid2007
Sonyrolfy

I can duplicate the issue when using CIDR format as the Source IP. The DNS exclusive rule is not getting created if using CIDR format. The RPDB rules does get created though.
 

Triton

Occasional Visitor
since i updated from 384.18 to 384.19b1 i get frequently disconnected from the WAN, "WAN_Connection: Ethernet link down."
 

RMerlin

Asuswrt-Merlin dev

Triton

Occasional Visitor
Check your modem and the cable.
i did. nothing changed, cat6 cable and the ISP checked the modem, no issues there. same cable that was used before. Modem is an Arris TM3402B
 

L&LD

Part of the Furniture
I've updated the usual assortment of routers (RT-AC66_B1, RT-AC68U, RT-AC3100, RT-AC86U, RT-AX58U, RT-AX88U) to 384.19 Beta 1 and all are performing without issues.

The update process from 384.18_0 release final or from one of the 384.19 Alpha releases:
  • Update all scripts installed first, including amtm and Entware, if necessary.
  • For the RT-AC86U routers, save a 'Backup JFFS Partition' config file (to Restore after flashing, if necessary).
  • Safely remove USB drives via the GUI (no need to physically remove the drive(s) though).
  • Flash the 384.19 Beta 1 firmware.
  • Verify that the update was successful, and all scripts worked after 10 minutes or more after the reboot.
  • After 15 minutes (or more) uptime, reboot the router.
  • After an additional hour (or more) uptime, reboot the router one last time.

In addition to the above, some of the routers needed the Unbound Manager script to be updated and/or re-installed for Unbound to work correctly (the 'error' show was it wasn't running. Some, but not all (therefore why we test).

Great upgrade once again by @RMerlin. Thank you!
 

brummygit

Senior Member
i did. nothing changed, cat6 cable and the ISP checked the modem, no issues there. same cable that was used before. Modem is an Arris TM3402B
I believe there are some issues in the more recent Asus code that I've seen discussed. How is your modem connection configured (Static IP, DHCP or another setting)?
 

Triton

Occasional Visitor
I believe there are some issues in the more recent Asus code that I've seen discussed. How is your modem connection configured (Static IP, DHCP or another setting)?
the modem is set to DHCP. no authentication scheme or other things. IPv4
 

tgfruth1

New Around Here
I have an Asus RT-AX88U running the 384.18 firmware after downgrading from latest beta. Had problems with a VPN provider under the beta software - kept insisting I needed to provide certificates. Even when I pasted them in, nothing changed. Had to back-rev to latest stable build and now the policy-based routing I was seeking is working. Also, under the beta, the LED button did not work to turn off the lights.
 
Last edited:
Status
Not open for further replies.

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