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

[jdthood]

Karl Hegbloom Wrote: 
> 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.
> 
ifupdown is indeed underrated.
The real problem with ifupdown is that it is undermaintained.

> 
> 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'.
> 
If it does low level network configuration then it should Conflict with
ifupdown, since ifupdown does not expect other configuration tools to do
low level configuration.

> 
> 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 ?)
> 
That is good.  I think that any decent network configurer should, in
the future, work with D-BUS.

> 
> 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.
> 
That's how I do it too.

It took me a long time to get it all to work seamlessly.

> 
> 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.
> 
Known bugs, left unfixed for months.  :(

> 
> 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.  
> 
As you are no doubt aware, waproamd has been deprecated by its author
in favor of wpasupplicant.

> 
> 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...
> 
Yes, and this all works pretty well once it's configured properly.

> 
> 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.
> 
This is what I have been thinking, although I must say that I haven't
looked deeply into the NetworkManager code.

There are other people who want to write the successor to ifupdown.  It
is something I would like to work on.

> 
> (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...
> 
gnome-system-tools is another package that has been allowed to sit for
months with unfixed bugs related to network configuration.  See the
Debian BTS page for g-s-t.

> 
> 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.
> 
I fully agree that future Debian and Ubuntu network configurers must
either use ifupdown or compatibly replace it.

> 
> 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.
> 
Yes.

> 
> 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
> 
> 
> 
> -- 
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


-- 
jdthood