Re: NM tidbits

[Dan Williams <dcbw redhat com>]

On Wed, 2006-01-25 at 15:19 -0500, Robert Love wrote:
> On Wed, 2006-01-25 at 14:21 -0500, Dan Williams wrote:
> 
> > 1) What was the rationale for Enable Networking again?  If we have that,
> > do we really need Enable Wireless?  If there's a need for Enable
> > Networking, I'd rather remove Enable wireless and just have one.  Two
> > seem redundant.  Internally, one essentially calls "sleep" and the other
> > actually disables wireless, no?
> 
> 'Enable Networking' does supersede 'Enable Wireless' in all cases except
> where you want to disable scanning, but not all networking.  I think
> this is a valid use case.
> 
> Disabling all networking has two primary uses: As a "lock down" or
> "flight mode" and in the case of performing a clean disconnect.  A clean
> disconnect might be nice if using a docking station, for example.
> 
> So we definitely need an 'Enable Networking' option, because I think we
> really need to give users a way to cleanly disconnect, and (legally) we
> will eventually need a "flight mode."
> 
> But "Enable Wireless" is nice for the scanning case.  Albeit, I admit
> that the two are a bit redundant.

Except that Enable Wireless turns off wireless completely!  Enable
Wireless _is_ "airplane mode" essentially.  WRT to scanning, the
decision was that you will never be able to turn off scanning, that NM
will scan every now and again based on some heuristics.  Scanning every
2 minutes doesn't really take that much power, and people who think it's
unnecessary can simply deal with it.

> What do you think?
> 
> > 2) I'm thinking 0.6 release within the next 2 weeks.  Sound good in
> > general (and wrt SUSE 10.1)?  What are the major bugs to get fixed
> > before then?  Do you want to man the release stuff?  I'd like to get
> > some new content on the website too.  General push for excitement, more
> > docs, etc for 0.6.
> 
> I will happily man the release 100%.  0.6 sounds good.  I think we are
> just about ready.  Update website, sing a song on the blog, and so on to
> light a fire under everyone and get them excited.

Cool.

>         - Some people have suggested to me that NM is a regression over
>         straight wpa_supplicant, because wpa_supplicant can auto-detect
>         ciphers and even WPA version.  So all of our options are
>         excessive.  If accurate, apparently we can just not specify the
>         details and wpa_supplicant will get it right via auto-detection.
>         Allowing the fine tuning is fine, but if the default is just
>         "auto" and that works, all the better.

Right, we can do this.  I had intentionally kept the current model to be
less-smart on the wpa_supplicant front for (a) simplicity, and (b)
consistency.  ie, we want to make sure where the bugs are, and what
exactly wpa_supplicant can do before we open it up and let
wpa_supplicant be "smart" about stuff.  Error reporting is still
something of a concern here, but that will only get better with time.

Note that WEP still needs to be hard-coded since you can't ever know
that an access point supports only 40-bit WEP rather than 104-bit, or
whether it's using Shared Key or Open System until you try to connect to
it.  But at least they nailed that bit with WPA.

Dan