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?
 

 

Edited October 13Oct 13 by Lesords

Should be reported...
 

Why we're fine: our image attaches the Bluetooth chip with hciattach, not btattach. hciattach sets the speed the proper way, so the glibc change doesn't touch it. Nothing in our build calls btattach, and Bluetooth works on both boards. I've added a rule to my notes: never switch a 26.04 image to btattach without that fix.

What I'd tell Armbian, if you want to reply:
 

The proper route is an Ubuntu bug. It's a six-line, already-upstream fix in a package Ubuntu updates often, so a stable-update request on Launchpad is the fix for everyone. The poster should file it, with the forum post as evidence.

Boards with a Broadcom or Realtek chip can switch to hciattach meanwhile. It has drivers for those and isn't affected. Our RK3588 boards do exactly that.

The noble-binary workaround is fine short term, but it's an old 5.72 build and will be lost on the next bluez update unless it lives in /usr/local, as the poster did.

GL