Re: Network Manager Wifi thoughts

[Dan Williams <dcbw redhat com>]

On Fri, 2008-04-04 at 15:35 -0400, Dan Williams wrote:
> On Fri, 2008-04-04 at 11:52 -0400, Martin Owens wrote:
> > >  This would be problematic at best, how would NM know the difference?
> > >  The Captive portals work by intercepting all the traffic and in theory
> > >  work transparently.   I am actually setting up one using the Captive
> > >  Portal on Aruba and also testing one Consentry switch right now and I
> > >  couldn't think of an easy way to allow NM to reliably determine if it
> > >  had authenticated to the Captive portal or not.   What about networks
> > >  that require the use of a Proxy?   In those cases the yellow
> > >  connection notification would be incorrect.
> > 
> > There are ways of doing it so it's an additive notification, just
> > because a method can not be found at the moment does not mean that the
> > idea it's self is problematic, there is a need to have a greater
> > status of connectivity. But think about this from the users
> > perspective, KISS! Having any sort of information about the state of
> > the network hidden away until you open up firefox and try out a
> > website isn't good.
> > 
> > >  I think I understand your intent but I personally (And I have no say
> > >  in the matter ;-) ) feel that this is better off in a separate network
> > >  troubleshooting tool and not in Network Manager.
> > 
> > I disagree strongly, another tool would be subject to complicating the
> > user interfaces and would push the functionality away. Suggesting that
> > it be another tool while logical is just missing the point and ethos
> > of the network manager (to make managing networks easy).
> > 
> > So far we've had a number of suggestions that the devs could implement
> > and test out, see if they work and what the problems are. Fear of
> > foresight can be a terrible thing sometimes.
> 
> While I agree that an "am I really connected to the internet" notifier
> would be a nice thing to have, there really are a number of problems
> that make it pretty much impossible to do easily or nicely.  Others have
> pointed most of these out:
> 
> 1) Captive portals: these are _everywhere_, and there's no way to get
> around them.  They intercept and redirect all traffic.  See also (2) and
> (3) because captive portals intercept these and render them useless.
> 
> 2) pinging google/root-dns/whatever: this doesn't work, because the
> captive portal intercepts the ping and it looks like it's coming from a
> legitimate host.  Plus, it's just bad etiquette, because every time a
> connection comes up/down you have to send out some _internet_ traffic
> that must be routed.  I'd like to direct you to [1] if you think this is
> _really_ a good idea...
> 
> 3) page-scraping google/yahoo/whatever: very problematic, because it
> depends on the google page to be the same.  Yes, you can develop
> heuristics but this gets quite complicated and you'll have frequent
> updates just like antivirus products are updated frequently.  Same exact
> problem.  Plus, users will want to configure the site they want checked
> because not everyone lives in the US and wants google.com.  Every
> different site would need a different ID
> 
> 4) ARP-ing a known MAC: this _might_ work, but of course requires the
> user to set up the known MAC for every connection, which regular users
> shouldn't have to know about.
> 
> 5) Proxies: pretty much explanatory; if your DHCP server doesn't send
> them to you, you're out of luck and certainly can't do (3) even if you
> wanted to, even though you may be able to access other services
> 
> A _big_ problem here, and one that you may not realize, is of user
> trust.  If there are so many difficulties with determining whether or
> not the user has actual internet access, how can the user really trust
> the icon?  Either it won't show up when you really _do_ have access, in
> which case you have to pretty much ignore it because it's wrong much of
> the time, or it will show up when you _don't_ have access (ex. captive
> portals), at which point you can't trust it either.  There's a real
> danger that we'd got to a lot of effort to implement the feature which
> would then be quite useless to users because they can't actually trust
> that the icon is correct or not.

A good example of this issue is the Firefox SSL self-signed-certificate
warning dialog.  How many people take the time to click the "Details..."
button and read the certificate and verify the information?  Eventually
you just get in the habit of clicking "Ok" and you get desensitized to
the risk entirely.  It's a false-positive; which is the same sort of
risk that having an Internet icon would be.

I'm not against it, I just need to see an implementation that doesn't
have too many false-positives and doesn't have too many false negatives
first.

Dan

> The big question I have is "What does Vista do?"  Vista has a feature
> where it _does_ show a little globe over the device icon in the system
> tray when it has determined that you are connected to the Internet, and
> not just your local network.  That said, it's pretty flaky and drops out
> quite a bit.
> 
> In the end, it's certainly possible for an external tool to do this and
> provide it's own D-Bus interface telling apps whether it thinks there's
> a connection or not.  It could listen to  NM and when there's a network
> connection, do it's discovery and send out it's own signals as
> appropriate.  If somebody wants to do that, that would be great.  I'd
> like to see a working implementation with a pretty high success rate
> (90%+) before I'd consider pulling this functionality into core NM.
> 
> Dan
> 
> [1] http://pages.cs.wisc.edu/~plonka/netgear-sntp/
> 
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list