[ 386.4 alpha Build(s) ] Testing available build(s)

[SomeWhereOverTheRainBow]

After a very dirty upgrade from alpha_1 (USB stick plugged in), Entware installation seems like corrupted. In amtm all scripts except Diversion looks like installed correctly, however when I run them they throw errors. For example ntpmerlin says "Entware not found, sleeping for 10s (attempt 1 of 10)".

When trying to install Entware through amtm, this is the console output:

View attachment 37139

View attachment 37140

Trying to install Diversion also throws a similar error with a larger output.

View attachment 37141

Restoring the JFFS partition from backup doesn't help.

I think I have to format the USB stick and start over.

Any thoughts?

The best practice is to always unmount before you flash because of potential unmounting hang ups causing corruption from the process's spawned from the said usb stick resulting in the hang ups. The best practice in the situation would be to attempt to run a disk check/repair in hopes that it fixes the corrupted read only file system. I recommend temporarily stop all your script runs by turning of JFFS custom scripts and rebooting the router. Then mount the device and use the GUI's disk check to repair the device. the next step would be to turn back on JFFS custom scripts and reboot your router.

 

[Blacklistedcard]

I upgraded to Alpha 2 and amtm stuff is working perfectly fine here. Skynet and Diversion working perfectly fine?
Using an AX88u

 

[RMerlin]

Honestly how the hell did you figure that out ?

Connected to an RT-AX58U's internal serial port to get debugging output while the router was running. Saw in which function the router crashed, so I inserted over 20 printf() calls to determine at which point within that function it crashed. Once I knew the last line of code that worked fine, I only had to analyze 4-5 lines of code to determine what was broken.

I call it "pounding code into submission through the application of debugging output carpet bombing".

 

[roundaway]

RT-AC66U_B1. Read the release notes for Alpha 2 and noticed support for the RT-AC68U_V4 was added. Will the RT-AC66U_B1 use the same firmware or is the RT-AC68U_V4 totally different?

Running Alpha 1 with an uptime of over 29 days.

 

[DiGz_Au]

kernel: httpd (1494): drop_caches: 1
This causes wifi clients to temporarily disconnect and reconnect.

 

[RMerlin]

RT-AC66U_B1. Read the release notes for Alpha 2 and noticed support for the RT-AC68U_V4 was added. Will the RT-AC66U_B1 use the same firmware or is the RT-AC68U_V4 totally different?

Running Alpha 1 with an uptime of over 29 days.

DIfferent firmware. However I haven't decided yet if I will do like Asus and merge both together, or keep them as separate images (which would be easier to flash under low memory situations).

 

[RMerlin]

kernel: httpd (1494): drop_caches: 1
This causes wifi clients to temporarily disconnect and reconnect.

No it doesn't. All this does is free up RAM by flushing things like disk buffers.

 

[DiGz_Au]

No it doesn't. All this does is free up RAM by flushing things like disk buffers.

What about this message?
kernel: sched: RT throttling activated

Also yes for me when the cache is released (not everytime) my wifi stops momentarily, it stays connected but no throughout and kicks me out of a game or stops the stream I'm watching. Lan clients not affected. Alpha 1 and prior works normal. Stock firmware has this issue the past 3 or so releases. Not sure what's going on I've enabled more logging but nothing jumps out as it only releases the cache.
Hopefully you (If possible) can give us an option to disable this in the future. I don't see the point of clearing ram when I have 580 mb free just to free up 16 mb more.

 

[RMerlin]

What about this message?
kernel: sched: RT throttling activated

Also yes for me when the cache is released (not everytime) my wifi stops momentarily, it stays connected but no throughout and kicks me out of a game or stops the stream I'm watching. Lan clients not affected. Alpha 1 and prior works normal. Stock firmware has this issue the past 3 or so releases. Not sure what's going on I've enabled more logging but nothing jumps out as it only releases the cache.
Hopefully you (If possible) can give us an option to disable this in the future. I don't see the point of clearing ram when I have 580 mb free just to free up 16 mb more.

The cache only gets flushed if you actually access the login page and you haven't done so in the past 10 minutes. This is probably done because it helps ensuring that if you are logging in to flash a new firmware image, then you will have as much free RAM as possible. It does not occur automatically otherwise.

 

[DiGz_Au]

The cache only gets flushed if you actually access the login page and you haven't done so in the past 10 minutes. This is probably done because it helps ensuring that if you are logging in to flash a new firmware image, then you will have as much free RAM as possible. It does not occur automatically otherwise.

Ahh so only on login. That makes sense. Yeah that's a fair point. Thanks for clearing that up

 

[kernol]

Connected to an RT-AX58U's internal serial port to get debugging output while the router was running. Saw in which function the router crashed, so I inserted over 20 printf() calls to determine at which point within that function it crashed. Once I knew the last line of code that worked fine, I only had to analyze 4-5 lines of code to determine what was broken.

