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

Thu Oct 25 01:19:26 UTC 2012

I was mainly thinking of deferring that problem to the user.

We don't announce which networks have a usable internet connection
either (yet), which is a similar problem that we already delegate to
the user.

On Thu, Oct 25, 2012 at 10:29 AM, Hans-Christoph Steiner
<hans at guardianproject.info> wrote:
>
>
> On 10/24/2012 07:03 PM, Jeremy Lakeman wrote:
>> A pre-association test would be great. A beacon IE message sounds
>> interesting. Wifi-Direct service discovery might also be useful, but I
>> don't know if it's possible while still connected to an adhoc network.
>
>
> Sounds like we either need a wifi vendor ID or an IEEE OUI to do that.
> Getting a wifi vendor ID sounds basically impossible, but perhaps not an IEEE
> OUI.  Isn't there someone at Battlemesh who had one for this stuff?
>
>
>> Assuming we can't get that to work, or to support current devices that
>> have no hope of that working, what about the following;
>>
>> associate with adhoc network
>> try dhcp / adhcp
>> fall back to link local IPv4 (+IPv6?)
>> send probe broadcast UDP packet to well known port (repeat a few times)
>>
>> any mesh routing daemons respond with a packet in a well defined format like;
>>
>> header
>> - format version
>> - protocol type (olsr, batman, experiment#3, serval, ...)
>> - message to display to user if protocol unknown (eg "See olsr.net for
>> more info")
>>
>> generic IP config
>> - IP / netmask
>> - DNS
>> - etc
>>
>> optional protocol specific config
>> ...
>>
>> Once the network is up, you keep the link local IP address so you can
>> respond to similar requests.
>
> We discussed that in the conversation below.  Upon thinking about it more, I
> think it is not workable since that means NetworkManager would have to attach
> to every adhoc network it sees in order to provide a scan of which networks
> are OLSR-capable.  That could easily make the scanning very slow and error
> prone since you'd have to wait for a lot of timeouts before you could do
> anything else with the network interface.
>
> .hc
>
>
>> On Thu, Oct 25, 2012 at 8:17 AM, 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
>>>