# Полный текст исследования и документация: Wi-Fi Cafe (Бабчук Г. В., 2026) ## Выходные данные - Название: Разработка системы локального оповещения «Wi-Fi Cafe» посредством программной генерации 802.11 Beacon-кадров на базе микроконтроллера ESP32 - Учреждение: Государственное учреждение образования «Гимназия г. Иваново» - Автор: Бабчук Георгий Владимирович, учащийся 11 «А» класса - ORCID: https://orcid.org/0009-0000-2505-2841 - DOI: https://doi.org/10.5281/zenodo.22865566 - Репозиторий: https://github.com/egraich/wifi-cafe - Лицензия: MIT - Год: 2026 --- ## 1. Введение и актуальность В настоящее время системы локального информирования и оповещения широко применяются в различных сферах. Традиционные аппаратные решения обладают рядом ограничений, связанных с необходимостью внедрения и технического обслуживания специализированного оборудования. Программные аналоги, как правило, требуют от пользователя установки сторонних приложений, прохождения процедуры авторизации или обязательного наличия доступа к глобальной сети Интернет. В связи с этим актуальной инженерной задачей является разработка автономной системы передачи коротких сообщений, использующей стандартизированные протоколы связи, аппаратно поддерживаемые большинством современных мобильных устройств, без необходимости выполнения дополнительных действий со стороны конечного пользователя. Спецификации стандарта беспроводных локальных сетей IEEE 802.11 описывают механизмы широковещательной рассылки сервисной информации на канальном (MAC) уровне посредством управляющих кадров-маяков (Beacon frames). Тем не менее, практическое применение базовых служебных полей 802.11, таких как идентификатор сети (SSID), в качестве независимого канала для динамической передачи текстовых данных конечным пользователям исследовано недостаточно. Целью работы является разработка аппаратно-программного комплекса для односторонней локальной передачи текстовой информации с использованием управляющих кадров стандарта IEEE 802.11 на базе микроконтроллера ESP32, а также исследование алгоритмов обработки данных сигналов различными мобильными операционными системами. Для достижения поставленной цели решены следующие научно-практические задачи: 1. Изучена структура канального уровня стандарта IEEE 802.11, в частности спецификации управляющих кадров (Management frames). 2. Разработано программное обеспечение для микроконтроллера ESP32, реализующее алгоритмы генерации низкоуровневых кадров стандарта 802.11 и дистанционного управления через Telegram API. 3. Проведено кроссплатформенное тестирование разработанного комплекса на мобильных устройствах под управлением различных ОС (Android, iOS). 4. Проанализированы особенности приёма широковещательных пакетов мобильными ОС и выявлены технические причины ограничений при отображении сетей на различных устройствах. В основу исследования положена гипотеза о том, что динамическое изменение поля SSID в программно генерируемых Beacon-кадрах может быть использовано в качестве канала для передачи коротких текстовых сообщений непосредственно в системный интерфейс устройства пользователя, без необходимости установки соединения с сетью. --- ## 2. Теоретическое обоснование и реализация программного комплекса Для подтверждения выдвинутой гипотезы был разработан аппаратно-программный комплекс на базе микроконтроллера Espressif ESP32. Выбор данной платформы обусловлен наличием встроенного радиомодуля Wi-Fi с поддержкой низкоуровневого API, а также достаточным объёмом оперативной памяти для хранения очереди данных. Архитектура программного решения построена на одновременном использовании двух сетевых интерфейсов. Микроконтроллер функционирует в режиме WIFI_AP_STA, выступая одновременно в качестве клиента (станции, STA) для подключения к внешней сети и программной точки доступа (SoftAP). Подключение к сети необходимо исключительно для работы интерфейса управления. В качестве панели управления был интегрирован Telegram Bot API, работающий по технологии Long Polling. Это позволяет администратору дистанционно управлять записями и их статусом без необходимости развёртывания стороннего локального веб-сервера. Взаимодействие с аппаратурой осуществляется через интерфейс администратора в мессенджере Telegram. Пакеты данных маршрутизируются через глобальную сеть Интернет и локальный узел доступа Wi-Fi на микроконтроллер ESP32. Аппаратное разделение сетевого интерфейса на режим клиента (STA) и программную точку доступа (SoftAP) позволяет комплексу параллельно опрашивать сервер Telegram API и осуществлять одностороннюю трансляцию Beacon-кадров в радиоканал. Ключевой инженерной задачей являлся обход ограничения стандартных библиотек, которые позволяют устройству транслировать только один SSID. Для реализации одновременного массового оповещения в проекте задействована функция `esp_wifi_80211_tx` из фреймворка ESP-IDF. Данный подход позволяет формировать низкоуровневые управляющие кадры (Beacon frames) и осуществлять их прямую передачу в радиоэфир на едином радиоканале. Структура формируемого пакета включает стандартный MAC-заголовок, сгенерированный случайным образом локальный MAC-адрес передатчика и блок информационных элементов. Информационным каналом выступает поле Service Set Identifier (SSID), длина которого по стандарту IEEE 802.11 ограничена 32 байтами. Программное обеспечение ESP32 динамически формирует строку, состоящую из имени клиента и текущего статуса (например, «Alex: 40%»), проверяет соблюдение лимита в 32 байта и интегрирует строку в полезную нагрузку кадра. Данные хранятся в оперативной памяти с использованием структуры `std::vector`, что обеспечивает эффективное управление ресурсами при добавлении и удалении записей. Сформированные пакеты отправляются в эфир циклически с интервалом в 100 миллисекунд. --- ## 3. Исследование алгоритмов сканирования стандарта 802.11 в мобильных ОС Практический этап исследования заключался в верификации работоспособности комплекса на реальных пользовательских устройствах. Первоначальная гипотеза предполагала универсальность отображения SSID, однако серия натурных экспериментов выявила принципиальные различия в поведении клиентских операционных систем Android и iOS. На устройствах под управлением ОС Android разработанная система функционирует в штатном режиме. В стандартном меню выбора сетей Wi-Fi у пользователя отображаются все сгенерированные записи как отдельные точки доступа. Анализ сетевой активности показал, что ОС Android преимущественно использует механизм пассивного сканирования (Passive Scanning). При пассивном сканировании Wi-Fi модуль смартфона переключается на определённый радиоканал и переходит в режим прослушивания на заданное время. Обнаружив транслируемые микроконтроллером ESP32 кадры типа Beacon, операционная система считывает поле SSID и сразу выводит его в пользовательский интерфейс, не требуя двустороннего сетевого взаимодействия. При тестировании на устройствах iPhone (ОС iOS) было зафиксировано полное отсутствие сгенерированных сетей в списке доступных подключений, несмотря на то, что радиоперехват подтверждал физическое наличие пакетов в эфире. Исследование технической документации и механизмов работы сетевого стека iOS выявило, что данная ОС использует строгие алгоритмы активного сканирования (Active Scanning) для защиты от подмены сетей (спуфинга). Вместо прослушивания радиоканала iPhone активно отправляет широковещательные запросы Probe Request. Согласно стандарту 802.11, авторизованная точка доступа, получив такой запрос, обязана ответить пакетом Probe Response, подтверждающим её готовность к установке соединения. В результате алгоритмы iOS не получают обязательного ответа на активный запрос, из-за чего классифицируют данные сигналы как некорректные и не выводят сеть в пользовательский интерфейс. Поскольку разработанный на базе ESP32 комплекс осуществляет лишь одностороннюю программную генерацию и отправку кадров и не поддерживает работу полноценного конечного автомата (State Machine) точки доступа для каждого сгенерированного MAC-адреса, программное обеспечение микроконтроллера не выполняет обработку входящих запросов Probe Request. Аппаратный радиомодуль физически принимает данные пакеты, однако из-за отсутствия программного обработчика (Callback-функции) ответные кадры Probe Response не формируются. В результате алгоритмы iOS классифицируют данные радиосигналы как неподтверждённые сети и блокируют их отображение. Данный факт подтверждает строгое соблюдение стандарта IEEE 802.11 фильтрующими защитными механизмами ОС iOS. --- ## 4. Заключение В ходе выполнения научно-исследовательской работы был разработан аппаратно-программный комплекс локального информирования на базе ESP32. Полученные результаты позволяют сделать следующие выводы: 1. Выдвинутая гипотеза подтверждена частично: использование поля SSID в кадрах управления 802.11 позволяет сформировать автономный канал доставки информации на устройства без установки соединения. 2. Установлено, что эффективность данного метода зависит от имплементации алгоритмов сканирования радиоэфира производителем операционной системы. Метод работоспособен при использовании пассивного сканирования (Android), однако отбрасывается фильтрами активного сканирования, требующими подтверждения пакетами Probe Response (iOS). 3. Степень новизны работы заключается в нестандартном использовании служебных широковещательных пакетов канального уровня OSI в качестве источника данных системного интерфейса (GUI) для массового информирования. 4. Практическая значимость: предложенный архитектурный подход может быть использован для создания низкобюджетных систем электронной очереди в условиях отсутствия инфраструктуры. 5. Направления дальнейших исследований: доработка микроконтроллерного программного обеспечения для обработки входящих запросов активного сканирования (Probe Request), а также миграция логики управления на более современную библиотеку FastBot2 для оптимизации взаимодействия с Telegram API. --- ## 5. Исходный код C++ (Ключевые фрагменты) ```cpp // spamBeacons() — инъекция сырых Beacon кадров void spamBeacons() { static unsigned long lastSpam = 0; if (millis() - lastSpam < 100) return; lastSpam = millis(); std::vector& orders = orderManager.getAllOrders(); if (orders.empty()) return; uint8_t primaryChan = 1; wifi_second_chan_t secondChan; esp_wifi_get_channel(&primaryChan, &secondChan); for (Order& order : orders) { String suffix = ": " + String(order.progress) + "%"; String safeName = order.name; safeName.trim(); int maxNameLen = 32 - suffix.length(); if (safeName.length() > maxNameLen) { safeName = safeName.substring(0, maxNameLen); } String ssid = safeName + suffix; int ssid_len = ssid.length(); int packet_size = 36 + 2 + ssid_len + 13; uint8_t packet[packet_size]; memcpy(packet, beacon_header, 36); memcpy(&packet[10], order.mac, 6); memcpy(&packet[16], order.mac, 6); packet[22] = (seq_num & 0x0F) << 4; packet[23] = (seq_num & 0xFF0) >> 4; packet[36] = 0x00; // Tag 0 (SSID) packet[37] = static_cast(ssid_len); memcpy(&packet[38], ssid.c_str(), ssid_len); int tail_idx = 38 + ssid_len; packet[tail_idx++] = 0x01; // Tag 1 (Supported rates) packet[tail_idx++] = 0x08; packet[tail_idx++] = 0x82; packet[tail_idx++] = 0x84; packet[tail_idx++] = 0x8b; packet[tail_idx++] = 0x96; packet[tail_idx++] = 0x24; packet[tail_idx++] = 0x30; packet[tail_idx++] = 0x48; packet[tail_idx++] = 0x6c; packet[tail_idx++] = 0x03; // Tag 3 (Channel) packet[tail_idx++] = 0x01; packet[tail_idx++] = primaryChan; esp_wifi_80211_tx(WIFI_IF_AP, packet, packet_size, false); seq_num++; } } ```