[Problem] FRITZ!Box Reconnect Software gesucht - FRITZ!OS: 06.50+

[Capideluxe]

Hallo!

Ich Suche ein fertiges Package oder eine DAU-Schritt-für-Schritt-Anleitung, wie man bei aktuellen FRITZ!Boxen einen Reconnect durchführt.

Vorhanden:
FRITZ!OS: 06.50 - Box: 7362 SL
Statusinformationen über UPnP übertragen ist aktiv.
Win7 x64.

Es soll wohl über cURL gehen. Also habe ich folgendes getan:
1. curl.exe runtergeladen für Win7-x64: http://winampplugins.co.uk/curl/
2. reconnect.bat Datei erstellt mit folgendem Inhalt den ich gefunden habe:

curl "http://fritz.box:49000/upnp/control/WANIPConn1" -H "Content-Type: text/xml; charset="utf-8"" -H "SoapAction:urn:schemas-upnp-org:service:WANIPConnection:1#ForceTermination" -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:ForceTermination xmlns:u='urn:schemas-upnp-org:service:WANIPConnection:1' /> </s:Body> </s:Envelope>"

oder

curl "http://fritz.box:49000/upnp/control/WANIPConn1" -H "Content-Type: text/xml; charset="utf-8"" -H "SoapAction:urn:schemas-upnp-org:service:WANIPConnection:1#ForceTermination" -d "<?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body> <u:ForceTerminationResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"></u:ForceTerminationResponse> </s:Body> </s:Envelope>

3. reconnect.bat (zusammen im Ordner mit der curl.exe) ausgeführt. Leider tut sich da nicht wirklich was. Die IP bleibt gleich und in der Kommandozeile von Windows wird auch kein Fehler beim Ausführen angezeigt. Ich sehe nur den Inhalt der .bat .

Kann jemand helfen?

 

[informerex]

du hast leider nicht angegeben, warum du den connect brauchst (um das passende Tool oder Einstellungen zu benennen)
bzw. bei welchem Anbieter, denn es kann durchaus sein, dass du nicht immer eine neue IP bekommst, obwohl das script bspw. korrekt arbeitet. hast du geprüft ob das script funktioniert in dem auf der Startseite der fritz.box der letzten reconnect geprüft wird.

bspw. chrome + https://chrome.google.com/webstore/...pp?utm_source=chrome-app-launcher-info-dialog

 

[thtomate12]

Da du scheinbar Windwows benutzt, kannst du einfach das UPnP-Gerät verlinken, dort wird bei jeden zweiten Klick ein Receonnect ausgeführt.

 

[Capideluxe]

Ich benötige den Reconnect für IP Tracking Tests unserer SaaS. Es reicht den Reconnect manuell anzustossen.
Früher hatte ich eine 7270 und da hat FritzBoxVoipReconnect_v1.0.3 gute Dienste geleistet.
Ja, ich erhalte immer eine neue IP vom Provider.

Da du scheinbar Windwows benutzt, kannst du einfach das UPnP-Gerät verlinken, dort wird bei jeden zweiten Klick ein Receonnect ausgeführt.

Achja? Wie macht man das denn?

 

[Capideluxe]

Hello? anybody there?

 

[koyaanisqatsi]

Ich sehe nur den Inhalt der .bat .

Wie führst du die denn aus ?
Hat die keinen Namen, nur .bat ?

Ach, guck mal an, (ur)altes Skript, probier doch mal...

curl "http://fritz.box:49000/igdupnp/control/WANIPConn1"

...weil AVM das schon seit etlichen Firmwareversionen geändert hat.

Als positive Antwort wird dann...

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle "http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:ForceTerminationResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"></u:ForceTerminationResponse>
</s:Body>

...zurückgeliefert.

Nachteil: Deine Telefonnummern (Internetanbieter) sind nicht mehr registriert.

 

[Joe_57]

Wenn du als Browser den Firefox verwendest, kann ich dir das Add-on Fox!Box empfehlen.

