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.
RMerlin what's your opinion on whether this is a problem or not? And how would be the best way to bring it to the attention to get it looked at? E-mail ASUS tech support or get in touch with the WTFfast service?

No idea if that's a problem or not, I don't use WTFast. If it's a VPN technology, then I would expect high CPU usage from it.

Asus are the ones you need to contact for any issue with their firmware implementation of it.
 
The fact that I could not get the wireless config settings screens to work at all in the UI in Beta 3 ("Apply" button did absolutely nothing), might be a helpful hint.
One thing that can change in the merges are the input parsing routines. Make sure your SSIDs and passphrase only use alphanumerics, dash and underscore....no special characters (or double byte characters for int'l users). Actually, you should follow this advice for any user input strings anywhere in the gui,
 
Since beta3 NAT is no longer working for me.

Tried to disable the Firewall and also NAT acceleration but no luck...
 
Since beta3 NAT is no longer working for me.

Tried to disable the Firewall and also NAT acceleration but no luck...

Please reboot the router a few times. Helped me, didn't reset myself since 68_something.
Also point out which was your old version.
Did you try a factory reset yet?
 
The temp setting (c/f) does not stay set. For me it has been this way for some time. (circa 1 year across diff versions) Its not a huge deal to change and sometimes to be honest, I forget if I changed it after a beta update etc.

I always figured it was something locked from ASUS and because of an update (beta) it must be manually set again.

Not a problem, just something I have been curious about, is that expected behavior ?
 
I just went to 384.3 thread and was wondering if the AIRProtect issue have a workaround. I passively aggressively use the time scheduling to ensure that my kids aren't on devices too long. Anyway to get the scheduling back working?
 
Don't have the time to investigate right now, but both my iPhone and iPad cannot connect to the IPsec VPN on my AC86U (which did work OK with a previous beta).
 
Don't have the time to investigate right now, but both my iPhone and iPad cannot connect to the IPsec VPN on my AC86U (which did work OK with a previous beta).

I am able to connect to IPSec VPN on the latest beta. Connected fine from an iPhoneX while on LTE.
 
One thing that can change in the merges are the input parsing routines. Make sure your SSIDs and passphrase only use alphanumerics, dash and underscore....no special characters (or double byte characters for int'l users). Actually, you should follow this advice for any user input strings anywhere in the gui,
Good Tip. My SSID's are all Alpha/Num, no special characters, and same for the passphrases. So I don't think that was the issue. Would it make any sense to reset the router to factory defaults, perform a minimal startup config (simple SSID / passphrase), confirm both wireless radios are working, then upgrade to Beta 3, and then, if all is good, perform my usual customizations or load a saved config?
 
Running b3.

Tried 7 ways from Sunday but I am completely unable to restore JFFS partition. Throws an upload error every time.
 
I had some pretty major problems with the RT-AC68U bridge mode on 384.3. Has anyone tried bridge mode yet on 384.4 beta 3?
 
Please reboot the router a few times. Helped me, didn't reset myself since 68_something.
Also point out which was your old version.
Did you try a factory reset yet?

I came from a legacy version so now did a factory reset and manual re-config and everything is fine now, thanks :)

Btw, i think the DST setting is (still?) wrong for GMT +1 (Amsterdam). I found this old post; https://www.snbforums.com/threads/rt-n66u-system-time-wrong.13427/#post-212517

And i've configured it like that now but by default it says 2th (or 3rd... don't recall exactly) sunday and hour 2 for both start and end which is wrong.
 
Btw, i think the DST setting is (still?) wrong for GMT +1 (Amsterdam).
And i've configured it like that now but by default it says 2th (or 3rd... don't recall exactly) sunday and hour 2 for both start and end which is wrong.
they have never been correct by default (these are global default values), you always had to change it according to your location.
For EU: both 5th sunday (will be interpreted as last sunday), 2nd and back 3rd hour
 
