i have 2 desktops and one schlepptop with new installs of rev 1604.1 lts
what i describe here was working flawless with 1404 and 1404.3 lts
a udev rule with providing a group policy for dialout is also in place
KERNEL=="rfcomm*", GROUP="dialout"
pairing a bluetooth spp serial device with bluetooth manager works
coecting the bt spp serial device with bluetooth manager works in a limited way, as does the following commandline
"sudo rfcomm coect /dev/rfcomm0 00:15:FF:F3:24:B1"
opening of the rfcomm0 serial port now will (might) only succeed under "sudo" permission level, otherwise a "couldn't open /dev/rfcomm0" will be the result (tested with cutecom and my own app using a serial port)
killing the ModemManager process and coecting again (after discoect) will allow a normal user to open the bluetooth rfcomm port sucessfully
and now the 2nd issue, which seemed to linger on and off for about 7 plus years ... it worked in rev 1404
using the discoect button at the bottom of the bluetooth manager popup dialog indicates the discoect action, BUT it did not discoect ... the port can still be opened
pushing the discoect line with the device name indicated in the 4th line doesn't do anything (not sure if it should)
any subsequent coect action with the bluetooth manager to coect to the same device will now iterate through the rfcomm0 ... rfcomm7 and more port names, since the device was not really discoected
the coection of the newly assigned rfcommx will discoect the previously "still" coected one
not using the bluetooth manager and using the command line as indicated above will provide a command line workaround which will close the rfcommx port and prevents this port number iteration
summary :
don't use bluetooth manager, use the "rfcomm coect xx
x ...
x" on the commandline to coect and discoect
if u can only coect with sudo permission, kill the ModemManager process and recoect and a bit praying perhaps, like always in linux ![]()
cheers !!!
برچسب:
نویسنده: استخدام کار