What's new

[Beta 384/NG] Asuswrt-merlin 384.4 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.
Coming from 384.4 alpha 2 to beta 1, with rt-ac5300, i am seeing slower speed in wifi on adaptive qos fq_codel by 30%. Speed drops from 111 Mbps to 70Mbps. Do i need to do factory reset, Merlin?


Sent from my iPhone using Tapatalk
 
Weird, I was made to understand that the AC3200 would burst into flames immediately upon installation of 384 code.
Applies only to PEBKAC models.
 
Majority of my network "problems" have been diagnosed as PEBKAC, thus easily solved by reading the instructions.
RTFM!

And a praise and wholehearted thank you to @RMerlin : I upgraded my 86U to this latest beta. This router is my main router. It went through the complete upgrade process with my SONOS system playing form an external source, never missing a beat. There is some caching on the players but never stop playing while the WAN is down? That never happened with the 87U.
The RT-AC86U is a dream to have and work with.
 
Coming from 384.4 alpha 2 to beta 1, with rt-ac5300, i am seeing slower speed in wifi on adaptive qos fq_codel by 30%. Speed drops from 111 Mbps to 70Mbps. Do i need to do factory reset, Merlin?

Doubt it since nothing was changed related to wifi between these two releases, however if you came from 380 to 384 without doing so, it might be a good idea indeed.
 
Ac3200 - router seems fine, but issue where you change a Wi-fi setting (2.4 in this case) causes all radios to go offline, only a power recycle will bring radios back with new settings. Did do a reset both before and after applying firmware..


Sent from my iPhone using Tapatalk
 
Ac3200 - router seems fine, but issue where you change a Wi-fi setting (2.4 in this case) causes all radios to go offline, only a power recycle will bring radios back with new settings. Did do a reset both before and after applying firmware..

Which specific setting did you change?
 
Thank You Merlin, excellent work. So far everything seems fast and rock solid.

I fixed the Italian dictionary BTW. That language incorrectly provided a complete description for one of the entries instead of just the short "Malicious Website Blocking" label that it should have, causing the whole layout to be broken.
 
Channel - set from auto to channel 6


Sent from my iPhone using Tapatalk

Just tried on my own RT-AC3200 and no issue - channel went from 9 (that was auto-selected) to 1, still broadcasting normally.

What do you have in your system log after you changed channel? Normal output should look like this:

Code:
Feb 28 16:44:47 rc_service: httpds 310:notify_rc restart_wireless
Feb 28 16:44:49 kernel: br0: port 2(eth2) entering forwarding state
Feb 28 16:44:49 kernel: device eth2 left promiscuous mode
Feb 28 16:44:49 kernel: br0: port 2(eth2) entering disabled state
Feb 28 16:44:49 kernel: br0: port 3(eth1) entering forwarding state
Feb 28 16:44:49 kernel: device eth1 left promiscuous mode
Feb 28 16:44:49 kernel: br0: port 3(eth1) entering disabled state
Feb 28 16:44:49 kernel: br0: port 4(eth3) entering forwarding state
Feb 28 16:44:49 kernel: device eth3 left promiscuous mode
Feb 28 16:44:49 kernel: br0: port 4(eth3) entering disabled state
Feb 28 16:44:50 kernel: device eth2 entered promiscuous mode
Feb 28 16:44:50 kernel: br0: topology change detected, propagating
Feb 28 16:44:50 kernel: br0: port 2(eth2) entering forwarding state
Feb 28 16:44:50 kernel: br0: port 2(eth2) entering forwarding state
Feb 28 16:44:50 kernel: device eth1 entered promiscuous mode
Feb 28 16:44:50 kernel: br0: topology change detected, propagating
Feb 28 16:44:50 kernel: br0: port 3(eth1) entering forwarding state
Feb 28 16:44:50 kernel: br0: port 3(eth1) entering forwarding state
Feb 28 16:44:50 kernel: device eth3 entered promiscuous mode
Feb 28 16:44:50 kernel: br0: topology change detected, propagating
Feb 28 16:44:50 kernel: br0: port 4(eth3) entering forwarding state
Feb 28 16:44:50 kernel: br0: port 4(eth3) entering forwarding state

