On Sat, 2020-02-15 at 12:24 +0000, Andreas Sandberg wrote: > > Hi all, > > When writing a driver for the RDTech UM24C, I started to play around with > Sigrok's Bluetooth (RFCOMM) interface. When scanning for the device, > everything works fine. However, I ran into problems when sampling the > device. > > It seems like the connect() call that connects the Bluetooth socket to the > device sometimes fails with EBUSY. This usually happens if a connection to > the device was recently closed. I don't know if this is a general Bluetooth > issue on Linux or due to a dodgy interface in the device. Unfortunately, > this behaviour is consistently triggered when sampling the device since > Sigrok first opens a connection to the device to scan the device, closes > it, and then opens a new connection to sample the device.
This sounds like what you'd experience with regular networking, too, when sockets get closed but not properly shut down before closing. Which then keeps them dangling for unnecessary long times, before they get reaped when a timeout has expired, and the ports can get used again. Check the shutdown(2) system call's documentation for details. > I have hacked around the problem by changing sr_bt_connect_rfcomm to retry > a few times if connect returns EBUSY. I'm not sure if this is a good > solution though. That's too late, working around symptoms. > It seems like a better solution would be to reuse the > socket that is used to scan the device, but that probably requires some API > changes. That's too complicated, because you (the driver) don't know at the end of the scan whether any other activity is about to happen next, and which it might be. Could be anything, or nothing at all. There are several applications, implementations, and use cases "above" the driver API which uses the transport. > What's the prefered solution here? I'm happy to submit my patch to retry if > that is a good enough solution for now. Ideally you'd try to properly shut down the socket before closing it and losing its handle. This is totally untested, but outlines the approach that'd be most reliable: https://termbin.com/nwavc virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
