[Dev] New CAPI Proposal for ConnMan based WiFi P2P Solution

Zhang, Zhengguang zhengguang.zhang at intel.com
Tue Jul 22 06:13:49 GMT 2014


Hi, Tomasz
Please check my comments below, thanks!

> -----Original Message-----
> From: Bursztyka, Tomasz
> Sent: Monday, July 21, 2014 7:31 PM
> To: Zhang, Zhengguang; Dev at lists.tizen.org
> Cc: steve.jun at samsung.com; C S BHARGAVA; taesub.kim at samsung.com;
> Laperie, Andrei; Patrik Flykt; Le Foll, Dominique; Liu, Bingwei; Zhu, Peter J; Xu,
> Martin; Yin, Yan; guoqiang.liu at archermind.com;
> chengyi1.zhao at archermind.com
> Subject: Re: New CAPI Proposal for ConnMan based WiFi P2P Solution
> 
> Hi,
> 
> >> I think it will somehow yes. Martin and I had already discussed about
> >> it but most probably through 1 string or something like that.
> >>
> > So we can confirm that ConnMan will support it, right?
> 
> Yes. Not sure when, since there is still much work on primary features.
> And don't forget: connman will tell you about peer's device type, but you won't
> be able to set the local device type.
> This will have to be configured differently (either /etc/connman/main.conf or
> directly via wpa_supplicant if possible) About getting the local device type, I am
> not yet sure what to do with it or not. Your api can propose it, but not sure
> connman will provide it. (your lib could just read /etc/connman/main.conf
> etc...). Will see that later.
> 
OK, since it will be supported anyway, we will propose the API for it.

> >>
> >> ConnMan, This enum is used when an incoming P2P connection request
> >> arrives whose WPS method is PIN_DISPLAY. The information can support
> >> the application to choose the proper handler function. for example:
> >> if it's PIN_KEYPAD it will display a text input to receive user's
> >> input. if it is PIN_DISPLAY, it will display a pin text.
> >>
> >> ConnMan supports WPS PIN only in outgoing connection. For incoming ones:
> >> only WPS PBC is supported.
> >> It's far easier for all: either you "accept" the incoming connection
> >> (and thus run the WPS PBC underneath) or you reject it.
> >> So previous comment still applies.
> >>
> > We still feel confusing about it, do you mean that ConnMan will only support
> outgoing WPS PIN, but it won't support incoming WPS PIN?
> 
> Yes.
> 
> > If it won't support incoming WPS PIN, it seems not make sense, for example,
> there are 2 devices with ConnMan running, one device can't setup connection
> with the other by WPS PIN?
> 
> Why do you want to mess with PIN? PBC is so much simpler (and the only
> real/useful use case used in the field btw) Why making thing complex when you
> can force simplicity?
> 
> > 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?
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?
> >
> > Remember connman won't help you to differentiate a pin input or pin display.
> > Thus it's up to your lib or the ui to pre-generate one to propose to
> > the user (so either he'll pick that one, or he will input the one he wants).
> >
> > So review the naming here. I think you can join all pin/pbc choice in
> > one unique function. Unless CAPI style forces you to split as much as possible.
> >
> > Also when you say "wifi_direct_connect_with_pin" it's like you suppose
> > to use wps pin when connecting.
> > But you don't know that before hand. You will first ask connman to
> > connect this peer, and only then: agent api might request you
> > "pin/pbc" choice. Only at this stage you will be able to say "I want to connect
> with pin, here it is".
> > It's a 2 stages connection process. Tell me if I am wrong, but it
> > looks like you API does not handle it this way.
> >
> > Our previous thinking is that upper layer can get what config method(pbc/pin)
> peer supports before connecting it, then upper layer can select through which
> method to connect. Is it possible to add the config method in peer property and
> expose it?
> 
> No. This is up to ConnMan to deal with this, here you would delegate too much
> to upper layer. Upper layer should be as dummy as possible using ConnMan API.
> When user connects a distant peer, if both pbc and pin are supported and
> connman does not detect that the other peer is already running pbc: it will do
> an Agent request. So here you can tell either you want pbc or pin (with the pin
> you want)
> 
> This is exactly how it works for wifi wps enabled services, so it will follow this
> same approach.
> 
OK, we will refresh our previous design for the work process of upper layer.

> > For example, in Tizen, when it will connect a service, it will firstly check
> whether the service is favorite, if yes, it will connect it directly, otherwise, it will
> request input via ConnMan agent, so here is it possible to get the config
> method(pbc/pin) before calling agent?
> 
> You are mixing up here, it's the other way round.
> - tizen does not check if it's favorite or not: connman does.
> - tizen does not request input via connman agent: connman does.
> 
> Agent is a way for connman to request something to the upper layer, and the
> Agent API is what the upper layer should implement so connman can talk with
> it.
> 
OK, thanks!

> >> There is nothing specific ConnMan needs to handle here. The wifi
> >> diplay stuff will be merged in Peer's Services property that your lib
> >> will have to parse (for distant peer's info at least).
> >> For local wifi display stuff, it's up to you to manage it, the only
> >> requirement about connman is that you register your wifi display
> >> stuff through
> >> RegisterPeerService() Manager API.
> >>
> >> So your wifi display api seems ok to me here then.
> >>
> > It seems we have some misunderstanding about it before.
> > Do you mean that we can only get some WiFi Display info through peer's
> services property, but we can't make some wifi display operations through
> ConnMan?
> > 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?
> 
> Tomasz



More information about the Dev mailing list