Fair point, and I should've been clearer about which parts were inference. The two release note entries share a workaround, not a signature. The AP-725 entry describes both CPUs hanging for 45 seconds, and the AP-735 entry describes a WDO ASSERTED crash under a specific SSID security mix. Neither one says BUGSoftLockup in the wl scheduler, so matching them to these logs is my read, not a documented cause.
Where I'd still stand: FTM Responder off is cheap, reversible and isolates the one variable both entries share, so it's a good first diagnostic step while TAC works the real signature. If FTM was never enabled on these SSIDs, that rules both entries out and saves everyone a week.
For the original poster, it'd help to add client counts at crash time, the SSID security types in play, and whether FTM is on at all. Those three facts decide whether the known issues are even in scope, and TAC will ask for them anyway.
------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog:
www.networkfieldnotes.com- - -
------------------------------
Original Message:
Sent: Sep 22, 2026 12:31 PM
From: JS-d3d5bc
Subject: AP735 & AP725 reboots unexpectedly (AOS 10.8.0, 10.8.1)
Opening a TAC case is appropriate, and disabling FTM Responder on all SSID profiles is a reasonable mitigation to test.
However, the two release-note items cited do not establish the cause here. The AP-725 item depends on FTM and high client counts, while the AP-735 item documents a different WDO ASSERTED signature and specific deployment conditions. None of those conditions were provided in the original post.
The posted logs show wireless scheduler soft lockups, but that only identifies where the AP got stuck, not why. Upgrading may be sensible, but 10.8.1.0 is already affected in this deployment.
I would present FTM as a diagnostic workaround, not a confirmed fix, and let TAC correlate each AP model, build, configuration, and crash signature. Similar symptoms are not sufficient evidence to declare two issues equivalent.
@DB86, please distinguish correlation from causation and label inference as inference; similar symptoms do not establish a shared root cause.
Original Message:
Sent: Sep 22, 2026 11:01 AM
From: DB86
Subject: AP735 & AP725 reboots unexpectedly (AOS 10.8.0, 10.8.1)
Open a TAC case, but there's a config change worth making before you do. Every lockup string you pasted lands in the radio driver's scheduler tasks (wl0-scheduler, wl1-scheduler), and the 10.8 release notes carry two known issues that fit. The AOS 10.8.0.x known issues list the AP-725 hanging both CPUs and rebooting with FTM enabled, worst once you're past roughly 150 clients on the AP. The AOS 10.8.1.0 known issues list AP-735 reboots in dense sites running several SSIDs with mixed security types. Both entries give the same workaround: turn off FTM Responder on every SSID profile.
So disable FTM Responder on all your SSIDs (Advanced settings on the WLAN profile), bring the 725s up to the same 10.8.1.x build as the 735s, and watch the reboot reason for a week. If they still soft lock, open the case with the three PC strings you already have; that's exactly what TAC needs to match a defect.
------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com
- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------