Verbindung über ftp zum AVM Downloadserver

[samuididi600]

Hallo falls ich hier falsch bin bitte in das richtige forum stellen. Ich bekomme einfach keine FTP Verbindung mehr zu ftp.avm.de .Bist vor wenigen Tagen ging immer alles einwandfrei. Hier mal zwei Screen von meiner Einstellung was könnte falsch sein ? Freue mich für jede Hilfe
Grüssle Samuididi600

 

[NDiIPP]

Mir ist es erstmalig am 13.11.2023 aufgefallen, dass bei download.avm.de bzw. ftp.avm.de das FTP-Protokoll nicht mehr unterstützt wird (am 10.10.2023 wurde es noch unterstützt, dazwischen hatte ich nicht per ftp zugegriffen). Nur noch HTTP bzw. HTTPS. Aktuelle Browser unterstützen ja FTP seit einiger Zeit von Haus aus auch nicht mehr, vermutlich scheint man daher seitens AVM FTP nicht mehr unterstützen zu wollen…

 

[samuididi600]

Danke Dir für die schnelle Antwort ,ist mir auch erst seit wenigen Tagen aufgefall das nichts mehr geht, Grüße Samuididi600

 

[FlyingToaster]

Schon wie bei samuididi600 in #1 ergab mein FTP-Zugriffsversuch und mein anschließender Ping keine IP mehr für ftp.avm.de.
Also ist der Host abgeschaltet und Versuche per http(s)://ftp.avm.de sind sinnlos.

 

[PeterPawn]

Also ist der Host abgeschaltet

Erstens war das auch bisher nicht nur ein einziger Host (irgendwo läßt sich bestimmt noch eine ältere DNS-Abfrage nach ftp.avm.de in einem Beitrag hier finden) und zweitens gibt es spätestens seit dem 17.11.2023 (nach dem SOA-Entry für die Domain avm.de zu urteilen) den DNS-Eintrag für ftp.avm.de nicht länger.

Stattdessen wird der DNS-Eintrag für download.avm.de in 10 unterschiedliche IPv6-Adressen und/oder in 11 unterschiedliche IPv4-Adressen aufgelöst und auch alles das, wo seitens AVM eine URL zurückgegeben wird (u.a. auch bei JUIS-Abfragen), verweist mittlerweile wohl auf den DNS-Namen download.avm.de - wer also nicht irgendwelche alten Angaben für Download-Pfade verwendet, sondern die aktuellen Angaben aus dem JUIS, der sollte ohnehin keine Probleme haben oder kriegen.

Ich denke mal, daß für AVM auch die Tatsache eine Rolle gespielt haben dürfte, daß bei der Verwendung des HTTP(S)-Protokolls eben gerade KEINE Wildcard-Suche nach irgendwelchen Download-Files in einem Folder mehr möglich ist (WebDAV gibt es m.W. dort nicht) - zumindest kann ich mir (neben der fehlenden Unterstützung in neueren Browser-Versionen, wobei die dort ja schon länger entfallen ist) das gut vorstellen, daß die ganzen Leute, welche die AVM-Server ständig per FTP mit Wildcard-Suchen "gequält" haben, irgendwann auch den Admins bei AVM mal auf den Sack gegangen sind. Eher verwundert es mich, wie lange man das bei AVM mehr oder weniger stillschweigend hingenommen hat ...

 

[KunterBunter]

(irgendwo läßt sich bestimmt noch eine ältere DNS-Abfrage nach ftp.avm.de in einem Beitrag hier finden)

Zum Beispiel hier von @PeterPawn: AVM-Download-Server

 

[NDiIPP]

BTW:

[…] und auch alles das, wo seitens AVM eine URL zurückgegeben wird (u.a. auch bei JUIS-Abfragen), verweist mittlerweile wohl auf den DNS-Namen download.avm.de

Hatte mich damals schon gefragt, was @cuma/fda77/opto mit folgendem Commit bei Freetz-NG bezwecken wollte:
https://github.com/Freetz-NG/freetz-ng/commit/1a45b1632558e441c0fbbd63f0383e5c33c8fce0

Machte meiner Ansicht nach schon damals keinen Sinn, selbst als ftp.avm.de noch funktionierte…

 

[H´Sishi]

Jedenfalls ist derzeit unter download.avm.de das zu finden, was früher unter ftp.avm.de zu finden war - die Firmwares der Boxen, Repeater und anderer Geräte, sowohl aktuelle als auch EoL / EoS-Geräte sowie der im Laufe der Jahre entstandenen Softwares und Tools.
Es ist also nix verloren, nur der Weg ist minimal anders.

 

[NDiIPP]

Jedenfalls ist derzeit unter download.avm.de das zu finden, was früher unter ftp.avm.de zu finden war