Last edited:
Possibly unrelated to the beta but posting here because it just happened. RT-AC1900P running Beta3. This morning router was frozen, SSIDs were broadcasting but couldn't connect. All lights were stuck on. Rebooted and logged in. Poking around I saw that "Enable Web Access from WAN" was, in fact, enabled, which I have NEVER done. Is there any scenario in an upgrade path that would enable this by default? I disabled it, changed passwords, etc.

Nothing in logs I can see that would indicate access attempts.
 
Possibly unrelated to the beta but posting here because it just happened. RT-AC1900P running Beta3. This morning router was frozen, SSIDs were broadcasting but couldn't connect. All lights were stuck on. Rebooted and logged in. Poking around I saw that "Enable Web Access from WAN" was, in fact, enabled, which I have NEVER done. Is there any scenario in an upgrade path that would enable this by default? I disabled it, changed passwords, etc.

Nothing in logs I can see that would indicate access attempts.


In my router RT-AC68U Ver E1...........asus router app for android....always enable web acces from wan......:confused::confused:

Beta 3 ..............continue solid
 
Possibly unrelated to the beta but posting here because it just happened. RT-AC1900P running Beta3. This morning router was frozen, SSIDs were broadcasting but couldn't connect. All lights were stuck on. Rebooted and logged in. Poking around I saw that "Enable Web Access from WAN" was, in fact, enabled, which I have NEVER done. Is there any scenario in an upgrade path that would enable this by default? I disabled it, changed passwords, etc.

Nothing in logs I can see that would indicate access attempts.

Did you use the Asus router app to access the router from your phone? If yes, it might be the cause since I had encountered that issue after upgrading from beta 2 to beta 3. It had even stated that "Enable Web access from WAN" was necessary for the app to run :oops: and I had to disable it immediately due to security concerns and stopped using the app (what a pity I did not take a print screen at that moment but I can pretty sure about that statement).

Updated: I have tried the app again and been able to access my router without that option kicking in...have no idea about it...
 
Last edited:
Did you use the Asus router app to access the router from your phone. If yes, it might be the cause since I had encountered that issue after upgrading from beta 2 to beta 3. It had even stated that "Enable Web access from WAN" was necessary for the app to run :oops: and I had to disable it immediately due to security concerns and stopped using the app (what a pity I did not take a print screen at that moment but I can pretty sure about that statement).

Updated: I have tried the app again and been able to access my router without that option kicking in...have no idea about it...

Only the first time used this app..........enable acces web from wan........

After reset to factory default......enable acces web from wan......

On 380.69-2.......first time used.......too....for me.
 
bridge mode on 384.3. Has anyone tried bridge mode yet on 384.4 beta 3?
Many times discussed. Known problem since the beginning of 384_xxxx, dont know for 384.4, I gave up trying to settle the problem in bridge mode.Sticking with 380.69_2,which works wonderfully from the beginning without any problems
 
Possibly unrelated to the beta but posting here because it just happened. RT-AC1900P running Beta3. This morning router was frozen, SSIDs were broadcasting but couldn't connect. All lights were stuck on. Rebooted and logged in. Poking around I saw that "Enable Web Access from WAN" was, in fact, enabled, which I have NEVER done. Is there any scenario in an upgrade path that would enable this by default? I disabled it, changed passwords, etc.

Nothing in logs I can see that would indicate access attempts.
I haven’t seen this behavior on my 1900P. I just checked “Enable Web Access from Wan” and it’s disabled. I know if you install the Asus app, it will turn that feature on automatically.
 
Hello,

I have been long time user, and lurker on these forums.
Have been running Asuswrt-Merlin for many years now. Current setup is RT-AC88U
Currently running 384.4 Beta 3 and My Wireless 2.4Ghz and 5Ghz both die once a day or twice. I have restart scheduled at 3am but that isn't enough as it seems it is happening more often.
After major update I always do factory reset and manually enter my config just to make sure things are clean.

