On Thu, 2016-06-09 at 16:07 +0200, Tomasz Bursztyka wrote:
> Thank you very much for your feedback. For this proposal we based
> on this assumption: we are talking about DBUS interfaces, these are
> not directly the interface the end user will need to understand, in
> between there must be and application for shell/graphical UI =>
> here the developer may not be a WiFi expert, so we put all the
> parameters of StartWPS and CancelWPS optional (except
> authentication), and connman will try to figure out an automatic
> behavior => this already goes in the direction you proposed
> On the other hand the automatic behavior may not suit all cases and
> an expert developer may know how to manage several WiFi interfaces
> (in our case three, STA, P2P and AP) => in this case the optional
> parameters can come in handy.
> “Ifname" : optional, meaning it can be empty, but with it we don’t
> need other methods when the UI needs to choose between STA-WPS or
> AP-WPS, or there is a P2P interface that can be used also as an
> alternative STA or AP with WPS
Still, ConnMan never uses ifnames as an entry point for a decision.
Actually, the only place where you will see an interface name is in
the description of a Service entry (Ethernet dict attribute).
This is enforced, you can't change that rule :) we don't want users
or UI code to mess up with interfaces directly.
Make it work for 1 device first.
For P2P, you could use an alternate method called "Pair()" maybe. The
role is decided during pairing anyway (if I remember well? this is so
Let's see how to solve that for 2+ device later.
(devices could be ordered by their support: the device which supports
more technologies would be the first, etc...
ConnMan would loop on them, each time StartWPS() - or Pair if
supported - failed. Just a quick idea.)
I suppose this will be used after setting 'Tethering' true for a
technology. I think ConnMan can pick up a/the tethering WiFi device
which supports WPS once WPS is requested. Then no ifname is needed.
The P2P and STA only interfaces should be identifiable, there exists
code that does try to figure out AP support when tethering (see
e.g. 452fa8db3eb7e88fe93c93569f21884697f2d2c6 and where it ended up
> "Type" and "Pin" you are proposing to have
only one parameter
> “authentication” but when the device with connman is enrollee it
> must show a PIN to the user, not receive one: then we need to have
> two parameters (Type, PIN)
We never supported the registrar side on current WPS support in
ConnMan (as far as I remember at least).
So if the Agent is requesting about WPS, up to the UI to provide a
PIN the user would use if user wants to use PIN method.
For the AP case an empty PIN should once again mean "pushbutton", while
a PIN with a value is, well, a pin.
> like we propose, or if you prefer only one (Authentication) it
> be parsed in the following way:
> - A string like “PIN” which means the connman must provide
> a PIN to the GUI so that the user can enter it in the other device
> (normally the AP)
> - A string containing a number like “12345678” which means
> this is the PIN to be used
> - Empty: means use PBC
The pin needs to be set beforehand, there are no Agent method calls to
be done for this. And after setting a pin that same entity can
call StartWPS to get the procedure into a running state.
> “role” – optional, meaning it can be empty, but while for the
> agree with you it mostly is an enrollee, the AP is a more
> complicated system; why not offer the possibility to the developer
> to choose the role if he wants (or if he needs)?
AP mode in ConnMan is a very simplistic one. Actually, wpa_s does not
provide much feature there as well (compared to hostapd).
You could stick with registrar and that's it.
If you want to differentiate, you could add a configuration entry in
main.conf (like APWPSMode=<registrar/enrollee> ? registrar would be
Less stuff to expose through DBus at least. I would be surprised
people really care about such option anyway.
Setting the precise role seems to be unnecessary for now. It can be
added once there is evidence that it won't work without. I'm not sure
anybody can master more than a pin and calling start and stop here :-)
Hope it clarifies things.
I hope my comments do so too.