Re: Next steps (Was Re: Initial version of a SuSE backend)

[Dan Williams <dcbw redhat com>]

On Thu, 2005-06-09 at 17:43 +0200, Tom Parker wrote:
> David Zeuthen wrote:
> > Ideally, I'd like to see a plug-in based solution (both back-ends and
> > front-ends), much like the VPN stuff we're doing now, leaving
> > NetworkManager proper as a core that controls these plug-ins and deals
> > with core stuff such as dhcp, named etc. Yes, this means wired and
> > wireless networking would be plug-ins as well. Things would probably
> > need to be layered too. I would start by considering the UI we need and
> > the use that to design the API interfaces.
> 
> Related thought I had a while back (but hadn't gotten around to having a better 
> look at due to current time constriants), was that currently we have a fairly 
> hard-coded approach to what link is "better". I'm fairly sure it's still set to 
> "if we've got a wired link that supports carrier detect and it's alive, pick 
> that over *anything* else".
> 
> I had some thoughts regarding a better classification scheme for links, which 
> becomes even more important if we start supporting lots of things. In order of 
> worst->best:
> 
> 1) Link does not support minimum features we need (e.g. wireless scan/link detect)
> 2) Link supports features, but we can't see any connections (e.g. scan returns 0 
> APs/link detect is down)
> 3) Link supports features, has a possible connection but is restricted. e.g. you 
> need to login somewhere (VPN for example) before you've got full access, or 
> maybe it's just a walled garden somewhere.
> 4) Link has basic features, has a possible connection, and appears unrestricted. 
> *Then* we start to sort on connection speed...
> 
> Overriding by user UI can jump from 1->3 (and possibly 4, but probably not). 
> Also, a wireless connection with multiple APs should be considered as a group of 
> connections, one per detected/known AP. They have the same basic features, but 
> some may be in group 3 and others in 4.
> 
> How do we detect restrictions? Well, there's a couple of easy ways that might 
> work e.g. attempt to resolve something.invalid. RFC 2606 guarantees that 
> *.invalid will always be non-lookable, which might work for walled garden 
> "everything points to one server" DNS. Or, check a couple of known sane lookups. 
> If both gnome.org and microsoft.com resolve to the same address, then either the 
> apocalypse has come or you're in a walled garden. I guess there are a few other 
> tests that people could think of...

The problem with some of this is that to do anything like this, you've
already got to have the interface configured and "up".  You need an IP
address to be able to do any DNS, and getting that is what takes the
longest amount of time...

Dan