Re: [PATCH 5/8] emulator/btdev: Overwrite default feature mask when SPP is toggled

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

 



Hi,

On 09/04/2014 01:09 PM, Johan Hedberg wrote:
Hi Jakub,

On Thu, Sep 04, 2014, Tyszkowski Jakub wrote:
This looks suspicious to me. The only thing that should matter is
whether the host features bit is set on or not. That already looks
correct to me in the btdev_get_host_features() function. I.e. isn't your
problem with some piece of code higher up in the stack that's not
keeping SSP properly disabled? (since what you're now doing is not just
disabling SSP but making it look like SSP was never supported to begin
with as soon as you disable it).

I'm trying to mimic reconnecting legacy HID device (which was previously
paired with PIN) to check if security level will be raised when keyboard
subclass is being found in remotes SDP records. To get the SDP records
we need to trigger SDP search when remote connects the control channel.
But we block such incoming connection with 'security block'.

If I get the emulator code right, host and remote uses the same array of
features which is reason for this patch. When emulated remote tries to
connect l2cap on PSM other than the SDP one, it's being rejected if it
reports SSP in features.

Maybe the correct way to fix this is to make remote_features_complete() also
use btdev_get_host_features() instead of directly copying
"btdev->conn->features"? With this we wouldn't need to overwrite the
->features.

The remote_features_complete() function returns page 0 which is the
controller features. Page 1 the host features and you need the extended
features command for that.

Oh, I get it now.

The actual bug seems to have been that we
were returning the local instead of remote features when getting the
host features in remote_ext_features_complete().

Looks like I've lost the point of view by mixing up local and remote btdevs. Thanks for clearing that up.

I've pushed a fix for
it. Let me know if that was the actual problem you were having and
things now work fine for you.

This fixes the issue I had, Thank you.
I'll be sending v2.

Jakub
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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