Seit 30.9.20 immer die selbe externe IPv4

[eisbaerin]

Am 30.9.20 wurde ich und eine Bekannte auf einen anderen Breitband-PoP umgestellt. Nicht der selbe.
Andere dagegen blieben auf dem alten Breitband-PoP. Bisher waren alle die ich bei 1&1 kenne auf dem selben.

Seit dem beginnt meine und ihre IP nicht mehr mit 92, sondern mit 94. Soweit normal.

Aber seit dem bekomme ich und sie immer jeden Tag die selbe IPv4. (ich und sie natürlich unterschiedliche)
Ich habe selbst nach einem resync die selbe IPv4 bekommen.

Ich habe also fast keine Chance eine neue IP zu bekommen.
Hat das noch wer?
Was wurde da und warum geändert?

 

[NanoBot]

Ich kenne diesen Effekt schon seit längerer Zeit, nämlich seit ich vom Telekom Backbonenetz auf das Versanet Backbonenetz umgestellt wurde. Allerdings ist der Effekt bei mir nicht ganz so krass. Es kommt zwar häufiger vor, daß ich nach einem manuelen Reconnect die gleiche IP wieder bekomme. Im Gegensatz dazu ist es dagegen erst ein oder zweimal passiert, daß ich auch nach der 24h Trennung die gleiche IP hatte.

Bisher ist das Ganze allerdings noch erträglich, denn wenn ich die Reconnectfunktion aus dem JDownloader nutze, dann bekomme ich spätestens nach einigen Versuchen dann doch eine neue IPv4-Adresse. Der JDownloader überprüft nämlich, ob tatsächlich eine neue IP zugeteilt wurde und wiederholt den Reconnect ggf. bis zu fünf mal.

Längerfristig wird man als 1und1 Kunde mit diesem Phänomen leben müssen, denn 1und1 bzw. Versanet gehört eben zu den Anbietern, die nicht mehr so viele IPv4 Adressen in ihrem Pool haben wie es erforderlich wäre. Noch schlimmer ist es dagegen bei den Kabelinternet-Anbietern, die arbeiten aus diesem Grunde ja schon länger mit DS-Lite als default. Und während man bei 1und1 oder Vodafone ( Kabel ) auf Nachfrage kostenlos wieder echtes Dualstack bekommen kann, gibt es bei Unity Media für Privatkunden generell nur noch DS-Lite, nur noch die Kunden mit dem teuren Geschäftskundentarif bekommen bei Unity noch eine IPv4

 

[eisbaerin]

Im Gegensatz dazu ist es dagegen erst ein oder zweimal passiert, daß ich auch nach der 24h Trennung die gleiche IP hatte.

Genau so war es bei mir auch die letzten 9 Jahre.
Und ich bin auch schon lange über Versatel angebunden. Auch jetzt noch.
Ich protokolliere die IPs immer mit, so daß ich es genau nach vollziehen kann.

Reconnectfunktion aus dem JDownloader

Danke! Das werde ich mir mal anschauen.

 

[HabNeFritzbox]

Evt. hängt es mit DS Lite zusammen? Oder einfach am Versatel oder Vodafone Netz?

 

[Novize]

...oder mit der Region.
Ich habe seit Umstellung auf das 100er DSL den ebenso Versatel als Einwahlserver, bekomme jedoch trotzdem täglich eine neue IP.
Die täglich wechselnde IP bekam ich vorher bei Vodafone als Backbone-Betreiber beim DSL16k aber auch schon.

 

[u.g]

Kommt bei mir auch vor, z.B. viermal hintereinander vom 29.9. bis 2.10. eine 94.xxx IP

 

[Novize]

Die mir zugewiesenen IPs sind allesamt aus den Blöcken 83.x, 87.x 89.x
Region Ruhrgebiet

 

[eisbaerin]

viermal hintereinander vom 29.9. bis 2.10. eine 94.xxx IP

Immer die selbe? Oder nur aus dem Block?

 

[u.g]

Immer die selbe?

Ja.

 

[eisbaerin]

Ich hatte mal diese Nacht mal die vorgezogene Zwangstrennung abgeschaltet.
Ich hoffte, daß durch immer der selben IP auch die Zwangstrennung weg fällt.
Aber nein, die Trennung fand statt und ich habe wieder die selbe IP bekommen.

