Hi,
On 15.09.2010 20:53, Johan Hedberg wrote:
I'm still not convinced that the Agent is the right place for this. The
agent is typically representing the UI whereas in most cases (like NFC)
the OOB data will be coming from below bluetoothd in the software stack
and not from above it (which is where the agent resides).
In case of NFC I guess data will be coming from some application or
perhaps a daemon which can understand data coming from lower layers,
which I guess will rather process raw data. So these data will come from
the same level as bluetoothd resides or above. This is something that
agent can communicate freely with. Also from our point of view OOB data
is used in the same way as i.e. passkey and this is what agent provides.
We don't care how it will receive such data.
Also, the
presence of OOB data isn't really agent specific. It's something that
can come and go during the lifetime of an agent
That's not a problem, agent should make use of interfaces published by
applications which can provide secure channel. NFC application is one of
examples.
Also Jakiumar gave quite good example where NFC application receives
some data which is identified as BT OOB data so it initiates pairing
with device specific agent which will provide these data.
My idea has been to add a a plugin interface through which a hardware
specific plugin could notify the core daemon about the existence of OOB
data. bluetoothd would then take care of setting the right flag when it
gets a IO capability request.
Do I understand correctly that also plugin or daemon should manage
received data? Won't it make bluetoothd store unnecessary data, i.e. for
devices we won't use anyway?
Also what in case we want to use several different secure channels?
Multiple plugins? In case of agent, we make single call and no need to
worry where the data come from. Agent is platform dependent anyway so
platform vendor can put required logic there.
This doesn't of course rule out the
possibility of having part of the work done in another process since the
plugin could simply export a service over D-Bus or talk to another D-Bus
service.
I agree, such plugin can communicate with some other daemon/application
to get data. So do agent. And in case of agent we're consistent that all
bonding related data (pin, passkey, OOB...) are handled in one place
which is an agent application.
BR,
Andrzej
--
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
