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

[Felix Homann]

Hi Kel,

On Sunday 06 August 2006 15:09, Kel Modderman wrote:
> Okay then, we'll use shell built-in 'type' as a simple validity check of
> the mapping script. This is not as strict as I'd personally like, but
> should catch at least stupid typo's.

Great!

> > Furthermore, it could even be wanted that a script returns a nonexistent
> > logical interface name to make sure the interface won't ifup properly.
> >
> > I think we should do it as ifupdown does: Let's just pass it through.
>
> Ok, I agree.
>
> If WPA_LOGICAL_IFACE is returned from the mapping script we use it without
> validating its existence in /e/n/i.

Fine!

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

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

>
> 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".

> > I'm really looking forward to having this released!
>
> Me too.
>
> Thanks, Kel.

Kind regards,

Felix