Bluez unable to access serial device

snapcraft
1

Hi, I’m trying to use bluetooth on RaspberryPi CM4/Ubuntu Core.

I installed bluez and have a pi-gadget installed, that provides the bt-serial slot like here:

user@hostname:~$ sudo snap interface serial-port
name:    serial-port
summary: allows accessing a specific serial port
slots:
  - pi-gadget:bt-serial

However, I can only interact with bluetooth when I install bluez in devmode, otherwise I get access denied, e.g. when trying to use hciattach:

user@hostname:~$ sudo bluez.hciattach /dev/ttyAMA0 bcm43xx
Can't open serial port: Permission denied
Can't initialize device: Permission denied

Journal: Jan 03 12:31:48 hostname audit[7313]: AVC apparmor="DENIED" operation="open" profile="snap.bluez.hciattach" name="/dev/ttyAMA0" pid=7313 comm="hciattach" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

What am I missing so that bluez explicitly has permission to access the device, also in strict confinement? Is there a way, beside adding a plug to a custom, forked version of the bluez snap?

2

I think this may indeed be an issue with the bluez snap. In fact, in order to do its job, hciattach needs to be able to access the serial device, in order to switch it to a specific mode, but the snap does not declare such plug: https://github.com/snapcore/bluez-snap/blob/877965c56afd63c18aa90459fd3c2e6e8797ac50/snapcraft.yaml#L43-L45

Can you file an issue in the bluez-snap github repo?

cc @abeato

3

Thanks for your answer - sure, done.

(I tried to reply with the link to the issue and then this and an earlier post got flagged as spam, not sure whether that’s related.)

4

On the pi you need the pi-bluetooth snap installed, that will take care to initialize the bluez stack… due to the design of the pi implementation it will not work without it…

5

Just for reference, I’ve opened a PR to bluez-snap repo: https://github.com/snapcore/bluez-snap/pull/9

6

Interesting, I didn’t realize this. Did I miss the relevant documentation somewhere?

I tried installing pi-bluetooth but I’m still encountering the same issue with confinement: Jan 08 12:25:00 hostname kernel: audit: type=1400 audit(1704716700.937:1039): apparmor="DENIED" operation="open" profile="snap.pi-bluetooth.btuart" name="/dev/ttyAMA0" pid=20795 comm="hciattach" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

7

did you connect the pi-bluetooth interfaces properly ? (see snap connections pi-bluetooth, the serial port must point to the pi gadget’s bt-serial slot)

note that you should not call the bluez.hciattach at all then, pi-bluetooth installs a service that does all initialization as needed on boot and bluez should just work then as desired via all bluetoothctl commands)

8

did you connect the pi-bluetooth interfaces properly ? (see snap connections pi-bluetooth, the serial port must point to the pi gadget’s bt-serial slot)

No, because I can’t install pi-bluetooth, sorry I didn’t make that clear. Snap post-install tries to start snap.pi-bluetooth.btuart.service, which fails - looks like the same issue that this user faced as well. Since snap isn’t actually installed, I can’t connect the interface. The line I posted before is what I see with journal -xe.

note that you should not call the bluez.hciattach at all then, pi-bluetooth installs a service that does all initialization as needed on boot and bluez should just work then as desired via all bluetoothctl commands)

Yes, I’m aware of/looking forward to that :slight_smile:

9

hmm. let me guess, you are using a custom gadget snap in your install …

https://github.com/waveform80/pi-bluetooth/pull/3

was actually supposed to fix this, but seems @waveform has not released it to all channels yet (he seems to have seen some issues with merging but these can not be in any way related to the PR at all, so i’m not sure where that stands currently)

10

Indeed, I’m using a custom gadget (and running on core20). If that PR would fix the issue I’m of course interested @waveform whether there’s an ETA for this :slight_smile:

What would be my alternatives otherwise? Apply your fix @ogra to a fork of pi-bluetooth and release that to our custom store or wait for @mborzecki1’s fix to be released to bluez (and manage serial device attach manually)?

11

Ah, if you have a brandstore just forking pi-bluetooth is indeed the easiest and what most other customers have done up to now… my PR was to avoid the requirement of having to do that fork…

1 Like
12

Hmm, could you please help me with that actually? I thought I’d just add your changes to the core20-base branch but I encountered some issues - initially it was about missing GLIBC_2.34, so I added stage-packages to the bluez part. Now I’m getting an issue regarding missing hciattach (journal: /snap/custom-pi-bluetooth/x11/bin/btuart: 32: /snap/custom-pi-bluetooth/x11/usr/bin/hciattach: not found).

I also found this issue, so I wondered whether that’s not going to work altogether. OTOH, the pi-bluetooth snap from the global store does work on my core20-based system (when installed in devmode)… I don’t know what version (code) is used in the global store but there should be a way to get that to work. Could you point me in the right direction?

(I’m posting here since I don’t think I’ll get a timely reply on the GitHub issue, I hope you don’t mind).

13

that indicates that you are building it wrong … i.e. in --destructive-mode on the wrong version of the OS …

if you switch to a core22 base, you should also update the stage-snaps entry for bluez to use a core22 based version, do not add a stage-package for bluez !!

see below for the changed stage-snaps line:

  bluez:
    plugin: nil
    stage-snaps: 
      - bluez/22/stable
    prime:
      - usr/bin/hciconfig
      - usr/bin/hcidump
      - usr/bin/hciattach
      - usr/bin/hcitool
1 Like
14

Thanks, that’s great! I didn’t realize that I could specify the channel like that. The stage-package thing was more a desperation attempt for lack of other ideas…

I see you’ve also commented on the GH issue, thanks.

1 Like