Слышали ли вы жалобы на то, что принтеры, подключённые к сети по Wi-Fi, работают очень ненадёжно?
Принтер может без проблем печатать большую часть времени, но когда он вам срочно понадобился, ОС не может его найти и он оказывается недоступен?..

Или, может быть, смартфон, который бесперебойно вещал видео на Chromecast в телевизоре ещё 10 минут назад, теперь не может найти его в домашней сети?

В прошлом году я потратил немало времени на диагностику и устранение загадочных проблем с протоколами автообнаружения по Wi-Fi.
Разные настройки, разные Wi-Fi-роутеры, разные ОС и устройства, но основная проблема едина: всё, что использует автообнаружение, работает недостаточно стабильно и в самый нужный момент попросту ломается.

mDNS (и DNS-SD)

Многие современные устройства используют один из протоколов нулевой настройки (zero-configuration), что ускоряет процесс первоначальной установки оборудования и упрощает дальнейшее использование.
В настоящее время наиболее распространённым протоколом является mDNS (он же Bonjour), изначально созданный Apple и используемый принтерами, Apple AirPlay/HomeKit, Google Chromecast, колонками Sonos, Home Assistant, различными датчиками умного дома и оборудованием IoT.

mDNS (Multicast DNS) очень похож на обычный протокол DNS. Он передаёт практически те же данные, использует те же типы пакетов, и не реализует никаких новых функций по сравнению с классической версией. Но он сильно отличается на архитектурном уровне:

• Используются Multicast UDP-пакеты с жёстко заданным адресом назначения (Multicast-группой) 224.0.0.251 / ff02::fb и портом 5353;

• Не требуется сервер и централизованное управление доменной зоной;

• Обычно обрабатывает только запросы зоны *.local;

• Конфликты имён автоматически разрешаются путём переименования устройства/хоста, если в сети уже присутствует устройство с таким же именем.

Как и обычный DNS, mDNS публикует и преобразует имена хостов в IP-адреса, что позволяет удобно подключаться к устройству по имени вместо адреса.

Но как компьютер может узнать тип устройства, что принтер — действительно принтер? Тут вступает в игру DNS-SD.

DNS-SD (DNS Service Discovery) — это расширение mDNS, в котором распространённым типам сервисов присвоены определённые имена DNS-записей. Например, для принтеров с Internet Printing Protocol (IPP) это _ipp._tcp.local.
Устройство может опубликовать PTR-запись с домена DNS-SD на своё имя, и другие члены локальной сети смогут его обнаруживать.

Запросим записи DNS-SD в Linux с помощью avahi-browse:

$ avahi-browse -t _ipp._tcp

+ enp86s0 IPv6 Canon1120 @ uowprint _ipp._tcp local
+ enp86s0 IPv6 hp1000 @ uowprint _ipp._tcp local
+ enp86s0 IPv4 Canon1120 @ uowprint _ipp._tcp local
+ enp86s0 IPv4 hp1000 @ uowprint _ipp._tcp local

Работает, отлично!
Давайте рассмотрим случаи, когда ничего не работает.

Проблема №1: Wi-Fi-карты от Intel

В популярных Wi-Fi-модулях Intel AX201, AX210, AX211 (и более старых, таких как AC8260), имеется ошибка драйвера Windows, которая препятствует работе mDNS после режима сна (suspend) и выхода из него.

Проблема известна как минимум с 2020 года и не исправлена ​​по состоянию на октябрь 2025 года.

Шаги воспроизведения:

1. Убедиться, что в сети есть некое устройство, отвечающее по mDNS

2. Выполнить в PowerShell Resolve-DnsName name-of-that-device и убедиться, что оно резолвится

3. Отправить ноутбук в сон

4. Разбудить

5. Повторить пункт 2

Если mDNS продолжает работать, то:

1. Убедиться, что в сети есть некое устройство, отвечающее по mDNS

2. Выполнить в PowerShell Resolve-DnsName name-of-that-device и убедиться, что оно резолвится

3. Выключить Wi-Fi кнопкой "Wi-Fi" в Windows (т.е. не отключится от конкретной сети, а выключить сам адаптер)

