[Beta] Asuswrt-Merlin 384.12 Beta is now available

[Vexira]

It affects all HND models: RT-AC86U, RT-AX88U, GT-AC5300, GT-AX11000, etc... It's an issue with the nvram-to-jffs code on these models.

oh bugger, looks like im under that umbrella, I did notice setting qos through the app did cause it to reset settings.

 

[Swistheater]

View attachment 18190
Acsd on crack.

here is one that gets me

why is acsd making calls to eth1 ?

 

[RMerlin]

why is acsd making calls to eth1 ?

Because that's the 2.4 GHz interface.

 

[Nimloth]

LOL, that didn't take long. At the time this security measure was being discussed, we were debating whether the default should be block or allow. There always seem to be an outlier.

Frankly, updating a remote router's firmware seems pretty risky, just in general. Unless you have a *very* desperate need for a new feature or bug fix, this is something better left for when you are present at the remote site. And a *beta* ta-boot.

Assuming you accept the risk and intend to maintain the existing nvram settings (something I don't normally recommend either), I suppose you could add some firewall rules to the firewall-start script that precede the blocking.

SCRIPTS_DIR="/jffs/scripts"
FIREWALL_SCRIPT="$SCRIPTS_DIR/firewall-start"
mkdir -p $SCRIPTS_DIR
cat << "EOF" > $FIREWALL_SCRIPT
#!/bin/sh
iptables -I INPUT -i tun1+ -j ACCEPT
iptables -I FORWARD -i tun1+ -j ACCEPT
EOF
chmod +x $FIREWALL_SCRIPT

This assumes, of course, you have jffs and custom scripts enabled on the Administration->System page.

Once you have access to the OpenVPN client again, you can change the "Inbound Firewall" option to "Allow" and get rid of the firewall script. Or perhaps leave it there for future firmware updates.

No risk, no fun
OK so this are standard allow for Input and Forward which most of distros need - wasn't sure so better to ask.

Thx

 

[Swistheater]

Thanks Merlin on the awesome work of implementing these features. despite the firmwares limitations with handling the traceroute aspect.

 

[JimbobJay]

• Merged GPL 384_45717 for non-AX models, with 382_51634/51636 binary blobs for the RT-AC87U and RT-AC3200.

Firstly, thanks for all the great work you do, Merlin. I was just wondering, though, is this is a typo with regards to the AC-87U, or not? Because in the release notes for 384.11, it seems that the GPL code base for the 87U was actually newer, at 384_45149?

Asuswrt-Merlin 384.11 is now available for all supported models. This is a fairly big update which brings a number of new features.

• GPL merges: 384_5951 (RT-AX88U), 384_45713 (all other models). Note that the RT-AC87U and RT-AC3200 are still using the 384_45149 binary blobs for their closed source components.

 

[Livin]

Hi,

Is there anyne having issues with Wifi? sometimes and very randomly my iphone/ipad and my logitech harmony disconnects and unable to rejoin, if i restart the router, they work fine, this is a fresh install of the latest beta, and this has happened since the last 2 Merlin firmwares 384.11_2...

Help is appreciated..

I've had this problem with .11_2 also... and wifi sucked big time, on all bands and any channel. I may need to roll back to .10
Trying 12b1 right now, was hoping it would fix the problem.

 

[joe scian]

View attachment 18190
Acsd on crack.

I have an RT-AC5300 on same firmware and I get none of that

 

[Swistheater]

I have an RT-AC5300 on same firmware and I get none of that

are you using smart connect?

 

[princi]

Any info on the 384.12 beta2 wanup version that is up for testing?

Guess I will need to go fishing on Github

 

[Swistheater]

Jun 12 19:56:02 RT-AC5300-1650 rc_service: service 13257:notify_rc restart_wireless
Jun 12 19:56:03 RT-AC5300-1650 syslog: Error unlocking 5: 9 Bad file descriptor
Jun 12 19:56:03 RT-AC5300-1650 syslog: Error unlocking 0: 9 Bad file descriptor

does anybody see this message if they restart their wireless?

 

[joe scian]

are you using smart connect?

no because its useless when one can set their own settings

 

[Swistheater]

no because its useless when one can set their own settings

Joe, could you use SCmerlin and test restart your wireless and tell me if you see those in your logs,
the bad file descriptor.

 

[joe scian]

yes got two lines - no big deal - are you trying to find a solution for a problem that dosent exist>?

 

[Kingp1n]

Anyone agree 384.12 is ready to be converted to a final stage vs beta...jk...but this is really great beta and working flawlessly. Thanks RMerlin and all who make our routers work at a superior level compared to stock with the extra scripts available. Pure Awesomeness!!!

 

[Swistheater]

yes got two lines - no big deal - are you trying to find a solution for a problem that dosent exist>?

no just seeing if there is commonality in our setup making sure it didn't spell corruption.

 

[RMerlin]

Firstly, thanks for all the great work you do, Merlin. I was just wondering, though, is this is a typo with regards to the AC-87U, or not? Because in the release notes for 384.11, it seems that the GPL code base for the 87U was actually newer, at 384_45149?

The 382_xxxx and 384_xxxx codebase are separate, and their version numbers cannot be directly compared between the two branches.

Any info on the 384.12 beta2 wanup version that is up for testing?

Special test build for a tester, trying to reorganize the way time-critical services (such as DDNS and OpenVPN) are started at boot time, to ensure they get started after the clock is set, without having the router pause for potentially multiple minutes as it waits for a clock sync that never happens. It also contains a bit of extra logging info during the WAN up process to help analyze its behaviour.

@skeal, are you still able to reproduce your original issue? If so, could you try with this wanup2 test build in the Test Builds folder? Send me the resulting syslog generated during boot, so I can review the wan_up() calls and their timing relative to ntpd and OpenVPN starting. Initial results with another tester looked good, tho the wanup2 build contains one additional fix that hasn't been tested yet.

 

[Vexira]

It affects all HND models: RT-AC86U, RT-AX88U, GT-AC5300, GT-AX11000, etc... It's an issue with the nvram-to-jffs code on these models.

its odd though my qos priorities seem to stick, so am I not affect or just lucky?

I noticed I get a few messages about:
kernel: nf_conntrack: expectation table full

 

[RMerlin]

its odd though my qos priorities seem to stick, so am I not affect or just lucky?

I noticed I get a few messages about:
kernel: nf_conntrack: expectation table full

RT-AC88U is not an HND model... See the list I just posted.

 

[Vexira]

RT-AC88U is not an HND model... See the list I just posted.

I upgraded to the AX88U about two months back because I got a good deal at a computer shop on one, my old 88u with my family now.
The 192.168.50.1 tripped me out the first time I tried to login to it.

lol I forgot to update my signature.