Das war früher auch schon so. Und man konnte früher auch für download.avm.de das FTP Protokoll verwenden. Wie schon erwähnt gab es eigentlich auch keinen Unterschied zwischen download.avm.de und ftp.avm.de.

 

[4WD]

aber download.avm.de geht ja nach wie vor im Browser ... zumindest im FF

 

[H´Sishi]

Weil download.avm.de das http(s)-Protokoll nutzt, während der ursprüngliche ftp.avm.de ein FTP-Server war.
Vorübergehend konnte man auch per http(s) auf ftp.avm.de zugreifen, aber die Adresse wurde inzwischen abgeschaltet.

 

[NDiIPP]

aber download.avm.de geht ja nach wie vor […]

Ja klar, das ist ja nichts neues. Zugriff per HTTP und HTTPS wurde auch schon lange zuvor unterstützt und ist nicht neu. Es wurde lediglich FTP als Protokoll gestrichen inkl. dem Domainname ftp.avm.de (und auch ftp1.avm.de, ftp2.avm.de usw.). Es gibt also nur noch den Domainname download.avm.de (und download1.avm.de, download2.avm.de usw.).

Weil download.avm.de das http(s)-Protokoll nutzt, während der ursprüngliche ftp.avm.de ein FTP-Server war.

Sowohl download.avm.de als auch ftp.avm.de war per FTP, HTTP und HTTPS erreichbar. Es steckten auch jeweils die gleichen Server dahinter (unterteilt wiederum in ftp1.avm.de, ftp2.avm.de, ftp….avm.de, download1.avm.de, download2.avm.de usw.). Es war also letztlich egal man ftp.avm.de oder download.avm.de verwendete, unabhängig davon ob man per ftp, http oder https zugegriffen hatte. Und das war bereits seit ca. 10 Jahren so, also auch nicht nur "vorübergehend".

 

[stronzo46]

Schade, dass es nicht mehr geht. Ich hatte das als Netzwerkordner im Windows immer eingebunden. Mit https kann ja Windows selbst, bzw der Explorer nichts anfangen!

 

[mopedbill]

Hab das mal mit einem https Client auf Port 443 probiert aber die Verbindung wird vom Server abgelehnt :-(
(0x4c9) Der Remotecomputer hat die Netzwerkverbindung abgelehnt.

 

[KunterBunter]

Sehr komisch. Bei mir geht es nämlich.

 

[mopedbill]

Du benutzt ja auch einen Browser und ich rede von einem https-Client (SecureFX).
Mit dem Browser geht das bei mir natürlich auch !

 

[NDiIPP]

Mit wget klappt es:

$ wget https://download.avm.de/fritzbox/fritzbox-7690/deutschland/fritz.os/FRITZ.Box_7690-07.62.image
--2024-10-20 09:14:29--  https://download.avm.de/fritzbox/fritzbox-7690/deutschland/fritz.os/FRITZ.Box_7690-07.62.image
CA-Zertifikat »/etc/ssl/certs/ca-certificates.crt« wurde geladen
Auflösen des Hostnamens download.avm.de (download.avm.de)… 2001:bf0:212::74, 2001:920:197e:400::123, 2001:bf0:212::84,
Verbindungsaufbau zu download.avm.de (download.avm.de)|2001:bf0:212::74|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 42772480 (41M) [application/octet-stream]
Wird in »FRITZ.Box_7690-07.62.image« gespeichert.

FRITZ.Box_7690-07.62.image              100%[============================================================================>]  40,79M  54,7MB/s    in 0,7s

Und mit curl ebenfalls:

$ curl -o=FRITZ.Box_7690-07.62.image https://download.avm.de/fritzbox/fritzbox-7690/deutschland/fritz.os/FRITZ.Box_7690-07.62.image
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 40.7M  100 40.7M    0     0  47.6M      0 --:--:-- --:--:-- --:--:-- 47.6M

Also scheint das Problem eher bei deinem verwendeten https-Client zu liegen…

 

[mopedbill]

Klar liegt das Problem daran! Nur war mein Bestreben dahin einen Https-Client verwenden zu können. Standartmäßig wird dan Port 443 vorgeschlagen und das funktioniert leider nicht!

 

[NDiIPP]

Das sollte auch grundsätzlich kein Problem darstellen. Nutze ja ebenfalls einen https-Client zur regelmäßigen Synchronisation/Abgleich mit dem offiziellen AVM Download-Server. Einen anderen Port verwendet ein Browser, wget oder curl in diesem Fall auch nicht. Der HTTPS-Server von AVM nutzt den Standard-Port 443.

 

[KunterBunter]

ich rede von einem https-Client (SecureFX).

Connection 0xE277000A successfully established to address '[2001:bf0:212::71]:443'.