Schade, sonst hätte ich endlich mal ohne Unterbrechung telefonieren können.

 

[Peter_Lehmann]

Eine reine Verständnisfrage:
Worin liegt denn bei der "immer wieder erhaltenen selben IP" das hier mittlerweile schon in 10 Beiträgen genannte Problem?
ARD, ZDF, heise.de, golem.de, google und Millionen von Webseiten haben IMMER die gleiche IP. Sogar dieses Forum hier.
Ich wäre glücklich, wenn ich ohne Zusatzkosten eine fixe IP hätte. Damit könnte ich mir den Umweg über die Krücke DynDNS sparen.

Würde mich freuen, wenn mir mal jemand von euch den Vorteil einer wechselnden IP nennen könnte. (Ach ja, ich halte den erwarteten Shitstorm aus!)

Irgendwie erinnert mich das an eine (vor vielen Jahren mal in einem hier nicht genannten Forum) gepostete Frage, ob man es nicht schaffen könnte, aller x Minuten vom Provider eine neue IP zu erhalten. Mir kommt das so vor, als dass es immer noch Leute gibt die denken, dass man sich mit dem regelmäßigen Wechsel der IP im Internet vor den staatlichen und kommerziellen Schnüfflern verstecken könnte. Mittlerweile arbeiten deren Server auch mit synchronisierter und sehr genauer Netzzeit. Nix mehr mit Verstecken!

Ich nenne sogar (neben dem Wegfall des DynDNS) einen Vorteil einer dauerhaften IP: Es kann dann nicht mehr passieren, dass das eigene Heimnetz eine durch einen Spammer (o.ä.) verbrannte und geblacklistete IP bekommt und die Provider Mails von dieser IP nicht mehr weiterleiten.

So, nun bin ich gespannt ... .

MfG Peter

 

[eisbaerin]

Problem habe ich nicht damit.
Ich wundere mich nur, daß es nach über 9 Jahren nun so anders ist.
Man hatte sich so daran gewöhnt.

Ja, wenn es mal eine fixe IP wäre, dann wäre ich auch froh, daß ich das dynDNS nicht mehr bräuchte. Aber so fix wird sie nun auch wieder nicht sein.

Noch schöner wäre dann aber, wenn auch die Zwangstrennung weg fiele.

Vorteil erhoffe ich bei Angriffen von Hackern.

Einer hier im Forum hatte eine fixe IP und hat deshalb bei dropbear sich öfters neue host_key gemacht, damit ihn Hacker daran nicht eindeutig erkennen.

 

[Joe_57]

den Vorteil einer wechselnden IP nennen könnte.

Der manuell erzwungene IP-Wechsel wird gerne von Downloadern genutzt, die dadurch die Zwangspause zwischen den einzelnen Download-Parts einer Riesendatei umgehen möchten ohne sich beim Download-Provider kostenpflichtig registrieren zu müssen.

 

[koyaanisqatsi]

@Peter_Lehmann - Torrent Downloads zum Beispiel, wurde die Datei vollständig heruntergeladen bekommen die anderen "Leecher" über die eigene öffentliche IP Teilstücke des Torrent zum Download.
...ein IP Wechsel unterbindet dies und untergräbt auch die Philosophie dem diese Art des Filesharings zugrunde liegt.
...ach ja, Abmahnanwälte warten genau auf diesen Zeitpunkt des Uploads, um ihr Briefchen abzuschicken
Ist der "Oberleecher" schneller als der Anwalt, kann das Briefchen durchaus den falschen Nutzer treffen.

 

[Peter_Lehmann]

Fazit: Man "braucht" dass, wenn man nicht ganz saubere Aktionen vor hat.
Nun, das KONNTE ich nicht wissen, denn als jemand, der seine letzten fast 30 Arbeitsjahre im Bereich der IT-Sicherheit verbracht hat, der kennt die digitalen Schleimspuren und produziert davon nicht mehr als nötig. Sprich: er vermeidet derartige Aktionen. Und einen spürbaren Nachteil habe ich dabei auch noch nie gehabt.

