Laptop Networking, NetworkManager, ifupdown ---> Merge them?

[Karl Hegbloom]

I've begun looking over:

 cvs -d :pserver:anonymous at anoncvs.gnome.org:/cvs/gnome co NetworkManager

... and thinking about it's design architecture and how that relates to
Debian's wonderful (and perhaps under appreciated and under extended)
'ifupdown' package.

NetworkManager wants to be fully in charge of the interfaces and their
configuration.  It does things done traditionally by 'hotplug',
'ifplugd', 'waproamd', 'wpasupplicant', 'laptop-net', 'dhcp-client', and
'ifupdown'.  It uses the HAL and Dbus-1 systems to signal the network
manager when something about the networking state is changed -- a link
beat change on a wired interface, a new wireless access point (AP)
appears, and what have you...  (? heartbeat for failover ?)  Right now,
it totally bypasses most of the configuration in /etc/network/interfaces
-- it's Debian backend parses that file for some of it, but the
interface configuration is all done internally by NetworkManager.  As
far as I can tell (so far; 40 minutes of fast code reading; correct me
if I'm wrong) the special features of ifupdown are not supported.

I am not satisfied with NetworkManager just yet, aside from the obvious
bugs.  Right now, in my laptop, my favorite configuration to date
involves the complex (and admittedly Goldbergian[1] and clunky)
combination of 'hotplug', 'ifrename', 'ifplugd', 'waproamd', 'ifupdown',
'resolvconf', 'dnsmasq', and a little 'wlanctl' script I wrote in
suid-perl.  Here's how that's set up, for reference.

My laptop has an Atheros based wifi board, which uses the Madwifi
drivers... they name the interface 'ath0'.  I have an /etc/iftab that
says: 

wlan0	driver ath_pci

I've edited the /etc/hotplug.d/net/{waproamd,ifplugd}.hotplug scripts
(iirc, I submitted patches to DBTS) to have them support ifrename.  This
provides me with a canonicalized name for the wifi interface, no matter
what driver it happens to use, whether it be Madwifi or ndiswrapper.
The solution in NetworkManager is superiour, since it uses a better
means of determining if an interface is a wireless one or not.

The waproamd is set up to start on the hotplug event of the wifi driver.
I have it blacklisted so that it is not loaded unless I explicitly load
it, because I wanted to save battery power, and if it's always scanning
when there is no AP nearby, it will wear itself out.  I had a cellular
phone that would wear it's batteries out in an hour if it was taken
outside of it's home range.  It was always scanning for a tower, with no
back-off on the scan interval.  

There's a setuid root perl script that can load or unload the driver,
along with starting and stopping the waproamd.  I use the Gnome panel
mini-commander applet, and the 'wlanctl' command is always handy in it's
completions.  I verified by reading the driver code that when the module
is unloaded, the radio hardware is actually powered off, to save battery
life.

The ethernet interface is managed by the ifplugd.  I don't unload it's
module, and I don't know what is the power cost of monitoring it for MII
link beat when there is no cable jacked in.  Perhaps a back-off on the
timeout would be appropriate?  I don't know how event-driven that system
is yet.  Any and all power savings are significant -- I like having 7
hour battery life when I am in lecture taking notes.

The thing is that both waproamd and ifplugd are triggered by hotplug,
and both use the ifupdown system to perform the actual network
configuration stage.  ifupdown in turn uses whatever dhcp client
application is installed, and that uses the 'resolvconf' system to
manage the resolv.conf file.  It also supports whatever arbitrary hooks
I care to stick in there, such as running a script generated by
fwbuilder that sets up the right NAT rules for my user-mode-linux
machines, or whatever...

My proposal is this:  Adopt NetworkManager, but not until the ifupdown
functionality is rolled into it.  Let NetworkManager fully manage the
interfaces, but have it do the full deal that ifupdown does now.
(uh,... libifupdown.so ?)  That could conceivably become the backend for
all distros.

As for the idea that the interfaces file is somehow difficult for a UI
to manage, in that the gnome-system-tools doesn't get it right... I
think that's a bogus argument.  The file format is obviously quite
simple.  To handle extensions to it, could a debconf based configuration
system just add another page or tab to the UI for the extension?  (eg.
dns-nameservers for the dnsmasq hooks)  The extension would drop a hook
script into a directory, kind of like base-config or d-i does?  That
would add the loop for the configuration for the add-on features?  (eg.
dnsmasq would add a configuration for static external nameserver,
perhaps tied to what network is out there or something?  DHCP should
have given it that in most cases.)  [ It would be cool to have an
extensible configuration interface where new widgets are added by
plug-ins.  Does glade do that, perhaps with XML namespaces or
something? ]

I'm not clear on how this all should work yet, but I am sure that we
ought to think about rolling the ifupdown extensible architecture into
the NetworkManager for Ubuntu, Debian, and perhaps other distros as well
if they like what we all design for this.

Network configuration should certainly all be consolidated under one
subsystem and controlled by one interface.  Ideally, in my mind, the
configuration data back-end should be a file format that is
hand-editable and extensible.  Any GUI that edits it should be
considerate of hand edits and leave things it doesn't have a plug-in for
alone, and comments intact.

The issue then is that the NetworkManager is getting configuration data
from the user, rather than from a system wide location...  that makes
sense in some ways, but even if two different people use a laptop, if
they access networks in common, the configuration for those networks
will be identical, right?  What may differ across users would be
protocol or application specific, not network interface configuration
specific...  Hmmm... vpn setup hooks?  So maybe everyone should have
writes to the network configuration?  Or maybe admin can lock down some
profiles and allow others?

Well, thank you for letting me "think out loud" here.  I am looking
forward to your thoughts on this matter.

--------
Footnotes

[1] http://www.rube-goldberg.com/html/gallery.htm