BE14000/BT8 3.0.0.6.102_58234 Update

[tfhoughton]

I have a three node BE14000 system with a BD5 satellite. The BE14000s are hardwired. I upgraded to 3.0.0.6.102_58234 when it first came out. This is an update of my recent experience. Have noticed that after a few days the primary SSID - Wi-Fi 7, 2.4, 5, 6GHz becomes unstable. Specifically, devices like Android phones that used to connect at 6GHz with no issue now only connect to the primary SSID on the BD5 - which doesn't support 6GHz and is over 60 feet away. Two BE14000s are MUCH closer! To address it I scheduled a reboot once a week. However, the problem is happening more often. Tonight, I noticed that at least one of the processors CPUs is pegged at 100%. I submitted info via Feeback.. As a test I will change the primary SSID to remove the 6GHz band to see if the problem disappears. Will keep folks posted. I also noticed some new entries in the syslog:

Oct 9 19:47:07 rc_service: cfg_server 3297:notify_rc stop_fw_check
Oct 9 19:47:08 rc_service: cfg_server 3297:notify_rc start_fw_check
Oct 9 19:47:12 rc_service: dns_dpi_check 2552:notify_rc start_dnsqd
Oct 9 19:49:27 rc_service: dns_dpi_check 2552:notify_rc stop_dnsqd
Oct 9 19:52:59 rc_service: cfg_server 3297:notify_rc stop_fw_check
Oct 9 19:53:00 rc_service: cfg_server 3297:notify_rc start_fw_check
Oct 9 19:53:04 rc_service: dns_dpi_check 2552:notify_rc start_dnsqd

Oct 9 19:53:38 hapdevent: hapdevent_proc_event(381): ra2: Disassoc c8:c9:a3:a8:d2:be
Oct 9 19:53:53 kernel: nvram_commit(): pid 2501 comm [httpds] delay(2500)
Oct 9 19:53:53 kernel: #NV# emergency_sync2
Oct 9 19:53:53 kernel: _nvram_free: 2501(httpds) nvram_idx(1 / 2)
Oct 9 19:53:53 kernel: real_nvram_commit(): done
Oct 9 19:53:53 kernel: nvram_commit(): pid 2501 comm [httpds] delay(2500)
Oct 9 19:53:53 kernel: #NV# emergency_sync2
Oct 9 19:53:53 kernel: _nvram_free: 2501(httpds) nvram_idx(0 / 2)
Oct 9 19:53:53 kernel: real_nvram_commit(): done
Oct 9 19:53:53 kernel: nvram_commit(): pid 2501 comm [httpds] delay(2500)
Oct 9 19:53:53 kernel: #NV# emergency_sync2
Oct 9 19:53:53 kernel: _nvram_free: 2501(httpds) nvram_idx(1 / 2)
Oct 9 19:53:53 kernel: real_nvram_commit(): done
Oct 9 19:53:53 kernel: nvram_commit(): pid 2501 comm [httpds] delay(2500)
Oct 9 19:53:53 kernel: #NV# emergency_sync2
Oct 9 19:53:53 kernel: _nvram_free: 2501(httpds) nvram_idx(0 / 2)
Oct 9 19:53:53 kernel: real_nvram_commit(): done
Oct 9 19:53:53 kernel: nvram_commit(): pid 2501 comm [httpds] delay(2500)
Oct 9 19:53:53 kernel: #NV# emergency_sync2
Oct 9 19:53:53 kernel: _nvram_free: 2501(httpds) nvram_idx(1 / 2)
Oct 9 19:53:53 kernel: real_nvram_commit(): done
Oct 9 19:54:13 kernel: nvram_commit(): pid 2501 comm [httpds] delay(2500)

