Bug#225512: netcfg: add wifi configuration
Package: netcfg
Tags: d-i
Severity: wishlist
Am Sam, den 27.12.2003 schrieb Martin Michlmayr um 10:46:
> ----- Forwarded message from Thorsten Sauter <tsauter@debian.org> -----
> * Martin Michlmayr <tbm@cyrius.com> [2003-12-26 12:33]:
> | * Gaudenz Steinlin <gaudenz@soziologie.ch> [2003-11-20 11:10]:
> | > > It found my wired ethernet controller, but not my Airport card.
> | > As soon as there is a kernel module for the ariport card on the
> | > installer image, we can test if this solves the problem or if we have to
> | > add something more to support airport.
> |
> | The airport driver is included in
> | nic-modules-2.4.22-powerpc-di_0.20_powerpc.udeb now. Joe, can you try
> | a new daily build in a few days?
>
> if we have support for aiport (and maybe other wifi cards), doesn't a
> "wlancfg" udeb make sense?
>
> This package should basicly ask for the following options and then
> configure the wirless card based on these answers _before_ any network
> configuration is done.
>
> - network
> - station/nick name
> - encryption key
>
> If we include such a package, then we need an udeb from the
> wireless-tools package also.
>
> Bye
> Thorsten
>
>
>
>
> ----- End forwarded message -----
> ----- Forwarded message from Joey Hess <joey@kitenet.net> -----
>
> From: Joey Hess <joey@kitenet.net>
> Subject: Re: Bug#221533: install fails - "couldn't download exim4"
> Date: Fri, 26 Dec 2003 23:13:27 -0500
> To: 221533@bugs.debian.org, debian-boot <debian-boot@lists.debian.org>
> User-Agent: Mutt/1.5.4i
>
> Thorsten Sauter wrote:
> > if we have support for aiport (and maybe other wifi cards), doesn't a
> > "wlancfg" udeb make sense?
> >
> > This package should basicly ask for the following options and then
> > configure the wirless card based on these answers _before_ any network
> > configuration is done.
> >
> > - network
> > - station/nick name
> > - encryption key
> >
> > If we include such a package, then we need an udeb from the
> > wireless-tools package also.
>
> I looked at it a week ago, and concluded that to be a robust wifi
> configurator, it would need to be part of netcfg. Here is my rough
> design document:
>
> - wifi config should happen after netcfg has chosen an interface, but
> before the dhcp
> - in low priority, should let wifi be configured
> - in high priority, should see if there is an AP, and if so, use it with no
> config
> - should allow configuration of:
> ad-hoc or AP
> WEP key entry (ugh)
> ad-hoc channel, essid
> for AP, get a list of access points (how? at least dummy code with
> AP and signal)
> prompt with a question that asks which AP to use, with a manual
> entry at the bottom to let the user enter the essid;
> after the manual entry, see if an AP was found using that
> essid, else show an error and back to list
> - if dhcp or whatever fails, should be the option to go back and
> reconfigure wifi, in case that was the problem
> Instead of making there be 3 choices (retry dhcp, config static,
> reconfig wifi), how about changing netcfg/dhcp_retry to jump back to
> the start of netcfg (interface choice). This way, if you choose the
> wrong interface, you can also rectify that, and you get to
> configure wifi again too.
Always jumping back to the start would require changing the current
design of the dhcp retry code. If the dhcp client did not exit it is
currently not killed and restarted but we wait for another 10s instead.
If we go back to the start we would have to kill the dhcp client to
avoid unwanted side effects.
If we agree on using udhcp on all archs this would not be too serious,
because udhcp only runs for about 7s and is restarted on retry anyway.
I'm not sure if this behaviour of udhcp works with real world slow dhcp
servers though.
> - after network config is done, need to write wifi info to interfaces file
>
> Can this be made standalone, or how does it integrate with netcfg?
> Probably the latter.
I submitted this email as a wishlist bug to netcfg.
Gaudenz
>
> --
> see shy jo
>
>
>
> ----- End forwarded message -----
>
> --
> Martin Michlmayr
> tbm@cyrius.com
>
Reply to: