[Gelöst] TR-064 AddPortMapping FRITZ.Box 7490 113.07.01

[sky321]

Hallo,

ich probiere seid einiger Zeit über die TR-064 Schnittstelle einen Port auf meiner Box freizugeben.

Als Client benutze ich einen debian stretch linux server mit SOAP Zugriff über curl aus einem bash script.

----------------------------mein code schnipsel------------------------
location="/upnp/control/wanpppconn1"
uri="urn:dslforum-org:service:WANPPPConnection:1"
action='AddPortMapping'

SoapParamString="<NewRemoteHost>0.0.0.0</NewRemoteHost>
<NewExternalPort>80</NewExternalPort>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>80</NewInternalPort>
<NewInternalClient>192.168.0.213</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription>HTTP-Server</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>"

curl -k -m 5 --anyauth -u "$FRITZUSER:$FRITZPW" https://$IP:49443$location -H 'Content-Type: text/xml; charset="utf-8"' -H "SoapAction:$uri#$action" -d "<?xml version='1.0' encoding='utf-8'?><s:Envelope s:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'><s:Body><u:$action xmlns:u='$uri'>$SoapParamString</u:$action></s:Body></s:Envelope>" -s
----------------------------------------------------------------------------------------------------

Leider bekomme ich in allen erdenklichen Variationen der Konfiguration meiner Box immer folgenden Fehler.

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:dslforum-org:control-1-0">
<errorCode>600</errorCode>
<errorDescription>Argument Value Invalid</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

Wenn ich genau diese Freigabe abfrage, funktioniert alles und ich bekomme auch genau diese Werte zurück.

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetSpecificPortMappingEntryResponse xmlns:u="urn:dslforum-org:service:WANPPPConnection:1">
<NewInternalPort>80</NewInternalPort>
<NewInternalClient>192.168.0.213</NewInternalClient>
<NewEnabled>0</NewEnabled>
<NewPortMappingDescription>HTTP-Server</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
</u:GetSpecificPortMappingEntryResponse>
</s:Body>
</s:Envelope>

Ich habe schon den Haken für "Selbstständige Portfreigaben für dieses Gerät erlauben." gesetzt.
Versucht bestehende Freigaben zu enablen oder Neue hinzuzufügen.
Die Zwei Faktor Authentifizierung abgestellt.
Danach jeweils die Box durchgestartet.

Das Script läuft auf dem Rechner welcher auch das Ziel der Freigabe ist und im selben Subnetz.

Würde riesig freuen, wenn ihr mal schauen könntet ob es bei euch funktioniert oder mir einen Hinweis geben könntet was ich falsch mache.

Beste Grüße
Sky

 

[PeterPawn]

Ich würde es mal mit einer Lease-Time versuchen ... meines Wissens steht die "0" für eine (permanente) Freigabe, die nicht über TR-064 eingerichtet wurde und "ewig" gültig ist.

Das geht (afaik bzw. soweit ich das getestet hatte) aber nicht mit dem "AddPortMapping()"-Aufruf - hier muß man die Freigabe mit Timeout einrichten (z.B. 3600) und bei Bedarf dann wieder erneuern.

 

[edgecrusher]

Hi,

Nach meinem Wissenstand ist die LeaseDuration von "0" (unlimited) kein Problem (mehr). Frage, der curl Aufruf kommt auch explizit vom Client 192.168.0.213 oder wird versucht von einer anderen IP-Adresse für das Ziel 192.168.0.213 ein Port-Forward hinzuzufügen?

Grund der Frage siehe Schnittstellen Beschreibung von AVM für den wanpppconnection Service (Seite 6):

Port mapping entries are only allowed for hosts inside of LAN. Furthermore hosts can only add port mapping entries for themselves and not for other hosts in the LAN. It is not intended to allow port mapping entries for the guest network or hosts with IP adresses routed into WAN.

Gruß,
Edge

 

[sky321]

Hallo,

vielen Dank für eure Rückmeldung.

