Слышали ли вы жалобы на то, что принтеры, подключённые к сети по 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 года.
Шаги воспроизведения:
Убедиться, что в сети есть некое устройство, отвечающее по mDNS
Выполнить в PowerShell
Resolve-DnsName name-of-that-deviceи убедиться, что оно резолвитсяОтправить ноутбук в сон
Разбудить
Повторить пункт 2
Если mDNS продолжает работать, то:
Убедиться, что в сети есть некое устройство, отвечающее по mDNS
Выполнить в PowerShell
Resolve-DnsName name-of-that-deviceи убедиться, что оно резолвитсяВыключить Wi-Fi кнопкой "Wi-Fi" в Windows (т.е. не отключится от конкретной сети, а выключить сам адаптер)
Отправить ноутбук в сон
Разбудить
Включить Wi-Fi, подключиться к сети
Повторить пункт 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
Протестировано с 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.
Следует попробовать:
Проверить роутер на наличие опции фильтрации многоадресной рассылки (IGMP filtering, отключите её), а также IGMP Snooping (отключение этой опции приведёт к маршрутизации всего multicast-трафика без необходимости предварительного присоединения устройства к многоадресной группе).
Переключить режим безопасности Wi-Fi на "WPA-PSK/WPA2-PSK Mixed" — это приведёт к принудительному использованию шифрования TKIP для группового ключа (GTK), который более совместим с некоторыми устройствами (как продемонстрировано в проблеме № 3).
Полностью отключить смену ключа GTK (группового ключа). Multicast и Broadcast-данные будут шифроваться статическим ключом, что менее безопасно.
Создать отдельную (но не изолированную) сеть Wi-Fi только для принтера.
Комментарии (22)
BoreaAlex
31.10.2025 03:17Мне встречались отвалы mDNS и в проводной сети. Поэтому скажу банальщину - если можно подключить устройство по IP адресу, подключаю именно так.
RoasterToaster
31.10.2025 03:17Главное не забыть зарезервировать IP на роутере или выставить его вручную.
ValdikSS Автор
31.10.2025 03:17Сертифицированные по AirPrint принтеры, между прочим, обязаны работать вообще без IP-адресов:
7.8 Mixed-Network Interoperability
The printer MUST be able to route to the link-local address range in situations where
the printer contains a routable address but the computer has a link-local address. You
can implement this by adding a network address of 169.254/16 to the printer’s routing
table.
The printer MUST be able to communicate with a routable address in situations where
the printer has a self-assigned link-local address, but the computer, which is located on
the local-link, contains a routable address. This can be accomplished by ARP-ing for
the destination address and then sending the packet directly to the routable address
ValdikSS Автор
31.10.2025 03:17Системные администраторы уровня локалхоста могут сделать «незаметную» сегментацию сети (vlan'ы с маршрутизацией или arp-proxy между ними) так, что всё будет работать, кроме multicast'а, потому что его маршрутизация часто требует отдельной настройки (прямо как в случае проблем с Wi-Fi GTK).
gazkom
31.10.2025 03:17У меня на роутере сервис mDNS жрал память, поэтому я его отключил. Cromecast работает, принтер печатает. Зачем тогда этот mDNS нужен?
ValdikSS Автор
31.10.2025 03:17mDNS reflector? Чтобы mDNS работал между разными сегментами, и, возможно, разными роутерами, объединёнными в mesh-сеть.
Rim13
31.10.2025 03:17Этот пост мне напомнил про другой пост.
Инженер показал, что устройства Apple вызывают непредсказуемые скачки задержки в Wi-Fi из-за технологии AWDL, на которой основан AirDrop. По его словам, эта система заставляет сеть периодически «дергаться», что особенно заметно при потоковой передаче данных.
ValdikSS Автор
31.10.2025 03:17Multicast/broadcast-трафик передается с минимальной скоростью, чтобы его получили все подключённые к точке устройства.
itoolsy
31.10.2025 03:17Советовать WPA в 2025 году - это смело. Давать ссылки на разбор 11-и летней давности и дрова Unifi тех же годов - тоже смело. Да еще и бесполезно ибо пофикшенно, но как экскурс в историю - хорошо.
Есть еще много интересного в mDNS и, например, в multicast трафике между VLAN-ами, где один из них отведен под IoT да еще в IPv6 при использовании оборудования уровня Микротика - вот там можно 2 статьи написать. Вообще, как только речь идет про IPv6 и умные устройства типа MoT, начинает дергаться глаз.ValdikSS Автор
31.10.2025 03:17Давать ссылки на разбор 11-и летней давности и дрова Unifi тех же годов - тоже смело
Исправленная прошивка вышла в 2021 году. Точки UAP-AC-Lite, UAP-AC-LR и другие, для которых она предназначена, всё ещё продаются. О каких 11 годах речь?
Советовать WPA в 2025 году - это смело
Дофига и больше устройств не поддерживают WPA3, и уж наверняка этот стандарт поддерживает меньшинство IoT-техники, которое в основном использует 2.4 ГГц.
Да еще и бесполезно ибо пофикшенно
О, обожаю такие упрёки.
У нормальных людей цикл смены оборудования, если оно работает и отвечает требованиям (и требования не менялись с момента установки) — пока не сломается. Как правило, это 10+ лет.
Asus RT-AC68U из 2013 всё ещё маршрутизирует несколько сотен мегабит, раздаёт Wi-Fi по относительно скоростному Wi-Fi 5, 5 ГГц, и всё ещё поддерживается производителем — последнее обновление прошивки вышло 4 дня (!) назад. В рамках домашнего использования с домашними задачами нет совершенно никакого резона менять его на что-то другое.Я постоянно натыкаюсь на различные баги и проблемы в технике, и это меня заколебало до такой степени, что покупаю только оборудование, где либо производитель предоставляет прямую поддержку частным лицам, либо серии бизнес-класса, где срок поддержки в 10 лет считается нормальным явлением.
И мне регулярно приходится сообщать производителям о проблемах в их оборудовании.Для примера возьмём обычную, совершенно типичную ситуацию: именитый производитель, тот же Asus, берёт чип, скажем, Broadcom, и делает Wi-Fi-роутер на его основе. Системная часть ПО написана Broadcom'ом, Asus вносит только свои коррективы, интерфейс, пользовательские функции, и т.п.
Если обнаруживается низкоуровневая проблема, как из этой статьи, на её диагностику могут уйти годы.
Она проявляется только в отдельном сценарии использования
Она плавающая
Для её воспроизведения требуются особые условия и время (включите точку и IoT-устройство — все будет работать до смены GTK)
Для её диагностики требуется разбирающийся технический специалист со стороны Asus, чтобы задокументировать и передать информацию в Broadcom — сами они её решать не будут
Сообщения о проблемах от среднестатистического покупателя роутера будет а-ля «у меня не работает», без необходимых подробностей (т.к. пользователи не понимают, какие данные важны, а какие нет), и без технических деталей (потому что пользователь — не технический специалист). Как правило, такие сообщения целиком бесполезны. И это в лучшем случае!
А скорее всего письмо будет направлено сперва производителю принтера — ваш принтер сломан, пропадает из сети, не могу печатать, и Asus получит письмо, если производитель попытается разобраться в проблеме и укажет на дефективный роутер. Письмо, конечно же, от пользователя, а не от производителя принтера — ведь производитель принтера не клиент компании Asus и не может получить тех. поддержку, даже если его сообщения в разы полезней.Поэтому, ни много ни мало, в современном мире решение тех. проблемы — дисциплина, требующая технических навыков для её диагностики и документации, коммуникативных навыков для донесения информации через всю цепочку поставки ответственному лицу через сотрудника первой линии поддержки, и в каком-то смысле социально-экономических: если не обращают внимания и не исправляют, куда и как давить, чтобы добиться своего.
И в особенности для модулей Wi-Fi, которые один другого хуже.Если для вас информация неактуальна и бесполезна, не утруждайте себя чтением и комментированием этой и других статей. Я сам так делаю, временами одёргивая себя прямо во время написания комментария, когда сильно бомбит.
А я продолжу пополнять запасы модулей на старом AR9271 — сильно устаревшей, но единственной известной мне полноценной работающей Wi-Fi-карте, и с открытой прошивкой. Их у меня несколько сотен.itoolsy
31.10.2025 03:17Речь о посте, на который у вас ссылка вот тут:
Рекомендую прочитать ответ пользователя Spiff на сайте SuperUser, если хотите узнать особенности Wi-Fi подробнее.
Он от: answered Mar 25, 2014 at 1:36
Что касается вот этого:
Дофига и больше устройств не поддерживают WPA3, и уж наверняка этот стандарт поддерживает меньшинство IoT-техники, которое в основном использует 2.4 ГГц.
Ага, но вот незадача, есть колоссальная разница между безопасностью WPA и WPA2. Вы, по какой-то причине, сразу на WPA3 перепрыгнули, хотя до этого советовали именно комбинацию WPA/WPA2 и что там устройство выберет - одному разработчику известно. Я не знаю, в курсе ли вы или нет, но уже давно является хорошим тонов выделять под IoT отдельный SSID с WPA2 и заворачивать его в отдельный VLANValdikSS Автор
31.10.2025 03:17Речь о посте, на который у вас ссылка вот тут
Он описывает стандарт, он за это время не поменялся и работает так же. Информация актуальна.
Ага, но вот незадача, есть колоссальная разница между безопасностью WPA и WPA2
Речь о WPA/WPA2 Mixed Mode, который не привнесёт прям супер проблем с безопасностью в домашней среде. PMK сломается, наверняка роуминг тоже, multicast/broadcast в TKIP заинжектить могут, это да, но в чём колоссальная разница?
Я не знаю, в курсе ли вы или нет, но уже давно является хорошим тонов выделять под IoT отдельный SSID с WPA2 и заворачивать его в отдельный VLAN
VLAN с изоляцией? А пользоваться принтером и Chromecast'ом как, каждый раз переключаться в изолированную сеть?
Galkihtuw
31.10.2025 03:17А я то думала, что у меня руки кривые, раз принтер через раз находится, а оказывается проблема системная и сидит глубоко в драйверах
Статья просто бальзам на душу!
Mike-M
31.10.2025 03:17Десятилетиями использую дома простой сценарий:
вместо адресации по имени — адресация по IP-адресу
вместо динамического IP-адреса — статический
вместо Wi-Fi — Ethernet (кроме смартфона)
Никаких проблем.
user-book
оо, так это драйверная проблема? я всегда считал чисто программной, точнее более высокого уровня - программисты самого софта (а не драйверов) не заморачивались, потому как на разных платформах разные "приколы"
много лет разное разрабатываю и знаю что стабильно "ловить" устройство в локальной сети можно только по айпишнику.
То есть любое "автопределение" нужно строить на своих протоколах и рукопожатиях. Просканировать все доступные адреса и постучатся к каждому не так уж долго и абсолютно не сложно.
mDNS это здорово и обязательно для какой-то смарт железки, но он работает как бог пошлет и для реального использования когда парк клиентских устройств неизвестен "красивый" адрес доступа это больше маркетинговый ход
---
вообще вайфай для полоумных железок это всегда боль-дырка-задница потому как никогда не угадаешь как приемник будет обрабатывать соединение на своей стороне, а для слабых нестабильных по каналу железок это критично.
Еще большая боль это появившиеся относительно недавно "умные" сетевые функции в каждом утюге, из-за чего шибко умный роутер может рубануть на половине показавшееся ему медленное соединение, что бы тут же попытаться дать параллельно разные запросы на железку для получения этого же контента, но кусками:
- со стороны клиента это выглядит как зависший, а потом завершившийся ошибкой запрос
- а со стороны железки как агрессивный дедос где клиент даже не пытается читать ответ, ему нужно только забить канал.
ValdikSS Автор
Ого, и IPv4 /16 будете сканировать, и IPv6 /64 в IPv6-only-сетях? И через каждый сетевой интерфейс и диапазон?
В целом неплохо работает, но всецело полагаться на него не стоит. Часть устройств реализуют еще и UPNP-стандарты: Chromecast отправляет discovery и по DNS-SD, и по SSDP, и второй на старых точках доступа может работать лучше, вероятно, в силу того, что стандарт более старый и в драйверах написаны костыли конкретно для него (для его multicast-группы и порта, работает он по такому же принципу).
Я видел, как Wi-Fi был реализован неправильно даже на физическом уровне: использовалась модуляция QPSK при 1мбит/с MCS 0, что противоречит стандарту. Не работало, естественно.
user-book
99% покрывается сканированием ближнего от хоста диапазона (проверяя первым сам хост)
для 1% есть режим ручной настройки, где пользователь может сам руками вписать
по mDNS когда то еще очень давно на заре карьеры не раз пробовал что-то творить, но боевые интеграции показывали уйму подводных из за чего он остался уделом маркетинга и всяких фронт-енд аппок (и благодаря фронт-ендерам я знаю что проблемы с mDNS до сих пор всеобъемлющи и могут колебаться даже в пределах одной платформы)
К слову для интернет-железок IPv6 это до сих пор очень редкая редкость не в последнюю очередь потому что с ним не умеют работать
если прям вообще пиздец как очень сильно надо что бы железка была в сети корпоративного сегмента со всеми лицензиями и сертификатами то беру готовый сертефицированій модуль и работаю с ним по TTL (там зачастую свои протоколы) и такое было всего два раза у меня на практике, оба с немцами и оба раза как конкретное требование просто потому что
я видел вайфай который работал от степлера! Горе монтажники (причем вообще левые мимокрокодилы со своим кабелем ) пробили длинной скобой и на излете снайперски попали в жилу pcb-антены. Собственно у меня на столе она оказалась от заявки "нестабильно и слабо работает сеть"
haga777
Можно вопрос не по теме?
А что делать, если провайдер даёт /56 ДИНАМИческий префикс.
На микротик можно через ddns/cloud /bth получить доступ по в4/в6 адресу, а если нужно подключаться через в6 протокол, но через микротик на другое оборудование. Да тот же ноут.
Я пробовал с Мегафона, подключался на ноутбук. Но адрес меняется из-за смены префикса
Galkihtuw
Так в том то и дело что это многоуровневая проблема. Кривые драйверы, баги в прошивках роутеров, плюс еще и разработчики приложений, которые не хотят заморачиваться и делают все в лоб, в итоге получается что самый надежный способ это старый добрый статический IP
И это в 2025 году, с умными домами и нулевой конфигурацией)