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

Hans-Christoph Steiner hans at guardianproject.info
Wed Oct 24 21:47:24 UTC 2012


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



More information about the Commotion-dev mailing list