Hello Patrik, Tomasz,
Thank you for your feedback. Then the proposal could be:
void Start_STA_WPS(string authentication)
void Start_AP_WPS(string authentication)
I removed all parameters except authentication, assuming that connman will operate in this
- when starting connman is informed by the wpa_supplicant of the interfaces that
support P2P => these will be always the last to be considered when Start_STA_WPS or
Start_AP_WPS are called, in case there is a failure (or WPS not supported) on the other
interfaces (STA and AP)
- if the system has multiple interfaces connman will try WPS STA on STA one for
first and not P2P one (that normally also supports STA), and the same for WPS AP that will
be tried on the tethering one, not STA or P2P. that is very probably what the user
- If there is only one WiFi interface supporting multiple roles (STA, AP, P2P)
i. If connected STA:
disconnect and then start a WPS STA session
ii. If connected P2P:
disconnect and then start a WPS STA session
iii. If tethering
enabled: disable tethering and start WPS STA session
i. Similar algorithm
of above but for AP
- Authenthication: Empty means PBC, a value means PIN number. This also means
that for enrollee role the UI must generate a valid PIN and provide it to both connman and
to the user so he can enter it in the AP.
- Roles: for STA it is enrollee for AP it is registrar; as requested it can be
extended to support other combination of roles in main.conf
What do you think?
Da: Patrik Flykt [mailto:Patrik.Flykt@linux.intel.com]
Inviato: venerdì 10 giugno 2016 13:54
A: Tomasz Bursztyka; MANIEZZO Marco (MM); connman(a)lists.01.org
Cc: Blanquicet-Melendez Jose (MM)
Oggetto: Re: R: [RFC] Wi-Fi Protected Setup (WPS) connection
On Thu, 2016-06-09 at 16:07 +0200, Tomasz Bursztyka wrote:
> Thank you very much for your feedback. For this proposal we
> this assumption: we are talking about DBUS interfaces, these are
> directly the interface the end user will need to understand, in
> between there must be and application for shell/graphical UI
> the developer may not be a WiFi expert, so we put all the
> of StartWPS and CancelWPS optional (except authentication), and
> connman will try to figure out an automatic behavior => this
> goes in the direction you proposed
> On the other hand the automatic behavior may not suit all cases
> an expert developer may know how to manage several WiFi
> (in our case three, STA, P2P and AP) => in this case the
> parameters can come in handy.
> “Ifname" : optional, meaning it can be empty, but with it
> need other methods when the UI needs to choose between STA-WPS
> 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
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()"
role is decided during pairing anyway (if I remember well? this is
Let's see how to solve that for 2+ device later.
(devices could be ordered by their support: the device which
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 after db79090b895f23544d54abbf230efadbae9ec13b).
> "Type" and "Pin" you are proposing to have
only one parameter
> “authentication” but when the device with connman is enrollee
> must show a PIN to the user, not receive one: then we need to
> 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
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
> a PIN to the GUI so that the user can enter it in the other
> (normally the AP)
> - A string containing a number like “12345678” which
> 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
> “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
> to choose the role if he wants (or if he needs)?
AP mode in ConnMan is a very simplistic one. Actually, wpa_s does
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
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.
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE! www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain proprietary,
confidential and/or legally protected information and is intended solely for the use of
the designated addressee(s) above. If you are not the intended recipient be aware that any
downloading, copying, disclosure, distribution or use of the contents of the above
information is strictly prohibited.
If you have received this communication by mistake, please forward the message back to the
sender at the email address above, delete the message from all mailboxes and any other
electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free.
Therefore we do not assure that this message is complete or accurate and we do not accept
liability for any errors or omissions in the contents of this message.