1 |
On 29/05/14 06:28, Mick wrote: |
2 |
> On Wednesday 28 May 2014 20:02:29 Samuli Suominen wrote: |
3 |
>> On 28/05/14 21:42, Mick wrote: |
4 |
>>> Hmm ... am I alone in this quest? |
5 |
>> |
6 |
>> See here, http://bugs.gentoo.org/show_bug.cgi?id=505362 |
7 |
> |
8 |
> Thanks! I missed this bug when I glanced earlier. However, it does not |
9 |
> mention rfcomm is now missing, or the fact that the gentoo rc script fails to |
10 |
> initialise bluethooth and complains about rfcomm service not having |
11 |
> started/exist, or that bluetoothctl now does not work at all. Is all this |
12 |
> down to a missing udev rule? |
13 |
> |
14 |
|
15 |
No its the fact that bluez 5 has been redesigned to fit in more with the |
16 |
systemd world. |
17 |
|
18 |
it works if: |
19 |
|
20 |
remove rfcomm using rc-update |
21 |
/etc/init.d/bluetoothctl restart (get rid of any existing config) |
22 |
|
23 |
bluetoothctl |
24 |
power on |
25 |
scan on |
26 |
agent on |
27 |
default-agent |
28 |
trust [MAC ADDRESS OF CLIENT] |
29 |
pair [MAC ADDRESS OF CLIENT] |
30 |
enter PIN when requested |
31 |
wait for "Connected: no" |
32 |
exit |
33 |
|
34 |
After this you should have an rfcomm channel available to the client. I |
35 |
have the above in an expect script as bluetoothctl has no inate remote |
36 |
controllability capabilities. No separate pairing app or rfcomm init |
37 |
script needed. |
38 |
|
39 |
BillK |