Создание сниффера на ESP32

Все началось с того, что однажды у нас в GS-Labs наметился проект по поиску багов и уязвимостей. Да вот только дошли слухи, что железка, где должно работать приложение, будет хитрая — нельзя поставить root, нет любимого Ethernet. «Органы управления» — только Wi-Fi да пультик управления на несколько кнопочек, а что будет передаваться по WiFi — неизвестно. А хакеры, как вы знаете, не любят неизвестности! Дома у меня валялись пара отладочных плат на основе ESP32 — ESP32-PICO-KIT, и я решил сделать свой WiFi-сниффер — с блек-джеком и перспективой расширения до Bluetooth-сниффера!

Глоссарий

• AP (access point) — точка доступа.
• BSSID (basic service set identifier) — обычно MAC-адрес точки доступа.
• BSS (basic service set) — группа устройств, которые успешно синхронизированы для общения с помощью 802.11.
• DA (destination address) — MAC-адрес конечного назначения.
• DS (distribution system) — система, объединяющая BSS и LAN.
• ESS (extended service set) — несколько BSS, объединенных в единое целое, образующее DS.
• MPDU (MAC protocol data unit) — фактически это фрейм 802.11.
• MSDU (MAC service data unit) — payload, который содержит IP-пакет + данные LLC.
• PLCP (physical layer convergence procedure) — подуровень (физический уровень PHY делится в 802.11 на две части), который отвечает за подготовку к отправке фрейма, поступившего с MAC-уровня.
• PSDU (PLCP service data unit) — считай, то же самое, что и MPDU, только MPDU смотрим «сверху вниз» по модели OSI, PSDU — «снизу вверх» по модели OSI.
• SA (source address) — MAC-адрес исходного отправителя.
• STA (station) — любое устройство, поддерживающее 802.11, например твой смартфон, ноут или «малинка» (Raspberry Pi 3).

Техническая база

Думаю, ни для кого не секрет, что бал сегодня правят микроконтроллеры семейства STM32Fxxx (цифры и буквы на месте ххх означают класс устройства — от Ultra-low power до High Performance). Но пару лет назад появился «чудо-чип» под названием ESP32 — «старший брат» народного WiFi ESP8266.

РЕКОМЕНДУЕМ:
Как создать сетевой протокол

Изначально документация на этот чип была очень и очень скудна, но сейчас ситуация кардинально изменилась. Есть прекраснейший user guide, содержащий пошаговые инструкции по всем вопросам — от установки SDK и toolchain для этого микроконтроллера до описания его периферии. Все это приправлено массой примеров, выложенных на Гитхаб.

Надо отдать разработчикам должное, Espressif описывает, как устанавливать toolchain для популярных платформ:

Вся документация представлена в двух вариациях:

• ветка latest, которая включает все современные и передовые фичи SDK. Правда, они еще не оттестированы как следует;
• ветка stable (на момент написания статьи stable был 3.1.2), которая не содержит всех новинок, но рекомендована для production purposes.

Да, забыл упомянуть их шикарный форум, где можно обсудить вопросы, связанные с ESP32. Складывается впечатление, что техподдержка Espressif отвечает достаточно шустро.

В одной из наших статей (ссылка в начале статьи) мы уже упоминали этот чип, поэтому здесь я лишь кратко перечислю основные характеристики:

• 32-bit MCU Xtensa® single-/dual-core 32-bit LX6 microprocessor(s), который может работать в широком диапазоне частот;
  

  

• 520 Кбайт SRAM;
• «стандартный» набор периферии, представленный в виде UART/SPI/I2C, SDcard, Ethernet MAC (RMII), CAN2.0;
• WiFi (802.11b/g/n);
• Blueooth (Bluetooth v4.2 BR/EDR and BLE specifications).

Фанатам ассемблера производитель сделал царский подгон, любезно предоставив ULP (Ultra Low Power) сопроцессор, который кодится ассемблером и кушает до 150 мкА в режиме Deep-sleep (это для тех, кто хочет максимальной автономности). Да и вообще, не поленитесь заглянуть в даташит за деталями, там реально много интересного.

Кстати, если к этому моменту я уже внушил вам сильное желание обзавестись данным чипом и вы уже начали вспоминать пароль от «Алиэкспресса» и адрес ближайшего отделения Почты России, то не спешите. Удивительно, но разные варианты ESP32 можно купить у нас, причем порой это может оказаться дешевле и быстрее, чем заказывать из Китая. Например, вот такую двухсантиметровую штуку с возможностью подключения внешней антенны:

