Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04

[Paolo C.]

Hi all,
I'm reporting a problem on behalf of a friend of mine.

After the upgrade he was unable to connect to his mobile via the gnome ppp application.
Log message:
--> WvDial: Internet dialer version 1.60
--> Cannot open /dev/rfcomm0: Permission denied
--> Cannot open /dev/rfcomm0: Permission denied
--> Cannot open /dev/rfcomm0: Permission denied

s -l /dev/rfcomm0
crw-rw---- 1 root root 216, 0 2009-05-06 19:17 /dev/rfcomm0

$ ls -l /etc/udev/rules.d/
totale 12
-rw-r--r-- 1 root root 761 2009-02-02 05:57 70-persistent-cd.rules
-rw-r--r-- 1 root root 558 2009-05-05 20:13 70-persistent-net.rules
-rw-r--r-- 1 root root 1398 2009-04-09 02:19 README

Manually adding:
$ sudo chown username:users /dev/rfcomm0
to rc.local "fixed" the issue.

Yes, I know that's not the proper solution but I failed to understand the udev rule.

[Scott James Remnant (Canonical) (canonical-scott)]

This has already been fixed upstream (rfcomm were not in the dialout group)

The following extra rule will fix it for you:

  KERNEL=="rfcomm*", GROUP="dialout"

[Paolo C. (paolo.ciarrocchi)]

Hi Scott,
thank you very much for the prompt answer.

Does it mean that he can simply update the box and the problem will be automatically solved?

If not, where he is supposed to add:
 KERNEL=="rfcomm*", GROUP="dialout"

Currently, the udev.d dir is populated as follow:
$ ls -l /etc/udev/rules.d/
totale 12
-rw-r--r-- 1 root root 761 2009-02-02 05:57 70-persistent-cd.rules
-rw-r--r-- 1 root root 558 2009-05-05 20:13 70-persistent-net.rules
-rw-r--r-- 1 root root 1398 2009-04-09 02:19 README

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-05-11 at 16:53 +0000, Paolo C. wrote:

> Does it mean that he can simply update the box and the problem will be
> automatically solved?
>
The fix went into karmic, so an update in six months time will
automatically solve it.

In the meantime:

> If not, where he is supposed to add:
> KERNEL=="rfcomm*", GROUP="dialout"
>
Create a file in /etc/udev/rules.d - e.g. "rfcomm.rules" and paste this
into it.

A reboot will apply the change

Scott
--
Scott James Remnant
<email address hidden>

[tz (thomas-mich)]

This also affects many, if not every serial port profile device.

In particular, GPS units no longer work for any program which uses rfcomm to create the connection.

OBD2 sensors often use bluetooth, and generic serial ports (instead of a USB-to-Serial)

The only things which might not use rfcomm are HID (mice, keyboards) and Audio devices.

This should be marked to a reasonably high priority and included in some update to Jaunty instead of waiting for Karmic.

[Scott James Remnant (Canonical) (canonical-scott)]

Agree.

Binaries have been uploaded to ubuntu-proposed with the merged fix from karmic.

Once accepted by the archive admins, please test.

[Scott James Remnant (Canonical) (canonical-scott)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 14 May 2009 09:44:33 +0100
Source: udev
Binary: udev udev-udeb libvolume-id1 libvolume-id-dev libudev0 libudev-dev
Architecture: source
Version: 141-1.2
Distribution: jaunty-proposed
Urgency: low
Maintainer: Scott James Remnant <email address hidden>
Changed-By: Scott James Remnant <email address hidden>
Description:
 libudev-dev - udev library (development files)
 libudev0 - udev library
 libvolume-id-dev - volume identification library (development files)
 libvolume-id1 - volume identification library
 udev - rule-based device node and kernel event manager
 udev-udeb - rule-based device node and kernel event manager (udeb)
Launchpad-Bugs-Fixed: 374782
Changes:
 udev (141-1.2) jaunty-proposed; urgency=low
 .
   * Add rfcomm devices to dialout group. LP: #374782.
Checksums-Sha1:
 a25b935cd32a109744c4db8a19edc7972077fdda 1123 udev_141-1.2.dsc
 237a9a749a24311fb6e510c0df9888eca07c046c 46969 udev_141-1.2.diff.gz
Checksums-Sha256:
 fbc6810a3a572bf1cfeac27ca28fd65fa654eeae6dbc0814b0d64bba73478ca2 1123 udev_141-1.2.dsc
 244a1fe17d4979ff9df5cdcf86a8b64c7713fb8c431a1d64dca63f0f4abaa966 46969 udev_141-1.2.diff.gz
Files:
 4183dbff1e38e00190f463cd4868da0d 1123 admin important udev_141-1.2.dsc
 c91e6e83439a4fc9e6c01e588f0e8c76 46969 admin important udev_141-1.2.diff.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoL2gwACgkQSnQiFMl4yK4gRQCePNGlwMCshTeIOh+5bn+gpHBa
21sAn1Br27zvbOehZ4UeRwlpJUx4u/K2
=XwBB
-----END PGP SIGNATURE-----

[Martin Pitt (pitti)]

Accepted udev into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Martin Pitt (pitti)]

