Как теория Wi-Fi заставила меня искать "Cisco-Ubiquiti-TP-Link"

Несколько лет назад, во время одного из дежурств в выходные дни на производстве, которое относилось к зоне моей ответственности, произошел сбой сети. Пользователи массово жаловались на недоступность сервисов. Выдвинувшись на место, я обнаружил классическую аномалию: на рабочих машинах сменилась IP-адресация. Компьютеры между собой прекрасно пинговались, но доступ к корпоративным ресурсам полностью отсутствовал.

Многие уже наверняка догадались в чем дело - в сети появился нелегальный DHCP-сервер.

Выяснив IP этого "самозванца", я запустил Advanced IP Scanner, чтобы узнать его MAC-адрес и передать дежурному сетевику. Тот к этому моменту уже спешно включал DHCP-Snooping на коммутаторах (даже не спрашивайте, почему этого не было сделано ранее). План был простой: сетевик смотрит, за каким портом свитча зафиксирован этот MAC, и мы локализуем проблему.

Сканер выдал результат: производителем устройства с этим MAC-адресом значилась Ubiquiti. Так совпало, что на данном производственно-логистическом комплексе действительно висели точки доступа этого вендора, причем разных поколений. Мы решили, что какая-то из них сошла с ума, и я пошел ногами прочесывать предприятие.

Та самая фотография с IP и MAC адресами злодейского DHCP

Первой под подозрение попала старая точка доступа в административной части. Поднимаюсь на стремянку, смотрю - ба, да это же Cisco, еще и MAC-адрес совершенно не совпадал с разыскиваемым.

В этот момент кому-то в рабочем чате пришла гениальная мысль: "А почему мы просто не попробуем постучаться на этот левый IP через браузер?" (И снова не спрашивайте, почему мы не сделали этого сразу). Вбиваю адрес в строку, и мне открывается веб-интерфейс... старого бытового роутера TP-Link! Из тех домашних коробок, которых на предприятии в принципе быть не должно.

Настоящий винегрет: сканер говорит Ubiquiti, надпись на точке - Cisco, а веб-морда - TP-Link.

Чтобы не ломать голову в выходные, сетевик просто потушил порт коммутатора, за которым висел этот пришелец. Мы резонно рассудили: наступит понедельник, у кого-то отвалится сеть, он придет жаловаться - тут-то мы его и поймаем.

В рабочие дни местный админ устроил тотальную проверку и обнаружил виновника. Роутер TP-Link стоял в отдельно стоящем модульном здании, которое подключалось к сети главного комплекса через беспроводной радиомост Ubiquiti. Как оказалось, этот радиомост при определенных настройках подменяет MAC-адреса всех клиентов за собой на свой собственный беспроводной MAC. Для коммутатора и сканера сети роутер TP-Link физически превратился в Ubiquiti.

Эта история заставила меня глубоко закопаться в матчасть. Почему устройство, работающее в режиме L2-моста, занимается такой дичью, ломая диагностику и безопасность? Как выяснилось, виной всему архитектура кадров стандарта 802.11, а также куча недомолвок и костылей от производителей чипсетов.

Предлагаю подробно разобрать проблему "четвертого MAC-адреса" в беспроводных сетях, и почему WDS так и не стал нормальным стандартом.

Анатомия Wi-Fi кадра, или Куда пропал четвертый MAC-адрес

Чтобы понять, почему радиомост Ubiquiti из моей истории начал заниматься подменой MAC-адресов (L2 NAT/ARP-NAT), нужно спуститься на канальный уровень (Data Link Layer) и посмотреть на структуру стандартного беспроводного кадра.

Структура кадра IEEE 802.11(обратите внимание на флаги To DS и From DS)

Но перед тем как глубоко закопаться в структуру кадра 802.11, давайте дадим чёткое определение главному виновнику торжества. WDS (Wireless Distribution System) - это технология, призванная аппаратно расширять зону покрытия беспроводной сети путем объединения нескольких точек доступа (AP) в единую прозрачную L2-среду без использования проводного Ethernet-кабеля. Главное фундаментальное преимущество WDS перед обычными репитерами заключается в том, что он обязан в первозданном виде сохранять сквозные MAC-адреса клиентских кадров при их пересылке по воздуху.

Итак, в проводных сетях Ethernet (стандарт IEEE 802.3) в заголовке кадра всегда присутствуют два MAC-адреса: Source (откуда летит кадр) и Destination (куда он должен прилететь). Коммутаторы на пути следования кадра смотрят на эти два адреса и точно знают, в какой порт его перенаправить.