можно купить тут или тут примерно за четыре доллара.

Теория Wi-Fi (да, без нее не обойтись)

Возьму-ка я на себя очень амбициозную миссию: изложить три тысячи страниц стандарта в нескольких предложениях. Думаю, что у меня получится, отступать ведь все равно поздно?

Думаю, вы уже знаете, что WiFi — это «красивое» название, которое скрывает под собой целый набор стандартов 802.11. Вот лишь «некоторая часть» из них:

• 900 МГц — 802.11ah;
• 2,4 ГГц — 802.11b, 802.11g, 802.11n, 802.11ax;
• 3,6 ГГц — 802.11y;
• 4,9 ГГц — 802.11j;
• 5 ГГц — 802.11a, 802.11n, 802.11ac, 802.11ax;
• 5,9 ГГц — 802.11p;
• 45 ГГц — 802.11aj;
• 60 ГГц — 802.11aj, 802.11ay.

Поскольку для этого проекта нам нужно знание деталей, а не умение запустить magic-утилиту на wonderful-железке, давайте заглянем внутрь 802.11 поглубже. Итак, согласно IEEE 802.11—2012, MAC-фрейм имеет следующую структуру:

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

Frame Control

• Protocol version — согласно рассматриваемому стандарту, значение всегда 0. Остальные возможные значения зарезервированы.
• Type and Subtype — описывают тип и подтип фрейма. Всего существует три типа фреймов: Management, Data, Control с подтипами.

О том, какие бывают Management-, Control- и Data-фреймы, вы прочтете, как только закончим рассматривать MAC-заголовок 802.11.

• TO_DS, FROM_DS – их стоит рассматривать вместе, и они отвечают за то, как интерпретировать поля Address 1 … Address 4 из заголовка фрейма. Посмотрим на табличку ниже:
  

  

• Source Address (SA) — MAC-адрес исходного отправителя (ваш смартфон или ноутбук, с которого выходите в веб).
• Destination Address (DA) — MAC-адрес конечного назначения (тот сервер, куда вы зашли, чтобы прочитать эту статью).
• Transmitter Address (TA) — MAC-адрес, передающий фрейм 802.11 (точка доступа, через которую вы сидите).
• Receiver Address (RA) — MAC-адрес, принимающий фрейм 802.11.
• Basic Service Set Identifier (BSSID) — L2 identifier of the basic service set (BSS).

Четвертый случай (когда оба бита выставлены в единицу) наглядно пояснит вот такая картинка:

• More Frag выставляется в единичку во всех Data- и Management-фреймах, указывающих, что есть еще фрагменты в текущем MSDU или MMPDU.
• Retry устанавливается в единичку, когда фрейм является повторной передачей более раннего фрейма.
• Power Mgmt устанавливается в единицу, когда клиент показывает, что находится в режиме Power Save mode; необходимо буферизировать трафик, получаемый со стороны клиента.
• More Data выставляется в единицу, тем самым AP (точка доступа) указывает клиенту (STA), который находится в Power Save Mode, что для него есть еще данные и «ложиться спать» еще рано.
• Protected Frame — как, думаю, вы уже догадываетесь из названия, единица в этом бите указывает на то, что фрейм у нас зашифрован.
• Order устанавливается в любом non-QOS Data-фрейме, когда приложение требует, чтобы данные были отправлены строго упорядоченно.

Duration/ID

Несколько загадочное поле, поскольку смысл, который будет в этих 16 битах, сильно зависит от того, какой у нас фрейм — Data, Control или Management. Как вариант — если у нас Control PS-Poll фрейм (об этом будет сказано дальше), то тут будет содержаться идентификатор AID. А может быть указано время в микросекундах, требуемое для передачи следующего фрагмента в Data Frame.

Еще одна интересная железка от Cypress

CYW43907 привлекательна тем, что поддерживает Dual Band (2,4/5 ГГц) и на борту у нее USB 2.0. И что для нас самое интересное — вроде как поддерживает неразборчивый режим. Почему говорю «вроде как» — однозначного упоминания в документации и programming user guide я не встретил, но если посмотреть сюда, то в этой ветке форума говорится, что с SDK 2.4.1 появилась функция wiced_wifi_enable_monitor_mode(), которая позволяет прослушивать эфир и фреймы capture 802.11.