Here are last few lines of logs before wireless decided to take a dump.


Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x00ec8166 0x00c98166 0x00c98166 0x00c98166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x00ec8166 0x00c98166 0x00c98166 0x00c98166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 PC (psmdebug):
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x00ff8028 0x00ff8047 0x00fe805b 0x00ec8064
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x00ff8028 0x00ff8048 0x00ff8061 0x00ff8067
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 psmx stack_status : 0x1
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 psmx stack_entries:
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x002f
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x0141
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x0176
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x018c
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x1fff
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x1fdd
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x0cfd
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 0x06f7
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 txe_vasip_intsts 0x0
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.138 wl1: fatal error, reinitializing
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.139 wlc_ucode_download: wl1: Loading MU ucode
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.151 wl1: CORE INIT : nfifo 32 mu_tx_enab 1
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.152 wl1: CORE INIT : mode 2 pktclassify 1 rxsplit 0 hdr conve 0 DMA_CT Enabled
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.161 wl1 wlc_txbf_set_shm_idx: scb aleady has user index 255
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.161 wl1 wlc_txbf_set_shm_idx: scb aleady has user index 255
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.165 wlc_mutx_watchdog: PSMx wds diff = 1
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045732.166 wl1: link up (wl1)
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 wl1: PSMx dump at 18991 seconds. corerev 64 reason:watchdog 045733.138 ucode revision 0.19968 features 0x1426
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 psmxdebug 0x00ec8166 macctl 0x403 maccmd 0x5
Mar 13 08:19:03 kernel: DUMP CONSOLE: psm_brc 0x0011 psm_brc_1 0x0001 MX_UCODE_DBGST 0x2
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 PC (psmdebug_x):
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00fe8166 0x00fe8166 0x00fe8166 0x00fe8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00c98166 0x00fe8166 0x00fe8166 0x00fe8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00ec8166 0x00c98166 0x00c98166 0x00c98166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00fe8166 0x00fe8166 0x00fe8166 0x00fe8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00ec8166 0x00ec8166 0x00ec8166 0x00ec8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00ec8166 0x00ec8166 0x00ec8166 0x00ec8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00c98166 0x00c98166 0x00c98166 0x00fe8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00ec8166 0x00ec8166 0x00ec8166 0x00ec8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00ec8166 0x00ec8166 0x00ec8166 0x00c98166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00fe8166 0x00fe8166 0x00fe8166 0x00ec8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00c98166 0x00c98166 0x00fe8166 0x00fe8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00c98166 0x00fe8166 0x00fe8166 0x00fe8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00ec8166 0x00c98166 0x00fe8166 0x00fe8166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00c98166 0x00c98166 0x00c98166 0x00c98166
Mar 13 08:19:03 kernel: DUMP CONSOLE: 045733.138 0x00fe8166 0x00ec8166 0x00ec8166 0x00ec8166
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x00c98166 0x00c98166 0x00c98166 0x00c98166
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 PC (psmdebug):
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x00ec809b 0x00ff806a 0x00ec8096 0x00c9809b
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x00fe802a 0x00ff8051 0x00fe809a 0x00ff8069
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 psmx stack_status : 0x201
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 psmx stack_entries:
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x002f
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x0154
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x0166
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x018c
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x1fff
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x1fdd
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x0cfd
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 0x06f7
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 txe_vasip_intsts 0x0
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.138 wl1: fatal error, reinitializing
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.139 wlc_ucode_download: wl1: Loading MU ucode
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.151 wl1: CORE INIT : nfifo 32 mu_tx_enab 1
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.152 wl1: CORE INIT : mode 2 pktclassify 1 rxsplit 0 hdr conve 0 DMA_CT Enabled
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.161 wl1 wlc_txbf_set_shm_idx: scb aleady has user index 255
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.161 wl1 wlc_txbf_set_shm_idx: scb aleady has user index 255
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.164 wlc_mutx_watchdog: PSMx wds diff = 1
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.164 wlc_mutx_watchdog: 2 PSMx wds in 5 seconds
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.165 enable 1: q0 frmcnt 0, wrdcnt 0, q1 frmcnt 0, wrdcnt 0
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.165 enable 1: q0 frmcnt 0, wrdcnt 0, q1 frmcnt 0, wrdcnt 0
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.165 wlc_ucode_download: wl1: Loading non-MU ucode
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.180 wl1: CORE INIT : nfifo 6 mu_tx_enab 0
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.180 wl1: CORE INIT : mode 2 pktclassify 1 rxsplit 0 hdr conve 0 DMA_CT Disabled
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.193 wlc_ucode_download: wl1: Loading non-MU ucode
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.207 wl1: CORE INIT : nfifo 6 mu_tx_enab 0
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.208 wl1: CORE INIT : mode 2 pktclassify 1 rxsplit 0 hdr conve 0 DMA_CT Disabled
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.217 wl1 wlc_txbf_set_shm_idx: scb aleady has user index 255
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.217 wl1 wlc_txbf_set_shm_idx: scb aleady has user index 255
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 wl1: link up (wl1)
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220
Mar 13 08:19:04 kernel: DUMP CONSOLE: FWID 01-9a0dcf94
Mar 13 08:19:04 kernel: DUMP CONSOLE: flags 130005
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220
Mar 13 08:19:04 kernel: DUMP CONSOLE: TRAP 4(2ac6d0): pc 20b74e, lr 10dc7, sp 2ac728, cpsr 28000193, spsr 28000033
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 dfsr c06, dfar 4d8dc375
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 r0 0, r1 323452, r2 7c, r3 f205, r4 3f8670, r5 3f7b30, r6 323348
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 r7 3f7a10, r8 3f79f0, r9 3f7c58, r10 3f7a5c, r11 2ac73c, r12 0
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220
Mar 13 08:19:04 kernel: DUMP CONSOLE: sp+0 002ac73c 00000001 000000ff 000000ff
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+10 00000000 00207fc1 00000003 003f6890
Mar 13 08:19:04 kernel: DUMP CONSOLE:
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+14 00207fc1
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+3c 0020b80b
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+54 00205247
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+64 0020beeb
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+68 0020beb5
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+84 0022e5eb
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+a4 0024f789
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+bc 0001fd41
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+cc 0004913f
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+d0 0022df15
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+d4 00049129
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+dc 0022df27
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+e0 0022df15
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+ec 0020d50d
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+10c 0020d57f
Mar 13 08:19:04 kernel: DUMP CONSOLE: 045733.220 sp+114 0020d351
Mar 13 08:19:04 kernel: dhdpcie_checkdied: msgtrace address : 0x00000000
Mar 13 08:19:04 kernel: console address : 0x003FFCF0
Mar 13 08:19:04 kernel: Assrt not built in dongle
Mar 13 08:19:04 kernel: TRAP type 0x4 @ epc 0x20b74e, cpsr 0x28000193, spsr 0x28000033, sp 0x2ac728, lp 0x10dc7, rpc 0x20b74e
Mar 13 08:19:04 kernel: Trap offset 0x2ac6d0, r0 0x0, r1 0x323452, r2 0x7c, r3 0xf205, r4 0x3f8670, r5 0x3f7b30, r6 0x323348, r7 0x3f7a10
Mar 13 08:19:06 rc_service: restart_wireles 8133:notify_rc stop_amas_wlcconnect
Mar 13 08:19:06 rc_service: restart_wireles 8133:notify_rc stop_amas_bhctrl
Mar 13 08:19:06 rc_service: waitting "stop_amas_wlcconnect" via restart_wireles ...
Mar 13 08:19:08 kernel: br0: port 2(eth1) entering forwarding state
Mar 13 08:19:08 kernel: device eth1 left promiscuous mode
Mar 13 08:19:08 kernel: br0: port 2(eth1) entering disabled state
Feb 13 18:00:17 syslogd started: BusyBox v1.25.1
 
Last edited:
Status
Not open for further replies.

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!
Top