Client MLME for non-Linux OS

[Neil Cafferkey]

On Tue, Jan 05, 2016 at 12:03:22PM +0200, Jouni Malinen wrote:
> On Tue, Jan 05, 2016 at 07:10:42AM +0000, Neil Cafferkey wrote:
> > A few years ago I ported wpa_supplicant V0.7.3 to AmigaOS, MorphOS and
> > AROS. At the time, I found it convenient to use the built-in MLME code,
> > as the host OSes' network stacks are still Ethernet based.
> > 
> > At that time, my wireless drivers only supported the 802.11g standard and
> > earlier, and the built-in MLME worked quite well. However, as I now want
> > to add support for 802.11n, it looks like I need enhanced MLME code. The
> > problem of course is that the MLME code has been removed from current
> > versions of wpa_supplicant.
> 
> Where do the actual hardware drivers come for these operating systems?
> In practically all other cases I've heard of, that driver code (and/or
> firmware or kernel 802.11 stack) implements MLME for production use..

So far, they have been written from scratch for these OSes (apart from the
use of the Atheros HAL). The drivers conform to an Ethernet-era
OS-specific API called SANA-II. The TCP/IP stack therefore sees them as
Ethernet drivers.

> 
> > I'd be grateful for any advice on how I should proceed. I would consider
> > enhancing the built-in MLME code myself, but would there be any
> > possibility of merging these changes back into the trunk? IMHO the
> > removed code was useful for alternative OSes in general. Although
> > wpa_supplicant was designed to be cross platform, its current direction
> > appears to be more Linux-centric.
> 
> I would disagree with that last note, but other than that, I have not
> heard of any other production case where the WLAN driver would not
> provide the MLME functionality. If there were multiple such cases, it
> could be reasonable to see if common code within wpa_supplicant could be
> shared, but lacking such, I don't see why wpa_supplicant would be the
> place to maintain this code.

Yes, I could add MLME code directly to my soft-MAC drivers, but there are
two disadvantages to this: code duplication, and potentially having to
implement MLME from scratch. To avoid duplication, I could put the code in
a shared library (which is conceptually similar to mac80211 as far as I
understand it), but I think it would be tidier to have all shared wireless
code in one module, i.e. wpa_supplicant. After all, doesn't wpa_supplicant 
already have functionality beyond the requirements of a WPA supplicant?
E.g. it negotiates unencrypted and WEP connections.

> 
> > Where is the MLME functionality located when wpa_supplicant is used in
> > OSes such as the BSDs, Windows, etc.? Or do they all have ports of
> > mac80211 (I believe Haiku does for example)?
> 
> BSDs have their own 802.11 stack, Windows used to have both MLME and SME
> in the drivers and may still use that design.
> 
> > Also, in case I'm misunderstanding my problem, could someone confirm that
> > it is the MLME's role to decide that 802.11n modes should be used and to
> > tell the driver the MCS to use? (The MLME in 0.7.3 does not seem to
> > contain this functionality.)
> 
> MLME here refers to the part of constructing and parsing authentication
> and association management frames. SME would be the entity taking care
> of actual decisions on what to do with that information.

Thanks. I assume mac80211 implements the SME role.

Regards,
Neil