[pkg-wpa-devel] Re: wpasupplicant experimental branch
Reinhard Tartler
siretart at tauware.de
Mon Mar 27 10:25:57 UTC 2006
On Mon, Mar 27, 2006 at 08:08:55PM +1000, Kel Modderman wrote:
> >How do you make sure that the interface gets an ip via dhcp before running
> >any other scripts besides wpasupplicant? This is a quite important
> >point, because at least in ubuntu, interfaces are always ifupped via
> >udev, so there is no difference between hotplugged and not hotplugged
> >interfaces. Many other daemons like openvpn and ntpdate are running from
> >scripts in /etc/network/if-up.d. We need to make sure that
> >/etc/network/if-pre-up.d/wpasupplicants blocks until the interface got
> >an ip or was configured by alternate means. (e.g. statically).
>
> This complexity must be managed by the user, if the user expects to
> connect to various different wireless locations and run those sort of
> things, it is expected that (s)he knows what (s)he is doing, IMHO.
No, I disagree at this point. Even (and espc.) for simple cases, we MUST
ensure that after if-pre-up.d, the interface has an ip is ready to
transit data. The action script is handy when the user changes his
location, okay, but we really should at least try to wait for getting a
dhcp lease before handing control back to ifupdown. Thats why I put
'dhcp' instead of 'manual' in my interfaces line, so that ifupdown calls
dhclient to get an ip before calling the rest of ifup.d. So I suggest to
suggest using 'dhcp' instead of 'manual' for easy cases, because I don't
see how the action script can solve that problem.
On a side note, I've been fighting right now with integration with
whereami (in order to work around the above problem), and I found this
problem: whereami is started before wpasupplicant, because it comes before in
alphabet. this is wrong, I really want wpasupplicant to be run before
whereami. I therefore think it should be renamed to 0wpasupplicant.
> >I took a closer look to the dhcp action script. I noticed that when
> >roaming, the dhclient does not reliably request a new lease when getting
> >disconnected. I'm not sure why this happens, but I really think we
> >should signal a running dhclient daemon that we want the lease to be
> >renewed when we connect to a new location.
> >
>
> It releases the device on disconnect events very reliably here, and
> renews a lease or asks for a new lease at each connect event, also
> reliably here. I'm not sure i see your problem yet, maybe time will tell
> (and more intensive testing). But this script is just "proof-of-concept"
> really, and will not be the default mode, but simply a nice enhancement.
Yes, I expect that users will integrate some roaming logic in here. For
me, I'm thinking about just calling whereami at this point, so that all
my roaming needs gets satisfied at this point.
On a side note, integrating whereami into an wpasupplicant action script
(integrated into ifupdown) is a much better approach than integrating it
into ifupdown directly, which the maintainers try currently. But thats
not a problem at this point for the wpasupplicant package.
> >So you do want to make it active by default?
> Putting words into my mouth; no.
Sorry, I didn't want to put words in your mouth, this question was meant
seriously.
> >I don't want the default action script to be a conffile for this reason:
> >I expect many users to customize/edit that script to include local
> >configuration. If this happens, they will be bugged on every upgrade.
> >Therefore I suggest that if we don't intend to make it active by
> >default, to not ship it in /etc, so that we don't need to care about
> >conffile handling at all.
> >
> >If we do want to make it active by default, I'd like to provide some
> >means of overriding it with a local version but without needing to touch
> >any conffiles, so that upgrades go smoothly.
> >
>
> Now that is a great argument, and I completely agree, we should *not*
> mark them as conffiles, thus, they do not belong in /etc.
>
> I never intended an action script to be default mode, this should all
> remain optional.
So you agree putting it to /usr/share/doc/wpasupplicant/examples? I
can't think of a better place.
Gruesse,
Reinhard
More information about the Pkg-wpa-devel
mailing list