Beta Asuswrt-Merlin 386.1 Beta (stage 2) is now available

[The PyroPath]

This one seems a great ingredient for my current Frankenstein cocktail. AX88u running this beta, let's encrypt back to working, nice additions to the UI, one XT8 running RC10 and the last XT8 (least used) running the last official stable. Happy as a clam for now. Aimesh working as intended but not all functions available on the 2nd node as expected.

 

[modestyB]

This is with beta4b. I'm thinking after various iterations of flashes I might just take the time this evening to do a full reset.

Could not hurt. After initial factory-reset I have flashed beta2 - beta3 - beta4 - beta3 - beta4b, no resets between these flash. Just made it powerless.

 

[princi]

Thanks!

Would be interesting to know whether that solves the problem, and you could now go back to B3 if you wanted to.

But as I said, I am only interested in going forward.

Will confirm whether it worked for me.

I was lucky enough to be able to extract myself from the Invalid Firmware issue by just doing a simple GUI-based firmware update to 4b.

Odd how it affects some and not others. I never use the Trend Micro stuff, or QoS. Maybe that‘s a factor.

 

[SomeWhereOverTheRainBow]

I was lucky enough to be able to extract myself from the Invalid Firmware issue by just doing a simple GUI-based firmware update to 4b.

Odd how it affects some and not others. I never use the Trend Micro stuff, or QoS. Maybe that‘s a factor.

yea 4b failed for me about 15 times in the gui.... but before i experienced issues trying to flash 4b i attempted flashing down to beta 3 which started the flash failures. I did this until one kind user pointed out there was a beta 4. At this point 4b wouldn't flash. it should be noted this was well beyond the point of factory reset. I normally flash a beta let it run a couple of days and come back and report what is going on, but it didn't take long for me to see something was amiss when i saw spdmerlin's speed logs for the past several days. @Jack Yaz is a genious developer and deserves all the best. if it wasn't for his scripts i probably would have gone between flashes without noticing anything was amiss. I did manage to finally get beta4b to flash. It took a manual reboot, and me walking away for a cup of coffee. Speaking of which, on payday I know who I am buying a coffee.

 

[SubElement]

Hope it's not the case, but many resets can mean the radios are dying. You could really turn up the logging (e.g., nvram set log_level=8 commit; service restart_logger; or set logging ti "All" in the UI).

That's about all the logging you can get to see what's going on.

I mean, it could be a possibility but its only a couple of months old. Also it was fine up until Beta 3/4, but I can't remember when I started using scripts etc, so I've gone back to just the beta with a minimal setup.

 

[aex.perez]

Rut roh!

AX88u B4B, was going to run some Bandwidth Tests when all of a sudden noticed a huge drop off, see attached. spdMerlin graphs and releveant log between the last known good and the first bad result.

Testing across different Speedtest servers, similar results. Based on prior testing I shared, I had accepted the TrendMicro privacy agreement, but had not enabled any of the features that depended on it. In doing so I got the same results with it on or off. As long as I didn't enable a TrendMicro feature all was good, enable one and you get a drop. Enable several and the drop stayed consistent. What's troubling is that this drop off started on its own, haven't touched the router since I resolved the 20Mhz bandwidth issue on 5Ghz-2 on the AC5300 B4 nodes late yesterday.

So, I did withdraw from the TrendMicro Privacy agreement and my Speedtest numbers went right back up to where they were, matching what B3 was giving me.

386.1 B3 - spdMerlin 4.1.1
Trend Micro Privacy withdrawn
~910 Down/~600 Up

386.1 B3 - spdMerlin 4.1.1
AIProtection Enabled, TrendMicro Privacy Accepted, AiProtection Disabled
Same ~910 Down/~600 Up

Really curious what kicked this off, and why. Kicking myself now for not getting a list of running processes before/after with scMerlin
Going to try an recreate it by doing what I did before, AIProtection Enabled, TrendMicro Privacy Accepted, AiProtection Disabled

So far so good, here's the relevant log from the last bad spdMerlin test to the good

