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.
I’m using the same adapter for three different computers and the only one that does not work is the one installed openSUSE 13.1
The problem seems to be with the services, I have noticed some differences:
On openSUSE 13.1 there are some lines that say: “Service Search failed: Invalid argument” (You can see in my previous post).
The “sdptool browse local” command returns: “Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory”
It’s not clear to me what the problem is , and the bug report you linked to refers to bluez. (I don’t have that installed anyway. Maybe you don’t either.)
If I do
hcitool dev
I get the my bluetooth device reported
Devices:
hci0 00:1E:37:B5:D4:B7
With that hardware address, I can create /dev/rfcomm0 with
That’s another way, first creating the rfcomm0 file, but when I try to connect does not work.
After that command I try to connect using the computer too with my phone, result:
The “sdptool add SP” command is now working, the correct parameter to pass bluetoothd is “–compat” or “-C”
I must add that everything is working, even KDE Networkmanager has added the phone as an “PANU” red.
I want to transmit data, such as a serial port.
When I try to make the connection with the previous command or from my phone, the icon indicates a links and blutooth led flashes fast then disconnects.
The connection I want to make is known as Bluetooth DUN - Bluetooth Dial-Up
You can install on your phone a Terminal program to see if it is actually working as a serial port.
Yes, but without being familiar with your hardware, that could be due to a number of factors. For example, it might be that you need to send a PIN code first.
The connection I want to make is known as Bluetooth DUN - Bluetooth Dial-Up
You can install on your phone a Terminal program to see if it is actually working as a serial port.[/QUOTE]
I’m interested in your progress, though I’ve never had need to do this and so not at all familiar with the process.
You might try using ‘bluetoothctl’ to establish a connection:
The “sdptool add SP” command is now working, the correct parameter to pass bluetoothd is “–compat” or “-C”
I must add that everything is working, even KDE Networkmanager has added the phone as an “PANU” red.
I want to transmit data, such as a serial port.
When I try to make the connection with the previous command or from my phone, the icon indicates a links and blutooth led flashes fast then disconnects.
The connection I want to make is known as Bluetooth DUN - Bluetooth Dial-Up
You can install on your phone a Terminal program to see if it is actually working as a serial port.
I’m sure you’ll get this working, and when you do, I think it will be worthwhile writing up a ‘how to’.
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’
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
Connection successful
# info 50:EA:D6:67:38:93
Device 50:EA:D6:67:38:93
Name: Dean’s iPhone
Alias: Dean’s iPhone
Class: 0x7a020c
Icon: phone
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: yes
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)
Modalias: usb:v05ACp1297d0710
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.)
I agree, but I suspect the demand for it is low. (I’m not aware of any recent posts on the subject.) Most use wifi or usb tethering when needed I guess.
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.)
