# 12 Fehler in der AVM UPnP IGD- und PCP-Implementierung (alle FritzBoxen), DNS, Dokumentation Erstmals gemeldet: 2023-04-27 ## UPnP IGD und PCP Fehler ### 1. UPnP: Freigabe des gleichen Ports über IPv6 von mehreren Clients funktioniert nicht (Fehler: 718 ConflictInMappingEntry) WICHTIG! Erstmals gemeldet am: 2023-04-27 (an Entwicklersupport). Status: Fehler existiert noch mit Fritz!OS 7.57 Wurde in Fritz!OS Labor 7.51-105682M vorübergehend behoben (durch Version des Entwicklersupports), tritt aber in neueren Versionen wieder auf ### 2. PCP: Erneuern eines Mappings funktioniert alternierend nicht bei mehreren gleichzeitigen clients WICHTIG! Erstmals gemeldet am: 2023-06-21 (an Support). Status: Fehler existiert noch mit Fritz!OS 7.57 Nur das Anlegen eines neuen Port Mappings funktioniert über PCP, nicht aber das Erneuern eines bestehenden Port Mappings. Siehe Spezifikation des Port Control Protocol (PCP) Abschnitt 11.2.1. (Renewing a Mapping) ### 3. UPnP/PCP: IPv6 Portfreigaben funktionieren nicht wenn die IPv6 Interface-ID nicht mit der im Webinterface übereinstimmt WICHTIG! Erstmals gemeldet am: 2023-08-03 (an Support). Status: Fehler existiert noch mit Fritz!OS 7.57 Benutzer, die aus Sicherheitsgründen temporäre IPv6-Adressen (RFC4941) verwenden oder eine Wieder-Identifizierung bei einem IPv6-Präfixwechsel (RFC7217) vermeiden wollen, müssen den IPv6 Interface-ID jedes Mal erneut, manuell im Webinterface eingegeben damit IPv6 Portfreigaben funktionieren Fritz!OS sollte es einem autorisierten Client erlauben, eine beliebige IPv6-Adresse für die selbstständige Portfreigabe zu vewenden. Idealerweise sollte Fritz!OS den Client anhand der erkannten MAC-Adresse autorisieren IPv6 Privacy Extensions (temporary addresses): IPv6 Stable Privacy: ### 4. UPnP/PCP: Längere LeaseDuration als 120 Sekunden nicht erlaubt, siehe IGD-Spezifikation WICHTIG! Erstmals gemeldet am: 2023-08-03 (an Support). Status: Fehler existiert noch mit Fritz!OS 7.57 Siehe 2.5.16.2 Service Requirements (S. 51): * NewPortMappingLeaseDuration value can be between 1 second and 604800 seconds, however value “0” can exist for port mappings made out of band * Infinite mappings cannot be made in WANIPConnection:2 and value “0” MUST be interpreted as 604800 seconds (7 d) * It is RECOMMENDED that a lease time of 3600 seconds would be used as a default value http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf Für PCP ist das Maximum laut Spezifikation 86400s (24 h) ### 5. PCP: Portfreigabe über IPv4 plus IPv6 funktioniert, wird aber im Webinterface nur einmal (als IPv6) angezeigt Erstmals gemeldet am: 2023-05-22 (an Entwicklersupport). Status: Fehler existiert noch mit Fritz!OS 7.57 Nach neueren Erkenntnissen funktionieren die Mappings, werden aber nur einmal im Webinterface angezeigt. Mit UPnP IGD funktioniert es. ### 6. Fritz!Box wird im Windows Explorer 5 mal unter Netzwerk aufgelistet, bei anderen Routern reicht 1x Erstmals gemeldet am: 2023-08-03 (an Support). Status: Fehler existiert noch mit Fritz!OS 7.57 Evtl. lässt sich das Problem einfach lösen, indem bei den nicht "direkt" nutzbaren UPnP-Diensten kein presentationURL-Element in der XML-Description angegeben wird, dann sollte Windows auf die Anzeige des Icons verzichten. Nur in der IGDv1-Description (igddesc.xml) sollte die presentationURL vorhanden sein, nicht jedoch in allen anderen XML-Descriptions (igd2desc.xml/avmnexusdesc.xml/fboxdesc.xml...). ### 7. UPnP: Discovery nicht konform zur UPnP-Spezifikation, GetListOfPortMappings ... von IGDv2 ist bei M-SEARCH nach IGDv1 nicht zur verfügbar / Vorschlag für besseren Microsoft-IGD-Client-Workaround Erstmals gemeldet am: 2023-06-06 (an Support). Status: Fehler existiert noch mit Fritz!OS 7.57 Betrifft die IGDv2 Funktionen: GetListOfPortMappings, AddAnyPortMapping, DeletePortMappingRange Die IGDv2 Pinhole-Funktionen AddPinhole ... (aus WANIPv6FirewallControl:1) sind jedoch verfügbar. Die Fritz!Box antwortet nach einem M-SEARCH nach IGDv1 mit einer IGDv1-only XML description URL, bei einem M-SEARCH nach IGDv2 jedoch mit einer (zweiten) IGDv2 XML description (dies wurde warscheindlich so implementiert wegen einer bekannten Microsoft-Client-Inkompatibilität, sie weiter unten). Da jedoch UPnP IGDv2 clients (aus Kompatiblitätsgründen und der Geschwindigkeit, zweiter M-SEARCH kostet Zeit) nach IGDv1 suchen stehen die obengenannten IGDv2-Funktionen den IGDv2 clients nicht zur Verfügung. Zu beachten ist jedoch dass ein konformer Router, nach einem Discovery (egal ob M-SEARCH nach IGDv1, IGDv2 oder upnp:rootdevice), beim HTTP-Request immer die neuste vom IGD Router unterstützt IGD-Version in der Root-XML-Description zurückliefern MUSS, bei AVM daher IGDv2. Bekannte Kompatililitätsprobleme mit dem IGDv1 client von Microsoft (in Windows XP-11/Xbox integriert): Der in Windows und der Xbox integrierte IGDv1 client hält sich nicht an die UPnP-Spezifikation, er funktioniert nach der HTTP-Antwort mit dem Inhalt einer XML root description mit IGDv2 nicht, daher hat das MiniUPnP-Projekt einen cleveren Workaround gefunden, welcher fehlerhafte (Microsoft) clients über eine HTTP-User-Agent-Weiche (nicht eine nach der M-SEARCH Version) in der HTTP-Reply eine IGDv1 XML root description zurückliefert. Dieser Workaround sollte besser als der von AVM's funktionieren (mit zwei verschiedenen XML root descriptions je nach M-SEARCH), da er gezielten ist und anderen IGDv2 clients die sich korrekt verhalten und nach IGDv1 suchen auch IGDv2-Funktionieren ermöglichen. Wie wäre es diesen Workaround bei der Fritz!Box zu implementieren? Siehe MiniUPnPd's Microsoft-Workaround: https://github.com/miniupnp/miniupnp/commit/8381867faf82f3d779f797e59582b3c76a827ecd#diff-b983244182bf2822af67e3a52d008d6c5848b40e5ba8ebea43821a820c94d6f4R315 ### 8. UPnP: GetListOfPortMappings (IGDv2) liefert immer nur eine leere Liste zurück Erstmals gemeldet am: 2023-04-27 (an Entwicklersupport). Status: Fehler existiert noch mit Fritz!OS 7.57 GetListOfPortMappings wird jedoch nach der Entwickler-Dokumentation unterstützt HTTP-Request von Client: ``` POST /igd2upnp/control/WANIPConn1 HTTP/1.1 Host: 192.168.178.1:49000 User-Agent: Linux/6.4.7 UPnP/1.1 MiniUPnPc/2.2.5 Content-Length: 459 Content-Type: text/xml; charset="utf-8" SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:2#GetListOfPortMappings" Connection: close Cache-Control: no-cache Pragma: no-cache 1 65535 UDP 1 1000 ``` HTTP-Reply von Fritz!Box: ``` HTTP/1.1 200 OK Connection: close Content-Length: 695 Content-Type: text/xml; charset="utf-8" Date: Fri, 11 Aug 2023 14:13:05 GMT Server: FRITZ!Box 4040 UPnP/1.0 AVM FRITZ!Box 4040 155.07.57 Ext: ``` Fehler: - Leere Liste (p:PortMappingList) - Zweimalige XML-Deklaration " Online-Monitor: Weitere Verbindungen: Portfreigabe Beim Online-Monitor: "2 über UPnP geöffnete Ports" Vorschläge zum Ersetzen beim Online-Monitor (finde es gut hier "PCP/UPnP" zu erwähnen): * "2 selbstständige Portfreigaben (PCP/UPnP)" * "2 über selbständige Portfreigaben (PCP/UPnP) geöffnete Ports" * "2 selbstständige Portfreigaben, über PCP/UPnP geöffnete Ports" * "2 über PCP/UPnP geöffnete Ports (selbständige Portfreigaben)" Zum Vergleich steht auf der Übersichtsseite: "2 selbstständige Portfreigaben" ### 11. Wissensdatenbank: korrigierte Links zu UPnP IGD und PCP Erstmals gemeldet am: 2023-06-08 (an Entwicklersupport). Status: Fehler besteht noch in der Wissensdatenbank de-Link: * "Port Control Protocol" falsch zum englischer Artikel verlinkt, korrekter Link: en-Link: * Gibt zu UPnP einen genauer passenden Artikel (UPnP IGD): * Port Control Protocol falsch zu UPnP IGD verlinkt, korrekter Link: * Würde den Text auf "UPnP IGD (Universal Plug and Play Internet Gateway Device)" und "PCP (Port Control Protocol)" ändern analog zur deutschen Seite "The application must support UPnP IGD (Universal Plug and Play Internet Gateway Device) or PCP (Port Control Protocol) protocol" Wobei der Text in der Klammer wie beim deutschen knowledge-base Artikel dem anklickbare Link-Text entspricht. Hinweis zum RFC entfernt da in Wikipedia-Artikel erwähnt. ### 12. Entwickler-Dokumentation: korrigierte Links zu den UPnP-Spezifikationen Erstmals gemeldet am: 2023-04-27 (an Entwicklersupport). Status: Fehler besteht noch in der Dokumentation Links: 1. Funktionierende Links zu UPnP-Spezifikationen: Korrigierter Link und Text (fix: "UpnP"): "Based on the Internet Gateway Device (IGD) V1.0 and Internet Gateway Device (IGD) V2.0 specification proposed by UPnP™ Forum at https://openconnectivity.org/developer/specifications/upnp-resources/upnp/internet-gateway-device-igd-v-2-0/ 2. Auf IGD2.pdf: "WANIPConnection:2" falsch zur v1-Variante verlinkt 3. Warum fast zwei gleiche Dokumente, ev. nur ein Dokument mit dem Hinweis versehen "only IGDv2" bei den IGDv2-Funktionen: - WANIPConnection:1/2: GetListOfPortMappings, AddAnyPortMapping, DeletePortMappingRange - WANIPv6FirewallControl:1 ganzer Dienst mit allen Funktionen 4. Warum sind IGDv1-Funktionen in IGDv2 aufgeführt und umgekehrt: - WANIPConnection:1 ist in IGD2.pdf aufgeführt, WANIPConnection:2 gehört doch zu IGDv2? - WANIPv6FirewallControl:1 ist in IGD1.pdf aufgeführt gehört doch zu IGDv2? ## Weitere Fehler und Verbesserungsvorschläge ### 1. DNS: Störungserkennung wechselt sehr langsam (ca. 4 h) zurück zum eingestellten DNS-Server WICHTIG! Erstmals gemeldet am: 2023-11-18 (an Labor-Feedback). Status: Fehler existiert noch mit Fritz!OS 7.70-109165 BETA Dieses spähte zurück wechseln zum eingestellten DNS-Server leakt die DNS-Anfrage an die von euch eingetragenen öffentliche DNS-Server für unnötig lange Zeit (ca. 4 Stunden) auch bei nur einem kurzen Ausfall des eigestellten Servers. Ereignisse aus Fritz!OS: 18.11.23 08:22:25 DNS-Störung beendet, Namensauflösung über öffentliche DNS-Server beendet. ... 18.11.23 04:18:11 DNS-Störung erkannt, Namensauflösung erfolgt ab sofort über öffentliche DNS-Server. Im Gegensatz: Die Umschaltung auf den öffentliche DNS-Server (nach einem Ausfall) erfolgt nach rund 20 Sekunden, also schnell. ### 2. DNS: Queries nach A/AAAA records die auf lokales Netzwerk/Subnet verweisen werde nicht aufgelöst Erstmals gemeldet am: 2023-11-20 (an Labor-Feedback). Status: Fehler existiert noch mit Fritz!OS 7.70-109165 BETA Mit dem Vorkunfigurierte default IPv4-Subnet werde alle Queries nach A mit Antworten im 192.168.178.*-Range nicht aufgelöst, dasselbe gilt für Queries nach AAAA mit Antworten aus dem aktuell zugewisenen IPv6-Prefix und fd80:: Damit auch das hosten eines lokalen DNS-Servers mit DDR-update funktioniert müssen solche Anfragen funktionierten. Es gibt zwar eine Einstellung (DNS-Rebind-Schutz) wo selektiv dies ausgeschaltet werden kann jedoch nicht global für alle domains. Ich bitte Sie das das für Home-Netzwerke offiziell reservierter suffix ".internal" oder ".home.arpa" dort stadardmässig bereits eingetragen ist. https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024 https://datatracker.ietf.org/doc/html/rfc8375.html