Комментарии 7
avahi-browse разве умеет бровсить произвольные RR-ы?
Кроме avahi-browse -tr _ipps._tcp, отдельно устройству и его RR у меня получилось вот так:
$ resolvectl query --type=srv 'Brother DCP-T720DW._ipps._tcp.local'
Brother\032DCP-T720DW._ipps._tcp.local IN SRV 0 0 443 brother.local -- link: wlo1
$ resolvectl query --type=txt 'Brother DCP-T720DW._ipps._tcp.local'
Brother\032DCP-T720DW._ipps._tcp.local IN TXT "txtvers=1" "qtotal=1" "pdl=application/octet-stream,image/urf,image/jpeg,image/pwg-raster,application/vnd.brother-hbp" ...
Еще resolvectl умеет в json.
Или даже так resolvectl service 'Brother DCP-T720DW._ipps._tcp.local'
Хм.
$ mcdig _ipp._tcp.local ptr - есть ответ
$ resolvectl query -p mdns --type=any _ipp._tcp.local
_ipp._tcp.local: resolve call failed: No appropriate name servers or networks for name found
Чего-то ему не хватает, а что именно, признаваться не хочет.
P.S. systemd, кажется, собрался потеснить avahi. Будем теперь всем линухом по второму кругу все грабли проходить...
В нюансы добавить можно следующее:
В прошлом месяце потратил некоторое время на отладку загадочных проблем с протоколами автоматического обнаружения через Wi-Fi: проблема была в старом маршрутизаторе, или, точнее, несовместимости (предположительно глючной) прошивки/чипа Wi-Fi маршрутизатора и чипа Wi-Fi устройства.
Если ваш принтер постоянно подключен к сети (и вы это видите в веб-интерфейсе роутера), но его обнаружение в сети работает только ровно 1 час, 1 день или другое круглое время, попробуйте:
Проверить маршрутизатор на наличие опции мультикаста и IGMP Snooping
Сменить режим безопасности Wi-Fi на "WPA-PSK/WPA2-PSK Mixed"
Отключить смену ключа GTK (группового ключа)
Создать отдельную (но не изолированную) сеть только для принтера
Протоколы автоматического обнаружения (mDNS/DNS-SD) используют мультикаст, который работает не так тривиально через Wi-Fi по сравнению с проводной сетью.
Wi-Fi использует разные алгоритмы шифрования и разные ключи шифрования для юникаст и широковещательного/мультикаст-трафика: индивидуальные ключи шифрования для каждого клиента для обычного юникаст-трафика (pairwise key) и отдельный общий ключ шифрования для группового трафика (group key) для броадкаст и мультикаст-трафика.
Оказывается, при некоторых условиях могут возникнуть проблемы с многоадресной рассылкой. Драйверы Intel Wi-Fi в Windows неправильно обрабатывают мультикаст-трафик после отправления компьютера в сон, а точки доступа Ubiquiti известны неправильной обработкой GTK.
Что касается IGMP Snooping: некоторые точки доступа требуют, чтобы устройство присоединилось к группе многоадресной рассылки mDNS для получения запросов mDNS. Большинство точек доступа пересылают запросы mDNS независимо от того, был ли запрос на присоединение к multicast-группе, или нет, но некоторые этого не делают или обрабатывают multicast неправильно.
Мне кажется, это достойно отдельной статьи, посвященной именно глюкам WiFi
В WiFi предусмотрена перепосылка потерянных пакетов потому, что TCP очень болезненно относится к большому проценту потерь. Он их воспринимает как сигнал о переполнении канала (на проводных сетях это разумное предположение, потому что из-за помех на линии пакеты теряются редко, а вот роутер при переполнении очереди запросто начнет отправлять их в /dev/null), и начинает снижать скорость. Поэтому, чтобы обеспечить сносную работоспособность TCP, WiFi следит за доставкой юникастных пакетов. Но за мультикастами не следит, и там потери будут равны канальным потерям, а при загруженной/забитой/зашумленной сети они запросто могут быть, скажем, 10% или типа того.
Я знаю, что юникастный и мультикастный ключи шифрования в WPA разные, но насколько я помню, при rekeying-е обновляются и те и другие. Я не знал, что в результате клиент может прохлопать смену группового ключа.
Что касается IGMP Snooping, по идее та же самая проблема существует даже на Ethernet-свитчах. Разные устройства, включенные в свитч, могут договориться с ним на разную скорость, и если юникаст будет отправлен на той скорости, на которой договорилось устройство, воткнутое в данную дырку, то бродкаст-мультикаст пойдет на самой маленькой скорости среди всех дырок. Т.е., достаточно, чтобы одно устройство договорилось на 100 мб, и в гигабитной сети мультикасты будут ходить на 100 мб (а некоторые альтернативно одаренные устройства умудряются и на 10 мб договориться). Поэтому если сеть объединена несколькими свитчами, свитчи будут стараться следить, кому на самом деле нужны мультикасты. Формально, wi-fi точка доступа - это тоже свитч, просто одна сторона у нее wifi-ная.
Multicast DNS и DNS-SD