[Commotion-dev] NetworKManager: the good news and the bad news

Wed Oct 24 23:46:33 UTC 2012

That's correct, but its also much more widespread than just GNOME and
Debian/Ubuntu.  I think basically every distro installs it by default, and it
also is fully supported in KDE as well as other environments.  Basically, if
you are doing user networking with GNU/Linux these days, its running
NetworkManager or you're an ueber-geek ;)

.hc

On 10/24/2012 07:02 PM, Ben West wrote:
> For background, this is the NetworkManager tool provided with GNOME
> UI's, et al, on most popular Linux distros, including Debian and
> Ubuntu, correct?
> 
> http://blogs.gnome.org/dcbw/
> 
> On Wed, Oct 24, 2012 at 4:47 PM, Hans-Christoph Steiner
> <hans at guardianproject.info> wrote:
>> The good news is that one of the main devs was already thinking about a full
>> on plugin system for networkmanager that will make it full possible to support
>> all known OLSR configs.  The bad news is it doesn't exist yet... and the only
>> existing plugin interface is the VPN plugins.  That VPN plugin API is
>> basically useless to us since it assumes the IP layer, i.e. the wifi, is
>> already configured, and therefore provides no way to configure the wifi.
>>
>> Here's the IRC transcript from my discusion dcbw aka Dan Williams aka Mr
>> Network Manager on the NetworkManager room (irc://irc.freenode.net/nm
>>
>>
>> (03:52:10 PM) _hc: hey all, I'm working on making OLSR mesh networking really
>> easy to do, and currently I'm focused on NM integration.  I don't have access
>> to an OLPC, so I can't try that stuff in NM.  So I wanted to ask here to get
>> some ideas for the right approach for me to take
>> (03:52:46 PM) _hc: the way I currently envision it is that you could browse
>> thru all adhoc wifi, then try to connect using OLSR
>> (03:53:04 PM) _hc: we're working on ways to detech OLSR meshes better, but
>> that'll come later
>> (03:53:48 PM) _hc: so there would be a separate listing, list "Wired
>> Networks", "Wireless Networks", "OLSR Networks"
>> (03:54:04 PM) dcbw: _hc: ideally we can find the OLSR networks via beacon IEs
>> (03:54:35 PM) dcbw: _hc: the OLPC stuff is quite OLPC specific and only works
>> with the mesh implementation done for those devices
>> (03:54:54 PM) dcbw: _hc: which means, basically, a specific SSID is used that
>> indicates that the adhoc SSID is part of the OLCP mesh
>> (03:54:55 PM) _hc: then the use just needs to click on one of the networks,
>> then entire a WPA password if needed, do IP inof, etc
>> 15:55
>> (03:55:10 PM) _hc: right, I konw the OLPC mesh is incompatible
>> (03:55:23 PM) _hc: but I was looking at it for an example of nm integration
>> (03:55:53 PM) _hc: our plan is to try to work out a similar SSID encoding for
>> OLSR networks
>> (03:56:12 PM) dcbw: _hc: kinda evil, ideally it would be a beacon IE but with
>> adhoc that's somewhat tricky
>> (03:56:14 PM) _hc: dcbw: what's a beacon IE?
>> (03:56:19 PM) dcbw: _hc: any reason it can't be 802.11s?
>> (03:56:30 PM) _hc: isn't 802.11s limited to 32 nodes?
>> (03:56:35 PM) dcbw: _hc: an Information Element
>> (03:56:50 PM) _hc: we're aiming for meshes of hundreds and thousands
>> (03:56:52 PM) dcbw: a TLV broadcast in the beacon for a specific type of
>> information
>> (03:57:06 PM) _hc: there are a number of long standing big OLSR meshes like that
>> (03:57:13 PM) dcbw: which could be a way to identify the network independent
>> of SSID
>> (03:57:50 PM) dcbw: _hc: sounds a lot like what we were trying to do with OLPC
>> 5 years ago
>> (03:58:03 PM) dcbw: which *kinda* worked, hopefully things have gotten better
>> with large meshes since then :)
>> (03:58:22 PM) _hc: yeah, figures, that stuff is coming later, right now we
>> just want a list of adhoc networks that the use can guess based on SSID
>> (03:58:43 PM) _hc: dcbw: do you know the funkfeuer, freifunk, and related
>> projects?
>> (03:58:58 PM) dcbw: _hc: so if there's a specific SSID that identifies the
>> OLSR network, why would we need a separate section?  or is the SSID supposed
>> to be configurable?
>> (03:59:51 PM) _hc: so you're saying the OLSR mesh would just show up under
>> "Wireless Networks" and if it received the right beacon IP or TLV, it would be
>> configured for OLSR?
>> 16:00
>> (04:00:27 PM) _hc: that would be very nice, too bad the ID work is not there
>> yet, that's led by someone else, not me
>> (04:00:27 PM) dcbw: not quite
>> (04:00:52 PM) dcbw: what I'm saying is that it would be really, really nice
>> from NM's point of view to know which scanned SSIDs were OLSR capable
>> (04:01:12 PM) dcbw: so that we can do something intelligent in the UI instead
>> of saying "hey, this coiuld be OLSR, but it migth not be, so I guess you have
>> to try connecting and if it's not OLSR it'll fail"
>> (04:01:38 PM) _hc: one sure fire way is to connect to the olsrd's UDP port
>> (04:01:49 PM) dcbw: yeah, but then you ahve to already be associated with the
>> network
>> (04:01:52 PM) _hc: but that comes later in the process, it would need to
>> associate, get an ip etc.
>> (04:01:53 PM) dcbw: so that's not going to work
>> (04:02:05 PM) _hc: yes, its the "better than nothing" solution
>> (04:02:07 PM) dcbw: ok
>> (04:02:15 PM) dcbw: OLSR is a routing protocol really, right?
>> (04:02:28 PM) _hc: kind of
>> (04:02:32 PM) dcbw: and it just runs on top of wifi adhoc or master-mode
>> networking?
>> (04:02:40 PM) _hc: right, adhoc
>> (04:02:52 PM) dcbw: ok, so any adhoc network can theoretically run OLSR
>> (04:02:59 PM) _hc: so yeah, you can think of olsrd as a routing daemon since
>> the IP effect is to change the routing table
>> (04:03:02 PM) dcbw: even in parallel with regular local network IP
>> (04:03:12 PM) _hc: hmm kind of, not really
>> (04:03:19 PM) _hc: olsrd will change the routing table
>> (04:03:28 PM) dcbw: ok, so IP addressing is done how?
>> (04:03:29 PM) _hc: but it'll keep the default route, I suppose
>> (04:03:31 PM) dcbw: link-local?
>> (04:03:44 PM) _hc: no, random number in a pre-assigned range
>> (04:03:53 PM) dcbw: how are collisions handled?
>> (04:03:58 PM) _hc: luck
>> (04:04:00 PM) _hc: hehe
>> (04:04:03 PM) _hc: big range
>> (04:04:05 PM) dcbw: ummm..... :)
>> (04:04:13 PM) _hc: yeah... that's in the works
>> (04:04:26 PM) _hc: there are a number of approaches for that, ahcpd is one
>> (04:04:27 PM) dcbw: ok, so you attempt to join the adhoc network and then you
>> assign yourself a random number in say the 10.x or 172.16.x range?
>> (04:04:31 PM) _hc: right
>> (04:04:40 PM) dcbw: and then you start up OLSR and hope somebody else you can
>> talk to is running it?
>> (04:04:48 PM) _hc: yup
>> 16:05
>> (04:05:22 PM) _hc: you can think of an OLSR mesh as defined by a BSSID and a
>> channel
>> (04:05:34 PM) _hc: the SSID and IP range are basically part of that too, but a
>> little bit optional
>> (04:06:20 PM) _hc: I guess I should say: OLSR mesh is BSSID, channel, and OLSR
>> conf
>> (04:06:37 PM) dcbw: ok, so the core UI question is how is the user supposed to
>> know to try OLSR on this network or not
>> (04:06:37 PM) _hc: since there are different approaches to sharing metic info
>> (04:06:53 PM) dcbw: and given that most  networks won't be OLSR, ideally we
>> don't ask "enable OLSR?" for everything you connect to
>> (04:06:54 PM) _hc: for sure
>> (04:07:00 PM) dcbw: which is why I was talking about beacon IEs
>> (04:07:11 PM) dcbw: that would be really, really nice to have :)
>> (04:07:17 PM) dcbw: since then it would be plug and play really
>> (04:07:23 PM) _hc: I'm unfamiliar with a beacon IE, how would I implement such
>> a thing?
>> (04:07:38 PM) dcbw: are you familiar with  how adhoc wifi works at a lower level?
>> (04:07:51 PM) dcbw: and BTW, you can't really depend on a specific BSSID
>> (04:08:01 PM) dcbw: with adhoc you can only depend on the SSID
>> (04:08:34 PM) dcbw: as drivers/firmware often have "BSSID coalescing" schemes
>> to all arrive at a given BSSID over time
>> (04:08:35 PM) _hc: we force the BSSID
>> (04:08:43 PM) dcbw: that doesn't work with all hardware
>> (04:08:47 PM) _hc: sad but true
>> (04:08:57 PM) dcbw: and there really isn't a good reason to do it
>> (04:09:28 PM) _hc: there are good reasons because that algo is fallable
>> (04:09:44 PM) _hc: well, for an established OLSR mesh, you know the BSSID, its
>> been there for years, or whatever
>> (04:09:59 PM) dcbw: oh, so it's a single global BSSID?
>> 16:10
>> (04:10:07 PM) dcbw: or each mesh has it's own defined BSSID?
>> (04:10:09 PM) _hc: sometimes the autoselection choses the BSSID of another new
>> node that is also starting the process of getting on the mesh
>> (04:10:27 PM) _hc: then they happen mesh together, but ignore the big one that
>> they really should be talking to
>> (04:10:41 PM) _hc: each mesh has its own BSSID
>> (04:11:11 PM) _hc: in bigger meshes, there are parallel meshes for optimization
>> (04:11:34 PM) _hc: so a private, encrypted backhaul mesh in parallel with a
>> public, unencrypted one
>> (04:11:44 PM) _hc: those are separate BSSIDs etc
>> (04:12:10 PM) _hc: often split by 2.4 and 5.0 GHz, but that's not so relevant here
>> (04:13:23 PM) dcbw: _hc: so back to adhoc wifi
>> (04:13:32 PM) dcbw: _hc: with adhoc, stations take turns beaconing
>> (04:13:50 PM) dcbw: _hc: a beacon is just a packet in the air that advertises
>> the adhoc (or master-mode) network
>> (04:14:23 PM) dcbw: _hc: it has a few parts; one standard part whose format
>> never changes, and then a variable part composed of IEs, which are just TLVs
>> (Type Length Value)
>> (04:14:53 PM) _hc: so i know about beaconing in terms of advertising in wifi,
>> but I've never toyed with that stuff, just read about it, and been aware of it
>> 16:15
>> (04:15:18 PM) _hc: ok, sounds promising
>> (04:15:18 PM) dcbw: ideally, OLSR would get a vendor ID assigned and then
>> could add an IE to the beacon so that anyone doing a scan could instantly know
>> it's an OLSR-capable network before they even tryto connect
>> (04:16:04 PM) _hc: getting a vendor ID sounds like a large, institutional process
>> (04:16:18 PM) dcbw: and there are only 256 of them :(
>> (04:16:30 PM) dcbw: there is a mechanism for extending though
>> (04:16:48 PM) _hc: is there a community wifi or hacker mesh vendor ID we can
>> share? :)
>> (04:17:01 PM) _hc: that's basically the devs of OLSR
>> (04:18:33 PM) jreznik_ left the room (quit: Read error: Operation timed out).
>> (04:19:51 PM) dcbw: _hc: does OLSR have an IEEE OUI?
>> 16:20
>> (04:21:38 PM) _hc: my guess is no, but let me look
>> (04:22:16 PM) dcbw: there's a vendor-specific IE, which is defined to be
>> whatever you want, but you need an IEEE OUI first
>> (04:22:36 PM) _hc: fyi, I don't think OLSR is incorporated itself, its just
>> the name of a IETF protocol with one main implementation: olsrd http://olsr.org
>> (04:22:42 PM) _hc: there are a bunch of orgs involved
>> (04:22:48 PM) _hc: and some military contractors
>> (04:23:31 PM) dcbw: might make sense to get one so this specific issue can be
>> made smoother for users, otherwise this sort of thing never gets better...
>> (04:23:52 PM) dcbw: at least on Linux it seems fairly easy to send the beacon
>> template that could include the OLSR IE
>> (04:24:05 PM) dcbw: in any case, that's the future (ideally)
>> (04:24:31 PM) dcbw: then everything can be automatic
>> 16:25
>> (04:25:00 PM) dcbw: for OLPC we just used link-local iPv4 addresses
>> (04:25:38 PM) dcbw: of which there are 64k
>> (04:26:33 PM) _hc: does the OLPC mesh route to the internet too?
>> (04:27:06 PM) dcbw: yes, through mesh portals
>> (04:27:35 PM) dcbw: but the point of all that is, non-802.11s OLPC meshing has
>> a known SSID so when connecting we know exactly what to do
>> (04:27:42 PM) _hc: so its a minor abuse of the link-local addresses to connect
>> them to the internet, no?
>> (04:27:44 PM) dcbw: which isn't the case for OLSR
>> (04:27:58 PM) dcbw: _hc: at least when I was working on that stuff, the portal
>> NAT-ed everyone to the internet
>> (04:28:40 PM) dcbw: so for OLSR, the core problem is that you don't know it's
>> OLSR until after you've connected, which isn't a great user experience because
>> you need to know it's OLSR so you don't try DHCP or something by default
>> (04:29:12 PM) _hc: right
>> (04:29:29 PM) dcbw: at the moment it's looking more like this is more a L3+
>> issue than anything wifi related
>> (04:29:38 PM) _hc: then either olsrd will already be running, or nm needs to
>> trigger it to start
>> 16:30
>> (04:30:01 PM) _hc: if olsrd is running, it'll see the change in the net if,
>> and respond by broadcasting to find other nodes
>> (04:30:25 PM) dcbw: can also be  done through dispatcher scripts, assuming
>> olsrd has some sane control interface
>> (04:30:39 PM) dcbw: and doesn't need to be restarted on every network change
>> (04:30:43 PM) _hc: I can write a sane control interface :)
>> (04:30:47 PM) _hc: it probably doesn't exist
>> (04:31:09 PM) dcbw: there are 3 core problems I see here:
>> (04:31:28 PM) dcbw: 1) how we're supposed to know that the network is running
>> OLSR so we can do (2) and (3)
>> (04:31:50 PM) dcbw: 2) after associating, we need a specific IP configuration
>> method when using OLSR
>> (04:31:57 PM) dcbw: 3) something needs to kick olsrd
>> (04:32:10 PM) dcbw: if (1) gets solved, then (2) and (3) are easy
>> (04:32:32 PM) dcbw: but (1) has to get solved in a way that doesn't
>> necessarily require more checkboxes every time you connect to an adhoc network
>> (04:32:57 PM) dcbw: and ideally also doesn't require editing a config file
>> somewhere, since that's pretty much the opposite of easy to use
>> (04:32:58 PM) jheretic [~jheretic at 64.124.162.98] entered the room.
>> (04:33:18 PM) dcbw: which is why the beacon IE is a nice solution
>> (04:33:45 PM) _hc: dcbw: so what about this approach: we make it easy to have
>> pre-configured meshes, then if the BSSID and channel match, it'll do its OLSR
>> thing
>> (04:33:50 PM) _hc: so its a manual approach to #1
>> (04:34:01 PM) _hc: but once in place will provide full auto-detect
>> (04:34:50 PM) _hc: it would also hopefully mean that once people figure out
>> how to do good full auto detect of OLSR meshes, the nm code wouldn't have to
>> change much
>> (04:34:55 PM) _hc: since 2 and 3 would be the same
>> 16:35
>> (04:35:18 PM) dcbw: if you're going the preconfigured route, then this gets
>> easier since you can just tell NM that it's OLSR instead of doing BSSID and
>> channel matching
>> (04:35:32 PM) dcbw: as in olsr=true or whatever for the network config
>> (04:35:58 PM) dcbw: _hc: then it's pretty easy
>> (04:36:12 PM) dcbw: _hc: NM has a 'dispatcher' functionality that calls
>> scripts in /etc/NetworkManager/dispatcher.d
>> (04:36:21 PM) dcbw: and it passes a lot of information in the environment
>> (04:36:30 PM) _hc: I mean that a user could download  a package of OLSR
>> configs that plug into NM
>> (04:36:32 PM) dcbw: which could potentially include OLSR=true or whatever
>> (04:36:51 PM) dcbw: hmm, potentially
>> (04:36:52 PM) _hc: then when NM sees an adhoc net that matches the profile,
>> it'll automatically set it up as an OLSR mesh
>> (04:38:10 PM) dcbw: is the IP addressing scheme well-defined?
>> (04:38:14 PM) dcbw: or is it site-specific
>> (04:38:29 PM) _hc: can this dispatcher mode pre-screen things? like I click on
>> "commotionwireless.net" in the Wireless Networking list, then some code
>> somewhere check it, and says "this is OLSR, config it as such", then it skips
>> the normal wiif config?
>> (04:38:41 PM) _hc: its mesh-specific, that would be part of the profile
>> (04:38:42 PM) dcbw: not at this time, no
>> (04:39:08 PM) dcbw: so what all is part of the profile?
>> (04:39:29 PM) _hc: SSID, BSSID, channel, ip-scheme, olsrd.config
>> 16:40
>> (04:40:05 PM) dcbw: and what are the IP schemes?
>> (04:40:31 PM) dcbw: (as in, what specifically is the addressing randomization
>> algorithm, and what ranges of IP does "ip-scheme" allow?)
>> (04:41:53 PM) _hc: since the meshes are all run by various groups, they range
>> from static IPs to random within a range, a range with last bytes of MAC,
>> ahcpd, etc
>> (04:43:35 PM) _hc: it seems to me that NM only needs to know about BSSID and
>> channel, then the olsr logic would handle the rest
>> (04:44:03 PM) _hc: I mean in terms of marking an ahdoc  as an OLSR mesh
>> (04:44:38 PM) dcbw: well, NM handles the IP configuration on the interface too
>> (04:44:45 PM) dcbw: and stuff like DNS
>> (04:44:55 PM) dcbw: so NM would be doing the actual IP configuration, more orless
>> 16:45
>> (04:45:09 PM) _hc: ok
>> (04:45:14 PM) _hc: makes sense
>> (04:45:25 PM) dcbw: btw where does the station get DNS servers from?
>> (04:45:39 PM) _hc: that's also part of the mesh config
>> (04:45:58 PM) dcbw: so they're static?
>> (04:45:59 PM) _hc: some are static, some use advertisments on the mesh
>> (04:46:03 PM) dcbw: ah
>> (04:47:06 PM) _hc: would it be possible to make dhclient kind of scripts that
>> NM delegates to?
>> (04:47:41 PM) dcbw: not in the way you're thinking, but having more hooks into
>> the mechanisms is an enhancement goal
>> (04:48:22 PM) _hc: so with NM, is dhclient the only mechanism for using some
>> external thing to config IP and DNS?
>> (04:48:51 PM) dcbw: _hc: or avahi-autoip, or IPv6 router advertisements, or
>> static configuration
>> (04:48:57 PM) dcbw: _hc: or PPP
>> (04:49:00 PM) dcbw: _hc: or VPNs
>> (04:49:39 PM) _hc: so it seems that OLSR meshes with specific needs could make
>> a kind of avahi-autoip as part of the config
>> 16:50
>> (04:50:06 PM) dcbw: yeah, that would be the idea, though we'd want to do this
>> more formally in NM
>> (04:50:18 PM) dcbw: well, with a more formal modular structure
>> (04:50:57 PM) dcbw: quite a few things want something like this
>> (04:50:59 PM) _hc: is there way in NM to have it ask something external for
>> the IP/DNS info, then it handle the actual setting of the interface, etc?
>> (04:51:03 PM) _hc: is that waht you mean?
>> (04:51:23 PM) _hc: that would be very nice for the OLSR mesh stuff, then the
>> IP config could be represented in a little script
>> (04:51:33 PM) _hc: that generates the numbers
>> (04:51:34 PM) dcbw: _hc: that's exactly how dhcp, autoip, ipv6, ppp, and vpn
>> already work, just that they're more or less hardcoded into NM
>> (04:51:43 PM) _hc: ah, I see
>> (04:51:49 PM) dcbw: _hc: you'd want more than a "little script"
>> (04:52:06 PM) dcbw: since that "plugin" if you will would also be responsible
>> for getting DNS, possibly from advertisements
>> (04:52:16 PM) dcbw: and thus would need to listen for them
>> (04:53:16 PM) _hc: so any suggestions on where I should start on this?  do you
>> think it'll only be possible with modifications on NM itself, or would any
>> kind of "plugin" be an option?
>> (04:53:33 PM) _hc: I looked at the VPN Plugins, they seem to tied to the idea
>> of a VPN
>> (04:54:02 PM) _hc: but if the VPN plugins can handle the BSSID/channel stuff,
>> it might be one way to get started
>> (04:54:22 PM) dcbw: _hc: vpns have to layer on top of existing hardware
>> connections so they wouldn't really be suitable
>> (04:54:29 PM) dcbw: _hc: we'd want the best way of fixing it :)  which would
>> mean plugins, really
>> (04:54:38 PM) dcbw: which needs some architecting thought
>> 16:55
>> (04:55:01 PM) dcbw: since you'd want the ability for plugins at different
>> levels of the process, and the ability to pass information back and forth
>> (04:55:09 PM) jheretic left the room (quit: Ping timeout: 244 seconds).
>> (04:56:09 PM) _hc: I've been employed to work on this stuff, so I'm happy to
>> dig in wherever you think is helpful
>> (04:56:19 PM) dcbw: _hc: and that would be excellent
>> (04:56:34 PM) _hc: in case you are interested, I'm working as part of this;
>> https://commotionwireless.net/
>> (04:56:55 PM) dcbw: cool
>> (04:57:03 PM) _hc: the only rub is that my wife is due anyday so I'm going to
>> disappear for 6ish weeks once the baby comes :-D
>> (04:57:10 PM) dcbw: heh :)
>> (04:57:17 PM) dcbw: congratulations
>> (04:57:18 PM) _hc: perfect time to start a new project ;)
>> (04:57:19 PM) _hc: thanks
>> (04:57:31 PM) dcbw: any day you'll be starting a new project :)
>> (04:57:41 PM) dcbw: one that will last a looooooong time
>> (04:57:48 PM) _hc: hehe, I have one already, so its just adding to the
>> maelstrom :)
>> (04:58:28 PM) _hc: by the way, some of the pauses in this convo were from my
>> 15 month old son insisting on turning my monitor on and off
>> (04:58:48 PM) _hc: he's little so he can sneak up
>> (04:58:52 PM) dcbw: _hc: so lets stop thinking about OLSR specifically and
>> starting thinking more generally about how to make it work the best way that
>> OLSR can also integrate with
>> (04:59:11 PM) _hc: ok, sounds good
>> 17:00
>> (05:00:23 PM) dcbw: _hc: first is to define that generic plugin interface
>> including how plugins register themselves for certain hooks, how plugins can
>> attach information to the interface activation process (ie, connecting) and at
>> what points they get asked to do things
>> (05:01:27 PM) dcbw: it might be as simple as passing the NMConnection to each
>> plugin at each step and asking if the plugin wants to do something
>> (05:01:36 PM) dcbw: which is basically how it works internally
>> (05:01:45 PM) dcbw: internally there are 5 steps
>> (05:01:57 PM) _hc: ok, fyi, I'm a long time NM user, and have done a little NM
>> scripting with dbus, but the dev is new to me.  but I've been doing C for 10+
>> years, and was a network manager before that, so I'm not starting from nothing ;)
>> (05:02:16 PM) dcbw: good to hear :)
>> (05:03:04 PM) _hc: I'll see if I can check out the code in parallel
>> (05:03:05 PM) dcbw: each step can return SUCCESS (everything already done,
>> like static IP where we just set the IP address and return), POSTPONE (ie dhcp
>> where we need to start dhcp and then wait for the answer to come back maybe 30
>> seconds later) and FAILURE (something went wrong, fail the interface)
>> (05:03:32 PM) dcbw: we also have some things that are really global plugins,
>> like for DNS handling
>> (05:03:37 PM) _hc: what if the plugin doesn't want to do anything?
>> (05:04:10 PM) _hc: like for the OLSR plugin: "is this adhoc? no, then
>> nevermind..."
>> (05:04:23 PM) dcbw: _hc: that's just the general way things work right now;
>> we'd want a more formalized mechanism for the plugin interface itself
>> (05:04:30 PM) dcbw: but it's a fairly good mapping so far
>> 17:05
>> (05:05:06 PM) dcbw: eventually we'd turn some of the internal stuff into
>> plugins as well
>> (05:05:39 PM) dcbw: like the avahi-autoipd IPv4 stuff is a great candidate
>> (05:05:53 PM) _hc: ok, so this is something already in the works?
>> (05:06:01 PM) dcbw: no, just been thinking about this for a while
>> (05:06:15 PM) dcbw: and how to best make it happen
>> (05:06:26 PM) dcbw: with minimal disruption
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>>
> 
> 
> 