[pkg-wpa-devel] Re: Patch: Support for mapping scripts,
e.g. guessnet
Felix Homann
fexpop at onlinehome.de
Sun Aug 6 16:52:29 UTC 2006
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
More information about the Pkg-wpa-devel
mailing list