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.
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.
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.
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.
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().
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
