On Tue, Apr 5, 2011 at 1:28 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2011-04-05 at 11:05 -0700, Javier Cardona wrote: > >> We would like to preserve the ability to join an open mesh without a >> daemon, in the same way that a station can associate with an AP >> without one. > > Keep in mind that even the station case on an open or WEP network is > pretty useless since it will not reconnect if the connection drops, or > do any sort of roaming. > >> With that goal in mind, the alternatives are to >> duplicate the MPM in userspace or to reuse the in-kernel MPM with only >> AMPE in userspace. Considering that AMPE uses MPM frames and state >> machines, reusing the in-kernel MPM is a significantly lower effort >> alternative. Furthermore, while working on AMPE we can also bring the >> in-kernel MPM up to spec. >> Of course this requires agreeing on a suitable API between MPM and >> AMPE. If you don't like the generic one I proposed we can try to >> define a mesh-specific alternative. But first, setting aside the API change >> proposal, do you object to this AMPE-in-userspace/MPM-in-kernel partition? > > After thinking about this more, yes, I think I do object. Not only is > the design strange with passing frames back and forth, but also it seems > like a rather slippery slope, at some point I fear somebody will attempt > to "fake" MPM to take advantage of that kernel code even when it's not > really fitting. The above seem to be concerns with the API itself and not with partitioning. We could make the API specific for mesh peering frames in a way that cannot be used for any other purpose other than protecting mesh peering frames. > Since practically speaking, wpa_supplicant is already required for > almost everything, I don't see any real disadvantages to duplicating the > MPM state machine there, and starting to deprecate the one in the kernel > over time with new features only available in userspace one, maybe even > removing it at some point. I realise this is a little more short-term > effort, but I think the long-term benefit probably outweighs it. I know of a few mesh use cases where wpa_supplicant is not required, such as resource constrained embedded platforms like the ones used in sensor networks. But hey, we'll re-evaluate the wpa_supplicant route and see if it is doable. Thanks for the comments, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