Any testers? This has been stuck in -proposed for two months without feedback. Thanks!

[Ilya Almametov (ilya-almametov)]

I haven't tested it since Scott's advice worked for my Xubuntu 9.04. But now I just upgraded udev from jaunty-proposed and it works fine as well. Thank you!

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 141-1.2

---------------
udev (141-1.2) jaunty-proposed; urgency=low

  * Add rfcomm devices to dialout group. LP: #374782.

 -- Scott James Remnant <email address hidden> Thu, 14 May 2009 09:44:33 +0100

[mark bower (mjbower)]

9.04 user. I am trying to use /dev/rfcomm0 to reach to a bluetooth printer adapter (and get the permission denied msg). I read what Paolo C. did as a work around, but I am inexperienced as to what specifically to enter on cmd line? His comments are,

"Manually adding:
$ sudo chown username:users /dev/rfcomm0
to rc.local "fixed" the issue."

so i tried: sudo chown rocky /dev/rfcomm0 and that did not work (rocky is my user name)
then i tried: sudo chown rc.local /dev/rfcomm0 and that did not work, would not accept format

so seeing what I am trying to do, could you please supply specifc code lines needed. I have ordered 9.10 which I understand fixes the problem.

mark bower

[tz (thomas-mich)]

"did not work" is not a bug report.

Did /dev/rfcomm0 EXIST, i.e. your device was paired and connected via bluetooth BEFORE you tried the command(s)?

If so, what was the error message?

[mark bower (mjbower)]

the commands (hcitool, sdptool search sp <BT-200 MAC addr>, sudo l2ping <MAC addr>, ls /dev/rfcomm0, and use of bluetooth setup via the tool bar icon) all indicated communication between devices and give results without errors. the dongle clearly communicates with the BT printer adapter. the goal is to set up a virtual serial port to be able to print wirelessly simular to use of BlueSoleil which worked with the same equipment via XP. i set all the permissions to rwx on the /dev/rfcomm0 file believing that might help. the initial post in this thread indicates a work around for the problem, but fixed in 9.10?

using the Sys/Admin/Printing I set the URI to to "serial:/dev/rfcomm0". when i use "print test page" then get the error msg which says "Cannot open /dev/rfcomm0: Permission denied"

mark

[tz (thomas-mich)]

Verify /dev/rfcomm0 is rwx using ls.
Also try "cat /dev/rfcomm0" and/or "wc /dev/rfcomm0" to see if they give errors.
You might also want to try the above with "strace" preceeding the command just to see the open, and/or with "sudo"

I normally have to start "rfcomm connect 0 <btaddr>" before it goes live - there is a way to give the address in a config file and maybe do it automatically but I've always done it from the command line.

This program must automatically create /dev/rfcomm0. Simply pairing the device and doing mknod will not associate the network pipe with the device node.

[mark bower (mjbower)]

in all cases FILE = /dev/rfcomm0

after boot, ls cmd, the FILE has permissions "crw-rw---- l root root"
after sudo su & chmod 777, ls cmd, the FILE has permissions "crwxrwxrwx". at this point tried test print, but permission denied.
reboot, ls cmd, FILE reverts to original permissions, ie "crw-rw----" .

cat cmd, FILE result is permission denied.
after sudo su, cat cmd FILE, cmd prompt is lost and have to close terminal to reset.

wc cmd produces same results as cat.

i do not understand why permissions once changed do not become permanent? does the previous give us any hints as to the permission problem?

mark

[tz (thomas-mich)]

/dev/rfcomm0 is NOT a file, it is a device node. That is what the "c" in crwx... means.

