[RFC] WPA Supplicant plugins
Wed Aug 17 13:32:18 PDT 2011
We have been thinking about extending the supplicant to support additional L2 protocol modules w/o they being tightly integrated within the supplicant. This could improve long term maintainability of the supplicant and affords some freedom to such protocol developers. Likewise we thought of introducing a concept of binary loadable library like plugins implementing such protocols and providing with appropriate interfaces to allow enabling the protocol plugs.
- Functional extensions need to be coded in the supplicant.
* Pollutes supplicant, cannot upstream, requiring constant rebasing with upstream
- Segregation of custom functionality xlates into RPC hop based separation
* Performance or platform/environment constraints can make it infeasible
- Lack of proper published API leads to inconsistency across various interfaces
- RPC interfacing code intertwined with core
- Cleanly segregated from supplicant while being in-process
* Plugs can be compiled independently
- Load decision can be run-time* (can also be statically linked)
- Minimal changes to supplicant
- Creates a formal, public supplicant API
* Promotes consistency and allows for conscious extensibility
* Shields supplicant and plugins from internal changes on either sides.
Scope and Design:
- Presently confined to control plane functionality (upper edge).
- Plugins are shared libraries exposing some std interface to allow loading, init/de-init by supplicant
- Supplicant supports explicit subscription based event model
- Plugins access supplicant functionality using published Supplicant APIs
- Plugins define and expose a 'plugin' structure that contains plugin's version* and pointers to entry point methods for
* Initialization: invoked during supplicant init
* Un-initialization: invoked before supplicant shutdown
* Interface added: invoked when supplicant starts managing a new interface.
* Interface removed: invoked when an interface is removed in supplicant.
(version mismatches only generate warning log message)
- Supplicant hands out a global handle and an API v-table when invoking plugin's initialization method.
* Allows transparent interception (if needed for certain applications).
- Supplicant hands out an interface-plugin specific handle during interface added callback.
- Plugins can add/remove interfaces along with invoking interface specific functionality (scan, etc).
- Plugins are expected to register for any events of interest by supplying an event callback method.
- Supplicant invokes each of the registered callback for a given event.
- Plugins invoke supplicant APIs using actual supplicant handles (global or interface specific).
* No changes to existing supplicant implementation
* The handles are still opaque to plugins
* certain existing types are part of the Supplicant API/interface.
- Plugins have ability to store and retrieve interface specific private data.
- Necessary changes for plugin support are completed and unit tested
* Aligned with recent versions of upstream code.
- D-Bus module, with old and new interfaces, has been converted into a 'static' plugin. This was chosen to demonstrate the concept with something that is being used in real life.
- WIP on an Intel internal plugin
- API Design: Uses accessor methods for access to fields of opaque types (e.g. struct wpa_supplicant) from among other choices and was not the preferred choice. The API footprint is large due to get_* type methods. Pl refer to README, available at the link below, for some more info on it
Available at http://intellinuxwireless.org/supplicant_plugin_patches/
More information about the Hostap