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

[Hans of Guardian]

Now that I'm back from paternity leave and getting sleep (waking up only once a night!), I'm ready to dive back in.  Did anyone have any luck tracking down an OUI?

.hc

On Oct 26, 2012, at 10:57 AM, Josh King wrote:

> Seems like we can try both. Will is currently looking into finding out
> whether there's an allied organization that might have an OUI, whom we
> could reach out to about using it for this purpose. Otherwise, we may
> look into whether OTI can just pay for one for Commotion. This could be
> independent of the rest of the discovery and configuration piece.
> 
> On 10/24/2012 09:19 PM, Jeremy Lakeman wrote:
>> 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
>>>>> 
>> 
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> http://lists.chambana.net/mailman/listinfo/commotion-dev
>> 
> 
> -- 
> Josh King
> 
> "I am an Anarchist not because I believe Anarchism is the final goal,
> but because there is no such thing as a final goal." -Rudolf Rocker
>