Jan 12 15:22:16 RT-AX88U spdMerlin: Speedtest results - Download: 388.42 Mbps (data used: 486.7 MB) - Upload: 551.86 Mbps (data used: 574.3 MB)
Jan 12 15:22:16 RT-AX88U spdMerlin: Connection quality - Latency: 4.32 ms (0.06 ms jitter) - Packet Loss: 0.0%
Jan 12 15:29:16 RT-AX88U rc_service: httpd 1194:notify_rc start_spdmerlincheckupdate
Jan 12 15:29:16 RT-AX88U custom_script: Running /jffs/scripts/service-event (args: start spdmerlincheckupdate)
Jan 12 15:34:07 RT-AX88U kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 12 15:37:11 RT-AX88U rc_service: httpd 1194:notify_rc restart_wrs;restart_qos;restart_firewall
Jan 12 15:37:11 RT-AX88U custom_script: Running /jffs/scripts/service-event (args: restart wrs)
Jan 12 15:37:11 RT-AX88U BWDPI: force to flush flowcache entries
Jan 12 15:37:11 RT-AX88U kernel: IDPfw: Exit IDPfw
Jan 12 15:37:11 RT-AX88U kernel: mod epilog takes 0 jiffies
Jan 12 15:37:11 RT-AX88U kernel: IDPfw: Exit IDPfw
Jan 12 15:37:11 RT-AX88U kernel: Exit chrdev /dev/idpfw with major 191
Jan 12 15:37:11 RT-AX88U kernel: Exit chrdev /dev/idp with major 190
Jan 12 15:37:11 RT-AX88U BWDPI: rollback fc
Jan 12 15:37:11 RT-AX88U custom_script: Running /jffs/scripts/service-event (args: restart qos)
Jan 12 15:37:11 RT-AX88U kernel: Cpuidle Host Clock divider is enabled
Jan 12 15:37:11 RT-AX88U custom_script: Running /jffs/scripts/service-event (args: restart firewall)
Jan 12 15:37:11 RT-AX88U custom_script: Running /jffs/scripts/nat-start
Jan 12 15:37:11 RT-AX88U ntpMerlin: Sleeping for 5s to allow firewall/nat startup to be completed...
Jan 12 15:37:11 RT-AX88U custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Jan 12 15:37:35 RT-AX88U rc_service: httpd 1194:notify_rc start_spdmerlinspdtest_user_WAN_
Jan 12 15:37:35 RT-AX88U custom_script: Running /jffs/scripts/service-event (args: start spdmerlinspdtest_user_WAN_)
Jan 12 15:37:36 RT-AX88U spdMerlin: Starting speedtest using Frontier (Miami, FL, United States) for WAN interface
Jan 12 15:37:54 RT-AX88U spdMerlin: Speedtest results - Download: 914.19 Mbps (data used: 744.5 MB) - Upload: 675.87 Mbps (data used: 730.9 MB)
Jan 12 15:37:54 RT-AX88U spdMerlin: Connection quality - Latency: 3.93 ms (0.15 ms jitter) - Packet Loss: 0.0%

 

[ugandy]

having a blast on ax88 and original b4 (no qos/aimesh).
only thing different to 384.18 is that i find the 5Ghz re initializing quite often (DFS). probably would stop if i manually set a width/channel and gave up on 160/dfs. 384.18 was quieter. otherwise very happy. getting close to 900mbps wireless to PC in the next room on 5GHz. coming from 384.18 because 384.19 was unusable for me due to dropping all 2.4 clients after some time.

 

[nzwayne]

I'm really curious if the difference between Beta4-gb9 and Beta4B-gb9 is just the time that you ran the tests seeing the difference is about ~10%
You have cable internet right? Were you nearing a peak time by the time you were doing the beta4b test?

If not, the fact that version beta4-gb9 had a downgraded trendmicro engine is probably making it faster in that version, but we would need more people to validate.
(Either way, I like the idea of having the most updated 386-41535 TM engine, but working correctly/as fast as possible instead of downgrading the TM engine completely to the version Beta 3 had, it's a best of both world's scenario for me)

I only pay to get a 300/20Mbps connection, and using Beta4B with all TrendMicro functions on; I have no performance degradation at my desktop connected to AX WiFi.
(I get on average around 293-294Mbps at my desktop over WiFi on a speedtest)

We would probably need someone else with a 1gig connection or higher to try and replicate these results. (Ideally on fiber so we can rule out any cable fluctuations!)
Again my slower connection package is fine on beta 4b, so no point in me trying to replicate as I won't see any higher anyways.

