[Preview] Early Asuswrt-Merlin 384.6 test builds are available

[iManuB]

Make sure you don't have a browser extension like a password manager or autofill agent that is 'remembering' your last value and filling it in for you.

do it with WPS button pressed while power on and 15s longer, maybe than it clears more than with initialize. After that while on additional with reset button some seconds.

Did you disconnect everything and only access via WiFi?
Suppose it gets the old IP from anywhere else DHCP.

I did another trial. I disconnected the Modem / router with 192.168.1.1 and I initialized the Asus RT-AC86U. He came back with 192.168.1.1.

Why if I leave the modem / router connected, do I keep 192.168.X.X? (ie what we decide and not that of dafault)?

After 15s, I'll see some leds blinking?

 

[kfp]

I did another trial. I disconnected the Modem / router with 192.168.1.1 and I initialized the Asus RT-AC86U. He came back with 192.168.1.1.

Why if I leave the modem / router connected, do I keep 192.168.X.X? (ie what we decide and not that of dafault)?

After 15s, I'll see some leds blinking?

Perhaps the 86U is smart enough to detect an IP conflict and jump onto 192.168.2.1

 

[Grisu]

Here a post that others (maybe chinese versions) got default 192.168.50.1 just like mine: https://www.snbforums.com/threads/rt-ac86u-default-ip-address.44588/
On other pages you will find yours 192.168.1.1 as default, I dont understand such things anyway ...

 

[Iwakan]

Alpha2 running for 24 hours on AC68u and working great.

In my case random problem with AiProtection not loading on router startup is solved.

AiProtection events deletion not solved.

 

[eddiez]

Perhaps the 86U is smart enough to detect an IP conflict and jump onto 192.168.2.1

You are right. The 2nd router detects that 192.168.1.1 is the incoming WAN and since WAN is a separate vlan, it picks the next subnet. I think

 

[Deleted member 22229]

Perhaps the 86U is smart enough to detect an IP conflict and jump onto 192.168.2.1

Yes even Netgear does this.

 

[iManuB]

Nice! It's all clear! Thanks, guys! The best trial is to set a 192.168.10.1 and the next time when I need to initialize the router for new Merlin's firmware,see what happen.

 

[GHammer]

I have been running alpha 2 on my 86U for days with no errors, not even an odd log entry.
WiFi on both bands is fine, LAN is fine, DDNS working, pretty happy camper at this point.
I did have to stop using scheduled restarts as that caused the router to power off after 2 days.

 

[jsbeddow]