@eisbärin:
Wir haben beide den gleichen Provider (ich schon seit Zeiten, wo er noch "Puretec" hieß.)
Und wie du vlt. im 1&1-Kundenforum mitbekommen hast, bin ich nicht immer einer Meinung mit deren "BWL-ern" und mosere auch manchmal höflich vor mich hin. Egal, ob es sich um sichere Anmeldung am Portal, das Hinterfragen des sinnfreien google-Bilderrätsels oder das unkommentierte Entfernen wichtiger Features im CC betrifft, Fragen nach der PW-Sicherheit, warum noch immer keine 2FA oder FIDO2 usw. Ich habe auch schon nach der Sinnhaftigkeit dieser unzeitgemäßen Zwangstrennung gefragt - und ich werde das immer wieder tun. Auch mit dem bewussten Haken für die Weiterleitung an den Support.
Jeder Tropfen (hier: Mitmacher) höhlt den Stein.
NEIN, dass soll hier keinesfalls die Aufforderung zum Zwergenaufstand sein! Pfui, wer so was denkt.

MfG Peter

 

[PeterPawn]

In gewisser Weise führen die Provider auf diese Weise aber auch selbst eine Vorratsdatenspeicherung (VDS) durch die Hintertür ein, die - in "roher" Gesetzesform - bisher vorm BVerfG immer gescheitert ist, wenn es um die anlaß- und unterschiedslose Speicherung von (Verkehrs-)Daten ging, wo dann IP-Adressen und Zeiträume der Zuteilung über lange Zeit bei den Providern gespeichert werden sollten (sechs Monate sind der feuchte Traum der EU im Moment, wenn ich nichts verpaßt habe - aber auch der EuGH spielt da nicht so ohne weiteres mit), damit sie auch noch nach Monaten "zur Strafverfolgung" abgerufen werden konnten. Im Moment ist m.W. die Vorratsdatenspeicherung nach einem BVerfG-Urteil gerade mal wieder ausgesetzt - ob man sich daran hält oder nicht, kann ohnehin kein Kunde kontrollieren.

Ändert sich aber die IP-Adresse eines Kunden ohnehin über diesen Zeitraum von sechs Monaten nicht, braucht es diese Speicherung gar nicht mehr - man kann dann auch noch nach Monaten/Jahren "nachverfolgen", wer diese Adresse hat(te).

Auf der einen Seite heulen die Strafverfolger schon seit Jahren herum, daß sie ohne die Vorratsdatenspeicherung gar nicht mehr in der Lage wären, irgendwelche Dinge aufzuklären - auf der anderen Seite liegen/lagen dafür auch Vorschläge wie ein "quick freeze" auf dem Tisch, bei denen (bei begründetem, zeitnahem Verdacht) dann diese Informationen beim Provider anlaßbezogen und auf wenige Anschlüsse begrenzt auch für längere Zeit gespeichert werden sollten, aber eben nicht für alle Kunden und praktisch "für immer". Die VDS ist auch nicht mit der Überwachung der Telekommunikation zu verwechseln, die dann eben auch wieder anlaßbezogen (und üblicherweise auch erst nach entsprechender Genehmigung nach §100a StPO) erfolgen sollte und gerade nicht die Daten "aller Bürger" umfaßt.

Zwar wird an dieser Stelle dann immer wieder argumentiert, daß das doch alles nur zum Besten der Bevölkerung wäre, weil man damit nur "die Bösen" fangen wolle (und der rechtschaffende Bürger hat ja ohnehin nichts zu verbergen) - aber die Realität sieht eben wieder deutlich anders aus und es zeigt sich immer wieder (angefangen bei den Maut-Brücken bis hin zu den Gastronomie-Listen zur Kontaktnachverfolgung im Rahmen der COVID-19-Maßnahmen und eigentlich gehört da auch die NSA-Überwachung und das, was wir von E. Snowden darüber erfahren haben, dazu), daß sich da, wo ein Trog ist (und es Daten abzugreifen gibt), auch immer wieder die Schweine sammeln und solche Datensammlungen praktisch nie nur für die Zwecke genutzt werden, für die sie (angeblich) mal eingerichtet wurden.

