Release Asuswrt-Merlin 3004.388.10 is now available

[Vaskivskyi]

Hello there. Since quite a number of replies here are related to the issues with the Home Assistant integrations causing issues with WebUI, I think I can clarify what happened. My project is the Python communication backend behind both mentioned here HA integrations - AsusWRT (native HA, from the version 2025.9.0) and AsusRouter - a custom one used by some.

Short version: The library works by introducing itself as the mobile app in the HTTP headers - thus the issue in the current release. Since the App is not supported by Merlin, nothing to judge the developers' team for this.

Long version: Depending on the exact FW version before, our favourite routers were able to keep a limited number of simultaneous connections over HTTP(S). So, for my library to work, I found the only method of connection, which was:
- non-blocking for the WebUI
- was not dropped when someone logs into the WebUI
shortly - mimicking the Asus Router mobile app. In this way, I got compatibility with routers as old as RT-AC66U (my first one) on 380.70 and as new as whatever is there now (BE models).
Some, of course, had more issues, for which I found "solutions" in terms of recommending an SSL connection to be set up (because those were dropped less), and some more to patch what was mostly working fine. Anyways...

Solution?
I will try to find an auth/communication method which would work better with the new release as soon as I get free time for this. I have an RT-AX88U, which can be used for tests, but as you can imagine, just taking an active router (actually, node) from my home network during the working week for this is troublesome.
Meanwhile, some of my users found that having SSL for the mobile app and HA, while keeping non-SSL for using WebUI, works in some cases. So, this might be a super temporary solution (https://github.com/Vaskivskyi/ha-asusrouter/issues/1024#issuecomment-3372815673).

P.S. Disclaimer: `AsusRouter` Python library, HA integration and other resources like the webpage mentioned in comments before, are NOT affiliated with Asus, regardless of their name. I don't have any actual information on how exactly the communication protocols for our routers work. Any work done by me is based on tracking what the WebUI and mobile apps are sending and receiving, dumb testing on my personal devices and a bit of scientific guessing. I am not paid for the work on these projects, nor do I receive any direct monetary or other kind of reward from any party.

An update regarding the Home Assistant integrations.

Unfortunately, after all my attempts, I did not manage to find a way to make 388.10 on an RT-AX88U work with my Python library (meaning also HA integrations). Regardless of different ways to set up the router, HTTPD crashes due to the segmentation error (the famous `potentially unexpected fatal signal 11`). The same will be the issue on beta1 and beta2.

At the moment, the only way I see to use HA integrations (for those who wish to) will be to roll back to 9_2. Also, for sure, the latest stock FW will work, but that is not something users here are interested in.

In any case, since the compatibility with the Asus mobile app (meaning also my lib and integrations) is not a part of the Merlin FW idea, any other info on this topic from my side, you can find (or ask about) in this GitHub discussion https://github.com/Vaskivskyi/asusrouter/discussions/698

 

[RMerlin]

Regardless of different ways to set up the router, HTTPD crashes due to the segmentation error (the famous `potentially unexpected fatal signal 11`). The same will be the issue on beta1 and beta2.

If it crashes, then it means it's a bug within httpd, and not an API change.

Are you able to determine at what exact step it crashes? Is it when connecting, authenticating, or using the API?

The change might be within the closed source portion (the whole authentication is closed source for instance) or elsewhere, no easy way to find out. Compiling httpd with debug headers would only partly help since it would only include symbols in the open source portions.

Comparing with "the latest stock firmware" does not help since it's not based on the same GPL version as this release.

 

[RMerlin]

As I suspected - the crash occurs within closed source portions of the code. My guess is a null/unitialized pointer within libasuslog:

(gdb) bt
#0  0xf69f26a4 in strlen () from /lib/libc.so.6
#1  0xf69be858 in vfprintf () from /lib/libc.so.6
#2  0xf69e13c8 in vsnprintf () from /lib/libc.so.6
#3  0xf6ae6690 in asusdebuglog () from /lib/libasuslog.so
#4  0x00098140 in add_token_to_list ()
#5  0x000a21bc in gen_asus_token_cookie ()
#6  0x0007afd0 in login_cgi (wp=0x84ddb0, auth_version=<optimized out>, url=<optimized out>) at web.c:21263
#7  0x0001e184 in handle_request () at httpd.c:1611
#8  0x00019c38 in main (argc=<optimized out>, argv=<optimized out>) at httpd.c:2671

 

[aex.perez]

As I suspected - the crash occurs within closed source portions of the code. My guess is a null/unitialized pointer within libasuslog:

(gdb) bt
#0  0xf69f26a4 in strlen () from /lib/libc.so.6
#1  0xf69be858 in vfprintf () from /lib/libc.so.6
#2  0xf69e13c8 in vsnprintf () from /lib/libc.so.6
#3  0xf6ae6690 in asusdebuglog () from /lib/libasuslog.so
#4  0x00098140 in add_token_to_list ()
#5  0x000a21bc in gen_asus_token_cookie ()
#6  0x0007afd0 in login_cgi (wp=0x84ddb0, auth_version=<optimized out>, url=<optimized out>) at web.c:21263
#7  0x0001e184 in handle_request () at httpd.c:1611
#8  0x00019c38 in main (argc=<optimized out>, argv=<optimized out>) at httpd.c:2671

Does the same happen with https or that a part of the http module?

 

[RMerlin]

Does the same happen with https or that a part of the http module?

This is unrelated to http or https. Libasuslog is an external shared library used for logging by portions of the firmware. The add_token_to_list() and gen_asus_token_cookie() functions are part of the closed source login code within httpd's web_hook.o binary object. Either the token generation code passes an invalid parameter to asusdebuglog(), or asusdebuglog() has a bug. Either way I have no access to that code.

 

[Vaskivskyi]

As I suspected - the crash occurs within closed source portions of the code. My guess is a null/unitialized pointer within libasuslog:

(gdb) bt
#0  0xf69f26a4 in strlen () from /lib/libc.so.6
#1  0xf69be858 in vfprintf () from /lib/libc.so.6
#2  0xf69e13c8 in vsnprintf () from /lib/libc.so.6
#3  0xf6ae6690 in asusdebuglog () from /lib/libasuslog.so
#4  0x00098140 in add_token_to_list ()
#5  0x000a21bc in gen_asus_token_cookie ()
#6  0x0007afd0 in login_cgi (wp=0x84ddb0, auth_version=<optimized out>, url=<optimized out>) at web.c:21263
#7  0x0001e184 in handle_request () at httpd.c:1611
#8  0x00019c38 in main (argc=<optimized out>, argv=<optimized out>) at httpd.c:2671

Thanks a lot for checking this! That would mean Asus has to share bug-free blobs

 

[Unetwork]

Have roaming assistant also disabled on 2.4 & 5.0 ghz?

This caused a lot of connection problems.

Roaming Assistant is always enabled by default, and that's not the cause of the problem (in my situation)

Disabling “Protected Management Frames” solves the problem of my HP printer disconnecting.

I also found another thread suggesting to disable this option, which may be useful to others :

HP Printer wifi issue

I am facing an unknown situation. I have a short-term solution but I don't know how to solve it in long term. I have searched on google and I don't see anything related. I have a HP LaserJet cp1525nw. I used tomatoUSB before, and everything was working without any issues. Last month I switched...

www.snbforums.com

 

[joed327]

At the moment, the only way I see to use HA integrations (for those who wish to) will be to roll back to 9_2. Also, for sure, the latest stock FW will work, but that is not something users here are interested in.

is there any reason folks cannot switch to SSH access for the HA integration now that it has been fixed in HA 2025.10.3?
what is lost by changing from HTTPs to SSH for integration access?
I've been using the updated aioasuswrt on 2025.9.4 for a month now via SSH.

 

[Vaskivskyi]

is there any reason folks cannot switch to SSH access for the HA integration now that it has been fixed in HA 2025.10.3?
what is lost by changing from HTTPs to SSH for integration access?
I've been using the updated aioasuswrt on 2025.9.4 for a month now via SSH.

Yes, sure, for the HA Core AsusWRT integration, you can also use SSH / Telnet if you wish. Support for both protocols is in a different library and on a different maintainer, who just came active after many silent years. If it works, nothing should change for you.

I was answering about two integrations - AsusRouter (custom one) and AsusWrt using HTTP(S) connections. My library came to HA Core to add new features and provide additional support which was missing before. Whether any of those will be backported to the SSH/Telnet lib by anyone is beyond my knowledge.

 

[RMerlin]

es, sure, for the HA Core AsusWRT integration, you can also use SSH / Telnet if you wish. Support for both protocols is in a different library and on a different maintainer, who just came active after many silent years. If it works, nothing should change for you.

Just as a reminder, I removed telnet support in Asuswrt-Merlin years ago. Only SSH would work.

 

[Avinitlarge]

RT-AX86U

Same issue with Home Assistent Asus Router Integration (https://www.home-assistant.io/integrations/asuswrt/). - understanding that this integration is not supported by Merlin, but a lot of my automations are depending on it. I was not able to access GUI after updating.

After turning off the HA integration i was able to connect to the GUI using HTTPS, with HTTP i got a (I think standard Asus screen) with the message that HTTPS was safer. Even after confirming to connect through HTTP is did not work. Tried to enable/disable HTTP and HTTPS via SSH (nvram set https_enable=1, nvram set http_enable=1 etc.), but this did not make a difference (ChatGPT gave it as suggestion).

This brings me to the very first time that I needed to do a roll-back, 3004.388.9_2 is working again with HA integration on.

Same for me, I need the router to work with HA, I have automations that depend on it.
I had to roll back to 3004.388.9_2

 

[A Purohit]

Just to clarify for others, correct me if I'm wrong, but the only time HA is affected is when the router is part of the HA integration. I, for example, don't have the router in my HA... so my HA is working fine after the update. I use it primarily for monitoring my solar panels, and EV charger.

Speaking of which, what HA automations are you guys running with the router itself? Feel free to take this off this thread, as it may derail this thread otherwise.

 

[Pergola Fabio]

Upgraded my router from ac88u to ax88u, so finally back in these firmware
Anyway, I read that a lot of people say that the app doesn't work? I can use it perfectly fine running this version? For me the ax88u was new, upgraded instant to this version...

 

[The PyroPath]

Just to clarify for others, correct me if I'm wrong, but the only time HA is affected is when the router is part of the HA integration. I, for example, don't have the router in my HA... so my HA is working fine after the update. I use it primarily for monitoring my solar panels, and EV charger.

Speaking of which, what HA automations are you guys running with the router itself? Feel free to take this off this thread, as it may derail this thread otherwise.

I use it for presence detection for the most part. I know no other proper way to track if anyone is home and if so, who is home. This allows for the automation of HVAC and power distribution. You can also arm/disarm alarms or emable/disable devices etc.

 

[jksmurf]

I use it for presence detection for the most part. I know no other proper way to track if anyone is home and if so, who is home. This allows for the automation of HVAC and power distribution. You can also arm/disarm alarms or emable/disable devices etc.

But is the AsusRouter integration (staying on topic for the purposes of this thread, as a workaround to the current issue) really needed for that? I use the Bermuda integration for presence detection, there’s also the older ESPresense. I do not use the Asus Router integration. I don’t know if the two I referred to could replace your current setup but worth a look. Bermuda particularly.

 

[joegreat]

Mine has randomly rebooted thrice in the last 12 hours since I updated. Anyone else experiencing this? Some errors in log before it reboots, not sure what they mean.

Oct  6 20:29:28 kernel: [ERROR pktrunner] buildFlowKey,210: LAN flow is not supported: Rx 0, Tx 6
Oct  6 20:43:26 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1
Oct  6 20:44:12 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1025
Oct  6 20:44:53 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=2049
Oct  6 20:46:14 kernel: [ERROR pktrunner] buildFlowKey,210: LAN flow is not supported: Rx 0, Tx 6
Oct  6 20:46:14 kernel: [ERROR pktrunner] __fhwPktRunnerActivate,388: New Mcast flow but key_in<0x003000d9> accel <0>

Same here on my AX88U - but I get the entries after every (weekly) reboot of the router once - was there before firmware update to version 388.10:

Oct  6 01:05:16 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=2049
Oct  6 12:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=3073
Oct  6 19:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=4097

Oct  7 07:05:14 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1
Oct  7 19:05:16 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1025

Oct  9 21:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1
Oct 10 09:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1025
Oct 10 19:05:16 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=2049

Oct 11 05:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=3073
Oct 11 17:05:14 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=4097

Oct 12 02:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1
Oct 12 15:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1025

Oct 13 05:05:16 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=2049
Oct 13 17:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=3073
Oct 14 03:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=4097

Oct 19 02:05:14 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1
Oct 19 11:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1025
Oct 19 22:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=2049

Oct 20 01:05:16 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1
Oct 20 13:05:16 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=1025
Oct 21 04:05:15 kernel: ERR: rdpa_cpu_tx_port_enet_lan#213: rdpa_cpu_tx_port_enet_lan failed. rdd_rc=120 tx_rdd_error_count=2049

 

[aex.perez]

Confused

Had lots of headaches with 3004.388.10, reverting back to beta1 to stabilize with just about every service failing and restarting. Then having to get on the develop track of the scribe add it to get logging and have my custom filters working again. Even had the Node not passing traffic with BACKUPMON failing to find the NAS, couldn't even ping the Router via SSH on the Nodes, though they could still be managed via the Router through the GUI, a reboot of each fixed that. Still with all that I was was not able to use the App, let alone the App and the GUI simultaneously and didn't risk even trying.

Then last night, after a few days of stability, I took a the risk. Downloaded the App on the iPhone and set it up and it was able to connect, login and actually report on active connections on the Router and on each Node

So, file under no risk no reward, took the next step. Tried this morning, being in the GUI and using the App at the same time. Before it wouldn't work and it would cause a cascade of failures with Router processes, firewall, logging, ACS, channel changes amongst others.

But this morning, both were working like they did under 3004.388.9.2 with the Router and Nodes remaining stable, though the log entries are different now.

Oct 21 08:43:43 Router HTTPD: [LOGIN][http][Web] success (192.168.1.99)
Oct 21 08:45:45 Router HTTPD: [LOGIN][https][APP] success (192.168.1.172)

Continues to work Not sure how or why but I'll take the WIN!

 

[Clark Griswald]

Please stay on topic, and create a separate HA thread.

 

[dbell]

Confused

Had lots of headaches with 3004.388.10, reverting back to beta1 to stabilize with just about every service failing and restarting. Then having to get on the develop track of the scribe add it to get logging and have my custom filters working again. Even had the Node not passing traffic with BACKUPMON failing to find the NAS, couldn't even ping the Router via SSH on the Nodes, though they could still be managed via the Router through the GUI, a reboot of each fixed that. Still with all that I was was not able to use the App, let alone the App and the GUI simultaneously and didn't risk even trying.

Then last night, after a few days of stability, I took a the risk. Downloaded the App on the iPhone and set it up and it was able to connect, login and actually report on active connections on the Router and on each Node

So, file under no risk no reward, took the next step. Tried this morning, being in the GUI and using the App at the same time. Before it wouldn't work and it would cause a cascade of failures with Router processes, firewall, logging, ACS, channel changes amongst others.

But this morning, both were working like they did under 3004.388.9.2 with the Router and Nodes remaining stable, though the log entries are different now.

Oct 21 08:43:43 Router HTTPD: [LOGIN][http][Web] success (192.168.1.99)
Oct 21 08:45:45 Router HTTPD: [LOGIN][https][APP] success (192.168.1.172)

Continues to work Not sure how or why but I'll take the WIN!

So somewhere between alpha 1 and beta 2 (IIRC) I did a factory reset, after seeing all the issues with mobile app, HA integration and general browser access to AX86U. That also meant I had to update admin password with new min length policy.
I have been running with 388.10 for the last 11 days with HA integration, mobile app and browser access all working fine. HA integration is using https (8443) access.

Yesterday, the mobile app started failing again - no connection on speed test page and no list of clients. Browser error "can't reach that page" after login. Rebooting the whole mesh resolves it, so this definitely seems like an issue that appears over time.

Here is the log snippet from failed logins and connection attempts after I finally managed to connect long enough to access it.

Oct 21 09:03:08 HTTPD: [LOGIN][https][Web] success (xxx.xxx.244.1)
Oct 21 09:03:08 kernel: potentially unexpected fatal signal 11.
Oct 21 09:03:08 kernel: CPU: 0 PID: 28345 Comm: httpds Tainted: P           O    4.1.52 #2
Oct 21 09:03:08 kernel: Hardware name: Broadcom-v8A (DT)
Oct 21 09:03:08 kernel: task: ffffffc03dc16100 ti: ffffffc028db8000 task.ti: ffffffc028db8000
Oct 21 09:03:08 kernel: PC is at 0xf6c0572e
Oct 21 09:03:08 kernel: LR is at 0xf6bd1858
Oct 21 09:03:08 kernel: pc : [<00000000f6c0572e>] lr : [<00000000f6bd1858>] pstate: 200f0030
Oct 21 09:03:08 kernel: sp : 00000000ffc731f8
Oct 21 09:03:08 kernel: x12: 00000000ffffffff
Oct 21 09:03:08 kernel: x11: 00000000ffc736f4 x10: 0000000000000000
Oct 21 09:03:08 kernel: x9 : 00000000f6ccb7a8 x8 : 00000000f6ccd000
Oct 21 09:03:08 kernel: x7 : 00000000f74ff4d0 x6 : 000000000000002d
Oct 21 09:03:08 kernel: x5 : 00000000000b6408 x4 : 0000000000000006
Oct 21 09:03:08 kernel: x3 : 0000000000000000 x2 : 0000000000000001
Oct 21 09:03:08 kernel: x1 : 000000000013ab48 x0 : 000000000013ab4e
Oct 21 09:03:23 watchdog: start httpd
Oct 21 09:03:23 rc_service: watchdog 1818:notify_rc start_httpd
Oct 21 09:03:23 RT-AX86U: start https:8443
Oct 21 09:03:23 RT-AX86U: start httpd:80
Oct 21 09:03:24 httpd: Succeed to init SSL certificate...8443
Oct 21 09:03:24 httpd: S:ax86u-office Server Certificate, I:RT-AX86U-E410 Root Certificate 20240101000028, 2025/9/28 ~ 2045/9/29
Oct 21 09:03:36 HTTPD: [LOGIN][https][APP] success (xxx.xxx.241.1)
Oct 21 09:09:31 HTTPD: [LOGIN][https][Web] success (xxx.xxx.244.1)
Oct 21 09:09:31 kernel: potentially unexpected fatal signal 11.
Oct 21 09:09:31 kernel: CPU: 2 PID: 11187 Comm: httpds Tainted: P           O    4.1.52 #2
Oct 21 09:09:31 kernel: Hardware name: Broadcom-v8A (DT)
Oct 21 09:09:31 kernel: task: ffffffc02bffc0c0 ti: ffffffc02a348000 task.ti: ffffffc02a348000
Oct 21 09:09:31 kernel: PC is at 0xf67c572e
Oct 21 09:09:31 kernel: LR is at 0xf6791858
Oct 21 09:09:31 kernel: pc : [<00000000f67c572e>] lr : [<00000000f6791858>] pstate: 200f0030
Oct 21 09:09:31 kernel: sp : 00000000ff7fd978
Oct 21 09:09:31 kernel: x12: 00000000ffffffff
Oct 21 09:09:31 kernel: x11: 00000000ff7fde74 x10: 0000000000000000
Oct 21 09:09:31 kernel: x9 : 00000000f688b7a8 x8 : 00000000f688d000
Oct 21 09:09:31 kernel: x7 : 00000000f70bf4d0 x6 : 000000000000002d
Oct 21 09:09:31 kernel: x5 : 00000000000b6408 x4 : 0000000000000005
Oct 21 09:09:31 kernel: x3 : 0000000000000000 x2 : 0000000000000001
Oct 21 09:09:31 kernel: x1 : 000000000013acc8 x0 : 000000000013accd
Oct 21 09:09:53 watchdog: start httpd
Oct 21 09:09:53 rc_service: watchdog 1818:notify_rc start_httpd
Oct 21 09:09:53 RT-AX86U: start https:8443
Oct 21 09:09:53 RT-AX86U: start httpd:80
Oct 21 09:09:54 httpd: Succeed to init SSL certificate...8443
Oct 21 09:09:54 httpd: S:ax86u-office Server Certificate, I:RT-AX86U-E410 Root Certificate 20240101000028, 2025/9/28 ~ 2045/9/29
Oct 21 09:10:23 HTTPD: [LOGIN][https][APP] success (xxx.xxx.241.1)
Oct 21 09:14:08 HTTPD: [LOGIN][https][Web] success (xxx.xxx.244.1)
Oct 21 09:14:08 kernel: potentially unexpected fatal signal 11.
Oct 21 09:14:08 kernel: CPU: 0 PID: 12243 Comm: httpds Tainted: P           O    4.1.52 #2
Oct 21 09:14:08 kernel: Hardware name: Broadcom-v8A (DT)
Oct 21 09:14:08 kernel: task: ffffffc03e9f2180 ti: ffffffc023810000 task.ti: ffffffc023810000
Oct 21 09:14:08 kernel: PC is at 0xf6d8d72e
Oct 21 09:14:08 kernel: LR is at 0xf6d59858
Oct 21 09:14:08 kernel: pc : [<00000000f6d8d72e>] lr : [<00000000f6d59858>] pstate: 200f0030
Oct 21 09:14:08 kernel: sp : 00000000ff927b98
Oct 21 09:14:08 kernel: x12: 00000000ffffffff
Oct 21 09:14:08 kernel: x11: 00000000ff928094 x10: 0000000000000000
Oct 21 09:14:08 kernel: x9 : 00000000f6e537a8 x8 : 00000000f6e55000
Oct 21 09:14:08 kernel: x7 : 00000000f76874d0 x6 : 000000000000002d
Oct 21 09:14:08 kernel: x5 : 00000000000b6408 x4 : 0000000000000002
Oct 21 09:14:08 kernel: x3 : 0000000000000000 x2 : 0000000000000001
Oct 21 09:14:08 kernel: x1 : 000000000013ade0 x0 : 000000000013ade2
Oct 21 09:14:23 watchdog: start httpd
Oct 21 09:14:23 rc_service: watchdog 1818:notify_rc start_httpd
Oct 21 09:14:23 RT-AX86U: start https:8443
Oct 21 09:14:23 RT-AX86U: start httpd:80
Oct 21 09:14:24 httpd: Succeed to init SSL certificate...8443
Oct 21 09:14:24 httpd: S:ax86u-office Server Certificate, I:RT-AX86U-E410 Root Certificate 20240101000028, 2025/9/28 ~ 2045/9/29
Oct 21 09:14:36 HTTPD: [LOGIN][https][APP] success (xxx.xxx.241.1)
Oct 21 09:15:12 HTTPD: [LOGIN][https][Web] success (xxx.xxx.244.1)
Oct 21 09:15:12 kernel: potentially unexpected fatal signal 11.
Oct 21 09:15:12 kernel: CPU: 0 PID: 13024 Comm: httpds Tainted: P           O    4.1.52 #2
Oct 21 09:15:12 kernel: Hardware name: Broadcom-v8A (DT)
Oct 21 09:15:12 kernel: task: ffffffc03dc461c0 ti: ffffffc02d62c000 task.ti: ffffffc02d62c000
Oct 21 09:15:12 kernel: PC is at 0xf6d0e72e
Oct 21 09:15:12 kernel: LR is at 0xf6cda858
Oct 21 09:15:12 kernel: pc : [<00000000f6d0e72e>] lr : [<00000000f6cda858>] pstate: 200f0030
Oct 21 09:15:12 kernel: sp : 00000000ff9dcea8
Oct 21 09:15:12 kernel: x12: 00000000ffffffff
Oct 21 09:15:12 kernel: x11: 00000000ff9dd3a4 x10: 0000000000000000
Oct 21 09:15:12 kernel: x9 : 00000000f6dd47a8 x8 : 00000000f6dd6000
Oct 21 09:15:12 kernel: x7 : 00000000f76084d0 x6 : 000000000000002d
Oct 21 09:15:12 kernel: x5 : 00000000000b6408 x4 : 0000000000000002
Oct 21 09:15:12 kernel: x3 : 0000000000000000 x2 : 0000000000000001
Oct 21 09:15:12 kernel: x1 : 000000000013ae20 x0 : 000000000013ae22
Oct 21 09:15:23 watchdog: start httpd
Oct 21 09:15:23 rc_service: watchdog 1818:notify_rc start_httpd
Oct 21 09:15:23 RT-AX86U: start https:8443
Oct 21 09:15:23 RT-AX86U: start httpd:80
Oct 21 09:15:24 httpd: Succeed to init SSL certificate...8443
Oct 21 09:15:24 httpd: S:ax86u-office Server Certificate, I:RT-AX86U-E410 Root Certificate 20240101000028, 2025/9/28 ~ 2045/9/29
Oct 21 09:15:24 HTTPD: [LOGIN][https][Web] success (xxx.xxx.244.1)

 

[jksmurf]

Please stay on topic, and create a separate HA thread.

Could you please clarify your concern here, as to divergence from the topic?

With all due respect, if this particular FW causes an issue with any system that integrates, communicates or interconnects with it, whether that be internal or external to the Routers “OS” for want of better terminology, then surely by definition it is on topic? That it happens to be HA in this instance is irrelevant.

Granted, commenting on the pros and cons of HA or its integrations is a divergence; but in my case above I was suggesting an interim solution for those who wanted to use the new FW and avoid the issues associated with HA that came with it, not to extol the virtues of HA itself. I do not think this unreasonable, in this particular instance, but I am open to hearing your concern.