Но как только мы переносим эту логику в беспроводную среду IEEE 802.11, два адреса перестают работать. Радиоэфир общий, среда разделяемая, а роутер (точка доступа) выступает в роли посредника между проводным миром и воздухом. Чтобы доставить кадр от смартфона к серверу, устройству мало указать конечную цель, ему нужно указать адрес транзитного узла, который этот кадр примет из эфира.

Поэтому в стандартном Wi-Fi кадре используется три MAC-адреса. Их роли динамически меняются, но если взять классический сценарий, когда кадр летит от клиента на точку доступа, адреса распределяются следующим образом:

Address 1 (RA/BSSID): MAC-адрес беспроводного интерфейса точки доступа, которая прямо сейчас должна поймать радиосигнал.
Address 2 (TA/SA): MAC-адрес беспроводного модуля вашего смартфона или ноутбука, который этот сигнал излучает.
Address 3 (DA): MAC-адрес конечного получателя (например, шлюза или сервера) в проводной сети.

За то, как именно должны интерпретироваться эти три поля, отвечают два флага в управляющем байте заголовка Frame Control - биты To DS (To Distribution System) и From DS (From Distribution System).

Обычно они работают в следующих комбинациях:

To DS = 1, From DS = 0 - Кадр летит от клиента на точку доступа.
To DS = 0, From DS = 1 - Кадр летит от точки доступа к клиенту.

В чем же тупик для радиомоста?

А теперь вернемся к нашему кейсу. У нас есть отдельно стоящее здание. В нем стоит коммутатор, в коммутатор воткнут тот самый злополучный роутер TP-Link (клиент) и беспроводная станция Ubiquiti (Station). Эта станция соединена по воздуху с главной точкой доступа Ubiquiti (AP) на основном здании.

Роутер TP-Link отправляет кадр DHCP-Offer (или DHCP-ACK), предлагая свой неправильный IP-адрес. Этот трафик в виде стандартного Ethernet-кадра доходит по проводу до станции Ubiquiti, та должна переупаковать его и выплюнуть в радиоэфир в сторону главной AP.

Считаем MAC-адреса, которые необходимы для успешной доставки:

MAC-адрес главной точки доступа Ubiquiti (кто примет радиосигнал).
MAC-адрес беспроводной станции Ubiquiti (кто излучает радиосигнал).
MAC-адрес назначения (Destination MAC) — адрес того самого компьютера-жертвы, которому роутер пытается скормить настройки.
MAC-адрес источника (Source MAC) — уникальный MAC-адрес нашего левого роутера TP-Link, который этот кадр сгенерировал.

Нам нужно четыре MAC-адреса. Но в стандартном режиме Wi-Fi (AP-Station) у нас есть поля только для трех!

В старых веб-интерфейсах Ubiquiti airOS за это отвечал незаметный переключатель WDS (Transparent Bridge Mode).

Вариант А: Галочка WDS выключена (Режим 3-х адресов).
Раз четырех адресов в кадре нет, а передать данные нужно, станция Ubiquiti идет на криминал. Она включает режим ARP-NAT. Станция берет входящий Ethernet-кадр от TP-Link, затирает в заголовке его реальный MAC-адрес источника, записывает туда свой собственный беспроводной MAC и в таком 3-адресном виде отправляет в эфир на главную точку доступа.

Чтобы сеть не стала дорогой в один конец, станция создает в памяти динамическую таблицу трансляции (аналог таблицы NAT в роутерах, но занимающийся подменой MAC, а не IP). Она смотрит на пролетающий сквозь нее IP-трафик и запоминает связку:

IP-адрес скрытого устройства <-> его реальный MAC-адрес.

Когда из эфира прилетает ответный 3-адресный кадр, станция заглядывает в эту таблицу, находит получателя по его IP, восстанавливает оригинальный MAC-адрес TP-Link в заголовке Ethernet-кадра и выплевывает его в проводной порт. Именно поэтому Advanced IP Scanner в моей истории и увидел MAC-адрес Ubiquiti вместо TP-Link - для всей остальной сети станция моста просто "прикинулась" автором всех кадров, идущих из соседнего здания.

Анализ стандартного 3-адресного кадра в CommView for WiFi. Поля Address 4 в заголовке физически не существует.