Joe

 

[compichief]

Ich bin leider kein Experte, schildere mein Problem deshalb leider nur in meinen einfachen Worten.

Irgedetwas hat sich für meine Kombination Unitymedia/Fritzbox7272 ca. Mitte September bzgl. reconnect geändert (also es lässt sich nicht mehr so durchführen wie früher...). Es kann nicht unmittelbar am Update auf FRITZ!OS 6.50 liegen.
Das wurde bei mir nicht automatisch installiert. Meine Hoffnung gestern durch manuelles Update auf 6.50 das Problem vielleicht zu lösen hat sich leider zerschlagen.

Fox!Box funktioniert nicht; RouterReconnect1.3 leider ebenfalls nicht

 

[compichief]

Hat sonst niemand dieses Problem? Funktionieren bei euch die alten Reconnect-Methoden noch?

 

[informerex]

...Unitymedia ...

ich hab diesbzgl. festgestellt, dass die "alte IP" trotz Trennung über die WebGUI der Box - mehrfach - "identisch" zugeordnet wird. ... dh. der reconnect arbeitet sauber, aber immer gleiche IP
dies ist jedoch zeitabhängig

 

[compichief]

Sehe ich es richtig, dass man bei dem Reconnect über die WebGUI früher eine neue IP bekommen hat? Warum ist das jetzt anders? Kann man es beeinflussen?

 

[informerex]

ich verstehe die Frage nicht, denn die Funktion in der WebGUI heißt "neu verbinden" http://fritz.box/?lp=mNetMoni - genau dies soll doch durchgeführt werden, entweder über WebGUI oder Tool
dass eine Unterbrechnung erfolgreich durchgeführt wurde, siehst du an der Uhrzeit, aber wie o.e. evtl. trotzdem gleicher IP
(Randbemerkung: manche DSL-User bezahlen für feste-IP)

Es wird sich um einen IP-Engpass zu bestimmten Zeiten handeln bzw. das System vergibt halt die gleiche IP, bei deinem Modem/mit deinen Zugangsdaten.
In der Regel kann dies durch längere "Unterbrechungszeit" geändert werden - kannst ja einfach selbst feststellen, zwischen schnell Stecker ein/ausstecken und/oder 5 Minuten Pause

 

[PeterPawn]

Es kann auch schlicht daran liegen, daß die Box (die hier ja dann wohl die IP-Adresse über DHCP bezieht) da RFC-konform nur die Erneuerung der IP-Adresse anfragt und das vom DHCP-Server bei UM jetzt korrekt behandelt wird. Es ist ein Unterschied, ob eine IP-Adresse verlängert werden soll oder ob man gerne eine neue IP-Adresse hätte ... bei DSL-Modellen mit aktiviertem Modem und dort verwendetem DHCP (ist z.B. bei der Swisscom die Standardkonfiguration, da dort kein PPPoE verwendet wird) hat es mal geholfen, den "dsld" neu zu starten, weil dann die vorher verwendete IP-Adresse nicht mehr bekannt war und eine richtige neue Anforderung gestartet werden mußte. Irgendwo in den Tiefen des IPPF habe ich mal etwas zu dem Thema geschrieben, da erhielt jemand auch keine neue IP-Adresse, wenn er nur "Neu verbinden" benutzte.

 

[thecoder2012]

Es kann auch schlicht daran liegen, daß die Box (die hier ja dann wohl die IP-Adresse über DHCP bezieht) da RFC-konform nur die Erneuerung der IP-Adresse anfragt und das vom DHCP-Server bei UM jetzt korrekt behandelt wird. Es ist ein Unterschied, ob eine IP-Adresse verlängert werden soll oder ob man gerne eine neue IP-Adresse hätte

Weißt Du ob man bei UM mit einer freien Fritz!Box 6490 (SSH/Telnet/modifizies Image) per Befehl/Software sagen kann das man gerne eine neue IP hätte?
Freetz gibt es ja leider (noch) nicht für 6490.