Oct 9 20:03:41 rc_service: cfg_server 3297:notify_rc stop_fw_check
Oct 9 20:03:42 rc_service: cfg_server 3297:notify_rc start_fw_check
Oct 9 20:03:53 rc_service: cfg_server 3297:notify_rc stop_fw_check
Oct 9 20:03:54 rc_service: cfg_server 3297:notify_rc start_fw_check
Oct 9 20:03:56 rc_service: dns_dpi_check 2552:notify_rc start_dnsqd
Oct 9 20:06:05 rc_service: dns_dpi_check 2552:notify_rc stop_dnsqd
Oct 9 20:07:27 rc_service: dns_dpi_check 2552:notify_rc start_dnsqd
Oct 9 20:07:55 hapdevent: hapdevent_proc_event(347): ra2: Assoc 3c:e9:0e:c6:32:38
Oct 9 20:07:55 hapdevent: hapdevent_proc_event(381): ra2: Disassoc 3c:e9:0e:c6:32:38
Oct 9 20:13:04 kernel: nvram_commit(): pid 2501 comm [httpds] delay(2500)
Oct 9 20:13:04 kernel: #NV# emergency_sync2
Oct 9 20:13:04 kernel: _nvram_free: 2501(httpds) nvram_idx(1 / 2)
Oct 9 20:13:04 kernel: real_nvram_commit(): done
Oct 9 20:13:06 rc_service: cfg_server 3297:notify_rc restart_sendfeedback
Oct 9 20:13:06 frs_feedback: start_sendfeedback() start...
Oct 9 20:13:06 kernel: nvram_commit(): pid 23378 comm [sendfeedback] delay(2500)
Oct 9 20:13:06 btn_check: alive
Oct 9 20:13:07 btn_check: alive
Oct 9 20:13:08 btn_check: alive
Oct 9 20:13:09 btn_check: alive
Oct 9 20:13:10 btn_check: alive
Oct 9 20:13:11 btn_check: alive
Oct 9 20:13:12 btn_check: alive
Oct 9 20:13:13 btn_check: alive
Oct 9 20:13:14 btn_check: alive
Oct 9 20:13:15 btn_check: alive

[Alex52]

By any chance are you using MLO? If so, turn it off and do a system reset. Also, I found 2.4 and 5GHz both caused interference when either was run in combination with 6GHz on the same SSID.

My SSIDs are;

WIFI 6 2.4GHz

IoT 2.4GHz and 5GHz 

WIFI 7 6GHz

This was the only way I could get band utilization down and have more stable bands. Any changes, even slight that I  make, require me to do a system reset with each and every one.

I also only use the IoT SSID and 6GHz SSID for client connections.

[tfhoughton]

@Alex52 , Thanks. I don't thnk it is an MLO issue. The CPU issues and the network lag that I see on FW 58234 were not seen on FW version 56914 with the main SSID being: WiFi 7, 2.4, 5, 6GHz. If it was an MLO issue shouldn't I have seen it  on 56914? My concern is: Why is an issue that is present on the latest FW (58234) was not present on a previous FW version (56914). FW upgrades should fix issues, not cause us to change config settings and possibly disable features. If disabling the 6GHz band on the primary SSID fixes the issue, IMHO this effectively removes a feature.

More on MLO: I have MLO enabled but it is not being used. I expected I could get MLO between the BD5 and the BE14000 host. However, ASUS reported that MLO only works between homogeneous nodes (i.e., BE14000 to BE14000). When the Ethernet cable is unplugged MLO does show as opertaing on a BE14000 to BE14000 link. 

[Alex52]

I actually was using MLO on the previous firmware that introduced the new Broadcom drivers - if I didn't turn it on then, my meshed BE96U wouldn't broadcast 6GHz and was erratic. After the later firmware update, I had to turn it off as it was causing multiple problems. Until I turned it off, it made my system unusable. I also had to reverse changes MLO had made to my SSIDs before my system had any throughput stability. After turning MLO off my BE96U began broadcasting 6GHz again as it should.

[tfhoughton]

Interesting. So, you had to disable a feature (i.e., MLO) in the latest FW to restore stability in your network.