Zeroconf-issues: Unterschied zwischen den Versionen
Lfittl (Diskussion | Beiträge) |
Lfittl (Diskussion | Beiträge) |
||
| (5 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| + | = Das Problem und die Lösung = | ||
| + | Aufgrund eines (wahrscheinlich) fehlerhaften mDNS Reflectors bei Avahi existierten teilweise doppelte mDNS Namen / Services. Das Problem wurde am 4.3.2007 von Clifford und Lukas gelöst indem man statt dem Reflector eine Ethernet Bridge nur für mDNS Pakete erstellt, alles andere wird weiterhin geroutet. Bis jetzt keine Probleme mehr. | ||
| + | |||
| + | = Archivierte Diskussion = | ||
== 1st Contact == | == 1st Contact == | ||
| Zeile 9: | Zeile 13: | ||
Grüsse, --[[Benutzer:MiKa|MiKa]] 17:36, 14. Feb. 2007 (CET) | Grüsse, --[[Benutzer:MiKa|MiKa]] 17:36, 14. Feb. 2007 (CET) | ||
| + | ---- | ||
== Findings == | == Findings == | ||
| Zeile 35: | Zeile 40: | ||
Grüsse, --[[Benutzer:MiKa|MiKa]] 19:21, 14. Feb. 2007 (CET) | Grüsse, --[[Benutzer:MiKa|MiKa]] 19:21, 14. Feb. 2007 (CET) | ||
| + | |||
| + | ---- | ||
Deswegen ist die jetztige Lösung eigentlich auch die einzig wirklich funktionierende befürchte ich (ausser man macht Bridging). Problem scheint zu sein das der Avahi Proxy / Reflector einen Cache hat und dieser dazu führt das er auch für Einträge antwortet die eigentlich nicht mehr existieren. Aber das ist alles nur Vermutung, müsste man noch etwas mehr debuggen (pcap files existieren, also theoretisch kann man das auch offline analysieren, bin selbst aber nicht schlau daraus geworden). | Deswegen ist die jetztige Lösung eigentlich auch die einzig wirklich funktionierende befürchte ich (ausser man macht Bridging). Problem scheint zu sein das der Avahi Proxy / Reflector einen Cache hat und dieser dazu führt das er auch für Einträge antwortet die eigentlich nicht mehr existieren. Aber das ist alles nur Vermutung, müsste man noch etwas mehr debuggen (pcap files existieren, also theoretisch kann man das auch offline analysieren, bin selbst aber nicht schlau daraus geworden). | ||
--[[Benutzer:Lfittl|Lfittl]] 20:12, 14. Feb. 2007 (CET) | --[[Benutzer:Lfittl|Lfittl]] 20:12, 14. Feb. 2007 (CET) | ||
| + | |||
| + | : Nach dem ich das Ticket von Antifuchs gelesen habe (siehe unten) kann ich mir vorstellen, was passiert... | ||
| + | : Sag mir, wann du Zeit für eine debug-session hast (vorausgesetzt das Problem ist gut reproduzierbar). | ||
| + | : Grüsse, --[[Benutzer:MiKa|MiKa]] 22:03, 14. Feb. 2007 (CET) | ||
| + | |||
| + | ---- | ||
| + | |||
| + | Ich hab' mir das schon einmal angesehen. Die Bemerkung dass die mdns-pakete nicht so ohne weiteres von einem Netz ins andere kommen, ist soweit richtig. Fuer das "nicth ohne weiteres" laeuft auf dem nacl ein [http://avahi.org/ avahi]-daemon (multicast-dns-klump), der als "reflector" konfiguriert ist. Heiszt, dass er die Pakete von einem Netz ins andere weiterschickt. Ich hab' mit den avahi-maintainern geplaudert (vor einem Monat etwa), und die wollten einen Bugreport: [http://avahi.org/ticket/107 Ticket "avahi-reflector seems to cause name conflicts"]. Einer von den developern (im channel #avahi auf freenode.net) hat das gleiche Problem bei einem aehnlichen Setup schon bei sich bemerkt. Wuerde sagen, weiteres Nachbohren in diese Richtung waer nicht verkehrt - besonders packet captures von den betroffenen Client-Rechnern waeren sicher hilfreich. | ||
| + | -- [[Benutzer:Antifuchs|Antifuchs]] 20:42, 14. Feb. 2007 (CET) | ||
| + | |||
| + | : Soweit ich die Dokumentation verstehe, ist avahi nicht geeignet für Applikationen wie I-Tunes. Wenn die sich tatsächlich strikt an die draft halten, dann haben sie tatsächlich probleme mit geräten nach wake-up etc... | ||
| + | : Der reflector kann nicht wissen, dass ein mDNS-Host in sleep gegangen ist denkt dass dieser Host noch verfügbar ist. Ausserdem steht auf der avahi Seite nicht, wie mit name-conflicts umgegangen ist. Wenn avahi (so wie ich vermute) selber einen name-postfix anhängt um conflicts zu lösen dann passiert genau das, wir im metalab beobachten. | ||
| + | : -> re-write avhai oder eigenes projekt wie unten beschrieben | ||
| + | : | ||
| + | : grüsse, --[[Benutzer:MiKa|MiKa]] 22:00, 14. Feb. 2007 (CET) | ||
| + | ---- | ||
| + | |||
| + | == Details aus [http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt draft-cheshire-dnsext-multicastdns.txt] == | ||
| + | |||
| + | Im Draft-Dokument steht explizit: | ||
| + | |||
| + | A host sending Multicast DNS queries to a link-local destination | ||
| + | address (including the 224.0.0.251 link-local multicast address) | ||
| + | MUST only accept responses to that query that originate from the | ||
| + | local link, and silently discard any other response packets. Without | ||
| + | this check, it could be possible for remote rogue hosts to send | ||
| + | spoof answer packets (perhaps unicast to the victim host) which the | ||
| + | receiving machine could misinterpret as having originated on the | ||
| + | local link. | ||
| + | |||
| + | D.h. dass mDNS prinzipiell nicht für Routing Umgebungen geeignet ist | ||
| + | |||
| + | |||
| + | == Wie wär's mit einem I-Tunes-Router Projekt? == | ||
| + | |||
| + | Ich helfe gerne mit Design und Projektmanagement für einen I-Tunes Router ;) nur coden kann ich nicht - total aus der Routine. | ||
| + | |||
| + | Mögliches Design: | ||
| + | |||
| + | # Router mit mehreren Interfaces, in jedem Segment eine Link-Local Adresse (bzw. über DHCP oder andere Mittel konfigurierte unique-IP-Address) | ||
| + | # Auf jedem Interface wird eine mDNS-Implementierung gefahren, die Namen lokal auflöst und verwaltet und daraus eine globale Namens-Liste aufbaut. | ||
| + | # Auf jedem Segment wird für jeden Host, der in einem anderen Segment zuhause ist, eine IP-Adresse reserviert (über 169.254.0.0/16 autoconfig, DHCP oder andere geeignete Mittel und gleichzeitig eine NAT-Address-Translation eingerichtet. | ||
| + | # Für jedes Segment werden für Hosts, die auf anderen Segmenten zuhause sind, Proxy mDNS Antworten generiert und eine mDNS-Conflict-Resolution nach [http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt draft-cheshire-dnsext-multicastdns.txt], 9.2 Simultaneous Probe Tie-Breaking, 9.2.1 Simultaneous Probe Tie-Breaking for Multiple Records und 10. Conflict Resolution durchgeführt. | ||
| + | # Registrierte Hosts für mDNS werden zyklisch mit mDNS-Requests gepollt um zu sehen, ob sie noch on-line sind, falls nicht, wird der mDNS-Eintrag und die dazugehörige Adresse sowie die Address-Translation und IP-Address (sofern sie dynamisch konfiguriert wurde) freigegeben. | ||
| + | # Der Rest ist simples NAT | ||
| + | |||
| + | Grüsse, --[[Benutzer:MiKa|MiKa]] 20:30, 14. Feb. 2007 (CET) | ||
[[Kategorie:Netzwerk]] | [[Kategorie:Netzwerk]] | ||
Aktuelle Version vom 5. März 2007, 00:02 Uhr
Das Problem und die Lösung
Aufgrund eines (wahrscheinlich) fehlerhaften mDNS Reflectors bei Avahi existierten teilweise doppelte mDNS Namen / Services. Das Problem wurde am 4.3.2007 von Clifford und Lukas gelöst indem man statt dem Reflector eine Ethernet Bridge nur für mDNS Pakete erstellt, alles andere wird weiterhin geroutet. Bis jetzt keine Probleme mehr.
Archivierte Diskussion
1st Contact
Habe gestern Abend mit Phillip geplaudert, Probleme mit mDNS (Multicast DNSk, Apple Zeroconf)
Durch die Trennung in 3 logische Segmente werden die Apple DNS-requests für die TLD .local nicht an alle IP-Netze weitergeleitet. Ich habe kurz recherchiert und bin schnell auf die Seite www.zeroconf.org gestossen, die vom Zeroconf-Erfinder Stuart Cheshire betrieben wird.
Die Lösung könnte trivial werden, wenn mir ein Linux-IP-Guru im IP-Stack/Routing rumstierln hilft
Grüsse, --MiKa 17:36, 14. Feb. 2007 (CET)
Findings
Im document (draft-cheshire-dnsext-multicastdns.txt) zu mDNS habe ich folgendes gefunden:
3. Multicast DNS Names This document proposes that the DNS top-level domain ".local." be designated a special domain with special semantics, namely that any fully-qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix, which are link-local and meaningful only on the link where they originate. Any DNS query for a name ending with ".local." MUST be sent to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB).
Das bedeutet, dass wir einer gerouteten Umgebung verloren haben, außer wenn wir auf eine Bridging-Umgebumg migrieren. Nur die m-cast-packete mit 224.0.0.251 an die anderen Segmente weiterzureichen könnte zu Ambiguitäten führen, da nicht sichergestellt ist, 1) dass eine 169.254.0.0/16 Adresse nicht schon im anderen Segment vergeben ist und 2) dass die Zieladresse auch ins andere Segment geroutet wird, da der Router keine Route dafür aufbauen kann.
Eine mögliche Lösung wäre, wenn wir selektiv nur IPv4 Link-Local Addressing transparent bridgen, um zu erreichen, dass 169.254.0.0/16 Adressen nicht mehrfach vergeben werden und sich die Geräte direkt ohne Routing sehen können.
Die letzte Lösung die mir einfällt, wäre das Netz umzugestalten und die Segmente, die Bonjour mit IPv4LL und mDNS benötigen zu bridgen und mit Routing vom restlichen abzutrennen.
Grüsse, --MiKa 19:21, 14. Feb. 2007 (CET)
Deswegen ist die jetztige Lösung eigentlich auch die einzig wirklich funktionierende befürchte ich (ausser man macht Bridging). Problem scheint zu sein das der Avahi Proxy / Reflector einen Cache hat und dieser dazu führt das er auch für Einträge antwortet die eigentlich nicht mehr existieren. Aber das ist alles nur Vermutung, müsste man noch etwas mehr debuggen (pcap files existieren, also theoretisch kann man das auch offline analysieren, bin selbst aber nicht schlau daraus geworden).
--Lfittl 20:12, 14. Feb. 2007 (CET)
- Nach dem ich das Ticket von Antifuchs gelesen habe (siehe unten) kann ich mir vorstellen, was passiert...
- Sag mir, wann du Zeit für eine debug-session hast (vorausgesetzt das Problem ist gut reproduzierbar).
- Grüsse, --MiKa 22:03, 14. Feb. 2007 (CET)
Ich hab' mir das schon einmal angesehen. Die Bemerkung dass die mdns-pakete nicht so ohne weiteres von einem Netz ins andere kommen, ist soweit richtig. Fuer das "nicth ohne weiteres" laeuft auf dem nacl ein avahi-daemon (multicast-dns-klump), der als "reflector" konfiguriert ist. Heiszt, dass er die Pakete von einem Netz ins andere weiterschickt. Ich hab' mit den avahi-maintainern geplaudert (vor einem Monat etwa), und die wollten einen Bugreport: Ticket "avahi-reflector seems to cause name conflicts". Einer von den developern (im channel #avahi auf freenode.net) hat das gleiche Problem bei einem aehnlichen Setup schon bei sich bemerkt. Wuerde sagen, weiteres Nachbohren in diese Richtung waer nicht verkehrt - besonders packet captures von den betroffenen Client-Rechnern waeren sicher hilfreich. -- Antifuchs 20:42, 14. Feb. 2007 (CET)
- Soweit ich die Dokumentation verstehe, ist avahi nicht geeignet für Applikationen wie I-Tunes. Wenn die sich tatsächlich strikt an die draft halten, dann haben sie tatsächlich probleme mit geräten nach wake-up etc...
- Der reflector kann nicht wissen, dass ein mDNS-Host in sleep gegangen ist denkt dass dieser Host noch verfügbar ist. Ausserdem steht auf der avahi Seite nicht, wie mit name-conflicts umgegangen ist. Wenn avahi (so wie ich vermute) selber einen name-postfix anhängt um conflicts zu lösen dann passiert genau das, wir im metalab beobachten.
- -> re-write avhai oder eigenes projekt wie unten beschrieben
- grüsse, --MiKa 22:00, 14. Feb. 2007 (CET)
Details aus draft-cheshire-dnsext-multicastdns.txt
Im Draft-Dokument steht explizit:
A host sending Multicast DNS queries to a link-local destination address (including the 224.0.0.251 link-local multicast address) MUST only accept responses to that query that originate from the local link, and silently discard any other response packets. Without this check, it could be possible for remote rogue hosts to send spoof answer packets (perhaps unicast to the victim host) which the receiving machine could misinterpret as having originated on the local link.
D.h. dass mDNS prinzipiell nicht für Routing Umgebungen geeignet ist
Wie wär's mit einem I-Tunes-Router Projekt?
Ich helfe gerne mit Design und Projektmanagement für einen I-Tunes Router ;) nur coden kann ich nicht - total aus der Routine.
Mögliches Design:
- Router mit mehreren Interfaces, in jedem Segment eine Link-Local Adresse (bzw. über DHCP oder andere Mittel konfigurierte unique-IP-Address)
- Auf jedem Interface wird eine mDNS-Implementierung gefahren, die Namen lokal auflöst und verwaltet und daraus eine globale Namens-Liste aufbaut.
- Auf jedem Segment wird für jeden Host, der in einem anderen Segment zuhause ist, eine IP-Adresse reserviert (über 169.254.0.0/16 autoconfig, DHCP oder andere geeignete Mittel und gleichzeitig eine NAT-Address-Translation eingerichtet.
- Für jedes Segment werden für Hosts, die auf anderen Segmenten zuhause sind, Proxy mDNS Antworten generiert und eine mDNS-Conflict-Resolution nach draft-cheshire-dnsext-multicastdns.txt, 9.2 Simultaneous Probe Tie-Breaking, 9.2.1 Simultaneous Probe Tie-Breaking for Multiple Records und 10. Conflict Resolution durchgeführt.
- Registrierte Hosts für mDNS werden zyklisch mit mDNS-Requests gepollt um zu sehen, ob sie noch on-line sind, falls nicht, wird der mDNS-Eintrag und die dazugehörige Adresse sowie die Address-Translation und IP-Address (sofern sie dynamisch konfiguriert wurde) freigegeben.
- Der Rest ist simples NAT
Grüsse, --MiKa 20:30, 14. Feb. 2007 (CET)