Auch ich habe zuerst an die Leasetime gedacht und verschiedene kleinere Werte probiert, leider ohne Erfolg. Werde aber mal ein Test mit 3600 machen.

Das script läuft definitiv genau auf dem client 192.168.0.213

Hat jemand von euch die Möglichkeit das mal nachzustellen? Ich wüsste gern ob es ein generelles Problem ist. Dann würde ich nochmal beim AVM Entwicklersupport nachfragen.

Gruß
Sky

 

[sky321]

Also die Leasetime ist es nicht. Mit einer Leasetime von 3600 oder auch beliebig anderen Werten, bekomme ich folgende Meldung.

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:dslforum-org:control-1-0">
<errorCode>725</errorCode>
<errorDescription>OnlyPermanentLeasesSupported</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

 

[PeterPawn]

Alles klar ... auf dem WANPPPConnection:1-Interface kann ich nichts testen, habe keine Box am DSL.

Ist denn sicher, daß beim Versuch des Einrichtens (vom Linux-System aus) auch die andere (permanente) Freigabe, auf der ja offenbar die Abfrage per "GetSpecificPortMappingEntry()" basiert, tatsächlich gelöscht ist?

Obwohl natürlich der Fehlercode 600 für diesen Fall ohnehin sehr komisch wäre ... mit dem 725 verwendet AVM bei einer Lease-Time > 0 dann ja wieder den passenden Fehlercode aus dem Service-Template (http://upnp.org/specs/gw/UPnP-gw-WANPPPConnection-v1-Service.pdf, Seite 34) und da sollte man dann für ein Problem mit einer "doppelten Freigabe" ja auch eher den Fehlercode 718 erwarten.

Dem "Augenschein" nach ist da aber auch nichts zu sehen, was einen Fehlercode 600 rechtfertigen würde ... die Angabe von 0.0.0.0 für den Host sollte als Wildcard m.E. auch durchgehen, wobei (wieder nach dem oben verlinkten Service-Template) auch eine leere Zeichenkette möglich sein sollte und vielleicht ist diese das, was im FRITZ!OS erwartet wird und damit ja das Problem.

 

[sky321]

Alles klar ... auf dem WANPPPConnection:1-Interface kann ich nichts testen, habe keine Box am DSL.

Ja stimmt, am Kabelanschluß ist die equivalente Schnittstelle die WANIPConnection:1. Von den Funktionen her sind die aber gleich.

Ist denn sicher, daß beim Versuch des Einrichtens (vom Linux-System aus) auch die andere (permanente) Freigabe, auf der ja offenbar die Abfrage per "GetSpecificPortMappingEntry()" basiert, tatsächlich gelöscht ist?

Wie in dem von die verlinketen Service-Template (S.33) beschrieben sollte beides möglich sein. Eine neu Freigabe oder eine Bestehende zu ändern.
----
This action creates a new port mapping or overwrites an existing mapping with the same internal
client.
----
Ich bekomme auch in beiden Fällen den gleichen Fehler 600.

... die Angabe von 0.0.0.0 für den Host sollte als Wildcard m.E. auch durchgehen, wobei (wieder nach dem oben verlinkten Service-Template) auch eine leere Zeichenkette möglich sein sollte und vielleicht ist diese das, was im FRITZ!OS erwartet wird und damit ja das Problem.

Guter Hinweis! Wenn ich das Argument leer lasse, bekomme ich auch eine 600 als Fehlercode zurück, mit meiner gültigen externen IP kommt folgender Fehler.

<errorCode>726</errorCode>
<errorDescription>RemoteHostOnlySupportsWildcard</errorDescription>

--------GEÄNDERT!----------------
Habe mal den UPnP client vom http://miniupnp.tuxfamily.org/ Projekt installiert, so aus Verzweifelung.
Wenn ich meine Firewall (iptables) abschalte, den Haken bei "Selbständige Portfreigabe" setzte und "Statusinformationen über UPnP übertragen" anschalte, geht die Portfreigabe mit dem miniupnp client.
Der macht das dann ohne Authentifizierung und auf http:49000!

Mit genau diesen Einstellungen und Konfigurationen geht allerdings das AddPortMapping über TR-064 immer noch nicht :-(
Das Löschen einer beim Start der Fritzbox vorhandenen Portfreigabe klappt allerdings in jedem Fall auch ohne diese Einstellungen, also immer.

 

[sky321]

Heureka!

Es war nur der Eintrag für die $IP Variable, kaum zu glauben.
IP="fritz.box" -> geht nicht bei AddPortMapping
IP="192.168.0.1" -> geht bei allen Aktionen

 

[Joe_57]

Vielleicht wurde ja irgendwo "fritz.box" in die Standard-IP 192.168.178.1 umgesetzt und somit deine veränderte IP nicht gefunden.

 

[stoney]

Mein allgemeiner Rat für solch "kritische" Angelegenheiten wäre immer die IP zu verwenden - wobei ich immer auf auf die IP setze, statt es der Namensauflösung zu überlassen, egal in welchem Szenario.

 

[koyaanisqatsi]

Moins


Ich kann weder Nachstellen, noch Nachvollziehen, warum nur DNS loses IPv4 funktionieren soll.
Meine Tests liefern Nach wie Vor...

<UPnPError xmlns="urn:dslforum-org:control-1-0">
<errorCode>402</errorCode>
<errorDescription>Invalid Args</errorDescription>
</UPnPError>

Ach, und "showshringbuf upnp_access" haut auch noch raus...

2019-03-24 19:21:59.941 - 192.168.188.9 - tr064koy [24/Mar/2019:19:21:59 +0100] \"POST /upnp/control/wanpppconn1 HTTP/1.1\" 500 - - \"curl/7.52.1\"\
2019-03-24 19:22:49.140 - 192.168.188.9 - - [24/Mar/2019:19:22:49 +0100] \"POST /upnp/control/wanpppconn1 HTTP/1.1\" 401 - - \"curl/7.52.1\"\

 

[sky321]

Ich verlinke mal mein Github Repo zum Thema TR-064 hier. Vieleicht hilft es ja dem Einen oder Anderen.

https://github.com/sky321/fritz_TR-064

Dort habe ich alles gesammelt, was mir auf meiner Suche zum Ziel unter die Finger gekommen ist. Danke an alle die dazu beigetragen haben.

 

[sky321]

Hey zusammen,

seid dem letzten update auf 7.27 geht leider das Löschen der Portfreigabe nicht mehr. mit den tr-069 script. Das Einrichten der Portfreigabe funktioniert einwandfrei.

In dem letzten info.txt steht was von:
- **Verbesserung** Ereignismeldung, wenn Port 80 temporär zur Zertifikatsausstellung für letsencrypt.org freigegeben wird

Ist da speziel was für letsencrypt geändert worden? Ich brauche die tr-069 scripte eigentlich auch nur für die Zertifikat Erneuerung.

 

[miyata]

Hey Sky321 gestern bin ich, nachdem ich diesen Thread: TR-064 DeletePortMapping Error 714 erstellt habe auf Deine Skriptsammlung bei Github gestoßen und werde heute von FischersFreetz auf diesen Thread hingewiesen...
Hoffentlich funktionierts bald wieder oder wir finden was anderes um die LetsEncrypt Bots ihre challenges erledigen lassen zu können... AVM schlug mir in nem Ticket dazu vor ne DMZ für den Webserver einzurichten, nicht das was ich wollte...

 

[sky321]

Falls mal wieder irgendwer darüber stolpert, Script habe ich seid längerem angepasst und jetzt klappt es auch wieder mit den Portfreigaben.

Anstelle des Port löschen setzte ich den Port jetzt einfach auf inaktiv nachdem Zertifikat erneuern.

pre-hook
post-hook
im Git Repo https://github.com/sky321/fritz_TR-064

 

[miyata]

Danke für Deine "kreative" Lösung! Das funktioniert gut!

 

[georg3003]

Coole Sache! Danke