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

Wed Oct 24 23:02:37 UTC 2012

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
>

-- 
Ben West
me at benwest.name