4. Отправить ноутбук в сон

5. Разбудить

6. Включить Wi-Fi, подключиться к сети

7. Повторить пункт 2

Итог: после цикла сон-пробуждение никакие mDNS-запросы не работают.
Иногда чинится включением-отключением авиарежима (чтобы отключился Wi-Fi-модуль), но не всегда.

Соответствующие темы на форуме сообщества Intel:

• Intel WiFi chips are blocking multicast after resuming from airplane mode etc.

• Multicast messages not always received over Wifi with AC8260

• mDNS packets not received on Intel Wi-Fi chips

Протестировано с Intel AX211 (драйвер 23.110.0.5, драйвер 22.240.0.6), AX201 (драйвер 22.40.0.7).

Проблема №2: Wi-Fi-карты от Qualcomm

В модуле Qualcomm QCA6174, который установлен в планшете Microsoft Surface Go (1-го поколения), имеется аналогичная ошибка драйвера, как и в Intel, с похожими симптомами, но шаги для её воспроизведения не столь очевидны, и мне не удалось надёжно повторять проблему.
Иными словами, ошибка плавающая (и не зависит от GTK — см. далее).

К сожалению, эта карта не поддерживается напрямую компанией Qualcomm, а Microsoft больше не поддерживает планшеты Surface Go, поэтому, скорее всего, проблема никогда не будет устранена.

Версия проблемного драйвера: 12.0.0.1159.

Проблема №3: ​​Mediatek MT6572M

Это очень старая (примерно 2009 года) смартфонная система-на-чипе (SoC) с двухъядерным процессором ARMv7, которая в своё время использовалась во множестве смартфонов, а также в одноплатном компьютере Orange Pi 3G-IoT-A из прошлой статьи про первую ревизию «умного» принт-сервера.

Принт-сервер на Orange Pi, под управлением CUPS, расшаривает USB-принтер через AirPrint/Mopria, по сети. Для работы этой функции требуется поддержка mDNS и DNS-SD.

Как выяснилось, чип Wi-Fi, интегрированный в SoC, некорректно обрабатывает «полноценное» (не смешанное) шифрование WPA2, в котором применяется шифр AES (CCMP) для Multicast-пакетов.

Переключение сети в «смешанный режим» (WPA/WPA2) решило проблему: в этом режиме для Multicast-трафика применяется шифр TKIP, что, по-видимому, не приводит к возникновению ошибки.

Проблема №4: Точки доступа Ubiquiti

Пользователь Reddit с ником sharhalakis потратил 1,5 года на диагностику и устранение проблем с работой Multicast на точках доступа Ubiquiti

Проблемы с Broadcast/Multicast-трафиком в UAP [диагностировано и решено]

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

• Станция подключается и получает от точки доступа GTK с индексом 1.

• Затем точка доступа отправляет Broadcast-кадры, используя ключ с индексом 2.

Проблема начинается в разные моменты:

• Может происходить сразу после подключения станции;

• Может начаться после смены ключа;

• Может произойти с подключёнными станциями, даже если смены ключа GTK не было.

Автор предложил несколько способов решения этой проблемы, и ошибка была окончательно исправлена ​​в обновлении прошивки 5.43.34.12682.

Почему проблемы mDNS так регулярно проявляются в беспроводных сетях

Протоколы автообнаружения (mDNS/DNS-SD) используют Multicast-трафик, который и сам по себе требует особого подхода на стороне сетевого оборудования и ПО, и для работы через Wi-Fi требует дополнительной обработки.

Групповой временный ключ (GTK)

Wi-Fi использует два типа ключей для различных ситуаций:

• Парный временный ключ (Pairwise Temporal Key, PTK) — это уникальный клиентский ключ, используемый для обычных unicast-пакетов, а также для broadcast и multicast от клиента Wi-Fi к точке доступа (или хосту в проводной сети);

• Групповой временный ключ (Group Temporal Key, GTK) — это общий ключ, используемый для broadcast и multicast от точки доступа (или хоста в проводной сети) к клиенту Wi-Fi.

Уже заметили проблему?

