Вопрос Как ограничить подключение wifi клиентов по mac?

[Алексей.]

Как ограничить подключение wifi клиентов?
Необходимо ограничить подключение wifi клиентов по mac-адресу.
Сейчас при попытке подключения wifi клиента при выполнении аутентификации на тасках, который запущены на ядре 0, происходят существенные задержки, что приводит к ошибкам при обмене по spi (модуль работает слейвом), что не удивительно.
Можно ли вообще фильтровать клиентов, не допуская их аутентификацию?

 

[pvvx]

Можно ли вообще фильтровать клиентов, не допуская их аутентификацию?

При текущей реализации WiFi драйвера - нельзя. Только после подключения будет доступен MAC клиента.
Исходников и информации по libcoexist.a, libcore.a, libespnow.a, libnet80211.a, libphy.a, libpp.a, librtc.a, libsmartconfig.a, libwpa.a, libwpa2.a, libwps.a, libbtdm_app.a, libhal.a не предоставляется.
ESP - это закрытый проприетарный проект.
Обойти это можно несколькими путями. Основной - "реинженеринг". Но смысла заниматься им с ESP-32 нет из-за наличия более доступных альтернативных решений.

 

[pvvx]

Вам следует попробовать и разобрать события и данные выдаваемые драйвером WiFi.
esp-idf/esp_wifi_types.h at master · espressif/esp-idf · GitHub
Возможно, через них будет вариант встроить фильтрацию клиентов по MAC...

 

[Алексей.]

При текущей реализации WiFi драйвера - нельзя. Только после подключения будет доступен MAC клиента.

Странно, на смартфоне ввожу неправильный psk, в логах на есп32 вижу что клиент с мак-адресом подключен, хотя аутентификация ещё не выполнена.
Скажу больше, я обрабатывал событие SYSTEM_EVENT_AP_STACONNECTED в котором пытался определить выданный ip, но в этот момент адрес ещё не выделялся этому клиенту, ip адрес был доступен спустя полсекунды или около того (я думаю после выполнения аутентификации).

 

[pvvx]

Странно, на смартфоне ввожу неправильный psk, в логах на есп32 вижу что клиент с мак-адресом подключен, хотя аутентификация ещё не выполнена.
Скажу больше, я обрабатывал событие SYSTEM_EVENT_AP_STACONNECTED в котором пытался определить выданный ip, но в этот момент адрес ещё не выделялся этому клиенту, ip адрес был доступен спустя полсекунды или около того (я думаю после выполнения аутентификации).

WiFi и ethrent тут при чем? WiFi в данной случае транспортный протокол. IP и прочее - это к нему не относится.
У WiFi источник и получатель описывается MAC, а не IP.
В стандартном заголовке фрейма WiFi для данных присутствуют поля для 3-х MAC, а какие вложенные данные - пакеты с IP или их куски, или ещё что - ему без разницы.
Сшиванием и выделением IP пакетов занимается прослойка между WiFi (драйвер) и LwIP.

 

[Алексей.]

Когда аутентификация ещё не выполнена в логах вижу mac:bla-bla join
мак уже виден, вот что я хотел сказать, а аутентификация и не выполнится вовсе, потому как psk не тот.

 

[pvvx]

Когда аутентификация ещё не выполнена в логах вижу mac:bla-bla join
мак уже виден, вот что я хотел сказать, а аутентификация и не выполнится вовсе, потому как psk не тот.

Ну вот на том уровне и надо скипнуть ненужное соединение по фильтру MAC.
В принципе достаточно фильтра на все входящие пакеты WiFi от разрешенных MAC, а остальные просто откидывать.
А система ESP-IDF и сама SDK разрабатывается для задач Arduino и не содержит ничего другого. Это и есть сфера применения ESP чипов (на большую они не тянут).
В Arduino нет спецификации и стандартов на подключение к WiFi клиентов по приоритетам и маскам, как и выбора связи по приоритетам с списком AP. В задачи пользователя Arduino это не входит.
Разная целевая аудитория - соединять разрешенные кубики, а вы последнее время требуете от этой системы уровня открытости и возможностей Linux. По этому никакие реальные задачи на ESP-IDF не решить, кроме повторов "скетчей" предоставленных авторами системы.
Что бы появилось что-то новое в данной системе, необходимо предоставить прецедент в другом (альтернативном) исполнении (конкуренция). Если аудитории он придется, то его встроят (скопируют) в ESP-IDF.

 

