You are not logged in.
Hello!
We're dealing with an issue related to Bluez supervision_timeout value of 42 on a BLE connection. After following https://stackoverflow.com/questions/249 … s-on-linux and increasing the supervision_timeout to 200, we've found a significant decrease in BLE connection timeouts.
Here's the issue: We are creating our own Archiso ISO on the computers but cannot write to /sys/kernel/debug/bluetooth/hci0/supervision_timeout during chroot as the /sys/kernel directory does not exist at the time.
If the file does get updated when the computer starts (manually writing to file using nvim as root), the file goes back to the value of 42 on computer restart.
So I've got a couple possibilities, but unsure how to perform them.
1. During Archiso installation, make the supervision_timeout file be 200 instead of 42 (though we can't just copy a file during the chroot process as again, /sys/kernel/.../ directory isn't there at that point). Is this file something that is created from Bluez stack itself? I've been looking for documentation but can't find anything other than Bluez source files that define this number for supervision_timeout.
2. Write to the file every time the computer starts. However, I cannot perform this operation in the .xinitrc file as only the root user has access to /sys/kernel/debug/ directory.
[Edit]
I would rather not have to change the constant in the kernel as explained here https://www.spinics.net/lists/linux-blu … 68702.html if possible.
Anyone have an idea on how to make the supervision_timeout stay at 200 instead of 42?
Let me know if any more details are needed.
Thanks!
Last edited by hunter10 (2022-09-22 22:38:24)
Offline
/sys is a kernel interface directory that doesn't exist on the drive and gets reset with every reboot as it is populated by the kernel during runtime when the bluetooth kernel module/stack gets loaded.
For doing system level autostart adjustments you should leverage systemd: https://wiki.archlinux.org/title/Systemd and https://wiki.archlinux.org/title/System … unit_files
Easiest is probably doing a systemd service that runs on boot after the bluetooth service has been started, so something like
[Unit]
Description=Switching supervision timeout
Requires=bluetooth.service
After=bluetooth.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/sh -c "echo 200 > /sys/kernel/debug/bluetooth/hci0/supervision_timeout"
[Install]
WantedBy=multi-user.target
And enabling that service should trigger it to be ran whenever the bluetooth.service has started.
Last edited by V1del (2022-09-22 08:27:03)
Offline
So, following V1del's advice I can successfully update the BLE connection parameter (supervision_timeout) on startup of the computer.
I needed to change the systemd file a little bit as follows:
[Unit]
Description=Switching supervision timeout
Requires=bluetooth.service
After=bluetooth.service sys-kernel-debug.mount
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c "sleep 5; echo 200 > /sys/kernel/debug/bluetooth/hci0/supervision_timeout"
[Install]
WantedBy=multi-user.target
I found that I needed to wait for the /sys/debug/ filesystem to be mounted, so needed to add sys-kernel-debug.mount to the After declaration.
Here's where it gets a bit weird (at least to me). If I don't put a sleep or only put a sleep for 1-2 seconds, I receive:
Sep 22 21:15:05 user sh[272]: /bin/sh: line 1: /sys/kernel/debug/bluetooth/hci0/supervision_timeout: No such file or directory
And then if I put in a sleep for 3-4 seconds, I receive:
Sep 22 20:42:01 user sh[274]: /bin/sh: line 1: /sys/kernel/debug/bluetooth/hci0/supervision_timeout: Permission denied
If I go ahead and at least put the sleep 5 declaration before performing the echo, it works great.
Quick Note: If I didn't put the sys-kernel-debug.mount in the After declaration, I would always receive No such file or directory even if I declared a sleep of 10 seconds.
I feel like this may be a bit hacky - but it seems to work? I'm not sure why the sleep is necessary, however.
Offline
I considered adding some sleep in my original suggestion and it is very likely to be necessary as bluetooth might not be fully started yet when your service is invoked, so that's probably a good workaround
Offline
I considered adding some sleep in my original suggestion and it is very likely to be necessary as bluetooth might not be fully started yet when your service is invoked, so that's probably a good workaround
Ah, bluetooth not being fully started yet makes sense.
Thanks for the help!
Offline