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:// 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 work
I remmed out all lines in /etc/bluetooth/ 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:
ro...@rocky-desktop:~$ sudo rfcomm connect 0 00
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
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
r
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"?
A
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. stil
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
"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
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 re
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).
--
Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04
https://bugs.launchpad.net/
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.
ro...@rocky-desktop:~$ ps ax | grep rfcomm
49 ?S< 0:00 [kr
/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
/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
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
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 " before it goes liv
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 " before it goes liv
the commands (hcitool, sdptool search sp , sudo l2ping
, 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 ser
"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?
--
Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04
https://bugs.launchpad.net/bugs/374782
You
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
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 RemnantThu, 14 May 2009 09:44:33
+0100
** Changed in: udev (Ubuntu Jaunty)
Status: Fix Committed => Fix
** Tags added: verification-done
** Tags removed: verification-needed
--
Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04
https://bugs.launchpad.net/bugs/374782
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-
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!
--
Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04
https://bugs.launchpad.net/bugs/374782
You received this bug notificati
Any testers? This has been stuck in -proposed for two months without
feedback. Thanks!
--
Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04
https://bugs.launchpad.net/bugs/374782
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
** Tags added: hw-specific
--
Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04
https://bugs.launchpad.net/bugs/374782
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.
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!
** Tags added: regression-release
** Chan
-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
Agree.
Binaries have been uploaded to ubuntu-proposed with the merged fix from
karmic.
Once accepted by the archive admins, please test.
** Also affects: udev (Ubuntu Jaunty)
Importance: Undecided
Status: New
--
Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04
https:
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
On Mon, 2009-05-11 at 16:53 +, 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:
>
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/
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"
** Changed in: udev (Ubuntu)
Status: New => Fix Released
--
Cannot open /dev/rfcomm0: Permission denied after upgrade to 9.04
ht
31 matches
Mail list logo
