On Fri, Jan 18, 2019 at 01:28:43AM +0100, Daniel Golle wrote: > Hi Jouni, > > On Tue, Jan 08, 2019 at 01:04:37PM +0200, Jouni Malinen wrote: > > On Mon, Jan 07, 2019 at 03:56:24PM +0100, Arnout Vandecappelle wrote: > > > On 20/12/2018 11:19, Jouni Malinen wrote: > > > > that it would be better to indicate this as a parameter > > > > specific to each instance of WPS provisioning, i.e., as a new optional > > > > argument to the WPS_PBC control interface command. > > > > > > That makes sense. > > I'm sure you have good reasons for requesting it do be done in that > way. It'd be great if you can elaborate on those reasons, see below > for the cause of my confusion with that. This information (whether to request credentials for Multi-AP use case or for something else) is associated with a specific instance of WPS protocol exchange; not to global state of a WPS Enrollee device. > > > > In other words, > > > > wpas_wps_start_pbc() should get this from the caller > > > > > > So an extra argument to wpas_wps_start_pbc, right? > > > > Yes. > > I've been going that road for a bit now and more and more come to > the conclusion that setting a global variable (just like other WPS- > related global configurations) would be much less complex. Sure, it might be less complex, but it would be less correct as well. It should also not be assumed that there is only a single WPS exchange in process at any point in time. The most common example of this is the use of WPS ER in wpa_supplicant, but that would obviously be Registrar instead of two Enrollees, so that might not hit this specific case. Anyway, using a global variable for setting a parameter for a single WPS protocol instance does not sound correct. > Also note that a station is most likely really either a regular station > or multi-ap backhaul station, also considering the context: multi-ap > interface in 4-addr-mode sitting in a bridge while regular station > being a whole different use-case. Probably true as well, but still, this is just trying to justify taking a shortcut over a cleaner design. > Coming from OpenWrt, whether the interface is a multiap backhaul sta or > a regular sta is known at the time of wpa_supplicant.conf being > generated. Sure, at this point we could store that somewhere next to > wpa_supplicant_$ifname.conf and when pushing the WPS butten checking > that file to decide whether multi_ap=1 is being passed along the call > of wps_start_pbc or not. A more dynamic decission doesn't make much > sense, because higher layers are also already set according to whether > the STA interface is part of a bridge or not. I don't think wpa_supplicant implementation design should be based on assumptions that OpenWrt or some other user of wpa_supplicant has such knowledge of the device using WPS Enrollee functionality only for a specific purpose. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
