Hi, Tomasz Thanks a lot for your quick response about it. I think we have almost achieved an agreement on the CAPI proposal, we will update the CAPI again and send you to review for the last time, if you have no different points about it, we will send it to Samsung to review. Besides, since the WiFi Display related operations will all go through ConnMan, when will you release the related interfaces so that we can begin to enable WiFi Display feature on tizen as early as possible?
Regards, Zhang Zhengguang > -----Original Message----- > From: Bursztyka, Tomasz > Sent: Tuesday, July 22, 2014 3:49 PM > To: Zhang, Zhengguang; [email protected] > Cc: [email protected]; C S BHARGAVA; [email protected]; > Laperie, Andrei; Patrik Flykt; Le Foll, Dominique; Liu, Bingwei; Zhu, Peter > J; Xu, > Martin; Yin, Yan; [email protected]; > [email protected] > Subject: Re: New CAPI Proposal for ConnMan based WiFi P2P Solution > > 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. > Understand, thanks! > >>> 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). > Got it, thanks! > Tomasz _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