(side note: I see Asus/Broadcom still haven't fixed their channel width downgrade, where the downgrade will move it back to channel 6 rather than stay on the manually selected channel. I recommend people also set the 2.4 GHz band to 20 MHz to ensure their selected channel does get used)
 
Just tried on my own RT-AC3200 and no issue - channel went from 9 (that was auto-selected) to 1, still broadcasting normally.

What do you have in your system log after you changed channel? Normal output should look like this:

Code:
Feb 28 16:44:47 rc_service: httpds 310:notify_rc restart_wireless
Feb 28 16:44:49 kernel: br0: port 2(eth2) entering forwarding state
Feb 28 16:44:49 kernel: device eth2 left promiscuous mode
Feb 28 16:44:49 kernel: br0: port 2(eth2) entering disabled state
Feb 28 16:44:49 kernel: br0: port 3(eth1) entering forwarding state
Feb 28 16:44:49 kernel: device eth1 left promiscuous mode
Feb 28 16:44:49 kernel: br0: port 3(eth1) entering disabled state
Feb 28 16:44:49 kernel: br0: port 4(eth3) entering forwarding state
Feb 28 16:44:49 kernel: device eth3 left promiscuous mode
Feb 28 16:44:49 kernel: br0: port 4(eth3) entering disabled state
Feb 28 16:44:50 kernel: device eth2 entered promiscuous mode
Feb 28 16:44:50 kernel: br0: topology change detected, propagating
Feb 28 16:44:50 kernel: br0: port 2(eth2) entering forwarding state
Feb 28 16:44:50 kernel: br0: port 2(eth2) entering forwarding state
Feb 28 16:44:50 kernel: device eth1 entered promiscuous mode
Feb 28 16:44:50 kernel: br0: topology change detected, propagating
Feb 28 16:44:50 kernel: br0: port 3(eth1) entering forwarding state
Feb 28 16:44:50 kernel: br0: port 3(eth1) entering forwarding state
Feb 28 16:44:50 kernel: device eth3 entered promiscuous mode
Feb 28 16:44:50 kernel: br0: topology change detected, propagating
Feb 28 16:44:50 kernel: br0: port 4(eth3) entering forwarding state
Feb 28 16:44:50 kernel: br0: port 4(eth3) entering forwarding state

(side note: I see Asus/Broadcom still haven't fixed their channel width downgrade, where the downgrade will move it back to channel 6 rather than stay on the manually selected channel. I recommend people also set the 2.4 GHz band to 20 MHz to ensure their selected channel does get used)
Mine looks like this...

Feb 28 09:09:41 rc_service: httpd 294:notify_rc restart_wireless
Feb 28 09:09:42 kernel: br0: port 2(eth2) entering forwarding state
Feb 28 09:09:42 kernel: device eth2 left promiscuous mode
Feb 28 09:09:42 kernel: br0: port 2(eth2) entering disabled state
Feb 28 09:09:42 kernel: br0: port 3(eth1) entering forwarding state
Feb 28 09:09:42 kernel: device eth1 left promiscuous mode
Feb 28 09:09:42 kernel: br0: port 3(eth1) entering disabled state
Feb 28 09:09:42 kernel: br0: port 4(eth3) entering forwarding state
Feb 28 09:09:42 kernel: device eth3 left promiscuous mode
Feb 28 09:09:42 kernel: br0: port 4(eth3) entering disabled state
Feb 28 09:09:43 kernel: device eth2 entered promiscuous mode
Feb 28 09:09:43 kernel: br0: port 2(eth2) entering listening state
Feb 28 09:09:43 kernel: br0: port 2(eth2) entering listening state
Feb 28 09:09:44 kernel: device eth1 entered promiscuous mode
Feb 28 09:09:44 kernel: br0: port 3(eth1) entering listening state
Feb 28 09:09:44 kernel: br0: port 3(eth1) entering listening state
Feb 28 09:09:44 kernel: device eth3 entered promiscuous mode
Feb 28 09:09:44 kernel: br0: port 4(eth3) entering listening state
Feb 28 09:09:44 kernel: br0: port 4(eth3) entering listening state
Feb 28 09:09:45 kernel: br0: port 2(eth2) entering learning state
Feb 28 09:09:46 kernel: br0: port 3(eth1) entering learning state
Feb 28 09:09:46 kernel: br0: port 4(eth3) entering learning state
Feb 28 09:09:47 kernel: br0: topology change detected, sending tcn bpdu
Feb 28 09:09:47 kernel: br0: port 2(eth2) entering forwarding state
Feb 28 09:09:48 kernel: br0: topology change detected, sending tcn bpdu
Feb 28 09:09:48 kernel: br0: port 3(eth1) entering forwarding state
Feb 28 09:09:48 kernel: br0: topology change detected, sending tcn bpdu
Feb 28 09:09:48 kernel: br0: port 4(eth3) entering forwarding state
Feb 28 09:10:11 rc_service: httpd 294:notify_rc restart_net_and_phy
Feb 28 09:10:11 rc_service: waitting "restart_wireless" via httpd ...
Feb 28 09:10:26 rc_service: skip the event: restart_net_and_phy.

I guess that waiting restart wireless gives a clue.. I will set to 20mhz and see if that takes tomorrow (am in uk)
 
I guess that waiting restart wireless gives a clue.. I will set to 20mhz and see if that takes tomorrow (am in uk)

Odd. It would seem to imply that the wireless stack restart never completed, or was taking far longer than expected to complete when you did the other change that initiated a complete net and phy stack restart.
 
Odd. It would seem to imply that the wireless stack restart never completed, or was taking far longer than expected to complete when you did the other change that initiated a complete net and phy stack restart.

What would have caused the complete net and phy stack restart ? I didn’t make any other changes at that point. I had to do a power recycle to get wireless back..


Sent from my iPhone using Tapatalk
 
I have ASUS RT-AC87U. Flashed with 384.4 Beta 1 coming from 380.69_2 firmware. Did a full reset. On Network Map then Clients when I click View List or on the Client Status (on Right) anything that is connected to the 5GHz wireless is showing as a Wired Connection. If I view Wireless Log it shows correct there. Have refresh page and cleaned temp files. This is with MS Edge and IE 11, only browsers I have installed.

It showed correctly with 380.69_2 firmware.

Thanks
 
What would have caused the complete net and phy stack restart ? I didn’t make any other changes at that point. I had to do a power recycle to get wireless back..


Sent from my iPhone using Tapatalk
Do you have a very large set of DHCP manual assignments migrated from an earlier build?
Hard to tell for sure, but I saw one place in the code where exceeding the new length limits might trigger an erroneous 'restart_net_and_phy' action
 
Quick question about performing a reset: is there any difference between doing it through the web interface or phsyically holding the reset button? Is one preferred over the other?

Thanks!
 
2.4 Ghz radio busted on AC86U with this build.
Done settings restore, reboot, power cycle.

Code:
Mar  1 03:06:01 kernel: br0: port 5(eth6) entered listening state
Mar  1 03:06:01 kernel: br0: port 5(eth6) entered listening state
Mar  1 03:06:01 kernel: acsd[2741]: unhandled level 2 translation fault (11) at 0x03e4a4cb, esr 0x92000006
Mar  1 03:06:01 kernel: pgd = ffffffc016644000
Mar  1 03:06:01 kernel: [03e4a4cb] *pgd=00000000161c2003, *pud=00000000161c2003, *pmd=0000000000000000
Mar  1 03:06:01 kernel: CPU: 1 PID: 2741 Comm: acsd Tainted: P           O    4.1.27 #2
Mar  1 03:06:01 kernel: Hardware name: Broadcom-v8A (DT)
Mar  1 03:06:01 kernel: task: ffffffc0167d0ac0 ti: ffffffc0169f8000 task.ti: ffffffc0169f8000
Mar  1 03:06:01 kernel: PC is at 0xf746c768
Mar  1 03:06:01 kernel: LR is at 0x40b68
Mar  1 03:06:01 kernel: pc : [<00000000f746c768>] lr : [<0000000000040b68>] pstate: 20080010
Mar  1 03:06:01 kernel: sp : 00000000ffe332fc
Mar  1 03:06:01 kernel: x12: 0000000000000100
Mar  1 03:06:01 kernel: x11: 00000000ffe33438 x10: 0000000000061e90
Mar  1 03:06:01 kernel: x9 : 00000000f7641ce0 x8 : 0000000000000000
Mar  1 03:06:01 kernel: x7 : 00000000ffffffed x6 : 0000000000061ad4
Mar  1 03:06:01 kernel: x5 : 00000000ffe33420 x4 : 00000000005f1c00
Mar  1 03:06:01 kernel: x3 : 0000000000000000 x2 : 000000008f40fc00
Mar  1 03:06:01 kernel: x1 : 0000000000000000 x0 : 0000000003e4a4cf
Mar  1 03:06:03 kernel: br0: port 5(eth6) entered learning state
Mar  1 03:06:05 kernel: br0: topology change detected, propagating
Mar  1 03:06:05 kernel: br0: port 5(eth6) entered forwarding state
 
Astrill won't fix issues happening with beta releases, because it might be wasted development time as things might change again during development. I'd be patient, and wait until after the final 384.4 release is out to give them a chance to look into it. So far, they've always resolved any compatibility issues introduced by firmware changes.

You might want to contact them as well, since they're the ones who can fix any compatibility issues. I have no information as to how their plugin works or is implemented.

Thanks for taking the time to reply. I've been in this position before and know the drill.

Actually, they did just push out an update - 2.9.9.10 - but the Router Applet still has no DNS resolution.

...and it may have killed Merlin's OpenVPN client. I can no longer connect to Astrill servers that were working this morning. Error in the log: OpenVPN could not start.


I will keep an eye on it. Have already brought it to their attention.
 
I can confirm in this version the WiFi scheduler does not work on RT-AC86U. I set both 2.4 and 5GHz to be turned off from Monday to Friday, starting from 1.00AM to 6.00AM. Here are the NVRAM involved values:

Code:
wl0_timesched=1
wl1_timesched=1
wl_timesched=1
wl0_sched=010001<120601<230601<340601<450601<500600
wl1_sched=010001<120601<230601<340601<450601<500600
wl_sched=010001<120601<230601<340601<450601<500600

To be honest, with previous release, the WiFi scheduler feature worked intermittently. I don't also if this is part of a closed source component and also I suspect this behaviour is the same for the stock firmware
 
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Top