я думал avahi-resolve
и dig -p 5353 @224.0.0.251
сделал то же самое.
Однако у меня есть устройство, на котором я могу разрешить его имя с помощью avahi-resolve
но не используя dig
:
$ avahi-resolve --name ding-5cd80b3.local
ding-5cd80b3.local 192.168.0.248
$ dig +short -p 5353 @224.0.0.251 ding-5cd80b3.local
;; Warning: ID mismatch: expected ID 60466, got 0
Ни с одним из них я не могу выполнить обратный поиск:
$ avahi-resolve --address 192.168.0.248
Failed to resolve address '192.168.0.248': Timeout reached
$ dig +short -p 5353 @224.0.0.251 -x 192.168.0.248
;; connection timed out; no servers could be reached
Устройство, рекламирующее его имя, является простым устройством IoT, поэтому я не удивлен, что у него очень простая поддержка mDNS (если используется поддержка mDNS предоставлено ESP-IDF).
Я пробовал использовать подробные флаги с обоими avahi-resolve
и dig
чтобы увидеть, даст ли мне какое-то представление о том, что происходит, но ни в том, ни в другом случае я не получил никакого дополнительного понимания.
Я предполагаю что ID mismatch
Значит это dig
на самом деле получает ответ, но отказывается его показать, поскольку интерпретирует это как случай Подмена DNS пока avahi-resolve
становится более снисходительным.
Есть ли способ получить dig
быть более снисходительным (я пытался +besteffort
) или каким-либо образом я могу увидеть, что здесь происходит, кроме использования Wireshark?
Я работаю над Ubuntu, и, как уже отмечалось, рассматриваемое устройство использует ESP-IDF.
Проблема действительно, похоже, связана с базовой библиотекой ESP-IDF и ее поддержкой mDNS.
Он не включает в свой ответ идентификатор, включенный в исходный запрос, он всегда просто использует 0. Следовательно, dig
ошибка говоря ID mismatch: expected ID 60466, got 0
.
Я зарегистрировал проблему # 5574 против ESP-IDF, чтобы решить эту проблему.