Sequence Control

Как видим из картинки выше, делится, в свою очередь, на Fragment Number и Sequence Number. Sequence Number указывает порядковый номер в MSDU-, A-MSDU- или MMPDU-фреймах. Fragment Number указывает номер каждого фрагмента в MSDU- или MMPDU-фреймах. Чтобы более четко понять, как используется Sequence Number в связке с Fragment Number, посмотрите на картинку ниже.

Нам надо передать данные размером в 1200 байт, но точка доступа сконфигурирована так, что размер передаваемого фрейма составляет 300 байт. Передача единого сообщения в 1200 байт будет выглядеть следующим образом.

QoS Control

Шестнадцатое поле, которое отвечает quality-of-service в Data frame.

HT Control

Последнее поле — HT Control, которое может встречаться в MAC-заголовке фрейма 802.11. Стандарт 802.11n расширяет заголовок данных полем размером в четыре байта. Присутствует только в QoS Data и Management фреймах и определяется Order bit из Frame Control.

Body

В поле Body «упаковываются» вышестоящие протоколы.

Подтипы фреймов

Как и было обещано, теперь поговорим немного детальнее о том, какие бывают подтипы у Control-, Management- и Data-фреймов.

Management frame

Как следует из названия, данный тип фреймов служит своеобразным «скелетом» для построения беспроводной сети.

Beacon Frame

В основном используется точкой доступа (ну или в режиме IBSS — когда устройства пытаются образовать ad-hoc-сеть, то есть когда вы хотите подружить свой смартфон с ноутом напрямую без точки доступа). Точка доступа периодически отправляет биконы для анонсирования своего присутствия и предоставления необходимой информации (SSID, частотный канал, временные маркеры для синхронизации устройств по времени, поддерживаемые скорости, возможности обеспечения QoS и подобное) всем устройствам в зоне ее покрытия.

Probe Request Frame

Это когда вы, уважаемый читатель, включаете на смартфоне WiFi, чтобы подключиться к какой-нибудь беспроводной сети. Отправляется обычно на широковещательный DA-адрес ( ff:ff:ff:ff:ff:ff).

Probe Response Frame

Получив Probe Request, точка доступа или клиентское устройство в режиме IBSS отправляет данный фрейм. Формат фрейма очень похож по структуре на Beacon-фрейм и содержит информацию, необходимую для подключения и установления соединения.

Authentication Frame

Association request

Содержит информацию о радиокарте устройства (например, поддерживаемые скорости передачи данных) и SSID сети WLAN, с которой устройство хочет быть ассоциировано. После получения запроса на ассоциацию точка доступа решает вопрос по ассоциированию с радиокартой и, если принято положительное решение, резервирует область памяти и формирует идентификатор сессии AID (Association Identifier) для данной радиокарты (устройства пользователя)

Association response

Disassociation Frame

Поле DA может быть как конкретным адресом клиента, с которым надо разъединиться, так и широковещательным, если AP решит разорвать соединения со всем. Но стоит учитывать, что деассоциированная STA все еще находится в состоянии авторизации с точкой доступа. Данный фрейм используется, когда точке доступа или клиенту надо пересмотреть параметры связи.

Deauthentication Frame

Формат аналогичен Disassociation Frame. Данный тип фрейма используется, когда необходимо разорвать все виды коммуникаций между клиентом и точкой доступа. Распознаются Deauthentication Frame и Disassociation Frame с помощью поля Subtype.

На том же ESP8266 реализована атака под названием Deauther. Заинтересовавшимся смотреть ESP8266 Deauther 2.0 или Wi-PWN.

Reassociation Request Frame

Данный фрейм отправляется исключительно клиентом на точку доступа. Возникает эта ситуация, когда STA подключена к ESS и хочет переподключиться к другой точке доступа, подсоединенной к той же ESS (расширенная зона обслуживания ESS — Extended Service Set).

Control frame

Одна из фишек этих фреймов (и их отличие от Management- и Data-фреймов) — у них нет поля Body. Ниже показаны основные типы Control frame:

RTS/CTS Frames

Расшифровываются они, соответственно, как request to send (RTS) и clear to send (CTS). В целом служат для улучшения взаимодействия между STA и AP. Представьте, что точка доступа у вас стоит около капитальной стены, вы сидите в инете со смартфона, а ваш друг в другом конце квартиры сидит за ноутом. Оба ваших устройства прекрасно видят точку доступа, но вот в радиоэфире уже не слышат друг друга, и чтобы оба могли почитать любимые статьи на tech-geek.ru, ваши железки будут использовать данные фреймы.

