I am trying to send and receive serial commands over bluetooth. I have installed pyBluez library. The issue is that while the rfcomm.conf exists there is no rfcomm0 in /dev/ directory. I rebooted but no change.

If I run the following I get Permission denied error.

sudo echo "This is a test" > /dev/rfcomm0

Why isn't the rfcomm added automatically to /dev after usb bluetooth module is connected? Bluetooth module is compatible and I am able to scan and find devices via command line. Bluez and bluez-utils were installed already.

2 Answers 2


Even if the bluetooth service was started, the /dev/rfcomm0 device would not just automatically appear.

At minimum, the bluetooth subsystem would need to know the address of the Bluetooth device and the channel on it, so that a particular /dev/rfcomm* device name can be bound to a particular Bluetooth device+channel combination.

You can use rfcomm bind 0 <bdaddr> [channel] to make the binding for /dev/rfcomm0. If you don't specify the channel number, channel 1 will be used by default. If your version of the rfcomm still supports the /etc/bluetooth/rfcomm.conf file and you have the address and channel information for /dev/rfcomm0 written to it, then you can omit the address and channel information from the command - but you still need to use the command to make the binding.

Newer versions of BlueZ tools no longer seem to document the /etc/bluetooth/rfcomm.conf file. It might be that you'll have to always use the full form of the rfcomm bind command to set up your bindings. You might want to add these commands to /etc/rc.local or some custom start-up script, to make them execute automatically at boot time, as the associations won't persist through a reboot.

It seems that the last major rebuild of BlueZ internals cost us some of the RFCOMM-related features, like the /etc/bluetooth/rfcomm.conf file. But at least the rfcomm command is still available and can do the job.


Why isn't this done automatically? First, the bluetooth service needs to start up a daemon and if that isn't in an init listing, you have to go into terminal and start it manually until you reconfigure the init listing to include it.

The reason for this is to allow you to test your configuration before you commit to making it all automatic on the computer. The reasoning behind this is based on Unix's concepts of how an OS should work, how users and groups are assigned rights to communications, and such.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .