iPad와 함께 DreamPlug Ubuntu에서 Avahi 사용

DreamPlug (Ubuntu Jaunty를 실행하는 플러그 컴퓨터)에서 Avahi를 사용할 때 다음과 같은 매우 독특한 문제가 있습니다.

이것에 며칠을 보낸 후에, 나는 문제를 좁히는 데 성공 했다고 생각 합니다.

DreamPlug은 WiFi 액세스 포인트로서 동작하고 호스트 보유 plug및 IP 주소 192.168.1.1(모두 설정 /etc/hosts하고 /etc/hostname)과 실행이 lighttpd를한다.

이제 내 Mac은 http://plug.localChrome에서 바로 액세스 할 수 있지만 http://plug.localiPad에서 로드하려고하면 작동하지 않습니다. 즉 , 바탕 화면에 페이지를로드 할 때까지 작동하지 않습니다 .

어떤 이유로 든 Mac에서 호스트 이름을 처음 확인할 때까지 iPad가 호스트 이름을 확인할 수 없습니다. iPad와 Mac이 연결되어 있다는 사실 외에는 iPad와 Mac이 연결되어 있지 않기 때문에 이상합니다. 동일한 액세스 포인트 (DreamPlug).

(실패한 열람을보고 할 때까지)에 액세스 할 때 아이 패드 사파리가 중단됩니다 : 그래서 그냥 다시 명확히 http://plug.localI 액세스하지 않는 http://plug.local맥에서 실행 ping plug.local수행 ssh root@plug.local또는 기본적으로 할 것을 결의가 아이 패드를 지적하는 호스트 이름이, 즉시 해결하는 것이 다른 사람을 호스트 이름과 제대로 작동하기 시작합니다.

이해가 올 바르면 iPad가 연결될 때에 대한 해결 요청을 브로드 캐스트합니다 plug.local. 어떤 이유로 든이 요청은 DreamPlug에 의해 무시됩니다 (또는 수신되지 않음). 그러나 Mac 은 요청을 브로드 캐스트합니다. 그것은 확인 요청을 브로드 캐스트하고 DreamPlug의 brodcasts이 결과를 다시 plug.local-> 192.168.1.1. 그런 다음 iPad는 이 결과 (실제로 Mac 용)를 받고 성공적으로 해결할 수 있습니다.

avahi-daemon.conf요청에 따라 내 또는 다른 구성 파일을 제공해 드리겠습니다.

업데이트 : 이제 Wireshark를 사용했으며 iPad가 실제로 네트워크에 요청을 브로드 캐스트한다는 것을 알았습니다.

나는 DID가 Avahi의 응답을 가져 오는 패킷과 그렇지 않은 패킷을 모두 캡처했습니다.

둘 다 완전히 동일하게 보이지만 유일한 차이점은 실패한 것이 유형의 추가 RR을 지정했다는 것입니다 OPT... 나는 OPT레코드가 무엇인지 전혀 모른다 . Avahi가 OPT어떤 이유로 RR이 연결된 DNS 쿼리를 좋아하지 않을 수 있습니까?

다음은 Wireshark에서 가져온 두 개의 스크린 샷입니다. 첫 번째는 "양호한"mDNS 요청을 보여줍니다.이 요청은 데스크탑 컴퓨터에서 전송됩니다 (이 경우 장치를이라고 함 runway.local). 이 쿼리는 정상적으로 작동하고 서버 (at 192.168.1.1)는 즉시 응답합니다.

다음에서 반환되는 응답의 예는 다음과 같습니다 runway.local.

한편, 다음은 동일한 호스트 이름으로 iPad에서 보낸 두 번째 DNS 쿼리입니다 runway.local. 이 경우 요청은 단순히 무시되는 것 같습니다 (어쨌든이 DNS 쿼리에 대한 응답이 수신되지 않습니다).

문제를 일으킨 iPad 요청의 내용을 추적하려고하면 두 패킷이 거의 동일하게 보이며 데스크탑 (OS X 실행)과 iPad에서 보낸 mDNS 쿼리의 유일한 차이점은 iPad가 추가한다는 것입니다. OPTDNS 요청의 맨 아래에 있는 리소스 레코드

문제는 리소스 레코드의 중요성이 무엇이며, Avahi가이 DNS 요청을 무시하도록하는 것은이 것 또는 다른 것입니다.

업데이트 이것은 내가 찾은 획기적인 것일 수 있습니다.

--debug 플래그와 함께 avahi-daemon을 실행하고 있으며 "잘못된 쿼리 패킷"이 많이 나타났습니다. 메시지. 이것은 나를이 페이지로 인도했습니다 : http://avahi.org/ticket/284 이것은 알려진 문제 (해결되어야 할 문제임) 인 것 같습니다.

구체적으로 특별히:

tcpdump는 이것이 RFC2671을 사용하여 DNS 쿼리의 추가 데이터 섹션에 정보를 추가하는 Mac OS 10.6 때문이라고 생각합니다. 특히 응답 패킷의 최대 크기에 대한 힌트로 'UDP 페이로드 크기'(내 경우에는 1440)를 제공합니다. [...] Avahi는 비어 있지 않은 추가 데이터 섹션이있는 쿼리를 유효하지 않은 것으로 간주합니다. 여기서 유효하지 않은 쿼리 패킷 메시지를 생성하기 직전에 AVAHI_DNS_FIELD_ARCOUNT! = 0인지 확인합니다.

SF를 자주 사용하지는 않지만이 질문에 상당한 관심을 끌고 있음을 알 수 있으므로 여기에 내 조사 결과를 요약하고 동일한 문제가 발생하는 사람들에게 해결책을 제공하기를 바랍니다.

이것은 Ubuntu Jaunty ( http://avahi.org/ticket/284 )와 함께 제공되는 Avahi 버전의 버그로 UDP 페이로드 크기 공급과 관련이 있습니다. mDNS 사양 (내가 직접 읽지는 않았지만). 원래 질문에 대한 의견에서 설명했듯이 Avahi 버전을 업그레이드하려고 시도했지만 Linux 기술이 제대로 작동하지 않아 작동하지 못했습니다. (어쨌든 3 살짜리 지원되지 않는 OS를 실행하는 것은 실제로 권장되지 않습니다 ...)

결국, 나는 급락하여 DreamPlug의 SD 카드를 닦고 데비안 스퀴즈를 설치했는데 잘 작동했습니다 (iOS 5.0 이상에서만 가능). DreamPlug OS를 변경하는 방법에 대한 논의는이 질문의 범위를 벗어 났지만, 하루가 끝날 무렵에 나온 것은 Avahi의 구버전입니다. 최신 버전을 사용하면 괜찮을 것입니다!

행운을 빕니다!