Per the thread at
http://permalink.gmane.org/gmane.linux.bluez.kernel/11455 it appears
that I need to ensure that my B/T adapter is the master in the piconet.
How do I go about doing this with bluez 4.69?
Cheers,
b.
Brian,
My suggestion earlier about influencing connection order won't apply I
think because the esco is opened indirectly after some negotiation on
the acl connection.
You could try a different headset. I think it is unusual for it to
behave this way. I haven't played with multiple bt adapters, that
would fix it but there's the possibility for more complications.
--
Brad Midgley
Experimenting again this morning with both the mouse and the headset
connected both with the B/T adapter as master and the eSCO connection as
slave (since I can't seem to influence that), it was working fairly
stably. Every now and then all devices would just completely
disconnected and then they would all reconnect.
However this most recent disconnect of all devices resulted in the mouse
reconnecting immediately but the headset went through a dozen or two
reconnection attempts (i.e. as observed by watching the output of
hcitool con with "watch -n 0") before it finally got reconnected.
This is in contrast to where I can have a completely stable (i.e. days
on end without a single hiccup) connection with just the mouse.
This really is frustrating. ~sigh~
With all of the time I have pissed away on this, if I knew of a B/T
adapter/chipset that would absolutely work stably with multiple devices
(mouse, headset, etc.) I would just run out and buy one, but as it is, I
am on my third B/T adapter here and still nothing works stably -- as
opposed to my laptop where multiple devices seem to cohabitate nicely.
Hrm, Given that I have multiple B/T adapters here, I don't suppose I'd
have any better luck by using another B/T adapter and just assigning 1
device to each, would I?
Cheers,
b.
On 11-03-14 11:29 AM, Brad Midgley wrote:
> Brian,
Hey Brad,
> iirc, the hcitool output tells you the role of the local adapter in
> the connection. So when you see 'master' in that list, it's what you
> want. You should also be requesting master when you try hcitool.
Does the above still jive with all of this:
$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: SLAVE ACCEPT
Notice the B/T adapter's link mode is set to slave, yet...
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
In the connection with the mouse, the B/T adapter is master.
I can change it successfully:
brian@pc:~$ sudo hciconfig hci0 lm master,accept
brian@pc:~$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: ACCEPT MASTER
Which doesn't change the connection with the mouse:
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
When I connect the headset using the bluetooth-applet:
$ hcitool con
Connections:
< eSCO 00:18:6B:E5:4F:7E handle 6 state 1 lm SLAVE
< ACL 00:18:6B:E5:4F:7E handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
The connection with the headset itself has the B/T adapter as master but
this eSCO connection is slave?
Oh wait. The eSCO connection disappeared now:
$ hcitool con
Connections:
< ACL 00:18:6B:E5:4F:7E handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
Now that I play something through the headset it comes back:
Connections:
< eSCO 00:18:6B:E5:4F:7E handle 6 state 1 lm SLAVE
< ACL 00:18:6B:E5:4F:7E handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
I guess that eSCO connection is only active when there is audio sent to
the headset perhaps.
I sure wish I could get all of this to work reliably. Even if I had to
follow a recipe of manual steps -- something I have not yet been able to
figure out with any consistency.
b.
Brian,
> I wonder why it worked so well on my laptop and doesn't work so well on
> my PC?
I suspect it's because some adapters can deal with switching between
multiple piconets much more gracefully than others, but it could be
something else.
iirc, you should have accept in your link policy.
--
Brad Midgley
I mean to add before I hit send that I had an opportunity to try all of
this out on my laptop yesterday (so far all of the problems I have been
reporting here have been with my PC which has a:
Bus 002 Device 003: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub
(part of BCM2046 Bluetooth)
Having my mouse and even the LG headset (which has been the most
problematic on my PC) on my laptop worked flawlessly -- without even
having to mess with any of this master/slave stuff. I was in a
teleconference with the headset for just over an hour and was using the
mouse at the same time without a hiccup. If only my PC would work as
reliably.
The chipset in my laptop is a:
Bus 001 Device 006: ID 0a5c:217f Broadcom Corp. Bluetooth Controller
What is interesting is that I can't seem to discover much about the
state of the adapter in that machine:
$ hcitool dev
Devices:
hci0 70:F3:95:3E:92:34
$ hcitool hci0 lm
returns nothing. When I do connect the mouse using the
bluetooth-applet's Connect menu for the device:
$ hcitool hci0 lm
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
After turning on the headset:
$ hcitool hci0 lm
$ hcitool con
Connections:
> ACL 00:18:6B:E5:4F:7E handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
I wonder why it worked so well on my laptop and doesn't work so well on
my PC?
Cheers,
b.
On 11-03-15 11:25 AM, Brad Midgley wrote:
> Brian,
Hi Brad,
> You can have both master and slave connections simultaneously, just
> like you can be slave to more than one master. In both cases it means
> your adapter is in different piconets.
Ahhh. See. Shows what I know about the details of B/T. I thought one
adapter == one piconet.
> There are rules about whether devices can refuse the master/slave
> switch. It's been some time since I read this so I can't remember, but
> maybe it's the initiating device that starts out as slave and the
> remote device has to agree to a role switch.
Hrm. I guess I will have to play with that a bit.
> So you should be able to
> force the headset to cooperate, even if it's refusing role switches,
> by changing who initiates that connection in addition to a link policy
> that keeps your adapter as master.
OK. So as far as the link policy that keeps the adapter as master,
after having rebooted this machine today I found the following:
$ hcitool con
Connections:
$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: SLAVE ACCEPT
So that means that the adapter will want to be the slave in all
connections, is that right?
I should change the above slave to master as such:
$ sudo hciconfig hci0 lm master
$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: MASTER
Is that correct? Do I want to enable that "ACCEPT" also?
Once I do that, for my mouse at least, do I want to press the "Connect"
button on the mouse or use the Connect option for the mouse in the
bluetooth-applet?
b.
Brian,
You can have both master and slave connections simultaneously, just
like you can be slave to more than one master. In both cases it means
your adapter is in different piconets.
There are rules about whether devices can refuse the master/slave
switch. It's been some time since I read this so I can't remember, but
maybe it's the initiating device that starts out as slave and the
remote device has to agree to a role switch. So you should be able to
force the headset to cooperate, even if it's refusing role switches,
by changing who initiates that connection in addition to a link policy
that keeps your adapter as master.
Brad
Hrm. It seems to be a real crap shoot whether this B/T stuff is going
to work or not under Linux...
Since the mouse got disconnected (not by me, but by the B/T stack) I
decided to try to disconnect the headset and connect it again. Success,
it was connected with the adapter as MASTER:
$ hcitool con
Connections:
< ACL 00:1A:45:1B:19:89 handle 11 state 1 lm MASTER
Then I tried to connect the mouse again. Doing that resulted in the
headset getting disconnected and the mouse was connected:
$ hcitool con
Connections:
< ACL 00:1F:20:0F:30:6A handle 0 state 5 lm MASTER
And then shortly after they were both connected and both as slaves.
Double yay.
$ hcitool con
Connections:
< ACL 00:1A:45:1B:19:89 handle 12 state 1 lm MASTER
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
I guess the connection to the headset was still being negotiated because
the connection changed:
$ hcitool con
Connections:
< ACL 00:1A:45:1B:19:89 handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
But then the headset reverted so that the adapter was the slave again:
$ hcitool con
Connections:
< SCO 00:1A:45:1B:19:89 handle 1 state 1 lm SLAVE
< ACL 00:1A:45:1B:19:89 handle 12 state 1 lm SLAVE AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
And the mouse got disconnected shortly after that:
$ hcitool con
Connections:
< SCO 00:1A:45:1B:19:89 handle 1 state 1 lm SLAVE
< ACL 00:1A:45:1B:19:89 handle 12 state 1 lm SLAVE AUTH ENCRYPT
~sigh~
Am I looking for something that B/T on Linux is just not ready to
deliver yet? Namely stable co-existence of multiple devices.
b.
On 11-03-14 11:29 AM, Brad Midgley wrote:
> Brian,
Hey Brad,
> iirc, the hcitool output tells you the role of the local adapter in
> the connection. So when you see 'master' in that list, it's what you
> want. You should also be requesting master when you try hcitool.
How does this reconcile with that though:
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 12 state 1 lm MASTER
< SCO 00:1A:45:1B:19:89 handle 1 state 1 lm SLAVE
< ACL 00:1A:45:1B:19:89 handle 11 state 1 lm SLAVE AUTH ENCRYPT
If that "MASTER/SLAVE" at the end of those lines is telling me what the
disposition of the B/T adapter is, how can it be both MASTER for one
device and SLAVE for another? Is this "MASTER/SLAVE" relationship per
device and the adapter can be master for some and slave for others?
I can't seem to change the connection for 00:1A:45:1B:19:89 to be master:
$ sudo hcitool sr 00:1A:45:1B:19:89 master
Switch role request failed: Input/output error
so I am back at this place again. And device co-existence is not at all
stable again. The mouse keeps dropping out. ~sigh~
Is the "MASTER" in this at all relevant? Isn't it telling me that my
adapter should be trying to negotiate being master in all of the
connections it tries to create?
$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: MASTER
b.
On 11-03-14 11:29 AM, Brad Midgley wrote:
> Brian,
Heya Brad,
> iirc, the hcitool output tells you the role of the local adapter in
> the connection.
Really?
> So when you see 'master' in that list, it's what you
> want.
Really?
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
^^^^^^
This means that in the connection to 00:1F:20:0F:30:6A which is my
mouse, my adapter is the master? That's a strange representation.
> You should also be requesting master when you try hcitool.
Do you mean like this:
$ hcitool sr 00:02:72:1E:E0:12 master
Cheers,
b.
Brian,
iirc, the hcitool output tells you the role of the local adapter in
the connection. So when you see 'master' in that list, it's what you
want. You should also be requesting master when you try hcitool.
Brad
On 11-03-14 08:29 AM, Brian J. Murrell wrote:
>
> Having been playing an audio stream to the headset for nearly an hour,
> it seems to be co-existing with the mouse today. Currently HCI
> connections are:
>
> $ hcitool con
> Connections:
> < SCO 00:1A:45:1B:19:89 handle 1 state 1 lm SLAVE
> > ACL 00:1A:45:1B:19:89 handle 11 state 1 lm MASTER AUTH ENCRYPT
> > ACL 00:1F:20:0F:30:6A handle 12 state 1 lm MASTER
>
> Which I find interesting.
>
> I'm going to try the other headset now and see if it's just as stable
> this morning.
So, I tried the other headset, which was reported as:
$ hcitool con
Connections:
< eSCO 00:18:6B:E5:4F:7E handle 6 state 1 lm SLAVE
> ACL 00:18:6B:E5:4F:7E handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
and it was not as stable. I had periodic disconnect/reconnects of all
B/T devices.
I've disconnected the (unstable) LG headset and connected the Jabra
headset again and it seems stable again.
It's just too bad I dislike the ergonomics of the Jabra headset. It's
nowhere near as comfortable as the LG headset. The LG headset "seals"
into the ear where Jabra basically just "hangs" there using gravity to
hold itself to the ear and does not create anywhere near as good a
fit/seal to the ear. :-(
I'd entertain going and buying yet another headset, hoping to get the
stability of this Jabra with the fit of the LG, but given my 50/50
success rate here, it seems like it will be a real crapshoot getting a
headset that works stably. :-(
b.
Hi again Brad.
On 11-03-14 07:00 AM, Brian J. Murrell wrote:
>
> Any advise how to proceed, even just to set the adapter to master manually?
A little more playing here and I seem to have been able to set the
adapter to master:
$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: SLAVE ACCEPT
$ hciconfig hci0 lm MASTER
Can't set default link mode on hci0: Permission denied (13)
$ sudo hciconfig hci0 lm MASTER
$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: MASTER
Or was I?
$ sudo hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
So the mouse is still reporting it's master.
But so is the adapter:
$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: MASTER
Maybe I am misunderstanding what I am reading.
For good measure I deleted (i.e. in the GUI) the mouse and re-added it
but it still seems to be master:
$ sudo hcitool con
Connections:
< ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
Hrm. Now I've added my Jabra BT125 headset and the connections being
reported now are:
$ sudo hcitool con
Connections:
< ACL 00:1A:45:1B:19:89 handle 12 state 1 lm MASTER AUTH ENCRYPT
< ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
Everybody's master now?
Having been playing an audio stream to the headset for nearly an hour,
it seems to be co-existing with the mouse today. Currently HCI
connections are:
$ hcitool con
Connections:
< SCO 00:1A:45:1B:19:89 handle 1 state 1 lm SLAVE
> ACL 00:1A:45:1B:19:89 handle 11 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 12 state 1 lm MASTER
Which I find interesting.
I'm going to try the other headset now and see if it's just as stable
this morning.
b.
On 11-03-13 11:46 PM, Brad Midgley wrote:
> Brian,
Hi Brad,
>
>>> $ sudo hcitool sr 00:1F:20:0F:30:6A slave
>>> Switch role request failed: Input/output error
>
> Sorry I didn't look at the gui again.
No worries. TBH, a gui knob would be nice, but I'd settle for just
being able to set it manually for the time being.
> Were you able to use hcitool to switch the role to master manually?
No, I never have been able to. I was playing with it again this morning
and I can't even seem to get a list of remote devices any more. I know
there is at least one -- a mouse, which I am using right at this moment.
$ sudo hcitool scan
Scanning ...
$ sudo hcitool inq
Inquiring ...
brian@pc:/etc/shorewall/gw-new$ sudo hcitool dev
Devices:
hci0 00:02:72:1E:E0:12
$ sudo hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
I'd guess that means the mouse is at address 00:1F:20:0F:30:6A and is
master currently, yes?
$ sudo hcitool sr 00:1F:20:0F:30:6A SLAVE
Switch role request failed: Input/output error
$ hcitool sr 00:1F:20:0F:30:6A SLAVE
Switch role request failed: Operation not permitted
Any advise how to proceed, even just to set the adapter to master manually?
Cheers,
b.
Brian,
>> $ sudo hcitool sr 00:1F:20:0F:30:6A slave
>> Switch role request failed: Input/output error
Sorry I didn't look at the gui again.
Were you able to use hcitool to switch the role to master manually?
--
Brad Midgley
On 11-03-08 06:08 AM, Brian J. Murrell wrote:
> On 11-03-07 05:57 PM, Andrei Warkentin wrote:
>>
>> What do you get for hcitool info 00:1F:20:0F:30:6A?
>
> $ hcitool info 00:1F:20:0F:30:6A
> Requesting information ...
> BD Address: 00:1F:20:0F:30:6A
> Device Name: Bluetooth Laser Travel Mouse
> LMP Version: 2.0 (0x3) LMP Subversion: 0x229
> Manufacturer: Broadcom Corporation (15)
> Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
> <encryption> <slot offset> <timing accuracy> <role switch>
> <sniff mode> <RSSI> <power control> <enhanced iscan>
> <interlaced iscan> <interlaced pscan> <AFH cap. slave>
Was this at all helpful?
Cheers,
b.
On 11-03-07 05:57 PM, Andrei Warkentin wrote:
>
> What do you get for hcitool info 00:1F:20:0F:30:6A?
$ hcitool info 00:1F:20:0F:30:6A
Requesting information ...
BD Address: 00:1F:20:0F:30:6A
Device Name: Bluetooth Laser Travel Mouse
LMP Version: 2.0 (0x3) LMP Subversion: 0x229
Manufacturer: Broadcom Corporation (15)
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<sniff mode> <RSSI> <power control> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <AFH cap. slave>
Cheers,
b.
On Mon, Mar 7, 2011 at 3:13 PM, Brian J. Murrell <[email protected]> wrote:
> On 11-03-06 08:08 PM, Brad Midgley wrote:
>> Brian,
>
> Hi Brad,
>
>> It has been really quiet.
>
> Indeed.
>
Does that mean I really should be posting to LKML for patch RFCs? To
get more eyes, hopefully?
>> I got the latest bluez and looked through doc/ and test/ for
>> references to link mode. I think maybe mentions of L2CAP_LM_MASTER in
>> test/l2test.c might be on the right track.
>
> OK.
>
>> You could probably follow
>> that model and set the l2cap link mode to get what you want. I didn't
>> see it in any gui I could find. A patch to a gui would be ambitious
>> but would end up being the nicest user experience in the end.
>
> Agreed. ?Unfortunately, unlike quite a bit of technology, I am a total
> end-user of B/T. ?I don't even really know what the stack looks like. ?I
> guess I just have not had the bandwidth to dive in.
>
> That said, it seems odd that without a knob to give total control to the
> user, that the implicit behavior is not to make the adapter the master,
> if it can be.
>
> Understood, yes, that there might be a situation such as B/T networking
> where there are two hosts with adapters, so one would have to fall back,
> but for the more common case such as mice, headsets, etc. if the adapter
> needs to be master for them to co-exist peacefully, I wonder why that's
> not being done implicitly.
>
> Can in inquire from userspace which devices are master/slave? ?hcitool
> looks interesting but I can't seem to get it to report master/slave of
> devices or the local adapter.
>
> Ahhh. ?Wait. ?I just did (after turning the mouse on):
>
> $ hcitool con
> Connections:
> ? ? ? ?> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
>
> So it seems the mouse, which is the only remote device that's on, is master.
>
> When I try to change that I get:
>
> $ sudo hcitool sr 00:1F:20:0F:30:6A slave
> Switch role request failed: Input/output error
>
> b.
>
>
>
>
What do you get for hcitool info 00:1F:20:0F:30:6A?
Brian
> $ hcitool con
> Connections:
> ? ? ? ?> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
>
> So it seems the mouse, which is the only remote device that's on, is master.
>
> When I try to change that I get:
>
> $ sudo hcitool sr 00:1F:20:0F:30:6A slave
> Switch role request failed: Input/output error
iirc, the remote device can deny a role switch. try the situation you
want, changing to master.
I think we can work this up. We need a new checkbox in bluez-gnome's
properties/general.c I think.
--
Brad Midgley
On 11-03-06 08:08 PM, Brad Midgley wrote:
> Brian,
Hi Brad,
> It has been really quiet.
Indeed.
> I got the latest bluez and looked through doc/ and test/ for
> references to link mode. I think maybe mentions of L2CAP_LM_MASTER in
> test/l2test.c might be on the right track.
OK.
> You could probably follow
> that model and set the l2cap link mode to get what you want. I didn't
> see it in any gui I could find. A patch to a gui would be ambitious
> but would end up being the nicest user experience in the end.
Agreed. Unfortunately, unlike quite a bit of technology, I am a total
end-user of B/T. I don't even really know what the stack looks like. I
guess I just have not had the bandwidth to dive in.
That said, it seems odd that without a knob to give total control to the
user, that the implicit behavior is not to make the adapter the master,
if it can be.
Understood, yes, that there might be a situation such as B/T networking
where there are two hosts with adapters, so one would have to fall back,
but for the more common case such as mice, headsets, etc. if the adapter
needs to be master for them to co-exist peacefully, I wonder why that's
not being done implicitly.
Can in inquire from userspace which devices are master/slave? hcitool
looks interesting but I can't seem to get it to report master/slave of
devices or the local adapter.
Ahhh. Wait. I just did (after turning the mouse on):
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
So it seems the mouse, which is the only remote device that's on, is master.
When I try to change that I get:
$ sudo hcitool sr 00:1F:20:0F:30:6A slave
Switch role request failed: Input/output error
b.
Brian,
> Nobody knows? ?I was hoping this was going to be one of those simple
> questions that just about everybody knew. ?:-(
It has been really quiet.
I got the latest bluez and looked through doc/ and test/ for
references to link mode. I think maybe mentions of L2CAP_LM_MASTER in
test/l2test.c might be on the right track. You could probably follow
that model and set the l2cap link mode to get what you want. I didn't
see it in any gui I could find. A patch to a gui would be ambitious
but would end up being the nicest user experience in the end.
--
Brad Midgley
On 11-03-02 09:07 PM, Brian J. Murrell wrote:
> Per the thread at
> http://permalink.gmane.org/gmane.linux.bluez.kernel/11455 it appears
> that I need to ensure that my B/T adapter is the master in the piconet.
Nobody knows? I was hoping this was going to be one of those simple
questions that just about everybody knew. :-(
b.