[Алексей.]

никакие реальные задачи на ESP-IDF не решить, кроме повторов "скетчей".

А нафига 2 ядра, возможность разнесения тасков по ядрам, в ардуине ведь это не требуется, лампочками моргать и данные собирать (1-wire, i2c) и всё?
Даже как то оптимизьм пропадает...

 

[pvvx]

А нафига 2 ядра, возможность разнесения тасков по ядрам, в ардуине ведь это не требуется, лампочками моргать и данные собирать (1-wire, i2c) и всё?
Даже как то оптимизьм пропадает...

Оптимиз пропадает когда не исполняется что-то. А тут прямая зависимость от политики Espressif. Закрытый код используется для привязки вас в зависимость от них, хотя никто не собирается повторять их убогий на сегодня чип (к другим чипам он совершенно не подходит).
Но решить то задачу фильтрации вы можете, подумаешь что это выйдет кривой костыль к данной системе, он же "работать" будет как-то...

 

[Алексей.]

При подключении в обработчике событий вызываю deauthenticate (на любой мак) по аид-у, клиенты не соединяются, но таски на нулевом ядре всё равно лАгают.

static esp_err_t event_handler(void *ctx, system_event_t *event) {
    switch(event->event_id) {
    case SYSTEM_EVENT_AP_STACONNECTED: {
       // TODO check staconnected->mac
       system_event_ap_staconnected_t *staconnected = &event->event_info.sta_connected;
       ESP_ERROR_CHECK(esp_wifi_deauth_sta(staconnected->aid));
       break;
    }
    }
    return ESP_OK;
}

В логах вижу: I (92362) wpa: Station left, stop send EAPOL frame
На клиенте: "Ошибка аутентификации"

 

[pvvx]

При подключении в обработчике событий вызываю deauthenticate (на любой мак) по аид-у, клиенты не соединяются, но таски на нулевом ядре всё равно лАгают.

Из калбака event_handler() опять не все вызовы функций проходят (рекурсия и недоинициализированные переменные в других функциях - в итоге выдавало протектед)? На ESP8266 c этим уже боролись, со временем (в новой версии SDK) исправили - перенесли вызовы калбака на окончания процессов, стадий...
Или что лагает?
Надо дизасмить и менять какую-то функцию на свою, в цепочке подключения клиентов... Можно с помощью опции -Wl,--wrap=имя_функции...
Код у Espressif дров WiFi и 802.11 всё равно цельно-тянутый с мелкими изменениями и восстановить про что там, какие заголовки и структуры, последовательности вызовов без проблем по другим открытым источникам. Вот только время на эту тупую работу надо, да перспективы от неё нет с ESP-32.
Пишите авторам и требуйте подключение фильтра по МАС Во всех роутерах это есть.
На RTL-ки к SDK даны (есть в mbed) все заголовки всех процедур и структур данных дров WiFi и хидеры описания самой аппаратной части WiFi. По этому я не хочу мучаться с ESP-32.

 

[pvvx]

В RTL существуют функции в wifi_util.c
int wext_init_mac_filter(void);
int wext_deinit_mac_filter(void);
int wext_add_mac_filter(unsigned char* hwaddr);
int wext_del_mac_filter(unsigned char* hwaddr);
Они оперируют с объектом List (список), указатель на который передается в переменную [inline]mf_list_head[/inline].
В [inline]int OnAuth(_adapter *padapter, recv_frame *precv_frame)[/inline] (т.е. при авторизации к AP) указатель mf_list_head опрашивается и если назначен список, то MAC с ним сверяется и принимается решение - разрешить или нет...

 

[Алексей.]

pvvx, Давно уж на rtl-ки заглядываюсь, arm-cm3 очень привлекателен, у Вас в Питере rtl-ки в магазинах продают а у нас не очень, всё никак не соберусь в свою деревню заказать

 

[pvvx]

pvvx, Давно уж на rtl-ки заглядываюсь, arm-cm3 очень привлекателен, у Вас в Питере rtl-ки в магазинах продают а у нас не очень, всё никак не соберусь в свою деревню заказать

Дык я к тому, что это очень просто реализуется. Кланяйтесь разработчикам ESP-IDF - может они впишут нечто подобное. У них все исходники есть и вставить пару строк не долго.