I call it "pounding code into submission through the application of debugging output carpet bombing".

I hope that GPL 386_45581 [which you are currently working on] was not hastily assembled to keep you busy - given that the firmware being released for Asus Stock is mostly 386_45898. I have not been able to find a single Asus router on Stock firmware based on "45581" ???

It seems most "odd" to me that code with a bug last seen in code which is 7 years old ... suddenly resurfaces in the code sent to you in 2021!
Also - most recent security patches provided by Asus for Stock firmware are in higher numbered releases than 45581!

I salute your continued efforts to debug the stuff sent to you - and remain grateful to those with the skills, patience and understanding to flush out the bugs so the rest of us can have it easy. As a PPPoE user - I'm pleased I did not jump in with my RT-AX86U's.

 

[H74]

PPPoE-related crash fixed, was caused by 7 years old code related to PPPoE MTU which was no longer compatible with the latest GPL code (one variable had changed type).

Confirmed. There is no boot loop on GT-AX11000 with alpha2.

 

[underdose]

The best practice is to always unmount before you flash because of potential unmounting hang ups causing corruption from the process's spawned from the said usb stick resulting in the hang ups. The best practice in the situation would be to attempt to run a disk check/repair in hopes that it fixes the corrupted read only file system. I recommend temporarily stop all your script runs by turning of JFFS custom scripts and rebooting the router. Then mount the device and use the GUI's disk check to repair the device. the next step would be to turn back on JFFS custom scripts and reboot your router.

Thanks for the suggestions. I'm aware of the best practices for the firmware upgrade process but previously I've never removed the USB stick while upgrading the firmware and had zero problems with that. I thought it would be the same this time but should've considered that alpha2 has many changes here and there and I should be cautious.

I've tried everything (and more) you've suggested in exact order to fix the issue but couldn't manage to get past the "read-only file system" error. Then rolled back to alpha1 with the same USB stick plugged in and no issues so far. That's what makes me believe that there might be a problem with mounting a USB device with rw permissions while upgrading to alpha2.

Thank you again.

 

[iJorgen]

Installed Alpha 2 (re-release) and all runs fine on my AX86U.

One minor thing I noticed is that events from "kernel" is one hour behind the correct time. Maybe some glitch since we changed to winter-time last weekend?!

Nov  2 09:55:55 kernel: [BLOCKED - INBOUND]
Nov  2 09:55:57 kernel: wl0: random key value: xxx
Nov  2 10:55:57 hostapd: eth6: STA IEEE 802.11: disassociated
Nov  2 10:55:57 wlceventd: wlceventd_proc_event(486): eth6: Disassoc
Nov  2 10:55:57 hostapd: eth6: STA xxx IEEE 802.11: disassociated
Nov  2 09:56:06 kernel: [BLOCKED - INBOUND] IN=eth0
Nov  2 09:56:24 kernel: [BLOCKED - INBOUND] IN=eth0
Nov  2 10:56:30 dropbear[2604]: Exit (xxx) : Disconnect received
Nov  2 09:56:32 kernel: [BLOCKED - INBOUND]
Nov  2 09:56:43 kernel: [BLOCKED - INBOUND]
Nov  2 10:56:47 nextdns[2177]: Connected xxx (con=4ms tls=10ms, TCP, TLS13)
Nov  2 09:56:55 kernel: [BLOCKED - INBOUND]
Nov  2 09:56:57 kernel: [BLOCKED - INBOUND]

 

[shabbs]

Dropped the Alpha 2 [UPDATED] this morning on my APs. Confirming 5GHz Guest Network entries are back. All devices re-connected. So far so good.

 

[SomeWhereOverTheRainBow]

Installed Alpha 2 (re-release) and all runs fine on my AX86U.

One minor thing I noticed is that events from "kernel" is one hour behind the correct time. Maybe some glitch since we changed to winter-time last weekend?!

Nov  2 09:55:55 kernel: [BLOCKED - INBOUND]
Nov  2 09:55:57 kernel: wl0: random key value: xxx
Nov  2 10:55:57 hostapd: eth6: STA IEEE 802.11: disassociated
Nov  2 10:55:57 wlceventd: wlceventd_proc_event(486): eth6: Disassoc
Nov  2 10:55:57 hostapd: eth6: STA xxx IEEE 802.11: disassociated
Nov  2 09:56:06 kernel: [BLOCKED - INBOUND] IN=eth0
Nov  2 09:56:24 kernel: [BLOCKED - INBOUND] IN=eth0
Nov  2 10:56:30 dropbear[2604]: Exit (xxx) : Disconnect received
Nov  2 09:56:32 kernel: [BLOCKED - INBOUND]
Nov  2 09:56:43 kernel: [BLOCKED - INBOUND]
Nov  2 10:56:47 nextdns[2177]: Connected xxx (con=4ms tls=10ms, TCP, TLS13)
Nov  2 09:56:55 kernel: [BLOCKED - INBOUND]
Nov  2 09:56:57 kernel: [BLOCKED - INBOUND]