It is great that 384.6 alpha builds are proving to be stable, but until we get a build for the RT-AC68 that addresses the massive LAN to WiFi slowdown that occurs with this build, I'll have to stay on 384.5. Frankly, I'm surprised this has not seen more users complaining (and yes, I know it is not Merlin's fault, it is an Asus bug), especially given how popular this model router has been.

I can only hope that Merlin is waiting on receiving the source files for 384_21140 to continue development on this branch, or perhaps I (and other 68U users) will have to wait for that to be integrated into the next build (384.7 perhaps?).

I can confirm the transfer slowdowns seen in these threads, resolved by rolling back to 384.5.
https://www.snbforums.com/threads/r...low-wifi-lan-transfer-rate.47560/#post-415653

https://www.snbforums.com/threads/ac68u-lan-to-wifi-downlink-throughput-issue.46992/

 

[kfp]

It is great that 384.6 alpha builds are proving to be stable, but until we get a build for the RT-AC68 that addresses the massive LAN to WiFi slowdown that occurs with this build, I'll have to stay on 384.5. Frankly, I'm surprised this has not seen more users complaining (and yes, I know it is not Merlin's fault, it is an Asus bug), especially given how popular this model router has been.

I can only hope that Merlin is waiting on receiving the source files for 384_21140 to continue development on this branch, or perhaps I (and other 68U users) will have to wait for that to be integrated into the next build (384.7 perhaps?).

I mean, you just linked to two separate threads (and there are a lot more complaints on this issue), not sure why you think there should be more people complaining. Maxing out WiFi to LAN is not a typical usecase and I doubt a lot of everyday users would notice.

Edit: to make this less of a rant, alpha2 still going strong in AP mode on AC3200, uptime was disrupted by an unnecessary power cycle (10+ days then 4+ now) but other than that it’s been very stable, logs quiet, no mention of “br0 entered promiscuous mode”.

 

[Sanna1967]

I can confirm the transfer slowdowns seen in these threads, resolved by rolling back to 384.5.

I can confim too

alpha2 still going strong in AP mode on AC3200

Fine for you if its work fine on AC3200, but this guy is talking about ac68 series

I doubt a lot of everyday users would notice.

I noticed each time i tried 21045 or 384.6 alpha

 

[jsbeddow]

I mean, you just linked to two separate threads (and there are a lot more complaints on this issue), not sure why you think there should be more people complaining. Maxing out WiFi to LAN is not a typical usecase and I doubt a lot of everyday users would notice.
.

In fact, it is not WiFi to LAN that is slow, it is the inverse (LAN to WiFi) that is problematic in this case. So, in my case, transferring a large number of files from my (wired) LAN computer to a WiFi laptop (5Ghz band) was painfully slow - on the order of 5-7 MB/s, not the 40-50 MB/s that is possible with previous Merlin builds, as well as apparently fixed on newest stock Asus 384_21140 firmware (according to reporting by others).

 

[kfp]

In fact, it is not WiFi to LAN that is slow, it is the inverse (LAN to WiFi) that is problematic in this case. So, in my case, transferring a large number of files from my (wired) LAN computer to a WiFi laptop (5Ghz band) was painfully slow - on the order of 5-7 MB/s, not the 40-50 MB/s that is possible with previous Merlin builds, as well as apparently fixed on newest stock Asus 384_21140 firmware (according to reporting by others).

You’re right, that was indeed a typo.
@jsbeddow since you sound more level-headed than others, is this problem exclusive to 68U? (and family??)

Just so others have reference, it was reported here and here that problem is fixed in 384.21140 so it’s just a matter of time Merlin gets access to the GPL archive and port the changes. There is no need for more reports of this issue or quoting me telling me how slow your transfers are.

 

[jsbeddow]

Thank you @kfp for the kind words: I wish I could say with certainty that the problem is exclusive to the 68U/P family of routers, but that is the only model I have for testing, so I cannot confirm one way or the other. There don't seem to be reports of other models being affected from what I can see.

Yes, I am well aware of the existence of the other threads on this subject (as evidenced by my linking to them previously), but was merely commenting that it seemed surprising to me that more attention to this issue hasn't been noted in this primary "384.6 alpha" thread. It would seem like a showstopper (to me at least) for users of this 68U family of routers.

 

[Geraner]

Did they release a change log?
I don't see this new firmware yet, it still shows version 3.0.0.4.384.21045 on the ASUS BIOS&Firmware download page.

Not much details so far more than:
ASUS RT-AC86U Firmware version 3.0.0.4.384.21140
- Fixed bugs.
- Improved system stability.

 

[Gingernut]

@RMerlin

How should I setup the Default message log level & Log only messages more urgent than for system logs to debug a soft reboot issue I´m having?

 

[scjr]

384.6 alpha 2 still chugging along great here. Very stable alpha.

 

[PolarBear]

384.6 alpha 2 still chugging along great here. Very stable alpha.

Here too, uptime 14 days now

 

[skeal]

384.6 alpha 2 still chugging along great here. Very stable alpha.

Here too, uptime 14 days now

Yup me too. AC3100 running excellent with all my scripts!!!

 

[FadgewackeR]

I have a recurring issue, which I've had on 384.5 and 384.6_alpha2-g5b076fc87 - I've never run stock firmware.

Essentially, the QoS Statistics screen, when left on for an extended period of time, ends up hanging / freezing, and the only way I can get back into the WebGUI is to restart via Putty or actually power cycle the router. This has happened multiple times as I've been working through Fresh's script and monitoring the activity generated.

Have any you experienced the same thing? FWIW I am a member of the fairly high memory usage AC86U club... ~90%