When the bluetooth serial connects, rfcomm can CONNECT THE DEVICE TO THE NODE. It normally crates the file when it starts. Most things in /dev don't exist - check but I think /dev is mounted and populated by udev and other programs with nodes as the system finds devices. Including bluetooth.

does "ps ax | grep rfcomm" show an instance running?
does "lsof | grep rfcomm" show anything?

The essence of the bug is that when rfcomm creates the node, it creates it root only. If you create something named /dev/rfcomm, it won't be a link to the bluetooth serial wireless link.

[mark bower (mjbower)]

o.k., pls see results below. i am too inexperienced to glean meaning, if any? i had wondered about the "c" prefix, but could not locate meaning by googling - gave up. understand now that the rfcomm0 is not a bonefide file.

rocky@rocky-desktop:~$ ps ax | grep rfcomm
   49 ? S< 0:00 [krfcommd]
 3720 ? S 0:00 cat /dev/rfcomm0
 4405 ? S 0:00 cat /dev/rfcomm0
 4674 ? S 0:00 wc /dev/rfcomm0
16008 pts/3 R+ 0:00 grep rfcomm

rocky@rocky-desktop:~$ lsof | grep rfcomm
krfcommd 49 root cwd unknown /proc/49/cwd (readlink: Permission denied)
krfcommd 49 root rtd unknown /proc/49/root (readlink: Permission denied)
krfcommd 49 root txt unknown /proc/49/exe (readlink: Permission denied)
krfcommd 49 root NOFD /proc/49/fd (opendir: Permission denied)

mark

[tz (thomas-mich)]

sudo would show what krfcommd is pointing at.

Did the cat (did you type in both) commands or the wc return any errors or just freeze.

The manpage for mknod explains C (and B and a few other things).

[mark bower (mjbower)]

ref #16. there were no errors with either cat or wc other than permission denied. when i executed those cmds with sudo, then in both cases the terminal freezes. what does the cmd line entry look like to "show what krfcommd is pointing at"?

i looked at mknod, but did not see how the "C" there relates to the file prefix permission "C"? it is probably a little over my head anyway.

mark

[tz (thomas-mich)]

"sudo ps ax | grep rfcomm".

The comnmands wc and cat are "freezing" because they work but no data is coming over the rfcomm port.

Did you try the original fix

Create a flie with the line:
KERNEL=="rfcomm", GROUP="dialout"
in a flie like /etc/udev/rules.d/rfcomm.rules

And are you running karmic or jaunty?

[mark bower (mjbower)]

i have now added the file rfcomm.rules (contents 'KERNEL=="rfcomm", GROUP="dialout" ') to the rules.d directory. still get the permission denied msg when attempting to print a test page. your explanation of this patch was better than original which i did not understand. i am in 9.04 (jaunty). i have the 9.10 disk on order, but would hope to solve this problem more immediately - CD may not arrive for weeks.

mark

[mark bower (mjbower)]

tz, i also tried the very first code offered by Paolo C. namely i added the following line to the rc.local files located at /etc/ and /etc/init.d/:

"sudo chown usernames: users /dev/rfcomm0". i also tried changing in both rc.local files the line to "sudo chown usernames:rocky /dev/rfcomm0. still permission denied. perhaps i have not entered the lines correctly or correct syntax?

mark

[tz (thomas-mich)]

It does say the fix is in jaunty-proposed. It would probably be a backport now, but you can use Software Sources to enable "proposed" and the update program might fix it.

With the added udev rule, what is the full output line from "ls /dev/rfcomm"?

Also did you try "sudo ps ax | grep rfcomm"?

And/or "strace cat /dev/rfcomm0"

[mark bower (mjbower)]

o.k., below are all of the outputs that may help you to see what is going on? except for ls /dev/rfcomm0, i do not understand meaning of outputs. and by the way, thanks for hanging in with me to try and hit on a solution. there does not appear to be any interest in this topic by others.

mark

rocky@rocky-desktop:~$ sudo ps ax | grep rfcomm
[sudo] password for rocky:
   49 ? S< 0:00 [krfcommd]
 4507 pts/0 S+ 0:00 grep rfcomm

rocky@rocky-desktop:~$ sudo ls -l /dev/rfcomm0
crwxrwxrwx 1 root root 216, 0 2010-01-03 11:47 /dev/rfcomm0
rocky@rocky-desktop:~$