Blame that one on the @kernol . Wait we mean kernel my apologies.

 

[JWoo]

Experiencing sadness because the RT-AX56U was not invited to the party.

 

[visortgw]

For both instances of Alpha 2 on RT-AX88U, I am unable to "Select client instance" on the VPN Client tab under Client Control — the dropdown has no selectable client numbers (i.e., it's empty). Client 2 is connected (as it was before the installation of Alpha 2), but I cannot access configurations (or start) Clients 1 and 3.

UPDATE: I was able to start Client 1 from the VPN Director tab, but Client 3 failed authentication (which, unfortunately, I cannot address since I have not found a way to reach the configuration GUI).

I also just discovered that

1. the "Redirect Internet traffic through tunnel" dropdown cannot be selected either; and
2. there is a new parameter under Network Settings for Client 2 — "Server is on the same subnet" (Yes/No).

 

[octopus]

Thank you to new build, just loaded new Alpha2 (alpha2-g23082e2452)

Found some things:
On then vpn-client 1-5 drop down select:

Uncaught ReferenceError: vpn_server_array is not defined
initial http://192.168.12.1/Advanced_OpenVPNClient_Content.asp:172
onload http://192.168.12.1/Advanced_OpenVPNClient_Content.asp:1
Advanced_OpenVPNClient_Content.asp:172:1

Same on this screen:
Network Settings, Redict Internet traffic through tunnel.

On router Account Page:


When click on dropdown, Verify Server Certificate Name: Value disappear.


PHY rate display nothing:

Uncaught ReferenceError: _ap_info is not defined
jQuery 11
nvramGet http://192.168.12.1/js/httpApi.js:60
jQuery 3
onclick http://192.168.12.1/AiMesh.asp:1

Uncaught ReferenceError: _ap_info is not defined
jQuery 10
trigger http://192.168.12.1/js/jstree/jstree.js:898
select_node http://192.168.12.1/js/jstree/jstree.js:3158
set_state http://192.168.12.1/js/jstree/jstree.js:3434
each jQuery
set_state http://192.168.12.1/js/jstree/jstree.js:3433
set_state http://192.168.12.1/js/jstree/jstree.js:3424
set_state http://192.168.12.1/js/jstree/jstree.js:3411
_load_nodes http://192.168.12.1/js/jstree/jstree.js:1317
set_state http://192.168.12.1/js/jstree/jstree.js:3408
set_state http://192.168.12.1/js/jstree/jstree.js:3392
refresh http://192.168.12.1/js/jstree/jstree.js:3502
load_node http://192.168.12.1/js/jstree/jstree.js:1286
i jQuery
_load_node http://192.168.12.1/js/jstree/jstree.js:1433
rslt http://192.168.12.1/js/jstree/jstree.js:1869
_append_json_data http://192.168.12.1/js/jstree/jstree.js:1911
_load_node http://192.168.12.1/js/jstree/jstree.js:1432
load_node http://192.168.12.1/js/jstree/jstree.js:1253
refresh http://192.168.12.1/js/jstree/jstree.js:3496
jQuery 2

trigger http://192.168.12.1/js/jstree/jstree.js:898
select_node http://192.168.12.1/js/jstree/jstree.js:3158
set_state http://192.168.12.1/js/jstree/jstree.js:3434
each jQuery
set_state http://192.168.12.1/js/jstree/jstree.js:3433
set_state http://192.168.12.1/js/jstree/jstree.js:3424
set_state http://192.168.12.1/js/jstree/jstree.js:3411
_load_nodes http://192.168.12.1/js/jstree/jstree.js:1317
set_state http://192.168.12.1/js/jstree/jstree.js:3408
set_state http://192.168.12.1/js/jstree/jstree.js:3392
refresh http://192.168.12.1/js/jstree/jstree.js:3502
load_node http://192.168.12.1/js/jstree/jstree.js:1286
i jQuery
_load_node http://192.168.12.1/js/jstree/jstree.js:1433
rslt http://192.168.12.1/js/jstree/jstree.js:1869
_append_json_data http://192.168.12.1/js/jstree/jstree.js:1911
_load_node http://192.168.12.1/js/jstree/jstree.js:1432
load_node http://192.168.12.1/js/jstree/jstree.js:1253
refresh http://192.168.12.1/js/jstree/jstree.js:3496
jQuery 2

 

[RMerlin]

It seems most "odd" to me that code with a bug last seen in code which is 7 years old ... suddenly resurfaces in the code sent to you in 2021!

That code was unique in Asuswrt-Merlin, it's not Asus's code. It's simply that in their code they changed the way one of the variables worked, and my code needed to be adjusted to match that change.