From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 Description of problem: with a t68 phone known to work with bluez (worked on slackware - i've just upgraded to fc4). l2ping <device> works, and it has been peered and re-peered using my /etc/bluetooth/pin (via the phone menus), so there's no issues there. this is verified with hcidump, which, when i run: # rfcomm connect 0 <address> 1 Can't connect RFCOMM socket: Permission denied # ... displays these: < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:80:37:A1:B7:49 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Connect Complete (0x03) plen 11 Version-Release number of selected component (if applicable): bluez-utils-2.15-7 How reproducible: Always Steps to Reproduce: 1. restart both devices 2. delete previous peers 3. create peer via phone menus, using /etc/bluetooth/pin - this is successful 4. hcitool scan for the address 5. l2ping <address> - ok 6. hcid (dunno if this is required, just tried it in case) 7. rfcomm connect 0 <address> 1 Actual Results: Can't connect RFCOMM socket: Permission denied Expected Results: the standard 'connected. press ctrl+c to disconnect' message. Additional info: tried doing an auto relabel on SEL, tail -f /var/log/audit/audit/log shows no activity however and after disabling with setenforce there's no difference. worked on EXACT same hardware with slackware. i copied over the EXACT same config files for /etc/bluetooth after the fc4 default ones failed to work, but that also made no difference.
Please show hcidump output while you attempt the connection.
That's it. # hcidump HCI sniffer - Bluetooth packet analyzer ver 1.18 device: hci0 snap_len: 1028 filter: 0xffffffff < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:80:37:A1:B7:49 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Connect Complete (0x03) plen 11 # rfcomm connect 0 00:80:37:A1:B7:49 1 Can't connect RFCOMM socket: Permission denied
What does 'sdptool browse 00:80:37:A1:B7:49' say? Are you sure it's channel 1 you're supposed to be using? Sorry, could you repeat the attempted rfcomm connection with 'hcidump -x -t'?
Oh, and... (sorry but I have to ask): You did run hcidump in a separate window and leave it running while you attempted the 'rfcomm connect', instead of running it first, then stopping it, right?
Yep. 2 concurrent windows. # sdptool browse 00:80:37:A1:B7:49 Failed to connect to SDP server on 00:80:37:A1:B7:49: Permission denied In the other window, hcidump (still running) shows: < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:80:37:A1:B7:49 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Connect Complete (0x03) plen 11 ....... an strace for that sdptool command shows: connect(3, {sa_family=AF_BLUETOOTH, sa_data="\1\0I\267\2417\200\0\0\0\0\0\20i"}, 10) = -1 EACCES (Permission denied) close(3) = 0 fstat64(1, {st_mode=S_IFREG|0644, st_size=2195, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fba000 write(1, "Failed to connect to SDP server "..., 72) = 72 munmap(0xb7fba000, 4096) = 0 exit_group(-1) = ?
hcidump -x -t for sdptool command: # hcidump -x -t HCI sniffer - Bluetooth packet analyzer ver 1.18 device: hci0 snap_len: 1028 filter: 0xffffffff 1125073837.835382 < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:80:37:A1:B7:49 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 1125073837.841786 > HCI Event: Command Status (0x0f) plen 4 00 01 05 04 1125073841.013259 > HCI Event: Connect Complete (0x03) plen 11 18 28 00 49 B7 A1 37 80 00 01 00 hcidump -x -t for rfcomm command: # hcidump -x -t HCI sniffer - Bluetooth packet analyzer ver 1.18 device: hci0 snap_len: 1028 filter: 0xffffffff 1125073880.922692 < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:80:37:A1:B7:49 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 1125073880.929604 > HCI Event: Command Status (0x0f) plen 4 00 01 05 04 1125073884.493009 > HCI Event: Connect Complete (0x03) plen 11 18 28 00 49 B7 A1 37 80 00 01 00
Do you have 'auth' or 'encrypt' set on your hci0 device? If so, try turning them off: 'hciconfig hci0 noauth noencrypt' Failing that, try making your phone forget its pairing with the PC and recreating the pairing again.
Neither were visibly set (hciconfig hci0 showed nothing similar, anyway), I ran the command anyway and retried - still no difference. I already had someone at the system reset the phone, deleted all pairings, and re-pair using the set password *twice*. It doesn't seem to make any difference. I think this is the device I'm using. (From /proc/usb/devices) T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0db0 ProdID=1967 Rev= 2.72 C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr= 0mA I'm travelling from tomorrow for a couple of weeks so cant provide any extra info.
Hm. This works for me with similar phones -- I've used a T68 with FC3, and now use a T630 with FC4. What happens if you try initiating a connection from the phone side instead of from the PC? Try sending a file (a picture or something) from the phone to the PC. To make that work, you may need to run the gnome-obex-server panel applet, and re-pair so that the phone knows the obex push service is available.
FC4 is no longer supported. Please reopen this bug if you still have problems with recent Fedora releases.