5.3 KiB
K1 station replies: misleading ATT error and fresh failures
Scope: the two operator-started Bridge attempts on Core 8000 following the operator-reported browser cache clear. No device write, START/STOP, Wi-Fi switch, subnet scan or firmware execution was performed by this investigation.
Fresh evidence
| Attempt, UTC | K1 first advertisement | Complete scan | Connect operation | Reply |
|---|---|---|---|---|
| 19:22:25 | 1.308 s | 6.366 s | 51.399 s | ATT 4 INVALID_PDU |
| 19:23:55 | 2.208 s | 6.023 s | 7.587 s | ATT 4 INVALID_PDU |
Both attempts reached the validated GATT contract, baseline status read and one 99-byte write-with-response. Neither write was acknowledged as successful. The observed command capacity was 253 bytes. Empty passwords are rejected before this path; presence does not prove correctness. Individual connect and write durations were not recorded, so total latency is not falsely attributed entirely to the Wi-Fi operation or entirely to CoreBluetooth.
Private snapshots, operation identities and the disassembly are retained under
the ignored .runtime/k1-connect-incident-20260906/fresh-1922/ directory with
0600 files, UTC/monotonic timestamps and a SHA-256 artifact index.
Firmware-level explanation
The reviewed official FW 3.0.2 artifact is the immutable source documented in
Lab 004.
Its extracted lixel_nman executable is 323,464 bytes, SHA-256
aead745e4e0073ae99e84e851e5560161f2d560d5804f21e5268116efbb1dc42,
ELF build ID 205fb546e44667ca0e74159a7672269a81b754f5.
Bounded offline AArch64 disassembly established:
- At 0x14588 the service registers characteristic 7f01, with write callback 0x17e48 selected at 0x14598.
- Its station branch calls
wifi_connectat 0x18034 → 0x15440. The return value is retained in w28 at 0x18038 and passed as the write-result error at 0x17fc4 → 0x291a8. wifi_connectreturns 4 in its network-not-found branches: 0x16190 and 0x16a2c. Adjacent diagnostics refer explicitly to the SSID not being found.- The branch matching NetworkManager's credentials-required output returns 6 at 0x1641c. This describes an unsuccessful credential path, not proof of the exact incorrect character or how the form was populated.
Thus the device's application return codes collide with generic ATT names: 4 is displayed as INVALID_PDU and 6 as REQUEST_NOT_SUPPORTED. The existing Mission Core message discarded the reviewed device meaning. Neither changing the 99-byte layout nor switching write mode follows from these observations. The callback performs Wi-Fi work before returning, so its response is not merely an instantaneous transport acknowledgment.
This is an interpretation under the selected exact firmware profile. It is not a universal ATT error mapping, proof of the live firmware before DeviceInfo, or confirmation that the network configuration remained unchanged. The actual SSID/radio condition still needs a corrected operator-run connection test. The old screenshot displays a network name whose exact spelling was queried; this report does not assume that spelling is a typo or assume K1 can see it.
Bounded correction
wifi_failure.py owns the pure profile-scoped classification. The service uses
it only for Bridge/Direct, selected FW 3.0.2, an annotated gatt-write failure,
a dispatched/unconfirmed 99-byte write-with-response and BleakGATTProtocolError.
It retains the original exception code and raw ATT facts. Quick Connect,
baseline-read failures, other firmware and unrelated errors retain their
original diagnostics. Retry flags, mutation ledger and ambiguity remain intact.
The frontend shares the station guidance between the form and recovery panel. It offers “Указать сеть Wi-Fi заново” through the existing explicit reset and scan flow. The pending stage explains K1 Wi-Fi connection. It does not populate, store, inspect or change the password. The GATT helper, packet bytes, MQTT, physical command control and all Rerun profiles are unchanged in this increment.
Validation
- 19 focused backend cases passed: 16 classification boundary cases, two service-level reply cases and the existing ambiguous-write recovery case. They verify one submission, retained raw codes, failed/unconfirmed state and an unresolved ledger rather than promoting an error to success.
- 24 classification/diagnostic cases passed; mypy and Ruff passed.
- 775 frontend tests passed, including rendered station guidance and the explicit same-device network setup action. Architecture: 4 passed.
- Production typecheck and build passed. The replacement canonical Core was confirmed ready at 2026-09-06T19:41:10.665304+00:00.
- Browser check: the real Core 8000 Test Devices page loaded; normal and expanded sizes worked. The page was left open. No BLE action was clicked. The new error messages were covered by rendered tests, not represented as a new hardware run.
- Hardware Wi-Fi acceptance remains pending the exact target SSID and an operator-started attempt. macOS networksetup did not provide the current SSID; its output was not treated as proof that the host network is down.
Ops MISSIONCOR-3 was read through the direct MCP. Its iPhone network capture starts at IP and does not contain Bluetooth HCI; it cannot establish the meaning of this GATT callback. No Ops card was written.