Вариант Б: Галочка WDS включена (Режим 4-х адресов).
Спецификация IEEE 802.11 на самом деле предусматривает комбинацию флагов To DS = 1, From DS = 1. Этот режим активирует заветное поле Address 4 в заголовке кадра. При такой схеме подмена адресов не требуется: в кадре честно прописываются и обе точки радиомоста, и конечные клиенты за ними. Сеть становится абсолютно прозрачной (я напомню это было несколько лет назад, в современных версиях airOS режим WDS при создании моста включается по умолчанию если в разделе Network Role включен Network Mode - Bridge).

Анализ 4-адресного кадра WDS-моста. В поле Frame Control активированы флаги To DS и From DS.

В подтверждение этих слов давайте заглянем в самый настоящий архивный первоисточник - оригинальный текст стандарта комитета IEEE 802.11-1999, бережно сохраненный на серверах Массачусетского технологического института (MIT)

Таблица комбинаций To/From DS из оригинального стандарта ANSI/IEEE Std 802.11 (1999 года). Обратите внимание на последнюю строчку - IEEE официально закрепил честный WDS-режим за комбинацией "1 и 1" еще 27 лет назад.

Казалось бы, вот оно решение! Включай WDS на обоих устройствах и радуйся жизни. Но именно здесь мы упираемся в регуляторный вакуум.

IEEE описал 4-адресный формат кадра на канальном уровне, но абсолютно не регламентировал логику построения моста. Стандарт оставил без ответа базовые вопросы: как двум точкам доступа согласовывать таблицы коммутации, как обмениваться служебными кадрами и, самое главное, как шифровать этот 4-адресный трафик.

В результате каждый производитель чипсетов написал свою собственную, закрытую логику обработки 4-адресных кадров на уровне драйверов. О том, к какому хаосу и несовместимости это привело, мы поговорим чуть ниже.

Анархия в мире беспроводных драйверов

Стандарт IEEE 802.11 определил формат 4-адресного кадра через комбинацию флагов To DS = 1 и From DS = 1. Но он не описал программную логику, которая должна этот режим включать и обслуживать. Поэтому производители реализовали её по-своему.

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

1. Штатный Linux-стек (архитектура mac80211/nl80211)

В этой группе - открытые драйверы, которые входят непосредственно в mainline-ядро Linux. Именно они обрабатывают 4-адресный кадр стандартным, задокументированным кодом ядра:

Qualcomm/Atheros: драйверы ath9k, ath10k, ath11k, ath12k.
MediaTek: семейство драйверов mt76.
Realtek: современные драйверы rtw88 и rtw89

Когда беспроводной интерфейс устройства работает на любом из этих драйверов, он без проблем может быть переведен в режим 4addr и выглядит для системы как обычный сетевой порт, который штатные подсистемы ядра Linux могут прозрачно объединить в программный мост br0. Как включается этот режим, описано в разделе 4-address mode документации Linux Wireless.

Благодаря общей кодовой базе ядра Linux, устройства на чипах Qualcomm, MediaTek или Realtek совместимы между собой в режиме WDS, если на них запущены открытые драйверы (что мы и наблюдаем, например, в дистрибутивах OpenWrt).

2. Проприетарные Vendor-SDK и бинарные модули

Это закрытый софт, который вендоры поставляют производителям сетевого оборудования в виде готовых "черных ящиков" для сборки заводских прошивок:

Broadcom (драйвер wl): Самый известный пример закрытой экосистемы. Вместо стандартного сетевого стека Linux он использует собственную. Обработка трафика, контроль целостности кадра и отслеживание таблиц MAC-адресов происходят внутри проприетарного кода.
Realtek / Роутеры на заводском софте: Огромная масса бюджетных роутеров работает на базе старых официальных Vendor SDK от Realtek (со своими кастомными драйверами), которые не имеют ничего общего с открытым rtw88.

Такие закрытые решения проектируются производителями исключительно ради совместимости внутри своей собственной экосистемы (а часто и ради Vendor Lock-in).

Практический результат

WDS между устройством на проприетарном драйвере Broadcom (wl) и устройством на штатном Linux-стеке (Qualcomm/MediaTek), как правило, не работает вообще, даже в полностью открытой сети без шифрования.

Физически они видят друг друга, но логика обработки 4-адресных кадров не совпадает. Точная внутренняя механика закрытых драйверов не документирована. Однако итог всегда один: стандартный Linux-стек ядра и проприетарная логика Broadcom/Realtek оказываются несовместимыми на уровне L2 и прозрачный мост не поднимается.

Криптографический ад: как шифрование уничтожает WDS

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

Любой стандарт безопасности Wi-Fi (от древнего WPA до WPA2) в инфраструктурном режиме (Infrastructure Mode) базируется на жесткой иерархической модели разделения ролей в сети. В ней всегда есть две стороны:

Authenticator (Аутентификатор) - роль, которую берет на себя Точка доступа (AP). Она инициирует проверку подлинности, генерирует параметры для сборки сессионных ключей и контролирует этот процесс.
Supplicant (Суппликант) - Клиент (Station), который запрашивает авторизацию, участвует в расчете ключей и подчиняется правилам AP.

В рамках этой классической модели полноценного, симметричного режима "Точка-Точка" (Peer-to-Peer) для связи двух AP между собой стандартом изначально не предусматривалось.

Вся защита данных в беспроводной среде держится на генерации сессионного ключа шифрования PTK (Pairwise Transient Key), который создается в процессе четырехэтапного рукопожатия (4-Way Handshake). Чтобы этот ключ получился уникальным и стойким, в математическую формулу его расчета (функцию PRF) в явном виде входят следующие переменные:

MAC-адрес Аутентификатора (AP);
MAC-адрес Суппликанта (Клиента);
ANonce — случайное число, генерируемое на стороне AP;
SNonce — случайное число, генерируемое на стороне Клиента;
Главный мастер-ключ PMK (Pairwise Master Key), который в домашней сети рассчитывается из пароля (PSK) и SSID, а в корпоративной — генерируется динамически RADIUS-сервером.

Логический тупик

В режиме честного 4-адресного WDS-моста обе стороны линка работают в роли Точек доступа (AP). Для стандартных механизмов безопасности здесь мгновенно возникает программный и криптографический тупик на уровне Control Plane:

Проблема ролей. Полноценный 4-Way Handshake требует, чтобы один участник жестко был Аутентификатором, а второй — Суппликантом. Две классические AP, работающие в WDS, не могут договориться, кто из них возьмет на себя роль ведомого клиента для генерации случайных чисел ANonce / SNonce;
Проблема групповых ключей (Broadcast/Multicast). Для шифрования широковещательного трафика (например, нашего кадра DHCP-Discover) используется групповой ключ GTK (Group Transient Key). В стандартной сети его генерирует и обновляет единственная AP. Но в WDS-мосте у нас две независимые точки доступа, каждая из которых крутит собственный цикл генерации GTK для своих клиентов. Механизма безопасной синхронизации и обмена ключами GTK между двумя AP разных вендоров в спецификациях WPA/WPA2 попросту нет.

Война вендорских "костылей"

Поскольку стандарты WPA и WPA2 не дали ответа на этот вопрос, производителям беспроводного софта пришлось выкручиваться самостоятельно. Каждая инженерная школа пошла своим путем:

В штатном Linux-стеке (mac80211):
Проблема решается гибридной программной надстройкой. В Linux-дистрибутивах (например, OpenWrt) за это отвечает единый компилируемый пакет wpad, объединяющий в себе код hostapd и wpa_supplicant. На транзитном WDS-интерфейсе одна из точек принудительно запускает клиентский процесс wpa_supplicant, чтобы "притвориться" обычным беспроводным клиентом для своего соседа по мосту. Происходит классический 4-Way Handshake, генерируется ключ PTK, уникальный для этой пары устройств.
То, что это костыль, работающий на честном слове, подтверждает известный баг рассинхронизации ключей WDS на GitHub OpenWrt: при плановом обновлении ключей (rekeying) демоны hostapd и wpa_supplicant на WDS-линке регулярно теряют синхронизацию группового ключа (GTK) и намертво роняют мост с ошибкой PREV_AUTH_NOT_VALID.
В закрытом драйвере Broadcom (wl):
За безопасность WDS-линка отвечает закрытый бинарный демон nas (или его аналоги). Точные криптографические механизмы согласования ключей внутри этого «черного ящика» производителем не документируются, а сам обмен служебными маркерами скрыт внутри проприетарного кода.

Как только вы попытаетесь активировать WPA/WPA2-PSK шифрование на WDS-мосте между устройствами разных вендоров (например, точкой доступа MikroTik на QCA9533 и роутером с OpenWrt на mt7621), их софтовые демоны безопасности гарантированно сойдут с ума.

Они не смогут договориться о ролях в беспроводной среде и просто не поймут криптографический диалект друг друга. Четырехэтапное рукопожатие намертво зависнет на первом же шаге. Точки доступа будут бесконечно слать друг другу запросы авторизации и сбрасывать соединение, считая действия соседа попыткой подмены.

