[pkg-wpa-devel] Re: Patch: Support for mapping scripts, e.g. guessnet

[Kel Modderman]

On Monday 07 August 2006 02:52, Felix Homann wrote:
> > But; in previous mails, you wanted to fallback to guessnet mappings when
> > the 'id_str' mapping was not present in /e/n/i, so this is somewhat
> > inconsistent, imho.
>
> Not exactly. I wanted the script only to be used as a fallback unless
> wpa-mapping-script-priority is set, i.e. as a *replacement* for
> wpa_action's default. I think that's a clear policy: Try id_str first, if a
> mapping-script is specified fallback to script mapping and then let ifup do
> its thing. Falling back to the wpa_roam fallback after the fallback to
> mapping script failed is a bit too much fallbacks IMO ;-)
>
> BTW, the idea behind using the script only as fallback by default was that
> guessnet currently doesn't have a viable ssi/bssid test (a patch of mine
> using wpa_cli was rejected due to the "new order" of wpasupplicant, see Bug
> #365930.) I thought, that the work of a ssid/bssid test could already be
> done by the id_str matching, if there's nothing to match guessnet or any
> other mapping script could come in.

Ok. I think I may have previously misunderstood you. The current behaviour is:

If 'id_str' is present (thus the WPA_ID_STR env var) then it is used 
(overridden by wpa-mapping-script-priority). If 'id_str' is not present, and 
a guessnet test is available, the test is used. If neither 'id_str' or 
guessnet tests are available, we fallback to the default => 
wpa-roam-default-iface or 'default|none'.

Is the above described behaviour correct in your opinion?

>
> > Maybe it should be a case of 'use one mapping method or the other', and
> > do not allow the possibility to mix and match?
>
> No, see above. We would loose the ability of mapping by ssid/bssid when
> using guessnet.

Ok. I *think* I understand now.

>
> > Ok, I see your thinking; maybe there should be no hardcoded fallback at
> > all?
> >
> > This way we can add the 'wpa-roam-default-iface' option and document its
> > usage and purpose. This would mean that a logical interface stanza must
> > exist for each known network including the fallback logical interface,
> > and specifying 'wpa-roam-default-iface' would be mandatory to activate
> > the fallback option.
>
> That's a viable solution, too.

wpa-roam-default-iface should be implemented now.

>
> > My primary concern is that people who've already picked up on wpa-roam
> > and are using the 'default' fallback mapping will be bitten by any
> > changes in this regard.
> >
> > On the other hand, wpa-roam has hardly been documented until now, so it
> > *is* the time to be making such decisions.
>
> Yes, I think this is something we can change without causing too much
> trouble, although I'm still in support of a "Don't break running setups"
> policy ;-)
>
> > However, with a default fallback using the dhcp inet method, simple
> > roaming is brain dead easy to setup. And I like that. But the dilemna
> > remains:
> >
> > Should we have a hardcoded fallback? And if so, should it be 'default'
> > or 'none' ?
>
> I'd prefer either "none" or no hardcoded fallbackat all ;-) Both are fine
> for me, but I'm a bit in favor of "none".

Yes, I would like 'none' too, but this still may cause disruption.

Maybe for a release or two, we should check if the user has a 'default' 
interface setup first and use it. At the same time, document the usage of 
wpa-roam-default-iface and 'none' while deprecating the usage of 
the 'default' interface, with a _big_fat_warning_ that it will be removed 
soon.

Comments on that approach?

But just as guessnet provides a default fallback of 'none', I think we should 
too, just for consistencies sake.

Thanks, Kel.