Firmware upload reaches 100% transfer but radio never activates/reboots on FLEX-6400 (v26.9.2)

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

What happened?

When updating firmware on a FLEX-6400 through AetherSDR's firmware update flow, the .ssdr file transfer completes cleanly — the debug log shows the file-server handshake succeeding and the transfer percentage climbing steadily from 0.00 to 1.00 (100%) with no dropped frames or timeouts. However, once the transfer reaches 100%, nothing further happens: there is no follow-up status indicating the radio is validating/applying the image, no reboot notification, and the client does not reconnect afterward. The UI appears to hang at (or silently past) the upload-progress stage with no error, no "staged/applied" confirmation, and no indication that the radio itself has restarted.

What did you expect?

Per the documented flow, after upload completion the radio should validate the firmware image, apply it, and reboot on its own, after which AetherSDR should detect the disconnect and automatically reconnect once the radio comes back up. Instead the process appears to stall silently after the upload reaches 100%, with no activation, no reboot, and no reconnect.

Steps to reproduce
Connect AetherSDR (v26.9.2) to a FLEX-6400 on the local network.
Open Radio Setup → Radio tab → Firmware Update (or use the Browse .ssdr... option to point directly at FLEX-6x00_v4.2.20.ssdr).
Confirm the upload when prompted (reboot warning dialog).
Watch the upload progress bar/log — transfer proceeds normally through 100%.
Observe that no activation/reboot message appears and the radio does not restart or the client does not reconnect afterward.
Radio model & firmware

FLEX-6400 (target firmware: FLEX-6x00 v4.2.20)

OS & version
AetherSDR: 26.9.2

aethersdr-20260911-191124.log

OS: Linux
Developer Notes

What the attached debug log shows:

TX: C329 file filename FLEX-6x00_v4.2.20.ssdr
TX: C330 file upload 386282416 update
RX: R329|0| (filename command ACK'd, no error)
RX: R330|0|42607 (upload command ACK'd, returns a file-transfer handle, "42607")
RX: S0|file server active
RX: S0|file client detected
RX: S121B5D93|file update transfer=0.00 ... transfer=1.00

The transfer climbs monotonically from 0.00 to 1.00 over ~57 seconds with consistent ~0.5–0.7s intervals between updates (no stalls, no retransmits, no error status codes). The log ends immediately after transfer=1.00 — there is no subsequent status line indicating validation, "update applied," or a reboot/disconnect event. This points to either (a) the client not listening for/handling a post-transfer completion status from the radio, or (b) the radio itself not receiving a final "commit" signal it needs to proceed to validation and reboot.

Note also the interleaved, unrelated status line S0|wan server_connected=1 radio_authenticated=1 partway through the transfer — worth confirming this isn't a SmartLink/WAN status handler momentarily stealing the connection or otherwise interfering with the firmware session's TCP stream, since the FlexRadio protocol multiplexes several status streams (S0, per-object S) over the same connection.

Likely subsystem: Per the project's documented logging categories, this falls under the aether.firmware category (firmware download, staging, upload) and secondarily aether.protocol (parsed status updates) / aether.connection (raw TX/RX framing, as seen in the attached log).

Where to look:

Whatever class owns the file upload command construction and tracks the S|file update transfer= progress callback — this is almost certainly where the update loop needs a terminal-state handler for transfer=1.00 (i.e., what happens after the last progress tick — is there a follow-up "apply"/"reboot" command that needs to be sent, or a final status code (S|file update ...) the client should be waiting for but isn't parsing?).
The disconnect/reconnect logic that's supposed to fire when the radio reboots post-update — confirm it's actually subscribed to fire off of a firmware-specific completion event, and not just the generic "radio unexpectedly disconnected" path (which may be suppressed or unhandled at this stage of the workflow, e.g. if the UI treats an in-progress firmware update as a reason to ignore disconnects).
Whether the client is expected to explicitly send a "reboot" or "commit" command once transfer=1.00 is observed, versus assuming the radio does this autonomously — if the former, that command may simply be missing or failing silently.

Diagnostic data to request/capture:

Enable aether.firmware, aether.protocol, and aether.connection logging categories (Help → Support → Logging) and reproduce, capturing the full aethersdr.log from before the upload starts through at least 2 minutes past transfer=1.00. -> attached log
Have the reporter check whether the radio's front-panel/LED behavior changes at all after 100% (does it show any indication of validating firmware, or does it simply sit idle as if nothing happened?). -> remains purple

What did you expect?

firmware update to commit after uploading, with the device then rebooting

Steps to reproduce

-Connect to the Radio
-Select the latest firmware
-Upload the firmware

AetherSDR version

26.9.2

Radio model & firmware

Flex-6400 - v4.1.5.39794

Operating system

Linux

OS version and hardware

Arch Linux, Qt: 6.8.3