HAL 0.5.x & networking

[David Zeuthen]

(adding NM list to the CC)

On Wed, 2005-06-08 at 07:40 -0700, Sean Meiners wrote:
> Then you might want to consider removing the interface_up key since  
> it's pretty much useless without a monitor behind it.  

Well, net.interface_up is merely whether the interface is up or not -
it's pretty orthogonal to whether there's the networking card is
connected to another transceiver (for 802.3) or whether there's a beacon
(802.11). 

> Unless of  
> course client applications can modify keys (something I haven't  
> looked into yet).

There was some dicussion about this early on but I don't think it's a
really good idea.

> Speaking of bad drivers, I noticed that non-PCI PCMCIA and USB  
> network devices won't currently show up in HAL.  I tracked it down to  
> the fact that net_add specifically looks for /sys/class/net/<if>/ 
> device and if it fails to find it, gives up.  Unfortunately, drivers  
> like airo don't provide device symlinks.  

First of all, it's a bug if there is no device link and the driver is
bound to a physical device. The PCMCIA thing should be fixed in 2.6.10
or 2.6.11 - sadly most USB drivers are out-of-tree (and they mostly suck
IMHO) so these projects needs to take the patches (it's mostly
one-liners; just a SET_NETDEV_DEV or something IIRC). The whole driver
situation pretty much sucks, see here

 http://lkml.org/lkml/2005/1/25/296

However, things are improving.

> I created a patch to remove  
> this restriction and the devices show up, but with no parents (as  
> would be expected).  I'd be happy to send it along as well as  
> entertain other ideas of how to resolve the issue.

We did this for a little while, but the problem is that e.g.
NetworkManager really wants to ignore stuff like lo, tun0 because it
doesn't represent a physical network connection (and e.g. tun0 is
brought up when you start things like VPN clients).

> I looked at it a few months back and it looks nice.  The only problem  
> I had was that it does *everything* itself.  

Yeah, it pretty much has to I'm afraid. Most existing code is really not
built with dynamically changing things in mind - however, Jason Van Dias
from Red Hat have done patches for both dhclient and named to control
them via D-BUS (I'm not totally sure about the details) - this is needed
e.g. when you connect via VPN and you want only *.foo.com addresses to
be taken care of by the name servers provided by the VPN concentrator.
You need to poke the locally running name-server to tell it that.

I've also seen discussion on the NM list about e.g. getting other DHCP
clients than dhclient to support the same D-BUS. Btw, I *think* we're
putting most of that code into Fedora Core Rawhide over the coming weeks
but I'm not really sure how and when. Dan would know for sure.

> And since we're Debian  
> based I prefer to use the rather nice if(up|down) system that's  
> already available to do most of the work since so many other things  
> (pppd, resolvconf, etc) have been made to work very well with it.   
> However, I've been planning on giving NetworkManager a second look to  
> see where it's at now.

Cool. I think that things we definitely want to add to NetworkManager in
the future is support for Bluetooth, PSTN modems, ISDN modems, PPPoATM,
PPPoE and so on. It's just a lot of work so I'm not sure when things
like this is done.

Cheers,
David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal