[Frage] Öffentliche IP unter OS 6.90 abfragen

[tommi.m]

Hallo liebe Community

Seit OS 6.90 funktioniert die Abfrage mittels curl "http://<locale IP des Routers>:49000/igdupnp/control/WANIPConn1... nicht mehr. Hat schon jemand von Euch den aktuellen String?

Ich danke Euch allen für die Unterstützung.

Viele Grüße
Thomas

 

[Shirocco88]

ich verwende:

pi@raspberry-pi:/$ wget -O - http://myip.dnsomatic.com/ 2> /dev/null
aaa.bbb.ccc.dddd
pi@raspberry-pi:/$

 

[rmh]

Ich verwende:

dig +short meinrouter.domain.com

 

[PeterPawn]

Hmm ... ich habe das gerade mal probiert:

curl "http://<locale IP des Routers>:49000/igdupnp/control/WANIPConn1...

und das funktioniert schon vor der 06.90 nicht - selbst wenn man die "offene" Zeichenkette noch mit einem "quote" schließt. Dabei habe ich natürlich "<locale IP des Routers>" durch die verwendete IP-Adresse ersetzt und es auch mit mind. zwei Locale-Sets (0x409 und 0x407) getestet; daran liegt es also auch nicht.

Wie soll man jetzt anhand dieser URL-"Rudimente" eigentlich erkennen können, was da irgendwann mal aufgerufen werden sollte? Es gibt zig Möglichkeiten, diese Adresse (auch per TR-064/IGD2) zu ermitteln und so ziemlich jede davon braucht einen speziellen Request-Aufbau und eine passende URL. Da muß man sich also schon die Mühe machen, den von einem selbst verwendeten Aufruf soweit zu dokumentieren, daß potentielle Helfer wenigstens wissen, was/welche Funktion man eigentlich benutzen wollte,

Nur dann wird jemand sagen können, ob das weiterhin so funktioniert und das Problem irgendwo beim Aufruf liegt, denn in #1 steht ja außer "funktioniert [...] nicht mehr" nicht so sehr viel Hilfreiches zum aufgetretenen Fehler. Denkbar ist natürlich auch die Möglichkeit, daß AVM das (hier vermutlich zu benutzende) IGD2-Interface nur noch mit passenden Credentials zugänglich macht (notfalls mit dem Standard-Kontonamen aus der IGD-Spezifikation) ... aber wie gesagt: Solange keiner wirklich weiß, was Du da machen willst, ist das alles (fruchtlose) Raterei und man kann nicht mal probieren, ob das behauptete Problem sich reproduzieren läßt.

Was ich hingegen definitiv weiß: Der Aufruf der Methode "GetInfo" auf diesem Interface funktioniert nach wie vor tadellos und liefert die IP-Adresse des WAN-Interfaces der betreffenden FRITZ!Box ... und die muß ja nicht zwangsläufig auch diejenige sein, mit der eine Abfrage (bei kaskadierten Routern) dann bei einem externen Service eingeht - insofern sind das eigentlich zwei getrennte Themen, wenn hier alternative Vorschläge zum Ermitteln der externen IP-Adresse eines Anschlusses unterbreitet werden. Das könnte sich zwar um dieselbe Adresse handeln, es muß aber nicht zwangsläufig auch so sein.

 

[joesix]

Ich verwende:

upnpc -l | grep ExternalIP | grep -o -P '\d+\.\d+\.\d+\.\d+'

oder noch einfacher aus dem Debian miniupnpc Paket:

/usr/bin/external-ip

 

[tommi.m]

Hallo liebe Community

Seit OS 6.90 funktioniert die Abfrage mittels curl "http://<locale IP des Routers>:49000/igdupnp/control/WANIPConn1... nicht mehr. Hat schon jemand von Euch den aktuellen String?

Ich danke Euch allen für die Unterstützung.

Viele Grüße
Thomas

Ich danke Euch allen für die Hilfsbereitschaft. Ich muss mir eingestehen, dass ich unterschätzt habe, wie wichtig der ganze von mir verwendete String ist. Hier ist der String in voller Länge

IP=$(curl "http://<lokale IP des Routers oder router.lokale.domain>: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>" -s | grep -Eo '\<[[:digit:]]{1,3}(\.[[:digit:]]{1,3}){3}\>')

 

[PeterPawn]

Da hat AVM irgendwo Mist gebaut oder das tatsächlich absichtlich geändert ... eine solche "leere" IP-Adresse gibt es bei anderen Versionen auch schon länger, aber m.W. war das bisher auf bestimmte "Anschlußarten" beschränkt (z.B. LAN1-Router). Jedenfalls trat es auch mit der 06.83 bereits auf: https://www.ip-phone-forum.de/threa...e-gesucht-fritz-os-06-50.287835/#post-2235859
- wenn auch mit einer 7390. Genauso klappt dieser IGD-Aufruf bei mir schon bei der 7490 mit 06.83 nicht mehr (die ist im LAN1-Routermodus).

Bei AVM muß man beim Lesen der Dokumentation zum IGD2-Interface (https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/IGD2.pdf) auf Seite 3 auch etwas aufpassen, weil das dort angeblich referenzierte Dokument zum "WANIPConnection:2"-Interface zwar im Text richtig steht, aber der dahinterliegende Link zur Beschreibung der Version 1 führt (wie auf Seite 2 davor).

Aber wie auch immer ... bei mir liefert(e) eben auch eine 06.83 auf der 7490 schon keinen Wert mehr bei "NewExternalIPAddress" und zwar weder auf dem IGD- noch auf dem IGD2-Interface. Ich bin dann einfach auf eines der anderen Interfaces ausgewichen ... die brauchen zwar passende Credentials für den Aufruf, aber da funktioniert das wenigstens noch (siehe oben für ein Beispiel eines solchen Interfaces).

Warum AVM da (ohne passende Fehlermeldungen) nur noch die leere Zeichenkette für die Adresse liefert (die Spezifikation für IGD2 fordert das in Punkt 2.3.13, wenn keine Adresse "ermittelt" werden kann), wird wohl noch eine Weile das Geheimnis von AVM bleiben ... die Schnittstellenbeschreibungen hinken ja immer heftig hinterher und stimmen auch an einigen (man könnte auch schreiben: vielen, je nachdem, wo man da selbst die Grenzen bei einer solchen "Mengenangabe" zieht) Stellen nicht so ganz mit der tatsächlichen Umsetzung überein.

Über etwaige Änderungen an dieser Stelle informiert AVM auch mehr als spärlich ... am Ende bleibt einem interessierten Programmierer gar nichts anderes als "trial & error" übrig, um ein bestimmtes Problem zu lösen. Ich weiß zum Beispiel auch gerade nicht, ob das von AVM auf dem IGD2-Interface angebotene Monitoring für Änderungen von "NewExternalIPAddress" (wo man sich ja dann von der Box über eine neue Adresse informieren lassen könnte über eine passende Event-Subscription) nun bei der 06.90 funktioniert ... bei der 06.83 wollte das (rein aus der Erinnerung) auch nicht so richtig klappen. Wobei das eben bei der 06.83 für die 6490 schon wieder anders aussah, wenn ich mich richtig erinnere ...

 

[tommi.m]

Ich verwende:

/usr/bin/external-ip

So einfach kann es sein. Danke joesix! So mache ich es fürderhin auch.

Danke auch an PeterPawn für den Erfahrungsbericht über IGD2 und AVM.

Viele Grüße
Thomas

 

[PeterPawn]

Wobei ich das wieder nicht verstehe, wenn es tatsächlich funktioniert. Dahinter verbirgt sich ja nichts anderes als ein Shell-Skript, das seinerseits wieder "upnpc -s" aufruft und die Ausgabe mit "grep" und "sed" in Form bringt. Dabei fragt das normalerweise auch genau (nach einem "GetStatusInfo") die Adresse mit diesem "GetExternalIPAddress" ab und wenn das tatsächlich eine andere Ausgabe liefert (bei mir ist das deutlich nicht der Fall, wenn ich dieselbe Box befrage ... das "upnpc" sucht sich das IGD ja mit einem SSDP-Discover), dann stimmt vermutlich doch etwas mit dem anderen Aufruf nicht. Das "upnpc"-Binary (das ist ja eigentlich nur ein Testprogramm für die UPnP-Library dahinter) fragt halt noch weitere Daten ab, verwendet dafür aber auch weitere Funktionsaufrufe auf dem "WANIPConnection:1"-Interface und auch weitere Interfaces (z.B. "GetCommonLinkProperties" auf dem Interface "WANCommonInterfaceConfig:1") werden genutzt.

Das macht es zwar alles einfacher beim Aufruf (wenn man das passende Paket installiert hat), aber es werden auch deutlich mehr Daten "bewegt", wenn man eigentlich nur die IP-Adresse wissen will und die Ausgabe von "upnpc -s" am Ende auch genau nur nach diesem Datum filtert. Macht man das nur mal schnell "manuell", ist es sicherlich mit "upnpc" einfacher ... automatisiert man es ohnehin, kann man auch gleich nur "GetExternalIPAddress()" aufrufen - das minimiert parallel dazu noch mögliche Fehlerquellen, weil zusätzliche (und hier unnötige) SOAP-Requests vor diesem Aufruf nicht fehlschlagen können.

Mich würde also tatsächlich sehr interessieren, ob der Aufruf von "upnpc -s" für dieselbe Box tatsächlich eine externe Adresse liefert, wenn der direkte Aufruf per "curl" fehlschlägt (ohne die sofortige Zuweisung zu "IP" und ohne das "sed"/"grep" am Ende der Kette) bzw. eine leere Adresse liefert. Bei mir stimmen die Ergebnisse auf beiden (bzw. allen) Wegen überein.

 

[koyaanisqatsi]

Moin

Wenn DDNS dann schau mal beim DDNS Anbieter ob der dir auch die Möglichkeit der IP Ausgabe bietet.
Securepoint bietet das für IPv6 & IPv4, nur IPv4 oder nur IPv6.
Siehe: https://wiki.securepoint.de/SPDyn/meineIP

 

[koyaanisqatsi]

So kriegste aber 2 Sachen gleichzeitig raus, von jeden beliebigen Klienten...
1. Steht die Internetverbindung
2a. Stimmt die IP mit einer früher gespeicherten überein
...dann kein Update
2b. Stimmt nicht mehr überein
...dann Update

Mit TR-064 mach ich höchstens eine "Neuverbindung", damit ich eine neue IP bekomme und die Fritz!Box macht dabei das Update für DDNS automatisch.

 

[PeterPawn]

Nach der Service-Description ist die Box auf dem IGD2-Interface in der Lage, über Änderungen der externen IP-Adresse per Event zu informieren:

igd2connSCPD.xml

<serviceStateTable>
[...]
  <stateVariable sendEvents="yes">
    <name>ExternalIPAddress</name>
    <dataType>string</dataType>
  </stateVariable>
  <stateVariable sendEvents="yes">
    <name>ExternalIPv6Address</name>
    <dataType>string</dataType>
  </stateVariable>
[...]
</serviceStateTable>

Beide Variablen sind als "event-fähig" ausgewiesen ... wenn ich mich richtig erinnere, klappte es aber am Beginn der Labor-Reihe nicht.

Das kann natürlich auch daran liegen, daß bei mir die 7490 ja gar keinen Wert mehr anzeigt bei "ExternalIPAddress" - aber auch bei der 06.83 für die 6490 (wo die Anzeige der externen Adresse noch klappt), wollte kein Event kommen ... wobei es am VF-(Kabel-)Anschluß bei mir auch nicht ganz einfach ist, IP-Adressen zu wechseln.

Es ist sicherlich nicht ganz uninteressant als Interface (auch über Änderungen der Anzahl von Portfreigaben soll man sich ja informieren lassen können), aber ich habe das Gefühl, daß AVM beim Management von Event-Subscriptions noch ein paar Probleme hat, besonders wenn derselbe Control-Point seine Subscription einige Male erneuern mußte, weil das Timeout abgelaufen war.

Aber das habe ich auch nur überwindlich getestet, quasi als "Abfall", als ich den TR-064-Interfaces etwas auf den Zahn gefühlt habe, was man dort ggf. an Lücken finden könnte ... also am besten noch einmal selbst testen, was da bei der 06.90 wirklich geht mit SUBSCRIBE auf dem IGD2-Interface.

 

[PeterPawn]

Wie schon mal irgendwo geschrieben ... ich denke auch, daß es eher an der Betriebsart liegt, ob die IP in der Antwort enthalten ist oder nicht.

 

[PeterPawn]

Daß ich den nicht wirklich meine, sollte eigentlich klar sein ... in diesem Modus hat die Box ja gar keine externe IP-Adresse und damit macht "GetExternalIPAddress()" dann auch wenig Sinn.

 

[MegaV0lt]

Also mein Skript funktioniert noch:

root auf HP-T610 am 13.10.2017 08:56
[~] # fb_extip.sh
80.138.166.28
root auf HP-T610 am 13.10.2017 08:56
[~] # cat /usr/local/sbin/fb_extip.sh
#!/bin/bash

# F�r neuere Fritz!Box ab Firmware 06.05
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>" \
     -s | grep -Eo "\<[[:digit:]]{1,3}(\.[[:digit:]]{1,3}){3}\>"

 

[d.heinrichs]

Hallo,

ich versuche auch gerade, die externe IP meiner neuen FB 7590 (seit heute, Deutsche Glasfaser) per Skript zu ermitteln, um meinen DynDNS Eintrag zu aktualisieren. Anscheinend benutzt DG CG-Nat, weshalb die FB eine andere externe IP hat als z.B. bei whatsmyip.org angezeigt wird. Bei 1&1 war das immer gleich.

Weder mit obigen curl Befehlen, noch mit upnc -s liefert die Box ihre Adresse zurück. Wäre für weitere Ideen echt dankbar.

 

[sulihari]

Wie wäre es, die Push Nachricht zu verwenden? Ich habe mir das eingestellt, da immer dann kein DynDNS (myfritz) funktionierte, wenn ich per VPN zugreifen wollte.
Per email hat man immer die aktuelle Adresse parat.

 

[KunterBunter]

Wenn CG-NAT verwendet wird, nützt dir die IPv4-Adresse aus der Push Nachricht auch gleich gar nichts. Dann musst du IPv6-Adressen benutzen.

 

[3-Finger-Harry]

unter Linux würde ich 'ping -R 1.1.1.1' machen. die gesuchte IP dürfte die 2. in der Liste sein, wenn die Linux-Kiste direkt am Router hängt.

 

[KunterBunter]

Habe ich gemacht:

Kunters-linux:141117 kunter$ ping -R 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=38.595 ms
RR:     192.168.178.1
    62.214.38.2
    mun1901bihd001.versatel.de (62.214.63.135)
    fra020isp005.versatel.de (80.81.193.80)
    162.158.84.1
    one.one.one.one (1.1.1.1)
    one.one.one.one (1.1.1.1)
    162.158.84.1
    fra1807dihb001.versatel.de (62.214.63.115)

Welche ist jetzt die gesuchte IP-Adresse?