А что насчёт WPA3? Он меняет только механизм аутентификации (с PSK на SAE), но архитектурная проблема WDS - необходимость "притворяться клиентом" и отсутствие штатной синхронизации GTK - остаётся.

Защищенный "прозрачный" WDS-мост между разными вендорами превращается в неразрешимую на уровне стандартов задачу. Именно поэтому построение прозрачного L2-моста с шифрованием требует однородной программной экосистемы на обоих концах линка.

На практике это означает два пути:

Использовать оборудование одного вендора на собственном проприетарном софте. Причем для активации режима важно правильно выбрать роли в настройках. Для Ubiquiti под современными версиями airOS нужно на обоих концах выбрать сетевой режим Bridge, а переключатель Access Point включить только на одной стороне. Для MikroTik RouterOS это связка режимов ap-bridge и station-bridge.
Использовать устройства разных брендов, но под управлением единой открытой ОС (например, OpenWrt). В этом случае, даже если у вас на одной стороне моста стоит Xiaomi, а на другой - GL.iNet, одинаковые версии пакета wpad поймут криптографический диалект друг друга, запустят идентичную логику 4-Way Handshake и успешно поднимут защищенный 4-адресный линк.

Wi-Fi мост или не совсем. А может совсем не Wi-Fi?

Стоит упомянуть еще один важный момент: для улучшения передачи данных на больших расстояниях практически все производители профессиональных радиомостов разработали свои проприетарные протоколы, использующие принципиально иной способ доступа к среде.

Здесь стоит вспомнить главный фундаментальный принцип классического Wi-Fi - "пока один говорит, все остальные послушно молчат". Механизм CSMA/CA заставляет любое беспроводное устройство слушать эфир перед отправкой кадра, и если среда занята, брать случайную паузу. Это отлично работает в сетях со множеством мобильных клиентов, но в магистральных радиомостах типа Point-to-Point (PtP) порождает огромные накладные расходы и утилизирует эфирное время впустую.

Чтобы обойти эти ограничения, производители WISP-оборудования полностью отключают стандартный MAC-уровень Wi-Fi и закладывают в софт собственную реализацию механизма доступа к среде — TDMA (Time Division Multiple Access).

В отличие от CSMA/CA, здесь никто не слушает эфир перед отправкой. Радиоэфир жестко нарезается на микроскопические тайм-слоты, и каждая точка передает или принимает данные строго в свой выделенный временной интервал.

Как именно устройства координируют эти интервалы, как раз и описывают фирменные протоколы вендоров: NV2 у MikroTik RouterOS, airMAX у Ubiquiti airOS или MAXtream у TP-Link Pharos.

Роль фирменного софта в TDMA-мостах

При организации уличных радиомостов производители задействуют TDMA-механизмы в комплексе с 4-адресным режимом. В этот момент управление радиоканалом полностью переходит под контроль фирменных программных протоколов вендора.

Защита данных, генерация ключей и инкапсуляция трафика в таких линках осуществляются силами самой операционной системы (например, RouterOS у MikroTik, airOS у Ubiquiti или PharOS у TP-Link). Фирменный софт берет на себя управление безопасностью транзитного канала, что позволяет производителям обеспечивать обратную совместимость между разными поколениями своего оборудования, даже если внутри устройств установлены чипсеты от разных кремниевых вендоров (Qualcomm или MediaTek).

Однако оборотной стороной такой софтверной привязки является абсолютная закрытость: построить работающий TDMA-мост между устройствами разных производителей невозможно, так как их закрытые фирменные протоколы несовместимы между собой на программном уровне.

Утопия честного Mesh: почему 802.11s не стал массовым

Концептуальная схема построения ячеистой сети и взаимодействия узлов в стандарте IEEE 802.11s

Разработчики стандартов понимали, что костыли WDS нужно хоронить. В 2011 году IEEE попыталась создать "серебряную пулю" - стандарт IEEE 802.11s. Идея была монументальной: честный Mesh, нативная поддержка 4-адресных кадров, Peer-to-Peer шифрование (SAE-Mesh) и полноценная динамическая маршрутизация прямо на канальном уровне (Data Link Layer) по протоколу HWMP.

Этот стандарт до сих пор существует и поддерживается в Linux/OpenWrt, однако в массовом сегменте и корпоративных сетях он так и не прижился. Реальные внедрения единичны и относятся к узким нишам: промышленная автоматизация, сети экстренных служб, community-сети и исследовательские проекты.