... bei DSL-Modellen mit aktiviertem Modem und dort verwendetem DHCP (ist z.B. bei der Swisscom die Standardkonfiguration, da dort kein PPPoE verwendet wird) hat es mal geholfen, den "dsld" neu zu starten, weil dann die vorher verwendete IP-Adresse nicht mehr bekannt war und eine richtige neue Anforderung gestartet werden mußte.

Dürfte bei Cable wohl nicht ganz so einfach sein weil es wenn wohl explizit angefordert werden muss.

Irgendwo in den Tiefen des IPPF habe ich mal etwas zu dem Thema geschrieben, da erhielt jemand auch keine neue IP-Adresse, wenn er nur "Neu verbinden" benutzte.

Es ist manchmal nicht einfach im IPPF ein bestimmtes Thema wieder zu finden.

 

[PeterPawn]

Weißt Du ob man bei UM mit einer freien Fritz!Box 6490 (SSH/Telnet/modifizies Image) per Befehl/Software sagen kann das man gerne eine neue IP hätte?

Nein ... ich würde aber zuerst einmal testen, ob eine solche FRITZ!Box bei UM tatsächlich nach jedem Neustart auch eine geänderte IPv4-Adresse (darum geht es hier sicherlich) erhält. Wenn das nicht klappt, wird es auch mit laufender Box extrem schwierig werden.

Dürfte bei Cable wohl nicht ganz so einfach sein weil es wenn wohl explizit angefordert werden muss.

Schlecht einzuschätzen ... im einfachsten Falle hat AVM die Aktionen hinter der "reconnect_button"-Message im "dsld" für DOCSIS angepaßt und es reicht das entsprechende "msgsend". Ansonsten gäbe es eine TLV, mit der ein Neustart des eRouters ausgelöst wird ... wenn ich das richtig im Hinterkopf habe, war das bei AVM auch dadurch umgesetzt, daß diese Aktion vom SNMP-Stack auf die AVM-Komponenten mit irgendeinem Skript-File "gemappt" wurde. Wenn Du die Firmware schon ausgepackt hast: Es war irgendwas mit "soft reset" oder so ähnlich und es war mit einiger Sicherheit ein Shell-File - das passende Kommando zur Suche kann man also sehr selektiv formulieren und es sollte max. 10 Minuten brauchen, die Datei auf diesem Weg zu finden.

Es ist manchmal nicht einfach im IPPF ein bestimmtes Thema wieder zu finden.

Aber auch nicht so fürchterlich schwer:

http://www.ip-phone-forum.de/showthread.php?t=279159 - gefunden mit https://www.google.de/search?q=site:ip-phone-forum.de+PeterPawn+DHCP+reconnect+dsld+stoppen

Ich mag ja im Vorteil gewesen sein, weil ich mich in etwa erinnern konnte, aber der Titel der ersten Fundstelle ist kaum mißzuverstehen.

 

[aliquis]

Hallo,

seit letzter Woche greift mein IP-Wechsel-Skript nicht mehr, das die letzten Jahre (mit geringen Anpassungen) stets gut funktionierte.

Ich verwende:
FRITZ!OS: 06.83
Modell 7390
√ Zugriff für Anwendungen zulassen
√ Statusinformationen über UPnP übertragen
Batchskript (cmd.exe) + cURL unter Win7 x64. (ISP ist easybell.)

In letzter Zeit ist kein Firmware-Update o.ä. eingespielt worden, auch habe ich keine Konfigurationsänderung vorgenommen.
Mein Skript läuft auch seit langem unverändert.

Wenn ich aus meinem Skript folgende Zeile manuell ausführe:
curl "http://fritz.box:49000/igdupnp/control/WANIPConn1" -H "Content-Type: text/xml; charset="utf-8"" -H "SoapAction:urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress" -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:GetExternalIPAddress xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1" /> </s:Body> </s:Envelope>"

dann erhalte ich folgende Antwort:
<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xml
soap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>401</errorCode>
<errorDescription>Invalid Action</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

Laut Fehlercode 401 liegt nun ein Berechtigungsproblem vor, hatte ich früher nie.
Spaßeshalber habe ich JDownloader nach einem möglichen Reconnect-Skript suchen lassen, es wurden einige XML-Muster durchprobiert, ohne Ergebnis.

Ich weiß nicht, wo ich ansetzen soll.
Hat jemand eine Idee?

 

[PeterPawn]

Neustart ... per se sollte das auch bei der 06.83 noch genauso funktionieren, die IP-Adresse abzufragen.

 

[aliquis]

Neustart ... per se sollte das auch bei der 06.83 noch genauso funktionieren, die IP-Adresse abzufragen.

Neustart funktioniert, d.h. eine neue IP wird zugewiesen.

Meine Überlegung war folgende: Wenn es, wie du schreibst, nicht an Firmware 06.83 liegt, wäre ein Defekt der schon mehrere Jahre alten FRITZ!Box denkbar.
Ich habe auch keine Erklärung dafür, dass von heute auf morgen mein Skript nicht mehr arbeitet.
Allerdings habe ich in der Vergangenheit schon einmal bei einem Firmware-Update Änderungen vornehmen müssen, à la
/\/upnp\//\/igdupnp\/
Könnte es dieses Mal etwas Ähnliches sein? igd2upnp vielleicht... ?

 

[PeterPawn]

Nein, der "curl"-Request funktioniert genau so wie er oben steht (allerdings unter Linux getestet) ... gerade noch einmal auf einer 7390 mit 06.83 (über VPN) probiert - jedoch mit der IP-Adresse anstelle von "fritz.box", aber ich glaube nicht, daß da der Host-Header im HTTP-Request plötzlich eine Rolle spielt. Außerdem kannst Du das ja problemlos ebenfalls mit der IP-Adresse testen ... ich würde auch einfach einmal hingehen und "Statusinformationen über UPnP übertragen" zunächst mal deaktivieren und (nach einem weiteren Neustart) dann wieder aktivieren. Für das Auslesen über die IGD-Interfaces sollte diese Einstellung die entscheidende sein ... das "Zugriff für Anwendungen zulassen" sollte die TR-064-Funktionen betreffen.

Ein Hardware-Defekt, der zu diesem Fehler führt, ist für mich aber nur schwer vorstellbar ... eher schon falsches Escaping und/oder falsche Variablen-Substitutionen beim Aufruf. Ich wüßte zwar im Moment auch nicht, welches Windows-Update das genau gewesen sein sollte, aber wenn das nach dem zweiten Dienstag in diesem Monat begann, würde ich eher auf eine Änderung in "cmd.exe" im Windows tippen bzw. in einer von "curl" am Ende benutzten Bibliothek (keine Ahnung, ob "curl" unter Windows auch die "winhttp.dll" benutzt oder was auch immer bzw. ob sich in den C-Runtimes am letzten Patchday irgendetwas Wichtiges getan hat).

 

[aliquis]

Der Tipp mit dem temporären Deaktivieren der Statusinformationen-Option gefolgt von Neustart hat etwas bewirkt.
Der UPnPError mit errorCode 401 kommt jetzt nur noch, wenn ich ein falsches Kommando abschicke, etwa "upnp" statt "igdupnp" im Adresspfad.

Ich habe cURL auf Version 7.55.0 aktualisiert und es zusätzlich auf einem zweiten System mit Windows 8.1 x64 getestet (Update-Stand: Juni 2017).
Auf beiden Systemen, Win7 x64 (aktuell) und Win8.1 x64 erhalte ich jetzt auf obiges curl-Kommando folgende Ausgabe (gilt für fritz.box bzw. für 192.168.178.1):

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetExternalIPAddressResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewExternalIPAddress></NewExternalIPAddress>
</u:GetExternalIPAddressResponse>
</s:Body>
</s:Envelope>

Interessanterweise bleibt der entsprechende Knoten immer leer...