2021-08-17 22:09:38

by Peter A. Bigot

[permalink] [raw]
Subject: how to cleanly shutdown an application using HCI_CHANNEL_USER

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


2021-08-19 15:04:03

by Marcel Holtmann

[permalink] [raw]
Subject: Re: how to cleanly shutdown an application using HCI_CHANNEL_USER

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

2021-08-19 17:54:19

by Luiz Augusto von Dentz

[permalink] [raw]
Subject: Re: how to cleanly shutdown an application using HCI_CHANNEL_USER

Hi Marcel, Peter,

On Thu, Aug 19, 2021 at 8:04 AM Marcel Holtmann <[email protected]> wrote:
>
> 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

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

2021-08-23 20:34:53

by Tedd Ho-Jeong An

[permalink] [raw]
Subject: Re: how to cleanly shutdown an application using HCI_CHANNEL_USER

Hi Peter

On Thu, 2021-08-19 at 17:01 +0200, Marcel Holtmann wrote:
> 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
>

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