Zwar wird dann auch immer wieder die Kriminalitätsbekämpfung als Grund dafür angeführt, warum das unbedingt so sein müsse und Kritiker dieser Vorgehensweise werden dann gerne mit Verweis auf Kinderpornographie "mundtot" gemacht (Ach, Du bist dagegen, daß diese Leute gefunden und bestraft werden können?), aber es gibt - sicherlich je nach eigenem Standpunkt - eben auch sehr gute Gründe bei denjenigen, die sich gegen diese Art der Datenspeicherung (bisher auch immer wieder erfolgreich) zur Wehr setzen, wenn dann die Regierung (hier in erster Linie das Innen-, Justiz- und das Wirtschaftsministerium) mal wieder ein Gesetz an dieser Stelle auf den Weg gebracht hat, bei dem praktisch schon bei seiner Verabschiedung klar war, daß es (zumindest in Teilen) gegen das Grundgesetz verstößt und von BVerfG wieder kassiert wird. Aber da gibt's dann auch immer wieder "Übergangsfristen", bis so ein Gesetz ganz offiziell nicht mehr "exekutiert" werden darf ... und in dieser Zeit kann man sich ja das nächste einfallen lassen, was ebenso gegen das GG verstößt.

Gegen solche Vorhaben kann man eben auch immer erst dann vorgehen, wenn das Gesetz tatsächlich in Kraft getreten ist - daher sind die Kritiker praktisch immer "hinten dran" und da solche Klagen vor dem BVerfG auch immer ihre Zeit brauchen, betrügen sich die deutschen Regierungen (da ist es auch einigermaßen egal, wer daran jeweils beteiligt war - allen Parteiprogrammen und dort ostentativ verkündeten Absichten zum Trotz) schon seit Jahren (im Prinzip seit dem "Otto-Katalog" - https://de.wikipedia.org/wiki/Otto_Schily - auch wenn beim ersten VDS-Versuch schon Schäuble unter einer GroKo im Innenministerium saß) von Gesetz zu Gesetz und "scheißen" dabei auch darauf, ob sich diese Regelungen nun mit dem GG vertragen oder nicht. Ich kann mich jedenfalls an praktisch kein Urteil erinnern, wo das BVerfG eines der Gesetze in diesem Kontext als vollständig konform (mit dem vorhandenen Grundgesetz) eingeschätzt hätte.

Wer sich damit wirklich mal eingehender befassen will, findet auch die Argumentationen der Gegner - ebenso wie die Nachrichten, daß bestimmte Politiker es eben nicht lassen können, immer wieder gegen die Urteile zum Schutz der Bürger anzugehen ... denen mittlerweile ja nur noch das BVerfG dafür bleibt, weil es eben keine Sau mehr stört, wenn ein Gesetz schon bei seiner Verabschiedung als problematisch eingeschätzt wird, selbst wenn diese Einschätzung vom (i.d.R. unparteiischen, zumindest beim idealisierten Bild, das man von ihm hat) wissenschaftlichen Dienst des Bundestages stammen sollte. Ich empfehle in solchen Fällen immer "Digitalcourage e.V." (https://digitalcourage.de/) oder auch "netzpolitik.org e.V." (https://netzpolitik.org/), wo man auch "themenbezogen" nachlesen kann (https://netzpolitik.org/?s=Vorratsdatenspeicherung).

Fakt ist jedenfalls, daß verschiedene Provider das schon länger so praktizieren (zum Kabelanschluß bei Vodafone/VFKD und deren Umgang mit IPv6-Adressen hatte ich mal etwas hier geschrieben und mittlerweile gilt dort dasselbe wohl auch für die IPv4-Adressen) und für die Kunden damit eben diese von mir postulierte "VDS durch die Hintertür" schon länger existiert. Ob das jetzt tatsächlich Teil einer großen politischen Verschwörung ist oder nicht, mögen die VTler entscheiden - es wäre aber sicherlich auch nicht das erste Mal, daß es irgendwelche "Branchentreffen" mit entsprechenden Vereinbarungen mit der Regierung gab, in deren Folge dann Veränderungen in Gang gesetzt wurden. Angesichts des (glücklicherweise) weiter zunehmenden Einsatzes von Verschlüsselung wird der Zugriff auf die Inhalte der Kommunikation schwieriger - umso mehr gewinnen die "Meta-Daten" (wer hat wann und mit wem kommuniziert) an Bedeutung und wenn man auch nach einem Jahr mit den IP-Adressen eines (irgendwann mal aufgezeichneten IP-Pakets) nachvollziehen kann, worum es da ging (bzw. um wen), dann sind damit - eben auch nach Jahren noch und dem Bürger bleibt als Gegenwehr fast nur noch der regelmäßige Wechsel des Providers - ganz schnell "Netzpläne" der gesamten Kommunikation zwischen Leuten erstellt ... und dabei ist der "gläserne Bürger" für die Exekutive dann auch nur noch ein Teilaspekt eines "Problems".

Denn der andere Punkt ist der Verlust der Privatsphäre - wenn bei mir als Betreiber irgendeines Dienstes im Internet jemand mit einer IP-Adresse aufschlägt, die ich einem bestimmten Provider zuordnen kann (dafür gibt es ja heute auch passende Datenbanken) und ich weiß, daß dieser Provider dem Kunden praktisch eine "feste IP-Adresse" zuweist, dann kann ich diesen Kunden (mit hinreichender Genauigkeit, die um Größenordnungen treffsicherer ist, als alle Spam-Mails zusammen) auch jederzeit wieder identifizieren (zumindest den Anschluß) ... und dazu brauche ich dann weder Cookies, noch sonst irgendeinen Mechanismus, bei dem die Politik sich immer wieder um "besseren Schutz der Bürger" bemüht und dabei den technischen Aspekten/Möglichkeiten doch immer wieder nur hinterher hechelt. Was bringen mir die ganzen Einstellungen zur Privatsphäre in den Browsern, wenn ein Server-Betreiber mich ganz einfach anhand meiner IP-Adresse(n) auch über einen längeren Zeitraum verfolgen (also "tracken") kann?

Ganz so einfach, daß der "rechtschaffene Bürger" damit doch eigentlich gar kein Problem haben sollte, ist es also (zumindest in meinen Augen) auch wieder nicht. Daß jemand, der einen Service (für andere) im Internet betreiben will, mit einer solchen festen Adresse "besser fährt", ist vollkommen klar und so jemand mag das dann auch begrüßen. Aber schon für die "private Nutzung" solcher Serverdienste (auch auf einer FRITZ!Box) hat sich - damals sicherlich eher der Not gehorchend, denn unter dem Datenschutz-Aspekt als Tugend - ein Verfahren entwickelt, mit dem man auch einen Host mit dynamischen IP-Adressen im Internet auffinden kann.

Von all den anderen möglichen Problemen mal vollkommen abgesehen ... wenn ich bei mir einen Service betreibe und der auf einem bestimmten Port meiner FRITZ!Box erreichbar ist, dann kann ich - bei wechselnden IP-Adressen, solange der Angreifer meinen DynDNS-Namen nicht auch noch kennt - einem (D)DoS-Angriff auf diesen Service auch einfach dadurch entgehen, daß ich die IP-Adresse wechsele (wechseln lasse) - das kann man bei 1&1 nun offensichtlich auch knicken.

AVM macht hier - nur mal so nebenbei - auch tatsächlich schon sehr viel richtig, wenn es um die "Wahrung" des Datengeheimnisses geht ... auch wenn der dabei eingeschlagene Weg schon etwas krude erscheint. Denn es ist natürlich tatsächlich auch ein Problem, wenn eine FRITZ!Box beim TLS-Zugriff mit der IP-Adresse auf ihren Fernwartungsport (und bitte nicht wieder: "Das benutzt man ja auch nicht freiwillig.", denn es gibt auch gute Gründe, die dafür sprechen können - selbst die hartnäckigsten Verweigerer sollen das schon das eine oder andere Mal benutzt haben), wo der "Angreifer" also offensichtlich noch keinen Schimmer hat, welchen "Namen" die Box denn hat und wie er sie nach einem Adresswechsel im Internet wiederfinden könnte, wenn er doch schon so viel Zeit darauf verwandt hat, den HTTPS-Port per Scan zu finden, den dann gleich (unabhängig vom SNI-Header des Requests) im Zertifikat selbst verkündet.

So generiert man einfach ein selbstsigniertes Zertifikat, das sich nur auf die IP-Adresse bezieht und präsentiert das dann bei allen Zugriffen (außer es gibt ein LE-Zertifikat und der Request enthält ohnehin schon die MyFRITZ!-Adresse). Das entwertet zwar praktisch jede Sicherheit beim TLS-Zugriff (weil die Box mit dem Wechsel der IP-Adresse dann auch das nächste Zertifikat generiert - insofern hilft hier das Verhalten der Provider sogar wieder der AVM-Implementierung), aber es wird wenigstens verhindert, dem Angreifer (oder auch nur dem "data harvester") auch noch die DynDNS-Domain auf die Nase zu binden. Jetzt mault zwar jeder Browser herum (solange der das Zertifikat beurteilt und nicht nur den darin beglaubigten öffentlichen Schlüssel, wie das die AVM-Apps selbst machen), aber das betrifft AVM ja nicht.

 

[eisbaerin]

das kann man bei 1&1 nun offensichtlich auch knicken.

Noch nicht ganz.
2 andere Bekannte haben noch die 92.x IP und bekommen jeden Tag eine neue IP.
Und einer hat zwar auch seit dem 30.9. die 94.x IP, hat aber (bis auf heute) auch jeden Tag eine neue IP bekommen.

Ich hatte mich aber auch schon bei einem Freund der bei O² ist gewundert, daß er seit dem 1.9. keine neue IP mehr bekommt. Hatte ich hier im Forum schon mal irgendwo erwähnt.

Ich werde beobachten und berichten.

 

[PeterPawn]

Ich habe das hier in Berlin jedenfalls auch schon beobachtet.

Ich verwende DynDNS-Anmeldungen, um auf meinen Servern dafür zu sorgen, daß "bekannte Anschlüsse" auch dann nicht von Firewall-Einstellungen blockiert werden, wenn sie gegen "Bestimmungen" verstoßen haben, die üblicherweise dazu führen, daß man von solchen Adressen erst mal die nächsten 60 Minuten keine weiteren Zugriffe starten könnte (so eine Art "fail2ban", das ich mir selbst gebaut habe).

Damit da nicht schon ein Vertippen bei der Anmeldung am IMAP-Server dazu führt, daß alle Dienste nicht mehr erreichbar sind (weil ich dann ganz rigoros auch wirklich jeden weiteren Zugriff unterbinde), gibt es eben diese DynDNS-Anmeldungen (was die FRITZ!Box auch ganz gut auf die Reihe kriegt), die dann dazu führen, daß für diese Anschlüsse bestimmte Ports/Dienste freigeschaltet werden (u.a. ein Asterisk, wo ich "Scans" eben auch dadurch entgehe, daß nur diese per DynDNS angemeldeten Adressen überhaupt einen offenen SIP-Port vorfinden).

Diese Freigaben werden alle 15 Minuten anhand der Angaben in der Datenbank "aufgefrischt", so daß nach einem Adresswechsel auch ziemlich schnell die alten Adressen verfallen - sofern sich die FRITZ!Box von der neuen Adresse angemeldet hat (was dann die Freigaben auch umgehend für die neue Adresse einrichtet ... irgendwann innerhalb der nächsten 15 Minuten sind die alten dann auch Geschichte). Solange die Reverse-Auflösung beim entsprechenden Provider klappt, wird bei der DynDNS-Aktualisierung sogar noch geprüft, ob die Adresse tatsächlich zum Netz des Providers (und nicht nach China oder Nigeria oder wo auch immer) gehört - leider vernachlässigen viele Provider diese PTR-Records aber auch.

Damit das so funktioniert, muß man natürlich dafür sorgen, daß die Adressen irgendwann auch mal verfallen, wenn sie nicht erneuert werden - meinetwegen weil eine FRITZ!Box defekt ist oder ein Anschluß weggefallen ist. Dazu gibt es in der Datenbank mit den Accounts auch eine "Verfallszeit" für eine solche Anmeldung ... und bei den Anschlüssen mit der "Zwangstrennung" funktionierte das bisher auch immer, wenn da nur 25 Stunden eingestellt waren, weil man sich praktisch darauf verlassen konnte, daß die Adresse nach der Zwangstrennung auch eine andere war.

Nur gilt das eben nicht länger (auch an einem 1&1-Anschluß von mir beobachtet), obwohl die Trennung immer noch regelmäßig erfolgt ... und hier fällt einem dann plötzlich auch die "Intelligenz" des DynDNS-Clients in der FRITZ!Box auf die Füße. Der macht nämlich zunächst mal eine DNS-Abfrage für den dynamischen Namen und wenn er feststellt, daß dabei schon die aktuell zugewiesene Adresse zurückkommt, dann aktualisiert der auch den DynDNS-Eintrag nicht. Es gibt zwar auch für solche "Erneuerungen" Parameter in der "ar7.cfg" ("touchtime" und "livedelay", wobei letzteres bestimmt, wie lange mit der Aktualisierung gewartet wird nach dem Wechsel der Adresse), aber die hat AVM (in weiser Voraussicht) auf "0 Wochen" eingestellt und damit deaktiviert.

Da es auch keine Möglichkeit gibt, das für "userdefined" dann irgendwie einzustellen im GUI (in der AVM-Firmware), bleibt hier wieder nur der Weg über die geänderte Export-Datei oder den Shell-Zugriff, wenn man eine "regelmäßige Meldung" der aktuellen Adresse haben möchte - dabei kann man auch gleich (wenn man keinen HTTPS-Zugriff beim DynDNS-Update will, weil der nur mit "benutzerdefiniert" machbar ist) einen eigenen "Provider" einrichten, wo man den Update-Modus (ddnsmode) dann auch noch passend einstellen kann.

Das sind eben alles "Kopfstände", die man mittlerweile machen muß und die aus der geänderten Vorgehensweise der Provider resultieren ... wobei AVM dafür dann tatsächlich mal nichts kann, wenn man vom vergeblichen Versuch des "ddnsd" absieht, da besonders "smart" zu sein oder auf die Frage verzichtet, warum AVM das alles nur mit halbem Herzen angeht und nicht einfach die anderen DynDNS-Parameter (touchtime, livedelay, ddnsmode) auch noch zugänglich macht für den "benutzerdefinierten" Eintrag - von der Möglichkeit, mehr als einen DynDNS-Account (schon aus Redundanz-Gründen) zu konfigurieren (was ja in der "ar7.cfg" problemlos machbar ist, nur fehlt das GUI dafür komplett) mal ganz zu schweigen.

Aber apropo "Intelligenz" bei AVM-Implementierungen und im Angesicht der letzten Firmware-Versionen, die als Kompositionen wohl alle in der Kategorie "Die Unvollendete" landen würden (hier wird es jetzt deutlich OT):

Es gibt da noch genug andere Stellen, wo AVM im Moment in meinen Augen auch nur Unsinn macht, seitdem man die "Spielereien" mit dem GUI entdeckt hat und nun am liebsten wohl auf alle "Standard-Controls" der Browser-Anbieter verzichten möchte. Ich hatte heute erst wieder das Vergnügen, eine (gekaufte) 6660 an einem UM-Anschluß (in Karlsruhe) per Fernwartung einzurichten (schon das Erhalten der IPv4-Adresse war ein Krampf, wobei das wieder nicht auf das AVM-Konto geht), die auch noch eingehendes VPN können sollte. Also frisch ans Werk gemacht und einen Benutzer für diesen VPN-Zugriff eingerichtet. Da es sich um ein Konto handelte, was auf dem (per Teamviewer von mir bedienten) PC verwendet werden sollte, wenn dessen Besitzerin fern der Heimat weilt, wurde auch gleich noch der Shrewsoft-Client von mir (auf dem W10-PC) installiert und die passende Verbindung hinzugefügt.

Dabei war ich in meiner Einfalt tatsächlich der Ansicht, das Fenster mit den Angaben, welche Daten man für die Einrichtung der Verbindung unter iOS oder Android benötigt, würde mir irgendwie dabei behilflich sein können, die Daten per Copy & Paste aus dem Browser-Fenster in die Eingabemaske des Shrewsoft-Clients zu kopieren. Aber Pustekuchen ... AVM war hier (beim Herumspielen) so schlau, daß man in diesem Fenster keinen Text mehr mit der Maus markieren und irgendwie kopieren könnte - da sind wohl diverse Event-Handler am Werk, die das (absichtlich vermutlich eher nicht, das ist für mich einfach nicht "durchdacht" und vermutlich auch nie wirklich von jemandem getestet - es war natürlich auch die aktuelle 07.21 installiert) verhindern - die genaue Ursache habe ich gar nicht erst ermittelt, weil ich so mit dem Fluchen beschäftigt war.

Das macht aber natürlich so richtig Sinn ... gerade bei zufälligen Schlüsseln (ich hatte auch noch 40 Zeichen Zufall generieren lassen) oder bei MyFRITZ!-Namen ist es ja praktisch ausgeschlossen, daß der Benutzer sich vertun könnte und das dann noch mal von vorne beginnen muß. Oder ist auch das am Ende "Feature", weil man so bei den Kunden die Spreu vom Weizen trennt und nur der-/diejenige, der/die das auch unfallfrei "übertragen" kann, es überhaupt verdient hat, per VPN auf die FRITZ!Box zugreifen zu dürfen?

Zu hart als Urteil meinerseits? Ich sehe das mit der "Spielerei" bei AVM tatsächlich einigermaßen unversöhnlich, weil das dabei verwendete JS dann auch Ressourcen auf dem PC des Benutzers frißt und das AVM-GUI ist nun sicherlich nichts, wo man sich wegen des "Benutzererlebnisses" stundenlang herumtreibt und sich von graphischen Gimmicks beeindrucken lassen will. Und komplett weg ist jeder eventuell verbliebene Rest an Verständnis dann, wenn man solche "User-Controls" implementiert und es dann versäumt (oder sogar nicht in der Lage ist), das ordentlich zu testen. Denn dabei kommt dann auch mal so etwas heraus:

Da wurde offenbar das (im HTML-Standard ja durchaus vorhandene und damit in der überwiegenden Anzahl von Browsern auch "out of the box" unterstützte) "input"-Control durch eine eigene Version ersetzt, bei der man sich selbst um die Ausgabe des Rahmens (links, schön mit abgerundeten Ecken, damit das ästhetische Empfinden des Kunden gehätschelt wird - wobei man auch das "mögen" muß, um nicht schon deshalb die Contenance zu verlieren) kümmert und das Eingabefeld wohl (vermutlich) auch selbst behandelt (auch hier hatte ich keine Lust, den Fehler zu suchen).

Hier lag das dann jedenfalls halt "haarscharf" daneben mit seinen CSS-Properties (übrigens ein frisch installierter "Firefox" auf dem erwähnten Windows 10, also auch nichts wirklich Exotisches) und damit über dem "OK"-Button, den die meisten Benutzer wohl wählen würden (per Maus-Klick oder auch per Touch-Klick, wenn möglich), um die Eingabe abzuschließen. Blöd nur, wenn man dank der Überlagerung jetzt gar nicht an diesen Button herankommt ... auf einem PC hat man wenigstens noch die Option, das mit der "Enter"-Taste zu beschließen - aber vermutlich auch nur deshalb, weil AVM vergessen hat, diese Taste hier auch noch in irgendeinem Event-Handler abzufangen.

Auch wenn das als "Ausflug" vielleicht nicht in diesen Thread paßt und ich nur über andere AVM-"Fehlfunktionen" beim DynDNS-Client hier gelandet bin, weil eben auch der versucht, "smart" zu sein beim Update und dabei deutlich ins Klo greift für meine Begriffe - ich will deshalb nur keinen neuen Thread aufmachen und wollte das trotzdem irgendwie loswerden:

Ich wäre schwer begeistert, wenn man bei AVM einfach mal wieder auf den Boden käme und an die Stelle irgendwelcher (vermeintlich "smarten") Automatismen bei Funktionen (spez. Mesh- und WLAN-Verwaltung, bis hin zur Kanalbreite, Radar-Erkennung und Steering) und Spielereien im GUI die "alten Tugenden" setzen würde, die sich in einer funktionierenden und benutzbaren Firmware manifestier(t)en. Das, was da zur Zeit (insgesamt in der "Außenwirkung") abgeliefert wird, ist für mich deutlich unterhalb der Gürtellinie - bei allem Verständnis dafür, daß neue Funktionen eben Zeit "zum Reifen" brauchen.

Dann muß man ihnen die eben auch mal geben und nicht in der nächsten Version dann das aus der vorhergehenden schon wieder komplett auf den Kopf stellen - das gilt auch und gerade im Hinblick auf die "Interna" der Lua- und Javascript-Implementierung(en), denn da bleibt von Version zu Version seit einiger Zeit schon kein Stein mehr auf dem anderen und anstatt einfach mal die Fehler in einer vorhergehenden Implementierung (bis zum Ende) zu beheben, springt man hier bei AVM einfach zur nächsten und hofft vermutlich, daß die dann irgendwie automatisch keines der älteren Probleme mehr haben würde.