Sử dụng Avahi trên DreamPlug Ubuntu với iPad

Tôi có một vấn đề rất đặc biệt sau đây khi sử dụng Avahi trên DreamPlug (đây là một máy tính cắm chạy Ubuntu Jaunty).

Sau nhiều ngày dành cho việc này, tôi nghĩ tôi đã thu hẹp được vấn đề.

DreamPlug hoạt động như điểm truy cập WiFi và có tên máy chủ plugvà địa chỉ IP 192.168.1.1(được đặt ở cả hai /etc/hostsvà /etc/hostname) và chạy lighttpd.

Bây giờ máy Mac của tôi hoạt động ngay lập tức với việc truy cập http://plug.localtrong Chrome, tuy nhiên nếu tôi thử và tải http://plug.localtrên iPad, nó không hoạt động. Đó là, nó không hoạt động cho đến khi tôi tải trang trên máy tính để bàn.

Vì một số lý do, iPad không bao giờ có thể phân giải tên máy chủ, cho đến khi tên máy chủ được phân giải lần đầu trên Mac ... thật kỳ lạ vì không có kết nối nào giữa iPad và Mac ngoài thực tế là chúng được kết nối với cùng một điểm truy cập (DreamPlug).

Vì vậy, chỉ cần làm rõ một lần nữa: Safari trên iPad sẽ bị treo (cho đến khi báo cáo rằng trình duyệt không thành công) khi truy cập http://plug.localtrừ khi tôi truy cập http://plug.localtrên Mac, chạy ping plug.local, làm ssh root@plug.localhoặc về cơ bản làm bất cứ điều gì khác giải quyết tên máy chủ, lúc đó iPad sẽ giải quyết ngay lập tức tên máy chủ và nó bắt đầu hoạt động đúng.

Nếu sự hiểu biết của tôi là chính xác, khi iPad kết nối, họ sẽ phát một yêu cầu giải quyết plug.local. Vì bất kỳ lý do gì, yêu cầu này bị DreamPlug bỏ qua (hoặc nó không bao giờ được nhận). Tuy nhiên, Mac không quản lý để phát yêu cầu của mình. Nó phát một yêu cầu giải quyết và các brodug DreamPlug quay lại kết quả plug.local-> 192.168.1.1. Các iPad sau đó nhận được kết quả này (điều thực sự đã được định sẵn cho Mac) và sau đó có thể giải quyết thành công.

Tôi rất vui lòng cung cấp avahi-daemon.confcác tệp cấu hình của tôi hoặc các yêu cầu khác theo yêu cầu.

Cập nhật: Bây giờ tôi đã quản lý để sử dụng Wireshark và thấy rằng iPad thực sự đã phát một yêu cầu lên mạng.

Tôi đã bắt được cả một gói mà DID dẫn đến phản hồi từ Avahi, cũng như một gói KHÔNG.

Cả hai đều xuất hiện hoàn toàn giống nhau, điểm khác biệt duy nhất là lỗi không xác định loại RR bổ sung OPT... Tôi không biết OPTbản ghi là gì. Có thể là Avahi không thích các truy vấn DNS có OPTRR được đính kèm vì một số lý do?

Đây là hai ảnh chụp màn hình được chụp từ Wireshark. Cái đầu tiên hiển thị một yêu cầu mDNS "tốt" được gửi từ máy tính để bàn (trong trường hợp này, thiết bị được gọi runway.local). Truy vấn này hoạt động tốt và máy chủ (at 192.168.1.1) trả lời ngay:

Đây là một ví dụ về phản hồi được trả về từ runway.local:

Trong khi đó, đây là một truy vấn DNS thứ hai đã được gửi từ iPad cho cùng tên máy chủ , runway.local. Trong trường hợp này, yêu cầu dường như bị bỏ qua đơn giản (trong mọi trường hợp, không nhận được phản hồi nào cho truy vấn DNS này):

Cố gắng theo dõi những gì trong yêu cầu iPad gây ra sự cố, có vẻ như hai gói gần giống nhau, sự khác biệt duy nhất giữa các truy vấn mDNS được gửi từ máy tính để bàn (chạy OS X) và iPad, đó là iPad nối thêm một OPTbản ghi tài nguyên ở dưới cùng của yêu cầu DNS.

Câu hỏi đặt ra là: tầm quan trọng của bản ghi tài nguyên - và nó là gì - hay nó là cái gì khác - chịu trách nhiệm cho yêu cầu DNS này bị Avahi bỏ qua.

CẬP NHẬT Đây có thể là bước đột phá mà tôi đang tìm kiếm:

Tôi đã chạy avahi-daemon với cờ --debug và tôi nhận thấy rất nhiều "Gói truy vấn không hợp lệ". tin nhắn. Điều này dẫn tôi đến trang này: http://avahi.org/ticket/284 mà dường như đây là một vấn đề đã biết (mặc dù một vấn đề cần được giải quyết).

Đặc biệt:

Một tcpdump khiến tôi tin rằng điều này là do Mac OS 10.6 sử dụng RFC2671 để thêm thông tin trong phần dữ liệu bổ sung của các truy vấn DNS. Cụ thể, nó đang cung cấp 'kích thước tải trọng UDP' (trong trường hợp của tôi, 1440) làm gợi ý cho kích thước tối đa của các gói phản hồi. [...] Avahi xem xét các truy vấn với các phần dữ liệu bổ sung không trống không hợp lệ, trong đó nó kiểm tra AVAHI_DNS_FIELD_ARCOUNT! = 0 ngay trước khi tạo thông báo gói truy vấn không hợp lệ.

Tôi không thường xuyên sử dụng SF thường xuyên, nhưng tôi có thể thấy rằng câu hỏi này đã thu hút được sự chú ý khá lớn, vì vậy hãy để tôi tóm tắt những phát hiện của tôi ở đây, và hy vọng cung cấp một giải pháp cho những người gặp phải vấn đề tương tự: -

Có vẻ như đây là một lỗi với phiên bản Avahi đi kèm với Ubuntu Jaunty ( http://avahi.org/ticket/284 ) liên quan đến việc cung cấp kích thước tải trọng UDP, có thể là kết quả của sự thay đổi sâu hơn đối với thông số mDNS (mặc dù tôi không tự đọc nó). Như tôi đã giải thích trong các bình luận cho câu hỏi ban đầu, tôi đã cố gắng nâng cấp phiên bản Avahi của mình, nhưng các kỹ năng Linux của tôi không phải là những gì chúng nên và tôi đã không quản lý để nó hoạt động. (Dù bằng cách nào, việc chạy HĐH không được hỗ trợ 3 năm thực sự không được khuyến khích ...)

Cuối cùng, tôi đã lao vào, xóa thẻ SD của DreamPlug và cài đặt Debian Squeeze trên nó, nó hoạt động tốt (mặc dù chỉ với iOS 5.0+). Một cuộc thảo luận về cách thay đổi hệ điều hành DreamPlug nằm ngoài phạm vi của câu hỏi này, nhưng tất cả những gì nó rút ra vào cuối ngày là một phiên bản lỗi thời của Avahi. Sử dụng một phiên bản mới hơn và bạn sẽ ổn thôi!

Chúc may mắn!