Lesords

Summary On Armbian images based on Ubuntu 26.04 (resolute), attaching any Bluetooth controller over UART fails silently: `btattach` gets no reply from the chip, `hci0` init times out, and the UART rx counter stays at 0. WiFi on the same combo module (different bus) is unaffected. Root cause is not Armbian — it's a broken binary in Ubuntu's bluez package (5.85-4ubuntu0.2). Filing here for visibility and possible Armbian-side mitigation. Environment Armbian 26.11, Ubuntu 26.04 (resolute), bluez 5.85-4ubuntu0.2 Rockchip RK3576 (Seeed reComputer Module Dev Kit, WQ9201S WiFi/BT, H4 over /dev/ttyS4 @ 1500000) Bug is board-independent: any resolute userspace + UART BT controller Technical detail `btattach` ORs the baud constant directly into termios `c_cflag`: ti.c_cflag |= (speed | CLOCAL | CREAD); In glibc 2.42 the `Bxxxx` constants changed value (raw baud numbers instead of c_cflag enum bits). A bluez binary built against glibc 2.42 headers writes the raw number into `c_cflag`. The low 4 bits of any standard even baud are 0 → the kernel sees B0 (hangup) → deasserts RTS/DTR → controller gated silent. No parameter combination works: every standard baud is even → low nibble always 0 → always B0. strace on resolute: $ strace -f -v -e ioctl btattach -B /dev/ttyS4 -N -P h4 -S 1500000 ioctl(4, TCSETS2, {c_cflag=B0|B200<<IBSHIFT|CS8|CSTOPB|CREAD|PARENB| PARODD|CLOCAL|0x10e000, c_ospeed=0}) = 0 Same command with noble's btattach (bluez 5.72): ioctl(4, TCSETS2, {c_cflag=B1500000|CS8|CREAD|CLOCAL}) = 0 // correct Sources are byte-identical between 5.72 and 5.85 — purely a build-time glibc difference. Upstream fix BlueZ master commit 12f5eb726c6e (2026-09-03): https://github.com/bluez/bluez/commit/12f5eb726c6e Replaces the c_cflag OR with `cfsetspeed()`. Not in any release yet (5.88 will include it). Workaround (verified) Use noble's btattach binary (links only libc, runs fine on resolute): dpkg-deb -x bluez_5.72-0ubuntu5.5_arm64.deb /tmp/bz cp /tmp/bz/usr/bin/btattach /usr/local/bin/ # then: btattach -B /dev/ttyS4 -P h4 -S 1500000 Verified: adapter UP RUNNING, correct BD address, scan/pairing working, survives reboot. Question What would be the recommended approach for Armbian to handle this until Ubuntu backports the upstream fix?