Классические интернет-протоколы обычно используют широковещательную и многоадресную рассылку только для анонсирования самого клиента серверу, который в случае Wi-Fi использует PTK, а не GTK.
Возьмём, к примеру, DHCP:

• Клиент broadcast'ом шлёт DHCP Discover: (Клиент (PTK) → AP);

• Точка доступа отвечает пакетом DHCP Offer unicast: (AP (PTK) → Клиент);

• Пакеты DHCP Request и DHCP Ack отправляются unicast и используют PTK.

Однако, в отличие от классического DNS, mDNS отвечает пакетами multicast, чтобы все в сети могли узнать IP-адрес устройства, даже если они его не запрашивали.

• Multicast используется для стандартного запроса mDNS: (Клиент (PTK) → AP)

• Также multicast используется для ответа на запрос mDNS: (AP (GTK) → Клиент) ← ошибка здесь!

Поскольку большинство протоколов используют многоадресную рассылку только от клиента к точке доступа (в этом случае используется PTK), но не наоборот, проблемы с GTK обнаружить и отладить непросто. В основном всё работает, но не mDNS!

Ключ GTK также часто меняется, обычно каждый час, 6 часов, 24 часа или другой «круглый» промежуток времени.
Рекомендую прочитать ответ пользователя Spiff на сайте SuperUser, если хотите узнать особенности Wi-Fi подробнее.

Присоединение к Multicast-группе

Чтобы получать многоадресный трафик, приложение должно сначала присоединиться к «группе» многоадресной рассылки с помощью протокола IGMP (Internet Group Management Protocol). В случае mDNS эта группа представляет собой известный IP-адрес 224.0.0.251.

Однако многоадресная рассылка по Wi-Fi — еще один особый случай. Поскольку multicast «точка доступа → клиент» по сути является обычным broadcast'ом, направленным каждому клиенту точки доступа, технически не требуется присоединение к группе для получения данных.
Несмотря на это, драйвер Wi-Fi клиента обычно сам отбрасывает многоадресные пакеты, полученные от групп, на которых ОС не подписывалась, в основном из соображений энергосбережения.

Пакеты присоединения к группе "Membership Report" имеют тайм-аут, по истечении которого его необходимо отправить повторно, для повторного присоединения к группе.
Работа с таймаутами (или с повторной отправкой пакетов) также бывает некорректно реализована в драйверах Wi-Fi.

VPN / Несколько интерфейсов (multihoming)

Некорректно написанные приложения отправляют пакеты mDNS только через основной сетевой интерфейс (интерфейс «маршрута по умолчанию»), что приводит к невозможности обнаружения устройств в локальной сети при подключенном VPN с маршрутом по умолчанию — пакет уходит в неправильный сетевой интерфейс.

Это, увы, очень распространенная ошибка как в клиентских приложениях (примером может служить KDE Connect), так и в VPN-клиентах, которые не применяют обходные пути для предотвращения маршрутизации Multicast/Broadcast в туннель.

Возможные решения проблемы

Кратко: если ваш принтер, Chromecast или другое устройство с mDNS постоянно подключено к сети (вы видите его IP-адрес в веб-интерфейсе маршрутизатора, его можно пинговать), но обнаруживается в сети только ровно 1 час, 1 день или другое время, скорее всего, это проблема c Multicast/GTK.

Следует попробовать:

• Проверить роутер на наличие опции фильтрации многоадресной рассылки (ICMP filtering, отключите её), а также IGMP Snooping (отключение этой опции приведёт к маршрутизации всего multicast-трафика без необходимости предварительного присоединения устройства к многоадресной группе).

• Переключить режим безопасности Wi-Fi на "WPA-PSK/WPA2-PSK Mixed" — это приведёт к принудительному использованию шифрования TKIP для группового ключа (GTK), который более совместим с некоторыми устройствами (как продемонстрировано в проблеме № 3).

• Полностью отключить смену ключа GTK (группового ключа). Multicast и Broadcast-данные будут шифроваться статическим ключом, что менее безопасно.

• Создать отдельную (но не изолированную) сеть Wi-Fi только для принтера.