Мобильные устройства отправляют RTS-фрейм к другому устройству как первую фазу в двухшаговом процессе, необходимом до отправки фрейма данных. В ответ придет CTS-фрейм, где будет указано, на какое время все остальным устройствам в сети стоит помолчать.

Acknowledgement Frame

Мы живем далеко не в идеальном мире… где существует масса помех, особенно когда речь идет о передаче чего-либо по радиоканалу. Данный фрейм будет сгенерирован получателем после проверки на ошибки полученного Data-фрейма.

Block Acknowledgement Request

Основная идея — улучшить/ускорить передачу данных, подтверждая сразу несколько принятых Data-фреймов, а не каждый по отдельности. Но прежде чем начать использовать такой хук, надо убедиться, что получатель знает про него.

• RA — MAC-адрес получателя.
• TA — MAC-адрес отправителя фрейма BlockAck-Req.

Block Acknowledgement

Собственно фрейм подтверждения, который генерируется в случае успеха нескольких QoS Data-фреймов, вместо того чтобы подтверждать каждый в отдельности.

• RA — MAC-адрес устройства, который запрашивает фрейм Block Ack.
• TA — MAC-адрес узла, который передает Block Ack.

PS-Poll

Когда конечное устройство проснулось после спячки и получило Beacon, проверяет наличие AID и TIM (фактически означает, что точка доступа имеет некие данные, которые надо отправить на конечное устройство). В этом случае STA отправляет PS-Poll на точку доступа, сигнализируя о том, что готово принять накопленные для нее данные.

• BSSID (RA) — MAC-адрес точки доступа, к которой подключен клиент.
• TA — MAC-адрес клиента, который сгенерировал PS-Poll.

Control Wrapper

Определен в стандарте 802.11n, который дает очень «интересное» трактование данного фрейма — он используется с любыми другими Control Frame (исключая Control Wrapper frame) вместе с полем HT Control.

Contention Free

Оба фрейма служат для информирования о том, что закончился CFP (contention-free period). Во втором случае требуется фрейм подтверждения.

Data Frame

Если вы еще помните, как описывается данный фрейм в Control Frame, то вас не должно удивлять, что существует 15 различных типов Data Frame.

Наблюдательный читатель заметит, что Data Frame следует разделить еще на две «большие» категории: Data Frame, который содержит данные и который не содержит данные. Напрашивается вопрос: зачем делать Data Frame, который не содержит данных? Ответ, возможно, вас удивит: иногда надо передать служебную информацию точке доступа или другому участнику сети. Иногда узлы используют Null data frames, чтобы активизировать или завершить power save mode.

Кстати, здесь стоит упомянуть возможность фрагментации фрейма.

С одной стороны, вроде бы увеличиваем overhead, но, с другой стороны, если произойдет коллизия, то передавать надо будет не jumbo-фрейм, а всего лишь небольшой кусочек, что положительно скажется на пропускной способности.

«Контрольным выстрелом» будет наличие A-MSDU (aggregate MAC service data unit) и A-MPDU (aggregate MAC protocol data unit). Чтобы внести небольшую ясность, сначала дадим еще несколько определений.

По-простому MSDU — payload, содержащий IP-пакет + некоторые данные LLC. MPDU — это фрейм 802.11, PLCP — physical layer convergence procedure. Вот так выглядит процесс агрегации для A-MSDU.

Если разрешено шифрование, то несколько MSDU шифруются как единое целое. Не стоит забывать, что MSDUs могут собираться в один MPDU в случае, когда DA- и SA-адреса отображаются на одинаковые RA и TA.

А вот так выглядит процесс агрегации для A-MPDU.

В случае шифрования есть существенное отличие — каждый MPDU шифруется отдельно. Также не стоит забывать, что все MPDU, входящие в A-MPDU, должны иметь один и тот же адрес получателя.

Тем же, кто хочет разобраться глубже/детальнее с 802.11, могу рекомендовать пару ресурсов (помимо самого стандарта IEEE 802.11). Первым делом посоветую прочитать My CWAP Study Notes, а в качестве дополнения этот ресурс. Не стоит забывать и про книги:

• CWAP Certified Wireless Analysis Professional Official Study Guide Exam PW0-270;
• CWAN Certified Wireless Network Administrator Official Study Guide Exam PW0-105.

