how to cleanly shutdown an application using HCI_CHANNEL_USER

4 messages, 4 authors, 2021-08-23 · open the first message on its own page

how to cleanly shutdown an application using HCI_CHANNEL_USER

From: Peter A. Bigot <hidden>
Date: 2021-08-17 22:07:22

I'm using an AF_BLUETOOTH socket bound with HCI_CHANNEL_USER from a
user-mode application with cap_net_admin=ep.  As expected this
requires the device be down, and brings the device up automatically.

When I close that socket and exit the application, the device appears
to remain up forever.  Which prevents me from re-starting the
application.

I tried to issue HCIDEVDOWN before closing, but that produces EBADFD
because ioctls cannot be performed with HCI_CHANNEL_RAW.

I can bring the interface down from within the application if, after
closing the socket, I wait a second or so, then create a new bound
HCI_CHANNEL_RAW socket and issue HCIDEVDOWN on it.

Is there some other way to cleanly shut down an application that used
HCI_CHANNEL_USER so that the device is returned to down state on exit?
Or is this supposed to happen automatically (I see code that suggests
it should)?

Kernel version is 5.11.0-7620-generic (System76), and I'm using go
1.16, if that's relevant.

Thanks!

Peter

Re: how to cleanly shutdown an application using HCI_CHANNEL_USER

From: Marcel Holtmann <marcel@holtmann.org>
Date: 2021-08-19 15:01:47

Hi Peter,
I'm using an AF_BLUETOOTH socket bound with HCI_CHANNEL_USER from a
user-mode application with cap_net_admin=ep.  As expected this
requires the device be down, and brings the device up automatically.

When I close that socket and exit the application, the device appears
to remain up forever.  Which prevents me from re-starting the
application.

I tried to issue HCIDEVDOWN before closing, but that produces EBADFD
because ioctls cannot be performed with HCI_CHANNEL_RAW.

I can bring the interface down from within the application if, after
closing the socket, I wait a second or so, then create a new bound
HCI_CHANNEL_RAW socket and issue HCIDEVDOWN on it.

Is there some other way to cleanly shut down an application that used
HCI_CHANNEL_USER so that the device is returned to down state on exit?
Or is this supposed to happen automatically (I see code that suggests
it should)?

Kernel version is 5.11.0-7620-generic (System76), and I'm using go
1.16, if that's relevant.
I think you found a regression. Calling close() on the HCI User Channel should bring the device back down. This used to work correctly, can you please bisect which kernel patch broke this.

Back in the days I added tools/userchan-tester, but it seems I never included enough test cases to catch this regression.

Regards

Marcel

Re: how to cleanly shutdown an application using HCI_CHANNEL_USER

From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date: 2021-08-19 17:51:34

Hi Marcel, Peter,

On Thu, Aug 19, 2021 at 8:04 AM Marcel Holtmann [off-list ref] wrote:
Hi Peter,
quoted
I'm using an AF_BLUETOOTH socket bound with HCI_CHANNEL_USER from a
user-mode application with cap_net_admin=ep.  As expected this
requires the device be down, and brings the device up automatically.

When I close that socket and exit the application, the device appears
to remain up forever.  Which prevents me from re-starting the
application.

I tried to issue HCIDEVDOWN before closing, but that produces EBADFD
because ioctls cannot be performed with HCI_CHANNEL_RAW.

I can bring the interface down from within the application if, after
closing the socket, I wait a second or so, then create a new bound
HCI_CHANNEL_RAW socket and issue HCIDEVDOWN on it.

Is there some other way to cleanly shut down an application that used
HCI_CHANNEL_USER so that the device is returned to down state on exit?
Or is this supposed to happen automatically (I see code that suggests
it should)?

Kernel version is 5.11.0-7620-generic (System76), and I'm using go
1.16, if that's relevant.
I think you found a regression. Calling close() on the HCI User Channel should bring the device back down. This used to work correctly, can you please bisect which kernel patch broke this.

Back in the days I added tools/userchan-tester, but it seems I never included enough test cases to catch this regression.

Regards

Marcel
It is worth checking if this is affected by the following fix:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=58ce6d5b271ab25fb2056f84a8e5546945eb5fc9

-- 
Luiz Augusto von Dentz

Re: how to cleanly shutdown an application using HCI_CHANNEL_USER

From: Tedd Ho-Jeong An <hidden>
Date: 2021-08-23 20:32:50

Hi Peter

On Thu, 2021-08-19 at 17:01 +0200, Marcel Holtmann wrote:
Hi Peter,
quoted
I'm using an AF_BLUETOOTH socket bound with HCI_CHANNEL_USER from a
user-mode application with cap_net_admin=ep.  As expected this
requires the device be down, and brings the device up automatically.

When I close that socket and exit the application, the device appears
to remain up forever.  Which prevents me from re-starting the
application.

I tried to issue HCIDEVDOWN before closing, but that produces EBADFD
because ioctls cannot be performed with HCI_CHANNEL_RAW.

I can bring the interface down from within the application if, after
closing the socket, I wait a second or so, then create a new bound
HCI_CHANNEL_RAW socket and issue HCIDEVDOWN on it.

Is there some other way to cleanly shut down an application that used
HCI_CHANNEL_USER so that the device is returned to down state on exit?
Or is this supposed to happen automatically (I see code that suggests
it should)?

Kernel version is 5.11.0-7620-generic (System76), and I'm using go
1.16, if that's relevant.
I think you found a regression. Calling close() on the HCI User Channel should bring the device
back down. This used to work correctly, can you please bisect which kernel patch broke this.

Back in the days I added tools/userchan-tester, but it seems I never included enough test cases to
catch this regression.

Regards

Marcel
Was bluetoothd running when you test?
If then, try to run without running the bluetooth daemon and check to see if you have a same
problem.

If you have to use the daemon, change the "AutoEnable" flag in the /etc/bluetooth/main.conf to false
and restart the bluetooth daemon. This will prevent the HCI interface from powering on after cloing
socket.

Regards,
Tedd


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help