Skip to content

← All documentation

Post-install setup · Y2Reborn

Connectivity audit

Documentation published by SchulzCode/Y2Reborn.

Instructions published by the project, shown here word for word.

Connectivity audit

> **Historical record.** The dates, candidate identity, "current" claims, > next steps and permissions below belong to this recorded boundary. See > [current state](../../CURRENT_REBORN_STATE.md) for the latest physically observed result.

Shared hardware authority

IMPLEMENTED / HIGH; limited physical functions VERIFIED. The native stack has one CONSYS kernel owner for shared rails, reset, SPM domains, BTIF/DMA, STP/WMT commands, firmware and calibration. Wi-Fi is exposed through cfg80211; Bluetooth through HCI/BlueZ. Reborn is not running a second vendor hardware-control stack.

Evidence: CONSYS core, firmware, Wi-Fi integration, factory provider, calibration helper. Firmware size/SHA checks precede controller use. The factory handoff accepts an exact bounded record size through a root-only interface; source calibration is read rather than silently replaced with a generic MAC/calibration block. Sensitive runtime files are private and private memory/core-dump handling is deliberate. Keep these safeguards.

Shared recovery has serialization, error counters, bounded automatic attempts and explicit manual recovery conditions. The empty legacy Wi-Fi glResetInit/glResetUninit functions are compatibility stubs because recovery moved to the parent; they do not mean recovery is entirely absent. The vendor-derived Wi-Fi core remains a maintenance burden, and its whole command/DMA/concurrency surface was not formally verified by this review. UNKNOWN: recovery correctness under simultaneous real audio and network traffic, RF interference and controller loss.

Wi-Fi path: F18

Reborn Wifi command worker
 -> rfkill + /data/network/enabled
 -> wpa_supplicant Unix control socket + separate attached event socket
 -> nl80211/cfg80211 -> native MT6582 fullmac port -> CONSYS firmware

supplicant connection event -> wpa_cli event helper -> udhcpc
 -> address/routes/resolver configuration

The Reborn adapter has bounded scan startup/completion deadlines, bounded/deduplicated results, separate scan-event monitoring, explicit Off/Starting/scanning state, saved-network operations and input escaping. Its fake-supplicant tests exercise asynchronous progression and malformed/error responses, not merely a success return. The platform service attaches interfaces and supervises supplicant/calibration/BlueALSA. wpa-event drives DHCP. These are useful pieces to keep.

What is incomplete:

What is physically proven

CONNECTIVITY-10 records wlan0 registration, scans returning 23 then 12 BSS entries, clean off/on cycles and simultaneous Bluetooth adapter power with core functions 0x9, zero observed transport errors. It explicitly says there were no saved network blocks and that association/authentication/DHCP/DNS/transfer were untested.

A later Reborn inspection records 28 Wi-Fi scan results through the deployed older Reborn build, and identified real status/UI defects subsequently addressed in source. This is stronger than a standalone iw scan, but still not a network connection test. The current scan-UI correction report leaves manual viewing/peer tests pending.

Conclusion: PARTIAL / HIGH. Scan/adapter bring-up is physically evidenced; complete Wi-Fi operation is UNKNOWN. Required physical qualification: WPA2 join with correct/incorrect credentials, DHCP timeout, DNS lookup and bidirectional transfer, saved reconnect after reboot/AP loss, radio off/on, suspend/resume if offered, and sustained coexistence with SBC playback. No credentials need to enter public logs to prove those outcomes.

Bluetooth, pairing and reconnect: F19

Reborn BlueZ worker + pairing agent
 -> system D-Bus -> bluetoothd -> HCI -> shared CONSYS/STP/WMT transport

processed PCM -> BlueALSA ALSA PCM -> bluealsa A2DP-source encoder
 -> BlueZ transport -> HCI controller -> remote audio sink

bluetooth.rs uses ObjectManager, a DisplayYesNo agent, explicit confirmation, bounded discovery and asynchronous device operations. It rejects unsupported legacy PIN requests instead of inventing a PIN. Playback rate selects the exact device, transport direction and negotiated 44.1/48-kHz PCM; tests reject unavailable/wrong-peer/unsupported-rate objects. Bond files persist through the platform's private BlueZ storage.

The reconnect helper has a sensible single preferred audio-device policy and bounded retries. BlueZ's built-in reconnect policy is disabled to avoid two autonomous retry owners. However, the helper requires a paired Trusted sink. Reborn issues Pair/Connect/Disconnect/Remove operations but contains no Trusted property assignment/control. Pairing alone does not establish that helper precondition. A manually trusted device may work; the end-to-end UI onboarding/reconnect path is PARTIAL, not demonstrated. Confirm with a fresh bond rather than reusing an owner-configured headset.

Reborn has no MediaPlayer1/RegisterPlayer implementation or corresponding AVRCP action/metadata service. BlueZ having AVRCP code does not connect remote play/pause/next commands to AppModel. This application integration is MISSING / HIGH. It need not block a wired-only alpha, but cannot be advertised as working headset control.

Operations are tracked with timeouts and errors, but whole-bus/service restarts, peer disconnection during writes and output fallback are not qualified. Output switching uses the same playback rebuild/lifecycle mechanisms reviewed in F02, not a seamless handover. The app reads the BlueALSA PCM rate/channels/direction; its baseline S16 choice is appropriate to the current narrow SBC path, not a future proof of arbitrary codec/PCM negotiation.

Actually built Bluetooth codecs

Inspected source: Buildroot BlueALSA 4.3.1 generated config.h and build sources in out/y2linux-reborn-audio-final/buildroot/build/bluez-alsa-4.3.1; BlueZ 5.79. The service launches bluealsa -p a2dp-source. SBC is built as the mandatory codec. Optional enable macros for AAC, aptX, aptX HD, LDAC, MPEG/MP3 and mSBC are undefined. The later focused codec audit confirms the v4.3.1 executable name, advertised controller EDR features, codec/library distinctions and the proposed Auto policy; upstream v5 uses bluealsad.

CodecEnabled in inspected image build?Reborn/Y2 peer qualification
SBCYesUNKNOWN: no retained actual A2DP listening/transport run identified
AACNoNot qualified; FFmpeg AAC file decoding is unrelated
aptXNoNot qualified
aptX HDNoNot qualified
LDACNoNot qualified

Do not describe these optional codecs as “supported today” merely because upstream BlueALSA supports them. Adding them is new codec/CPU/distribution scope, not a bug fix authorized by this audit.

Actual Bluetooth evidence and target

Historical adapter power/discovery and service availability exist. The Reborn physical scan report found zero discoverable peers, not a successful pairing or audio connection. The native HCI path is therefore more than a stub, but pairing, bonding, preferred reconnect, A2DP transport, audible playback, remote controls and sustained radio coexistence remain distinct unclosed evidence items.

CURRENT: native adapters, orchestration, UI commands and shared PCM-to-BlueALSA path. TARGET: reliable narrowly specified WPA2/SBC operation with truthful link/IP/audio states, one reconnect policy, and tested recovery. GAP: peer/network proof plus trust/AVRCP integration; optional codec expansion is not on the critical path. Before claiming Bluetooth as a release feature, use at least a fresh paired headset and a second interoperability peer, test disconnect/range loss/reboot and wired switching, then run Wi-Fi traffic concurrently. This is a proposed qualification plan, not permission to activate radios or change bonds now.

Published by the SchulzCode/Y2Reborn project [1] [3]