Ура, практика!

Надеюсь, вы прорвались через тонкости и нюансы 802.11 без потери мозговой ткани и нервных клеток и готовы к созданию сниффера. Поехали! Начнем, как всегда, с постановки задачи.

Что мы хотим?

1. Перво-наперво мы желаем простое подключение к компу/ноуту — то есть USB. Кек, Ethernet/LAN есть не у всех ноутов; да и не каждая WiFi-карточка позволит переключить ее в «неразборчивый режим» (promiscuous mode). Список сетевых карточек, которые можно переключить в неразборчивый режим, есть тут.
2. Второе — возможность динамически переключать номер канала, где прослушиваем трафик. Хотим гибкий фильтр входящих пакетов. Да-да, чтобы слушать только Control Frame или только Data Frame, c определенным MAC- или IP-адресом. Реализация начального этапа анализа пакетов: если пришел законченный пакет — отправляем его на комп, но если это фрагментированный пакет или часть агрегированного пакета, то дождаться прихода остальных частей, собрать его до полного и только потом отдавать на комп.
3. Естественно, хотим, чтобы wireshark мог отображать в режиме реального времени прослушанный трафик.
4. Еще одно абсолютно естественное пожелание: если вы знаете пароль от WiFi-сеи, которую вы прослушиваете, то хорошо бы иметь magic-функцию вида decrypt_message(* ptr_message, *WPA_WPA2_key), результатом которой будут расшифрованные данные для последующего анализа.

В отличие от ESP8266, EPS32 имеет конфигурируемый аппаратный буфер для приема и отправки фрейма 802.11. Мы можем менять количество буферов, при этом размер каждого буфера 1600 байт, что уже достаточно для приема кадра. Из своих экспериментов я выяснил, что 1600 байт хватает для прослушивания WiFi-сети. Однако надо иметь в виду важную особенность — ESP32 (точнее, драйвер, предоставляемый в SDK) в неразборчивом режиме поддерживает следующие типы фреймов:

• 802.11 Management frame;
• 802.11 Data frame, including MPDU, AMPDU, AMSDU, etc;
• 802.11 MIMO frame, for MIMO frame, the sniffer only dumps the length of the frame.

И не поддерживает:

• 802.11 Control frame;
• 802.11 error frame, such as the frame with a CRC error, etc.

Но если вы внимательно прочитали вводную часть о том, как устроен WiFi, то вы поймете, что в том, что в ESP32 нет full stack фреймов, нет особенной печали: помимо того что можно слушать приходящие фреймы, есть возможность и отправлять некоторые данные. Для этого существует функция esp_wifi_80211_tx. Но тут тоже есть нюансы — пока есть возможность отправлять только beacon/probe request/probe response/action and non-QoS data frame.

Теперь немного кода, который осуществляет захват WiFi.

Поскольку работа с ESP32 осуществляется с помощью SDK, сначала производим инициализацию Wi-Fi «по фэншую». Последней строчкой указываем функцию, которая будет вызываться при захвате нового фрейма.

РЕКОМЕНДУЕМ:
Espruino Pico: програмирование USB-микроконтроллера на JavaScript

Поскольку я работаю с ESP32-PICO-KIT V4, то из коробки данную отладочную плату можно подключить к USB через переходник UART — USB на чипе CP2102. Соответственно, нужна инициализация UART.

Тип пакетов для отлова можно задавать через фильтр:

Полный список пакетов, которые можно фильтровать:

Находится он в файле esp_wifi_types.h.

Эпистолярный жанр

Написал большущее письмо в support Espressif на тему расширения функциональности SDK в части WiFi: чтобы была возможность приема и отправки фреймов 802.11 без каких-либо ограничений. Обещали подумать и включить в план разработки. Так что, уважаемый читатель, если вы тоже хотите, чтобы ESP32 полноценно поддерживал прием и отправку всех фреймов 802.11, имел на борту хотя бы USB 2.0, начал поддерживать 5 ГГц и получил magic_function, которая при наличии пароля от WiFi будет расшифровывать полученные данные, то не поленитесь зайти в ветку форума What would you like to see in The Next Chip? и выразить свои пожелания. Возможно, у вас появятся еще классные идеи относительно того, что бы вы хотели видеть в следующем поколении ESP32, — не стесняйтесь об этом писать.

Также в этом файле, помимо define для фильтров, есть полезная структура:

