Ещё интересность. Тут сделано всё несколько хитрее.Обычно практикуется 2 подохода:
SME/MLME в драйвере а суппликант лишь нахлобучка, всё это связывается и управляется через WEXT который не позволяет перетащить SME/MLME на сторону суппликанта. Иногда даже и суппликант или hostapd (если AP) не нужен, как у нас в софте например.
Самая часто используемая схема на клиентах. В т.ч. QCA её практикует. Из плюсов всё в одном месте, все данные по линку и т.д. доступны в любое время не надо дёргать юзерспэйс который может стоять колом из-за взглючевшего приложения и т.д.
Вторая схема это использование NL802.11 интерфейса с переносом SME/MLME на сторону суппликанта (как в заметке моей рядом по интелам).
Из плюсов, можно заставить делать то, что драйвер не умеет. Единый код независимо от чипа на стороне суппликанта и т.д.
Минусы - если кто-то сожрал весь проц пиши пропало вплоть до отвала соединения.
Тут похоже используется третий подход.
SME/MLME на стороне драйвера, управление через суппликант, но часть MLME включая роаминг перетащена на сторону суппликанта. В драйвере храниться кэш PMK для станций на которых побывали, кэши сканов и т.д., но именно решение куда мигрировать и как принимает суппликант.
При этом используется "собственное расширение" активируемого по флагу читаемому через ioctl.
Т.е. тут ещё и суппликант пропатчен. Т.е. что бы разобраться полноценно в критериях нужно ещё и сырцы патченного суппликанта иметь.
Кто-то сильно заморочился. Видимо пилили под прохождения сертификации по программе о которой упоминал выше.
Сейчас пока нет времени глубоко вдаваться, может через месяцок полегче будет.
Пока разве что можно попробовать поиграться параметрами озвученными выше через CSC оно всяко через IOCTL их и дёргает.
Кому не лень - попробуйте.
