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
