Beta Asuswrt-Merlin 386.7 Beta is now available

[Trent Hubbert]

RT-AX86S, Updated 386.5_2 to 386.7_beta1
Dirty upgrade, no issues.

 

[Deleted member 22229]

Things in particular need of testing in this release:

• DNSFilter and IPv6 support

I entered my v4 and v6 DNS servers on the dns filter page that is set to router and so far no issues what so ever. Using DNS over TLS. This beta seems solid.

 

[octopus]

dhd logging is enabled at the time the driver is compiled. It's outside of my control.

Maybe you can ask them if they can compile without logging enabled next time.
Thanks!

 

[Deleted member 22229]

Maybe you can ask them if they can compile without logging enabled next time.
Thanks!

Yes and also ask them to stop with the>

WLCEVENTD​

​

 

[octopus]

Yes and also ask them to stop with the>

WLCEVENTD​

​

I can't do it

 

[Deleted member 22229]

I can't do it

But WHY !!!

 

[SwampKracker]

Maybe you can ask them if they can compile without logging enabled next time.
Thanks!

Agreed. Releasing a compiled blob to the public with diagnostic logging enabled is obnoxious and sloppy.

 

[octopus]

Agreed. Releasing a compiled blob to the public with diagnostic logging enabled is obnoxious and sloppy.

It's perfectly okay in alpha / beta software but then it should be removed.

 

[Smokey613]

LOL, that particular model the RT-AC86U is such a PITA with the updates NOT initiating properly...
I went to the following method & haven't had a problem since.
You need to change the variables in the top section, save the script & make it executable... of course.
It ALMOST makes it idiot-proof.

I have never had any issues updating either of my AC86U units. It may happen, but hasn’t in the last two years.

 

[lepa71]

Can somebody confirm that AC68 runs at full speed in bridge or mesh node mode?
I have AX58 as the main router and have to run John's fork on AC68 as a bridge.

Thanks

 

[David Williams]

Hi all, did a dirty upgrade from 386.5 to this new beta on mesh network with RT-AX86 as primary, RT-AC3100 and RT-AC88U as mesh nodes.

And getting a lot of the following errors with different domain's at the end:
Jun 11 16:13:51 kernel: *** ERROR: [send_redir_page:625] # redir_url=http://172.16.1.1:80/blocking.asp?cat_id=78&mac=C0B6F92D177F&domain=jomtingi.net

I assume this is from TrendMicro but wasn't getting it before upgrade. I do have AiProtection enabled. Let me know if there is any additional information needed. Thanks.

 

[capncybo]

I have never had any issues updating either of my AC86U units. It may happen, but hasn’t in the last two years.

I'm glad for all of your successes. Yet it's possible there may be some different iterations of hardware within these routers. Slight "internal variations" are apparently why some of the AX86U Bricked while others did not.

 

[Smokey613]

I'm glad for all of your successes. Yet it's possible there may be some different iterations of hardware within these routers. Slight "internal variations" are apparently why some of the AX86U Bricked while others did not.

I am sure the current “supply chain” issues will only increase the chance of variations in hardware. My units are a late 2019 China production and an early 2020 Taiwan unit. I guess I lucked out!

 

[sQumm]

Dirty update on my GT-AX11000 from 386.5_2 to 386.7_beta1. Don't notice any errors. jffs seems also fine.

 

[nzwayne]

Dirty upgrade on the GT-AXE1100, forgot to unmount the USB flashdrive (again), and the AiMesh'd units. All operational as are the installed scripts. Thanks for the time & work @RMerlin from myself & family!

 

[Tech9]

No flashing issues on RT-AC86U, clean installation, no scripts. First attempt, process as usual.

 

[RMerlin]

GT-AX11000 dirty flash over Alpha 1 successfully. All seemed OK except that this line about SFP in the syslog, don't really understand what it means, hope it is nothing serious.....

That router has no SFP port, hence the message.

Same IP assignments in Guest #2 is still present in Beta1, it seems cosmetic as they are leased the right IP's according to Network map and the

Can't reproduce, so no idea why your router would have the same IP associated to multiple MACs. I can't see anything in the code that could cause this kind of behaviour. Are you using any custom script or repeater/AiMesh node?

Maybe you can ask them if they can compile without logging enabled next time.

It took them three weeks to get through building all the GPLs. I'm not asking for customized builds on top of that.

 

[RMerlin]

Agreed. Releasing a compiled blob to the public with diagnostic logging enabled is obnoxious and sloppy.

They're not providing me release code, they're providing me development snapshots as I need to have the same codebase for all models.

Seriously guys, this is complaining about something totally irrelevant. Has any of you ever seen a Red Hat 7 system log, or even a Windows Event log? These are 100X more verbose than your router's log.

Be glad I am able to get something that works.

 

[Maverickcdn]

Yes and also ask them to stop with the>

WLCEVENTD​

Just kill the wlceventd process

MavMAIN|>/jffs/scripts| cat killwlc.sh
#!/bin/sh
F_log() { printf '%s' "$1" | logger -t "killwlceventd[$$]" ; printf '%s\n' "$1" ;}

F_log "Killing wlceventd process if running..."

pidofwl=$(pidof wlceventd)

if [ -z $pidofwl ] ; then
        F_log "Couldn't find wlceventd process running"
else
        kill $pidofwl
        F_log "Killed process $pidofwl wlceventd"
fi

I believe this is a WL Connection EVENT Daemon and is only used for logging interaction between the AP and clients making diagnosing wireless issues easier, I've noticed no ill effects killing this process

 

[octopus]

Seriously guys, this is complaining about something totally irrelevant.

Be glad I am able to get something that works.

Sorry, I'm not complaining was just a friendly question. I'm glad for what you doing.