I don’t use bluetooth much so can only really offer general advice here. To get the serial bluetooth device node /dev/rfcomm* created, rfcomm first needs to be called to set up the serial subsystem. (Maybe udev was configured to automate this in the past.)
You can ignore the wine advice towards the end, but it illustrates how to use a udev rule and simple script to get /dev/rfcomm0 created. You’ll also need to create /etc/bluetooth/rfcomm.conf with the relevant configuration entries.
Do not forget add “-C” or “–compat” in “/usr/lib/systemd/system/bluetooth.service” for backward compatibility.
As annotations I’ll leave the following information:
[15:30] <jhe> I think the permissions thing is just a difference between BlueZ 4.x and 5.x
[15:31] <jhe> 5.x defaults to root-only
[15:32] <luisdigital> Someday KDE will integrate the service into your GUI.
[15:32] <jhe> it should then use the Profile D-Bus interface
[15:32] <luisdigital> For years the request was made.
[15:32] <jhe> that's basically what is considered to supersede sdptool add
[15:33] <luisdigital> Where I can find information to connect the serial port over Bluetooth using the modern way?
[15:35] <jhe> luisdigital: the D-Bus interface is documented in doc/profile-api.txt, and test/test-profile shows how to implement it in python
[15:35] <jhe> luisdigital: however this all depends on how you intend to use it. if you really need a TTY and a direct fd/socket is not acceptable then you'd still need to stick to the rfcomm tool.
[15:36] <jhe> luisdigital: reason being that you get the RFCOMM socket through a NewConnection() D-Bus call with the Profile interface. i.e. there is not associated TTY device node.
Well, every site I’ve visited seems to vary in the method used to establish a connection. I can do so (with my iPhone) using the KDE Bluetooth widget, or by ‘bluetoothctl’
[NEW] Controller 00:1E:37:B5:D4:B7 linux-bbgi.site [default]
[NEW] Device 50:EA:D6:67:38:93 Dean’s iPhone
# connect 50:EA:D6:67:38:93
Attempting to connect to 50:EA:D6:67:38:93
# info 50:EA:D6:67:38:93
Name: Dean’s iPhone
Alias: Dean’s iPhone
UUID: Vendor specific (00000000-deca-fade-deca-deafdecacafe)
UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: NAP (00001116-0000-1000-8000-00805f9b34fb)
UUID: Handsfree Audio Gateway (0000111f-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Unfortunately, DUN is not one of the services offered, so obviously I can not test this aspect.
I recall that you mentioned the DUN service is not reported via ‘sdptool’ so that is the essence of the problem. I have no idea what might have changed. Do you use it to gain dialup networking via your mobile? Or some other reason that I’m not aware of? (Many only ever tether for mobile broadband connectivity these days.)
I can’t test that, but maybe you should submit a bug report. Anyway, thanks to your opening this thread, I did test PAN connectivity with my iPhone (via bluetooth), and that works flawlessly (user controlled), so that’s a bonus. (I think I did read somewhere that NM will gain support for DUN with the bluez5 stack.)
Well, one possible workaround is to modify rfcomm to become ‘suid root’ like this
sudo chmod u+s /usr/bin/rfcomm
Now when it is executed by a regular user, it will run with root privileges (since it is root owned to begin with), but it has security implications. (The same trick is done with ‘wvdial’ by some people.)