Данная структура доступна всякий раз, когда срабатывает callback, сигнализирующий о том, что новый фрейм доступен. Как видите, он содержит много полезной информации, которую можно использовать при обработке пакетов.

Возможно, дотошный читатель скажет: «Как же так — мы прослушиваем WiFi, а там скорости могут быть 600 Мбит/с для 802.11n, а связь с компом у нас осуществляется через скромный UART, который может работать на стандартных 115 200, что явно ниже скорости WiFi. Где-то тут подвох!» В чем-то вы будете правы, но позвольте сказать несколько «но» и поделиться своими наблюдениями.

• Во-первых, как показала практика, отладочная плата прекрасно работала на скорости 921 600 бод.
• Во-вторых, если преобразователь UART — USB заменить на более новую микросхему CP2102N, то скорость можно будет поднять до 3 Мбод.
• В-третьих, Espressif официально ответила, что ESP32 может работать: «The UART interface of ESP32 can work on 5Mbps band rate».
• В-четвертых, мы можем настроить фильтр так, чтобы ловились не все пакеты.

В итоге в ходе экспериментов удавалось на некоторое время получить непрерывный dataflow. Но тут не обошлось без «ложки дегтя в бочке меда». Отладочная плата греется. Яичницу на ней, конечно, не пожарить, однако и холодной назвать ее нельзя. Но не забываем, что стоимость такой отладочной платы составляет порядка десяти долларов.

Проверка боем

На одной из ESP32 была развернута точка доступа с простым веб-сервером. На начальном этапе шифрование я отключил. Ноутбуком подключаюсь к этой точке доступа и начинаю пинговать. На второй ESP32 запускаю сниффер.

Как результат работы сниффера видим такой пакет.

Разберем теперь немного байтики:

MAC HEADER -> FC: 88 02
MAC HEADER -> Duration/ID 30 00
MAC HEADER -> Address1 11 22 33 44 55 66
MAC HEADER -> Address2 AA BB CC DD EE FF
MAC HEADER -> Address3 AA BB CC DD EE FF
MAC HEADER -> SEQUENCE CTRL 90 2F
MAC HEADER -> QOS 00 00

Далее у нас в игру вступает LLC & SNAP Header: AA AA 03 00 00 00 08 00. Причем надеюсь, начиная с 08 00 в заголовке LLC & SNAP, вы уже узнаете одну из нужных команд, которая называется ping. Последние четыре байта — это контрольная сумма.

Благодарности

Спасибо коллеге, который, узнав о моем проекте, помог подогнать отладочную плату на основе СС3220SF — CC3220SF-LAUNCHXL. С одной стороны, данный микроконтроллер не блещет производительностью — скромные 80 МГц Cortex-M4 (против 240 МГц Xtensa LX6 C), а ОЗУ у TI всего лишь 256 Кбайт против 520 Кбайт у ESP32. Но дальше следует одно интересное «но» — согласно этой wiki, мы можем перевести ее в неразборчивый режим, который позволит как принимать все фреймы 802.11, так и отправлять raw-пакет, такой, как нам захочется.

Помимо такой гибкости приема/отправки 802.11, у платы, на мой взгляд, достаточно гибкая система фильтрации входящих пакетов:

То есть здесь можно организовать что-то в этом роде (раздел 10.3.2 «CC3120, CC3220 SimpleLinkTM Wi-Fi ® and Internet of Things Network Processor Programmer’s Guide»):

• Receive WLAN data broadcast frames only from two specific MAC addresses.
• Do not receive WLAN unicast frames from a certain SRC_IP address range.
• If a unicast frame is received from MAC address AA.BB.CC.DD.EE.FF, increase counter_1.
• If a unicast frame is received from MAC address CC.HH.II.JJ.KK.LL, increase counter_2.
• If a unicast UDP frame is received from MAC address AA.BB.CC.DD.EE.FF or CC.HH.II.JJ.KK.LL, pass only packets from port 5001.

В качестве заключения

Разумеется, этим проектом я не совершил революцию и местами даже изобрел велосипед, ведь подобные снифферы на основе ESP32 уже существуют — например, ArduinoPcap, ESP32-WiFi-Sniffer или проект самой Espressif. Но лично мне все нравится. «Пусть расцветают сто цветов, пусть соперничают сто школ», тем более что в каждой реализации есть свои недочеты, а имея свое устройство, вы можете настроить его полностью на свой вкус, под свои цели и задачи.