В оборудовании MikroTik вкладка Mesh - это не стандартный 802.11s, а их проприетарный протокол HWMP+, который несовместим со спецификациями IEEE и имеет жёсткие архитектурные ограничения (работает только на старых драйверах беспроводного стека и пасует при росте масштаба сети).

В чём основные причины, почему технология осталась нишевой?

Дикий оверхед: Накладные расходы служебного трафика на поддержание карты дорог (маршрутизации) между узлами утилизировали радиоэфир в ноль.
Падение скорости: Каждый транзитный прыжок (хоп) по воздуху срезал пропускную способность сети минимум вдвое.

В итоге индустрия признала: попытка реализовать динамическую Mesh-маршрутизацию на уровне "голых" Wi-Fi кадров силами самих точек доступа - это тупик для забитого эфира. Именно поэтому производителям абонентского и SOHO-железа пришлось искать принципиально иной компромисс.

Эра EasyMesh и абстракция стандарта IEEE 1905.1

Чтобы спасти индустрию массового абонентского и SOHO/SMB оборудования от окончательного разброда, организация Wi-Fi Alliance пошла по пути создания надстроек над существующими технологиями, выпустив спецификацию EasyMesh.

Вместо того чтобы изобретать новые типы беспроводных кадров, разработчики разделили архитектуру на два независимых уровня:

Передача данных: Всё тот же классический 4-адресный режим (To DS=1, From DS=1), который аппаратно умеют обрабатывать чипсеты любых вендоров.
Управление и безопасность: Координация ключей шифрования (включая современные WPA3-SAE), построение топологии сети и механизмы роуминга клиентов (802.11k/v) были вынесены на промежуточный слой абстракции - международный стандарт IEEE 1905.1.

Стандарт IEEE 1905.1 задумывался как универсальный программный клей. Это виртуальный слой над Уровнем 2, который объединяет в общую сеть вообще любые физические интерфейсы: Wi-Fi, Ethernet, Powerline (PLC) и MoCA (коаксиальный кабель). Устройства обмениваются специальными служебными кадрами в формате CMDU (Control Message Data Unit), строят честную карту топологии и централизованно синхронизируют настройки безопасности. Поскольку генерация и передача ключей шифрования для транзитных радиоканалов (Backhaul) теперь контролируются софтом на уровне абстракции 1905.1, криптографический тупик WPA наконец-то удалось обойти на устройствах с разными чипсетами.

Но здесь в игру вступил капитализм. Вендоры начали откровенно саботировать EasyMesh на программном уровне. Зачем условному производителю делать свои роутеры совместимыми с конкурентами, если можно запереть покупателя внутри своей экосистемы (Vendor Lock-in)? В результате тот "Mesh", который вы сегодня видите на красивых коробках в магазинах - это чаще всего закрытые системы. И по большому счету никаким "Мешем" там и не пахнет. Трафик в них передается не по кратчайшему пути между ячейками (как по идее должен передаваться в Mesh-сетях), а по единственному активному транзитному линку и топология динамически перестраивается только в одном случае - если этот основной транзитный линк физически "умер".

Резюме: Сравнительный анализ "многоадресных" технологий.

Чтобы окончательно разложить кашу в головах читателей, соберём все три подхода к построению беспроводных мостов и Mesh-сетей в единую таблицу:

Критерий	WDS (Transparent Bridge)	IEEE 802.11s (Честный Mesh)	Маркетинговый Mesh (EasyMesh / 1905.1)
Формат кадра	4-адресный (To-DS=1, From-DS=1)	4-адресный + Mesh-заголовок	4-адресный (инкапсулированный)
Где работает логика	На уровне беспроводного драйвера чипсета	Внутри сетевого стека ОС (Data Link Layer)	На уровне абстракции (IEEE 1905.1) над L2
Маршрутизация	Отсутствует (классический L2-коммутатор)	Динамическая (протокол HWMP)	Иерархическое дерево (STP/Multi-AP)
Совместимость вендоров	Нет (только один вендор/драйвер)	Да (если поддерживается драйвером ядра)	Теоретически да, фактически нет (из-за Vendor Lock-in)

Какие можно сделать выводы из вышесказанного?

Индустрия беспроводных сетей прошла огромный путь от L2-NAT до сложных абстракций вроде IEEE 1905.1. Но главная истина осталась неизменной: если вам нужно построить прозрачный, стабильный и защищенный радиомост или Mesh-систему — никогда не смешивайте вендоров в одной беспроводной L2-среде. Иначе скорее всего у вас просто ничего не взлетит.

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