>I find your patch actually highly complicated. So I tried to capture
>your intend the in the attached patch (only compiled test) and it would
>be good if you can try that.
Marcel, your fix is mode delicate compared to original and has same functionality.
There's small problem with both yours & Rons - there's no error handling for case when other device will never ACK's unsniff - you pretty much DOS session if there's no reply. No real HS will do that but it may present security flaw. I do not know how severe is that
I attached original conversation when we 1st time seen the problem.
Oleg.
-----Original Message-----
From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth-owner@xxxxxxxxxxxxxxx] On Behalf Of Marcel Holtmann
Sent: Monday, July 12, 2010 5:08 PM
To: Ron Shaffer
Cc: linux-bluetooth@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 3/3] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
Hi Ron,
> Certain headsets such as the Motorola H350 will reject SCO and eSCO
> connection requests while the ACL is transitioning from sniff mode
> to active mode. Add synchronization so that SCO and eSCO connection
> requests will wait until the ACL has fully transitioned to active mode.
I find your patch actually highly complicated. So I tried to capture
your intend the in the attached patch (only compiled test) and it would
be good if you can try that.
So in general it makes no difference which mode we are in. If a mode
change is pending, then we have to delay the SCO setup. And once we are
done we the mode change we just setup the SCO link. So in theory that
should be enough. Not sure if that is true. I could have overlooked
something since I don't really have tested the patch at all ;)
Regards
Marcel
--- Begin Message ---
Nick, finally we understand what's wrong with HS830 (I think I called it 850 before:)
It won't accept eSCO(or SCO for that matter, packet types do not apply in this problem) until it ack's unsniff requests - dumb but reality.
This involved a bit more logic after doing:
+ acl->power_save = 1;
+ hci_conn_enter_active_mode(acl);
+
in
http://git.kernel.org/?p=linux/kernel/git/holtmann/bluetooth-2.6.git;a=blobdiff;f=net/bluetooth/hci_conn.c;h=b10e3cdb08f87358ca64d0db8cf83c27f5ad624a;hp=b7c4224f4e7dee01288dd31f4581f7a8821c7a21;hb=c390216b3e868b16d8154939f4b6f8c16dbd9a9f;hpb=88d1a0cf659438a66135661538ae332b23f8635a
you actually need to wait for ack for it before doing hci_setup_sync. Ron extending kernel do to that and we'll mail you patch.
But honestly I think this sort of change should live in userland. Problem is that you do not have libbuetooth up in Java to issue unsniff request and wait for ack for it. Maybe having raw hci going up from java? I do not know - have you thought about this?
Oleg.
-----Original Message-----
From: Nick Pelly [mailto:npelly@xxxxxxxxxx]
Sent: Tuesday, March 16, 2010 4:45 PM
To: Shaffer, Ron
Cc: Perelet, Oleg
Subject: Re: mot hs850
On Tue, Mar 16, 2010 at 2:35 PM, Shaffer, Ron <rshaffer@xxxxxxxxxxx> wrote:
> Hey Nick:
>
>> -----Original Message-----
>> From: Nick Pelly [mailto:npelly@xxxxxxxxxx]
>> Sent: Tuesday, March 16, 2010 4:19 PM
>> To: Perelet, Oleg
>> Cc: Shaffer, Ron
>> Subject: Re: mot hs850
>>
>> I haven't tested with that one....what happens?
>
> The issue the we've run into is an eSCO negotiation problem with mot h350.
> It fails to make eSCO or SCO connection after adding in the patch below to
> handle the slow eSCO negotiation when in sniff.
>
> In particular, we request eSCO with 3-EV5, the headset says no let's do 2-EV3,
> then we say how about 3-EV3, and the headset says go pound sand.
>
> It really looks like a headset issue that we're trying to work around.
>
> I took a look at Bluetooth: Allow SCO/eSCO packet type selection for outgoing
> SCO connections,
> http://android.git.kernel.org/?p=kernel/common.git;a=commit;
> h=3b077241e02041b1f03fee912896b8de1d7ac096
>
> and I was wondering if the above behavior is what you saw prior to this patch.
The packet type selection patch was motivated by other headsets, but
can probably be used to resolve this issue as well. I think if you
experiment with disabling 3-EV3 and maybe 3-EV5 packet types with this
headset we might find packets that work. Please let me know if you
find the right packet mask so we can roll it in. With Froyo we are
introducing a config file to set packet type masks with known bad
headsets
I don't want to revert the exit sniff mode patch - it fixes a lot of
slow SCO problems and makes sense.
Nick
--- End Message ---