I ran the Beta4-9gb & Beta4B-9gb on Sunday evening, shortly after RMerlin had released those changes. 10% difference was showing then. Then on Monday evening re-ran all the tests again, results were effectively the same except documented down in spreadsheet form.
Here's Sunday's run (post #229). Only RMerlin knows what he did between the two releases...

 

[ugandy]

on the wireless page if i select "N/AC/AX" for 5GHz instead of "auto", the option to enable/disable AXmode disappears. is this expected?

 

[ExtremeFiretop]

I ran the Beta4-9gb & Beta4B-9gb on Sunday evening, shortly after RMerlin had released those changes. 10% difference was showing then. Then on Monday evening re-ran all the tests again, results were effectively the same except documented down in spreadsheet form.
Here's Sunday's run (post #229). Only RMerlin knows what he did between the two releases...
View attachment 29453

Luckily he already said what he did between the two version! It's also a commit on his GitHub for review, So we know which was an SDK patch on one and a full TM engine downgrade on the other.

I'd still like to see these results replicated with someone using fiber instead of cable to see if it can clearly be replicated.
(My cable internet also fluctuates in the evening)

If it can be replicated again, it might be worth while trying out the TM engine downgraded version. I'd like to know the difference between the current TM engine and the previous version in beta4-gb9

 

[nzwayne]

Luckily he already said what he did between the two version! It's also a commit on his GitHub for review, So we know which was an SDK patch on one and a full TM engine downgrade on the other.

I'd still like to see these results replicated with someone using fiber instead of cable to see if it can clearly be replicated.
(My cable internet also fluctuates in the evening)

If it can be replicated again, it might be worth while trying out the TM engine downgraded version. I'd like to know the difference between the current TM engine and the previous version in beta4-gb9

With my Cogeco cable connect, solid connection performance on my 1000Mb/s download if you look at the stats of the known good releases in my table. It's when you enable TrendMicro at present, then it becomes a lottery on performance stats. I've asked for Fiber connect to the house, sometime in next two years I've been told by Cogeco & Bell...not holding my breath though.

 

[ExtremeFiretop]

With my Cogeco cable connect, solid connection performance on my 1000Mb/s download if you look at the stats of the known good releases in my table. It's when you enable TrendMicro at present, then it becomes a lottery on performance stats. I've asked for Fiber connect to the house, sometime in next two years I've been told by Cogeco & Bell...not holding my breath though.
View attachment 29454

Again, not doubting the numbers you wrote down at all, just saying to completely eliminate any doubt on the cable internet being that 10% drop at that moment, we would need 3 devices at a time at your location, or fiber which doesn't fluctuate at all, or ideally just more testers with high bandwidth caps. (Like yourself)
Seeing you ran these tests on 3 separate days though with the same results, that lowers the odds by alot of it being cable related! But nothing saying you didn't run the same testing methodology at the same time for the same outcome on those 3 days.

I used to have 1.5Gbps Bell fiber here in Ottawa (I got a full 1.5Gbps over Wi-Fi when bypassing their modem with the AX88U as the main router!)
Sadly I've moved from that location; and now like you, the best I can get is gigabit cable, and I have selected 300Mbps cable for me and my girlfriend, so I don't even see the reported ~10% difference on beta4b (But that could be just due to the lower ceiling of my bandwidth.)

More testing necessary, I would still like to know what the actual differences are between the previous version of the TM engine and the one found in 386_41535, but like you said likely only Eric or maybe ASUS would know that.

 

[ExtremeFiretop]

Anyone else want to take a stab at replicating @nzwayne 's results?
Anyone else with gigabit cable or even maybe fiber that has or is willing to compare beta4b and beta4-gb9 for speedtests?

As mentioned I'd be happy to be the one to test and replicate this, but I won't see anything higher than I do now with my 300Mbps download speeds lol

 

[ExtremeFiretop]

No I understand, and it's fair enough, I'm not saying that I am doubting your numbers, it's just that without 3 routers; you couldn't possibly test all 3 firmware's at the same time on your cable internet for "truly" accurate results.
A ~10% flux could be related to the cable internet based on "time of testing", I am assuming your testing methodology was flash one firmware, run 3 tests a minute apart, and then flash the next, which would mean by the time you get to beta4b after the last 2 firmware tests it could be a time of slower networking on cable than when you started on beta3. (By about 10%)

Again, not doubting the numbers you wrote down at all, just saying to completely eliminate any doubt on the cable internet being that 10% drop at that moment, we would need 3 devices at a time at your location, or fiber which doesn't fluctuate at all, or ideally just more testers with high bandwidth caps. (Like yourself)
Seeing you ran these tests on 3 separate days though with the same results, that lowers the odds by alot of it being cable related! But nothing saying you didn't run the same testing methodology at the same time for the same outcome on those 3 days.

I used to have 1.5Gbps Bell fiber here in Ottawa (I got a full 1.5Gbps over Wi-Fi when bypassing their modem with the AX88U as the main router!)
Sadly I've moved from that location; and now like you, the best I can get is gigabit cable, and I have selected 300Mbps cable for me and my girlfriend, so I don't even see the reported ~10% difference on beta4b (But that could be just due to the lower ceiling of my bandwidth.)

More testing necessary, I would still like to know what the actual differences are between the previous version of the TM engine and the one found in 386_41535, but like you said likely only Eric or maybe ASUS would know that.

Actually, @nzwayne on second thought - scratch what I said above about your testing methodology, as long as you can confirm your testing methodology included a test run with TM Engine being off both *before* and *after* doing the test runs with them on.
(Just to validate the constant and only variable being TM.)

I am thinking to switch to beta4-gb9 if that's the case.

 

[RMerlin]

@RMerlin

I'm currently on 386.1 Beta 4 on RT-AC88U. ipset functionality is working properly. However, just wanted you to be aware of the following warning message about the kernal support protocol.

ipset -v

ipset v7.6, protocol version: 7
Warning: Kernel support protocol versions 6-6 while userspace supports protocol versions 6-7

Thank you.

It's telling you that the kernel supports version 6, and userspace supports both version 6 and 7. Nothing wrong there.

 

[Civ]

Seem to be having an issue with download speed on my AC88U... it was fine on Beta 3 but significantly slower on Beta 4. Gigabit internet, usually around 700-800... since updating to Beta 4, speeds don't exceed 200-250.

With a direct line to the modem from my PC, speed is normal. No router settings were changed since the update. Verified NAT Acceleration was still set to Auto and also disabled AiProtection but speed remains low. Considering downgrading to Beta 3 to further confirm it's an issue with Beta 4.

EDIT: Hmm, same issue on Beta 3... had to go all the way back to 384.19 to restore normal download speeds. I guess I didn't notice while on Beta 3 (skipped Beta 1 & 2).

 

[RMerlin]

Will that by any chance restore the released stock 386 code portion of power control to your compiled code for the RT-AX86U ?

No, that was a different issue. The GPL code failed to properly compile the power management kernel module for the RT-AX86U, I had to fix the build recipe for it. Stock firmware wasn't affected because it built it from sources rather than prebuilt objects.

 

[tdhite]

I mean, it could be a possibility but its only a couple of months old. Also it was fine up until Beta 3/4, but I can't remember when I started using scripts etc, so I've gone back to just the beta with a minimal setup.

I hear you -- like I said, hoping, but just noting. With that said -- you might take a look at: http://www.snbforums.com/threads/rt-ax58u-crashes-on-386-1-beta-4.69240/post-651324 -- if your reduction to 'minimal setup' works, I'd be very interested in the non-minimal setup. Asus stuck certain kernel debug configs for a reason (unbeknownst so far).

 

[SubElement]

I hear you -- like I said, hoping, but just noting. With that said -- you might take a look at: http://www.snbforums.com/threads/rt-ax58u-crashes-on-386-1-beta-4.69240/post-651324 -- if your reduction to 'minimal setup' works, I'd be very interested in the non-minimal setup. Asus stuck certain kernel debug configs for a reason (unbeknownst so far).

Yeah I hope it's nothing too. Although now i've set it up without any scripts with amtm it's - crosses fingers - pretty stable. I think it might have been the SSD I set up maybe...

 

[ardennguyen]

@RMerlin there is a critical bug with 386.1_beta3 on AX88U while using OpenVPN client. If option " Force Internet traffic through tunnel " is set to Yes and IPV6 is set to Disable, the connecting process will crash. Here's the log:

Jan 11 22:36:49 ovpn-client1[32047]: WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Jan 11 22:36:49 ovpn-client1[32047]: WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
Jan 11 22:36:49 ovpn-client1[32047]: OpenVPN 2.5.0 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 28 2020
Jan 11 22:36:49 ovpn-client1[32047]: library versions: OpenSSL 1.1.1i 8 Dec 2020, LZO 2.08
Jan 11 22:36:49 ovpn-client1[32048]: WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Jan 11 22:36:49 ovpn-client1[32048]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 11 22:36:49 ovpn-client1[32048]: TCP/UDP: Preserving recently used remote address: [AF_INET]174.128.180.120:443
Jan 11 22:36:49 ovpn-client1[32048]: UDP link local: (not bound)
Jan 11 22:36:49 ovpn-client1[32048]: UDP link remote: [AF_INET]174.128.180.120:443
Jan 11 22:36:49 ovpn-client1[32048]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jan 11 22:36:51 ovpn-client1[32048]: [7618/server] Peer Connection Initiated with [AF_INET]174.128.180.120:443
Jan 11 22:36:52 ovpn-client1[32048]: TUN/TAP device tun11 opened
Jan 11 22:36:52 ovpn-client1[32048]: /usr/sbin/ip link set dev tun11 up mtu 1500
Jan 11 22:36:52 ovpn-client1[32048]: /usr/sbin/ip link set dev tun11 up
Jan 11 22:36:52 ovpn-client1[32048]: /usr/sbin/ip addr add dev tun11 local 172.18.13.190 peer 172.18.13.189
Jan 11 22:36:52 ovpn-client1[32048]: /usr/sbin/ip link set dev tun11 up mtu 1500
Jan 11 22:36:52 ovpn-client1[32048]: /usr/sbin/ip link set dev tun11 up
Jan 11 22:36:52 ovpn-client1[32048]: /usr/sbin/ip -6 addr add fde4:8dba:82e3::102e/64 dev tun11
Jan 11 22:36:52 ovpn-client1[32048]: Linux ip -6 addr add failed: external program exited with error status: 2
Jan 11 22:36:52 ovpn-client1[32048]: Exiting due to fatal error