Re: PTS / linkkey issue

[Marcel Holtmann <marcel@xxxxxxxxxxxx>]

Hi Johan,

> > the real problem that you are seeing here is that the disappearing of
> > the BlueZ devices and with that the oFono modem is actually fully
> > intentional. It boils all down to the no bonding pairing. The device
> > never gets marked as bonded.
> > 
> > I honestly have no idea on how to workaround this issue. My only idea is
> > that we combine the access to a RFCOMM server channel with a re-pairing
> > to upgrade this to general bonding. Problem is just that I have no idea
> > if this would fly with the GAP qualification or not. Or if we would
> > break that one then.
> 
> This whole thing looks so obviously as a PTS issue to me that I don't
> see why anyone should spend any effort on anything else than raising an
> errata for the PTS.
> 
> As far as what you're suggesting as a potential workaround it still
> wouldn't guarantee that the PTS would start giving an authentication
> requirement other than no-bonding. We can only control our own
> authentication requirement.
> 
> Furthermore, you couldn't have this as general RFCOMM server behavior
> since there are servers for which no-bonding may be desirable, like OPP,
> and clients might not be tested to handle rejecting our general bonding
> request properly if they were designed to assume they can get by with
> their initial no-bonding request.

I was considering that if pairing is allowed and security is either
medium or high, then we force a repairing if the link key is temporary.

Something like in the area of a no bonding link key is only allowed to
connect a security low service. And if pairing is not allowed and you
try to access a medium or high security service with no bonding, you
will just get rejected.

Regards

Marcel


--
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