What's new

[Beta] Asuswrt-Merlin 384.14 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Bit of topic but I’m running ASUS beta with wpa 3 and Wi-fi 6 on for new iPhone when will that be included in Merlin
As I’m having issues with chrome cast appearing multiple times and some iot stuff homebridge I’m having to reboot router every other day
Thanks
Your better off starting your own thread for issues that are unrelated to this beta.
 
Flashed RT-AC86U from alpha 2 to 384.14 beta 1 factory reset etc

Led lights turn off and on via WebUI

Thanks RMerlin


Sent from my iPad using Tapatalk
 
Led on/off working fine on RT-AC68U.
 
Color me shocked that 384.14_b1 works better than the alphas I had issues with. Thanks, @RMerlin. All the programmers that work with you deserve kudos for fixing bugs. Will report if I find more bugs. So far everything is working like it should.

The only real "change" was that I tracked down the lines generating the debug output from bcmmcst and disabled them.

Had added in unbound. But it only works if Firefox's DoH "network.trr.mode" option is 2. If you are an advanced user, you will choose 3. I don't find this implementation useful. Best control is by proxy or firewall.

It will indeed only work if you leave it set to automatic switch. If the goal is to prevent your kids from bypassing your DNS over TLS or filtering DNS configurations, then you have very little control over that sadly, short of blocking the Cloudflare IP addresses in the firewall. That's one of my complains about the whole DoH feature in Firefox, the fact that it hides as regular https traffic specifically to avoid blocking. Good for people in countries with malicious entities, but bad for anywhere else where the network administrator is losing control over it.

At least in Chrome's case, they only do a "protocol upgrade", i.e. if you are using a DNS server that supports DoH, then it will switch from regular DNS to DoH, without changing the configured server.

when will that be included in Merlin

Asus were supposed to release a final version at the end of October (that was one of the reasons why I waited so long in the alpha stage). I suspect that release was delayed because of the Let's Encrypt issues that arose in October, so I decided to proceed with moving into the beta cycle with what I already had. I'd expect Asus to move to that new SDK in the coming weeks, so it should be available for the 384.15 development cycle.
 
Thanks for the new beta fw. I just dirty upgrade from 384.13...we'll test and report of any issues. Awesome job RMerlin,
 
Updated from alpha dirty, so far so good.
 
Upgraded from Alpha 2 and have the following errors when I try to install AMTM until I go back to 13

amtm: line 3175: can't create /jffs/.amtm_theme: Read-only file system
amtm: line 3175: can't create /jffs/configs/profile.add: nonexistent directory
amtm: exec: line 3175: /jffs/scripts/amtm: not found

Once I go back to 13 everything loads up ok. Also my LAN Led light won't come back on when I turn my Leds off via GUI.
 
Disable and enable LEDs works perfectly on my RT-AC88U.
 
Upgraded from Alpha 2 and have the following errors when I try to install AMTM until I go back to 13

amtm: line 3175: can't create /jffs/.amtm_theme: Read-only file system
amtm: line 3175: can't create /jffs/configs/profile.add: nonexistent directory
amtm: exec: line 3175: /jffs/scripts/amtm: not found

Once I go back to 13 everything loads up ok. Also my LAN Led light won't come back on when I turn my Leds off via GUI.
Sounds like your /jffs partition didn’t mount.
 
Sounds like your /jffs partition didn’t mount.
It happened during Alpha 2 also. But once I go back to 384.13 I have no problems. After going back to 384.13, I reload Beta 1 and I can load everything fine.
 
Updated to beta 1, from alpha 2. Everything working fine. Thank you.
 
Have just freshly installed this beta onto the Main router (AC86U), after reinitialize/manual config setup and have noticed the following in the log now on a reboot:

13:05:10 kernel: nand: Could not find valid ONFI parameter page; aborting
13:05:10 kernel: brcmboard registered
13:05:10 kernel: genirq: Flags mismatch irq 36. 00000000 (brcm_36) vs. 00000000 (brcm_36)
13:05:10 kernel: pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
13:05:10 kernel: pci 0000:01:00.0: of_irq_parse_pci() failed with rc=-22
13:05:10 kernel: pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
13:05:10 kernel: pci 0001:01:00.0: of_irq_parse_pci() failed with rc=-22
13:05:10 kernel: broadcomThermalDrv brcm-therm: init (CPU count 2 2 2 2)

Is there a concern with the above as I dont have a clue what it means
 
Have just freshly installed this beta onto the Main router (AC86U), after reinitialize/manual config setup and have noticed the following in the log now on a reboot:

13:05:10 kernel: nand: Could not find valid ONFI parameter page; aborting
13:05:10 kernel: brcmboard registered
13:05:10 kernel: genirq: Flags mismatch irq 36. 00000000 (brcm_36) vs. 00000000 (brcm_36)
13:05:10 kernel: pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
13:05:10 kernel: pci 0000:01:00.0: of_irq_parse_pci() failed with rc=-22
13:05:10 kernel: pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
13:05:10 kernel: pci 0001:01:00.0: of_irq_parse_pci() failed with rc=-22
13:05:10 kernel: broadcomThermalDrv brcm-therm: init (CPU count 2 2 2 2)

Is there a concern with the above as I dont have a clue what it means

Normal boot messages, nothing unusual there.
 
Normal boot messages, nothing unusual there.
Ok, thanks for the info, was a little worried.....

On another note have been a couple of hours now and no problems to report yet, all is good
 
Disabling and enabling LEDs via WebUI works fine on my RT-AX88U.
I had a issue where if the LEDs are disabled, if the WAN LED goes red (lost connection) then regains connection it goes back to white/ flashing rather than off. A simple test, are you able to confirm?
 
I had a issue where if the LEDs are disabled, if the WAN LED goes red (lost connection) then regains connection it goes back to white/ flashing rather than off. A simple test, are you able to confirm?

Can you test to see if the LED button has the same behaviour as the webui setting?
 
Is the Dual-WAN code still closed-source?
 
Nov 8 00:04:41 kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Anyone seeing this? Is there a script to fix that?

Something like this?

# Temporarily Solution
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
 
Upgrade RT-AX88U & RT-AC3100 from V384.14_alpha2-g5951cff143 & V384.14_alpha2_g5060deff5c to V384.14_beta1 via dirty firmware upgrade. 30+ devices and all appears to be working for main AX88U router.
 
Nov 8 00:04:41 kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Anyone seeing this? Is there a script to fix that?

Something like this?

# Temporarily Solution
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
I've seen that Also but I'm using the ram guy script to get rid of all those expectation table is full errors.
 
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