Hi Zhengguang,
So we want to make clear that ConnMan will not support incoming WPS PIN
in the first phase, or even in future by your design?
I don't see why it would support it at any time.
OK, here we wonder how will ConnMan handle an incoming WPS PIN request?
That's not how WPS works: device A, when connecting to a WPS enabled
device B, has to follow the WPS support exposed by B. If not, it will
just fail.
A knows about which WPS method B supports, when it scans.
So in this case, ConnMan will only expose WPS PBC, thus any other device
that wants to connect to it will have to follow WPS PBC.
We suppose that ConnMan will use wpa_supplicant.conf(or something like that) to
configure how local side support wps config methods such as
virtual_push_button, virtual_display, push_button or keypad. And ConnMan will
not support keypad config method on local side to delete the keypad from the
configuration file, so that it will avoid an incoming WPS PIN request. Is our
supposition right?
No need of wpa_supplicant.conf, it should be possible for ConnMan to do
this directly from wpa_supplicant's DBus API.
You don't have to care about that.
For example, set wifi display port, type and so on.
This is wifi display specific. But some of it has to be announced through P2P
Service (like: sink/source role and what not... see wifi display specs, I am not
aware of the details.).
That you will have to do it via giving the proper IE array to
RegisterPeerService().
If we want to use WiFi Display with wpa_supplicant, we need to use wpa_cli to
update wfd subelement and then set WFD IE into air frame via commands:
wpa_cli wfd_subelem_set 0 xxxxxxxxxxx
wpa_cli set wifi_display 1
Here we want to make clear whether ConnMan will support these logic in your
design or we must make these operations through wpa_supplicant directly?
No, the "sub-elements" you are talking about is the IE array I have been
talking about, so you'll do all this through ConnMan.
And anyway, you cannot use wpa_cli when wpa_supplicant is managed by
ConnMan, for the simple reason that wpa_cli uses
the socket interface of wpa_supplicant and not the DBus one. Both should
not be set at runtime, wpa_supplicant does not run properly
if both interface are in use (huge race conditions).
Tomasz
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
