Ещё интересность. Тут сделано всё несколько хитрее.

Обычно практикуется 2 подохода:

SME/MLME в драйвере а суппликант лишь нахлобучка, всё это связывается и управляется через WEXT который не позволяет перетащить SME/MLME на сторону суппликанта. Иногда даже и суппликант или hostapd (если AP) не нужен, как у нас в софте например.

Самая часто используемая схема на клиентах. В т.ч. QCA её практикует. Из плюсов всё в одном месте, все данные по линку и т.д. доступны в любое время не надо дёргать юзерспэйс который может стоять колом из-за взглючевшего приложения и т.д.

Вторая схема это использование NL802.11 интерфейса с переносом SME/MLME на сторону суппликанта (как в заметке моей рядом по интелам).

Из плюсов, можно заставить делать то, что драйвер не умеет. Единый код независимо от чипа на стороне суппликанта и т.д.

Минусы - если кто-то сожрал весь проц пиши пропало вплоть до отвала соединения.

Тут похоже используется третий подход.

SME/MLME на стороне драйвера, управление через суппликант, но часть MLME включая роаминг перетащена на сторону суппликанта. В драйвере храниться кэш PMK для станций на которых побывали, кэши сканов и т.д., но именно решение куда мигрировать и как принимает суппликант.

При этом используется "собственное расширение" активируемого по флагу читаемому через ioctl.

Т.е. тут ещё и суппликант пропатчен. Т.е. что бы разобраться полноценно в критериях нужно ещё и сырцы патченного суппликанта иметь.

Кто-то сильно заморочился. Видимо пилили под прохождения сертификации по программе о которой упоминал выше.

Сейчас пока нет времени глубоко вдаваться, может через месяцок полегче будет.

Пока разве что можно попробовать поиграться параметрами озвученными выше через CSC оно всяко через IOCTL их и дёргает.

Кому не лень - попробуйте.