Re: [PATCH 2/4] Bluetooth: Fix assuming EIR flags can result in SSP authentication

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alain,

> Starting with the 2.1 specification, it is my interpretation that it
> is not valid to support EIR but not SSP.  I understand that SSP may be
> disabled from BlueZ's point of view, but this doesn't seem to be a
> legitimate/qualifiable configuration.  Should we instead fail the
> legacy pairing if EIR was received as an invalid condition?

I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us.

You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result.

If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device.

Regards

Marcel




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux