False negative checking for SSP support

False negative checking for SSP support

[Bastien Nocera]

Heya,

I'm slowly adding SSP 2.1 support to gnome-bluetooth. For that, I got a
laptop running Fedora 11, with a Bluetooth 2.1 dongle, in addition to
the one in the machine I'm trying to pair from.

Is there any reason why the other machine shows up as not supporting
SSP, when it actually does?

We already handle that case in the wizard, but it would be nicer if it
did detect it.

Cheers

Re: False negative checking for SSP support

[Marcel Holtmann]

Hi Bastien,

> I'm slowly adding SSP 2.1 support to gnome-bluetooth. For that, I got a
> laptop running Fedora 11, with a Bluetooth 2.1 dongle, in addition to
> the one in the machine I'm trying to pair from.
> 
> Is there any reason why the other machine shows up as not supporting
> SSP, when it actually does?
> 
> We already handle that case in the wizard, but it would be nicer if it
> did detect it.

it could be an older kernel or some other detail. Did you check with
hciconfig hci0 sspmode that it is enabled on both sides? You can
manually disable it (actually bluetoothd has to manually enable it).

We might also have a bug in LegacyPairing property. Could be that it is
not working correctly. Can you post dumps and further details.

Regards

Marcel

Re: False negative checking for SSP support

[Johan Hedberg]

Hi Bastien,

On Sat, Jun 13, 2009, Bastien Nocera wrote:
> I'm slowly adding SSP 2.1 support to gnome-bluetooth. For that, I got a
> laptop running Fedora 11, with a Bluetooth 2.1 dongle, in addition to
> the one in the machine I'm trying to pair from.
> 
> Is there any reason why the other machine shows up as not supporting
> SSP, when it actually does?

Do both of the machines support 2.1? The LegacyPairing property tells you
whether SSP is likely to be triggered or not when you try to pair. It
doesn't tell you whether other device supports SSP or not e.g. if your
local adapter is pre-2.1 (but if your local adapter is 2.1 capable the
property should be a good indicator of SSP support).

In theory it is possible to get a false positive for LegacyPairing if the
other device is 2.1 but for some reason has extended inquiry response
disabled (iirc the spec mandates EIR if SSP is enabled). However, if both
sides have bluez and 2.1 HW then both EIR and SSP should automatically be
get enabled by bluetoothd. If that's not happening we may have a bug
somewhere (which I haven't seen with any of my 2.1 adapters).

Johan

Re: False negative checking for SSP support

[Bastien Nocera]

On Sat, 2009-06-13 at 21:36 +0200, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > I'm slowly adding SSP 2.1 support to gnome-bluetooth. For that, I got a
> > laptop running Fedora 11, with a Bluetooth 2.1 dongle, in addition to
> > the one in the machine I'm trying to pair from.
> > 
> > Is there any reason why the other machine shows up as not supporting
> > SSP, when it actually does?
> > 
> > We already handle that case in the wizard, but it would be nicer if it
> > did detect it.
> 
> it could be an older kernel or some other detail. Did you check with
> hciconfig hci0 sspmode that it is enabled on both sides? You can
> manually disable it (actually bluetoothd has to manually enable it).

SSP pairing works, between both machines, so I don't think that's the
problem (though the device creation never seems to finish).

> We might also have a bug in LegacyPairing property. Could be that it is
> not working correctly. Can you post dumps and further details.

It correctly detects a headset as being SSP. What kind of dumps do you
want? Just a dump on the computer that's initiating the pairing, from
the discovery process?

I'll update my bluez first on both machines, and test again.

Cheers

Re: False negative checking for SSP support

[Marcel Holtmann]

Hi Johan,

> > I'm slowly adding SSP 2.1 support to gnome-bluetooth. For that, I got a
> > laptop running Fedora 11, with a Bluetooth 2.1 dongle, in addition to
> > the one in the machine I'm trying to pair from.
> > 
> > Is there any reason why the other machine shows up as not supporting
> > SSP, when it actually does?
> 
> Do both of the machines support 2.1? The LegacyPairing property tells you
> whether SSP is likely to be triggered or not when you try to pair. It
> doesn't tell you whether other device supports SSP or not e.g. if your
> local adapter is pre-2.1 (but if your local adapter is 2.1 capable the
> property should be a good indicator of SSP support).
> 
> In theory it is possible to get a false positive for LegacyPairing if the
> other device is 2.1 but for some reason has extended inquiry response
> disabled (iirc the spec mandates EIR if SSP is enabled). However, if both
> sides have bluez and 2.1 HW then both EIR and SSP should automatically be
> get enabled by bluetoothd. If that's not happening we may have a bug
> somewhere (which I haven't seen with any of my 2.1 adapters).

it is actually the other way around. You can only use EIR if you enable
SSP. However you can have SSP without EIR.

Regards

Marcel

Re: False negative checking for SSP support

[Bastien Nocera]

On Sat, 2009-06-13 at 22:43 +0300, Johan Hedberg wrote:
> Hi Bastien,
> 
> On Sat, Jun 13, 2009, Bastien Nocera wrote:
> > I'm slowly adding SSP 2.1 support to gnome-bluetooth. For that, I got a
> > laptop running Fedora 11, with a Bluetooth 2.1 dongle, in addition to
> > the one in the machine I'm trying to pair from.
> > 
> > Is there any reason why the other machine shows up as not supporting
> > SSP, when it actually does?
> 
> Do both of the machines support 2.1? The LegacyPairing property tells you
> whether SSP is likely to be triggered or not when you try to pair. It
> doesn't tell you whether other device supports SSP or not e.g. if your
> local adapter is pre-2.1 (but if your local adapter is 2.1 capable the
> property should be a good indicator of SSP support).
> 
> In theory it is possible to get a false positive for LegacyPairing if the
> other device is 2.1 but for some reason has extended inquiry response
> disabled (iirc the spec mandates EIR if SSP is enabled). However, if both
> sides have bluez and 2.1 HW then both EIR and SSP should automatically be
> get enabled by bluetoothd. If that's not happening we may have a bug
> somewhere (which I haven't seen with any of my 2.1 adapters).

Both machines were running F-11, with the same kernel and versions of
bluez, and the same Belkin BT 2.1 adapter that has SSP working with
another 2.1 device.

The problem seems to have been fixed by me upgrading to bluez 4.40.
Either that or my tests weren't properly done.

In any cases, I'll know for next time.

Cheers