rocky@rocky-desktop:~$ sudo strace cat /dev/rfcomm0
execve("/bin/cat", ["cat", "/dev/rfcomm0"], [/* 16 vars */]) = 0
brk(0) = 0x9285000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb80ba000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=50808, ...}) = 0
mmap2(NULL, 50808, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb80ad000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320h\1\0004\0\0\0\344"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1442180, ...}) = 0
mmap2(NULL, 1451632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f4a000
mprotect(0xb80a6000, 4096, PROT_NONE) = 0
mmap2(0xb80a7000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c) = 0xb80a7000
mmap2(0xb80aa000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb80aa000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f49000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f498d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
open("/dev/urandom", O_RDONLY) = 3
read(3, "\224\357\202\344"..., 4) = 4
close(3) = 0
mprotect(0xb80a7000, 8192, PROT_READ) = 0
mprotect(0x804f000, 4096, PROT_READ) = 0
mprotect(0xb80d9000, 4096, PROT_READ) = 0
munmap(0xb80ad000, 50808) = 0
brk(0) = 0x9285000
brk(0x92a6000) = 0x92a6000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb80b9000
read(3, "# Locale name alias data base.\n# "..., 4096) = 2570
read(3, ""..., 4096) = 0
close(3) = 0
munmap(0xb80b9000, 4096) = 0
open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_IDENTIFICATION...

[tz (thomas-mich)]

Also try "rfcomm -a" (may need sudo).

Do you have the device in the /etc/bluetooth/rfcomm.conf file? If so could you include it (you can change the addersses if you are concerned). Also, try if it says "bind yes", try "bind no;" (or just use # to comment out all the active lines), reboot, then from a command line as a normal user, type:

rfcomm connect 0 <btaddr>

have another console window open, and if the above says "connected", do the ls -l /dev/rfcomm0 and see if the ownership and/or permissions have problems and/or try printing.

Part of the problem might that you are "binding" the rfcomm device - telling it to listen, and the printer at the other end is also listening. When you do the open on /dev/rfcomm0, it might try to connect or might assume there was a connection. It won't work if both are listening and neither is starting up the connection.

The rfcomm connect command above will initiate the connection to the printer.

(you may also need the -r switch on rfcomm command line for the printer to work)

[mark bower (mjbower)]

I remmed out all lines in /etc/bluetooth/ <rfcomm.conf> and ran "rfcomm -a". it returned the MAC addr, channel and "clean". the lines are 1)rfcomm0, 2)bind yes 3)device & MAC 4)channel 1 (no # parentheses of course).

rebooted computer and ran/get the following:
rocky@rocky-desktop:~$ sudo rfcomm connect 0 00:08:f4:23:28:71
Connected /dev/rfcomm0 to 00:08:F4:23:28:71 on channel 1
Press CTRL-C for hangup

in all cases, i continue to run test printer (with printer on) but msg still returns ' "Idle - Unable to open device file "/dev/rfcomm0": Permission denied'

I set the URI to serial:/dev/rfcomm0 (CUPS GUI ?) believing this to be correct to set up a virtual com port for the printer which is what BlueSoleil does. I assume that this is correct? It is my understanding that we are trying to direct the printer to "go out thru a virtual com port".

from your suggested "rfcomm connect" cmd, it would seem that /dev/rfcomm0 is by-passed since everything is remmed in rfcomm.conf?

and i tried the following with result:
rocky@rocky-desktop:~$ sudo rfcomm -r connect 0 00:08:f4:23:28:71
Can't connect RFCOMM socket: Device or resource busy

so does any of this produce possibilities? i see that BlueSoleil under XP sets up on COM port 4 if that means anything?

mark

[mark bower (mjbower)]

tz

i have solved the problem. the key is in Sys>Admin>Printing>New Printer>"Other". by selecting "Other", a URI request is made, and in it one enters "bluetooth://<MAC addr> where MAC addr is the addr of my BT-200 which is connected to the HP 4 printer parallel port. the epiphany came when i started working with Ubuntu 9.10. but on a computer with 9.04, i made the requisite URI entry and the computer easily connect to the printer. it of course seems simple and somewhat obvious now, but this is how these things nearly always go. at any rate, i am now moving completely to the linux (Ubuntu) platform save for ACAD2000 (which i still will try to get to work under WINE.

thanks again for all your time and support.