[Problem] wget: error getting response: Connection reset by peer

axleu

Neuer User
Mitglied seit
13 Nov 2011
Beiträge
33
Punkte für Reaktionen
0
Punkte
6
Hallo zusammen,

ich habe folgendes Problem:

Im auf Basis des lezten freetz-ng Stand(FritzOS 7.28 Fritzbox 7490) gebauten Image gibt wget diese Fehlermeldung aus, egal welche Serveradresse ich eingebe. Update der addhole Server-Blocklist funzt somit auch nicht;-(
[email protected]:~# wget http://winhelp2002.mvps.org/hosts.txt
Connecting to winhelp2002.mvps.org (198.187.28.133:80)
Connecting to winhelp2002.mvps.org (198.187.28.133:443)
wget: error getting response: Connection reset by peer
[email protected]:~#
Hat einer eine Idee was hier schief läuft.
Mit 7.21 ging ´s noch ohne probleme.
Meine .config mit der ich das Image gebaut habe, ist angehängt.

Danke im Voraus

Axleu
 

Anhänge

  • .config.txt
    99.3 KB · Aufrufe: 1

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,983
Punkte für Reaktionen
26
Punkte
48

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,983
Punkte für Reaktionen
26
Punkte
48

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,983
Punkte für Reaktionen
26
Punkte
48

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,983
Punkte für Reaktionen
26
Punkte
48
Evtl. liegt es am busybox-wget. Wenn wget die Option "verbose" kennt, dann mal mit:
Code:
wget -v https://winhelp2002.mvps.org/hosts.txt
probieren.

EDIT:

Hier funktioniert es mit dem wget aus der bb:
Code:
:~ $ /bin/busybox wget -S -c https://winhelp2002.mvps.org/hosts.txt
Connecting to winhelp2002.mvps.org (198.187.28.133:443)
  HTTP/1.1 200 OK
  Content-Type: text/plain
  Last-Modified: Sat, 06 Mar 2021 11:41:27 GMT
  Accept-Ranges: bytes
  ETag: "f01cbea47d12d71:0"
  Server: Microsoft-IIS/10.0
  X-Powered-By: ASP.NET
  Strict-Transport-Security: max-age=3600
  Date: Sat, 28 Aug 2021 09:13:41 GMT
  Connection: close
  Content-Length: 334861
  
hosts.txt            100% |**************************************************************************|  327k  0:00:00 ETA
Code:
:~ $ file hosts.txt
hosts.txt: ASCII text, with CRLF line terminators
 
Zuletzt bearbeitet:

axleu

Neuer User
Mitglied seit
13 Nov 2011
Beiträge
33
Punkte für Reaktionen
0
Punkte
6
nein geht auch nicht
[email protected]:/# wget -S -c https://winhelp2002.mvps.org/hosts.txt
Connecting to winhelp2002.mvps.org (198.187.28.133:443)
wget: error getting response: Connection reset by peer
[email protected]:/#
wie gesagt bei einem ältern Freetz image von mir gebaut funzt alles out of the box (7490_07.21.all_freetz-ng-17601M-efc33efbd_20201224-091841.image)
seit 7.27/7.28 nicht mehr. eventuell liegt der Problem schon beim erstellen des Images vor?

Kann mal einer mit meiner .config ein Image erstellen(siehe oben #1), und den Fehler verifizieren?!
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,120
Punkte für Reaktionen
1,343
Punkte
113
Das sieht eher nach einem TLS-Problem aus ... der .config nach ist openssl auch im Image (sogar statisch gelinkt, Platz war/ist hier also kein Punkt) und daher würde ich das mal mit dem s_client-Modul des openssl-Kommandos versuchen. Da kann man dann wunderbar alle notwendigen Optionen angeben (viele vergessen gerne mal -servername, was dann keinen SNI-Header sendet und auch zum Abbruch führen könnte bei einem Host mit vielen virtuellen Servern - wobei das BusyBox-wget eine SNI sendet und der Server ist ja offensichtlich ein IIS 10 von MS) und dann sieht man zumindest schon mal, ob die TLS-Verbindung überhaupt bis zum Lesen zu tunnelnder Daten kommt (wo man dann auch noch ein HTTP-GET von Hand eingeben könnte: GET /hosts.txt HTTP/1.0, gefolgt von 2x Enter-Taste) oder ob die schon vorher geschlossen wird - zum Beispiel, weil man keine gemeinsame Basis bei den zu verwendenden TLS-Standards findet.

EDIT:
Wenn man tatsächlich versuchen wollte, die gesuchte Datei per manuellem GET-Kommando von DIESEM Server zu laden, muß man vermutlich doch umfangreichere Header verwenden - zumindest einen passenden Host-Header, denn offensichtlich beherbergt dieser Server mehr als eine Präsenz und da braucht's dann diesen Header, um den richtigen davon auszuwählen (die SNI erleichtert nur die Auswahl des passenden Zertifikats, wenn der Server über mehrere verfügt).

Da dieser Server offenbar nur max. TLS 1.2 beherrscht, wird meine Vermutung - abhängig von der Konfiguration der OpenSLL-Libraries, die von Freetz-NG verwendet wird, denn beim (internen) Aufruf aus wget (der Busybox) werden da keine weiteren Angaben gemacht - wahrscheinlicher, falls die Libs/das CLI-Programm nur noch TLS 1.3 akzeptieren/anbieten sollten, sofern nichts anderes per Parameter/Option festgelegt wurde. Zwar ist TLS 1.2 (afaik) offiziell noch nicht "deprecated" (https://datatracker.ietf.org/doc/rfc8996/), aber die aktuellen Standardeinstellungen von OpenSSL (wo es ja auch noch unterschiedliche Versionsstränge gibt) und was davon von Freetz(-NG) beim Build wie umgestellt wird, habe ich nicht auf dem Schirm.

Da das BusyBox-Applet aber nur mit einer Pipe nach/von openssl s_client arbeitet und auch noch STDERR ignoriert wird, kann wget da häufig keine präzisen Infos zum Grund eines Fehlers ermitteln und wenn der Server eine TLS-Verbindung wg. irgendwelcher Unstimmigkeiten ablehnt, schließt er üblicherweise auch die darunter liegende TCP-Verbindung (ansonsten werden ja Ressourcen am Server blockiert). Der Grund dafür wurde dann i.d.R. vorher in der TLS-Aushandlung mitgeteilt - nur interessiert sich wget (als Applet) eben nicht für diesen Teil der Kommunikation und sieht damit nur das Resultat. Es hat ja auch Gründe, warum es bei curl (und auch beim "ausgewachsenen" (GNU-)wget) eine ganze Reihe weiterer Parameter zum Konfigurieren von TLS-Verbindungen gibt. Damit will ich nicht unbedingt behaupten, daß es mit curl oder dem "richtigen" wget auch hier funktionieren müsse - aber die sind hinsichtlich der Ursachen eines Problems deutlich aussagefreudiger.
 
Zuletzt bearbeitet:

axleu

Neuer User
Mitglied seit
13 Nov 2011
Beiträge
33
Punkte für Reaktionen
0
Punkte
6
Hallo Peter,

danke für die erschöpfende Ausführungen.

auf die abfrage mit openssl c_client kommt folgendes zurück:
BusyBox v1.33.1 (2021-07-28 10:46:39 UTC) built-in shell (ash)

[email protected]:~# openssl s_client -connect https://winhelp2002.mvps.org
7117952:error:2008F002:lib(32):func(143):reason(2):NA:0:Servname not supported for ai_socktype
connect:errno=2
[email protected]:~#
bzw.
[email protected]:~# openssl s_client -connect https://winhelp2002.mvps.org -showcerts
7117952:error:2008F002:lib(32):func(143):reason(2):NA:0:Servname not supported for ai_socktype
connect:errno=2
[email protected]:~#
komisch finde ich nur, das ich mit keinen server eine wget verbindung aufbauen kann, egal welcher server (auch http://)

normalerweise ging es mit der standard config, sobald man das packet wget ausgewählt hatte, zumindest als die fritz os 7.21 aktuell war,
hat sich seither mit kernel odet biblioteken geändert?
addhole benutzt ja wget im hintergrund zum download der blacklists.
jetzt schaut das beim klicken von "host jetzt herrunterladen "so aus:

Updating Addhole ...

Downloading http://winhelp2002.mvps.org/hosts.txt
wget: error getting response: Connection reset by peer
Downloading https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts;showintro=0
wget: error getting response: Connection reset by peer
Downloading https://adaway.org/hosts.txt
wget: error getting response: Connection reset by peer
Downloading https://www.malwaredomainlist.com/hostslist/hosts.txt
wget: error getting response: Connection reset by peer
Downloading https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/spy.txt
wget: error getting response: Connection reset by peer
Downloading https://someonewhocares.org/hosts/hosts
wget: error getting response: Connection reset by peer
Downloading https://adblock.mahakala.is/
wget: error getting response: Connection reset by peer
Downloading https://v.firebog.net/hosts/static/w3kbl.txt
wget: error getting response: Connection reset by peer
Downloading https://raw.githubusercontent.com/D.../domains/blacklist/adservers-and-trackers.txt
wget: error getting response: Connection reset by peer
Downloading https://raw.githubusercontent.com/nickspaargaren/no-google/master/categories/analytics.txt
wget: error getting response: Connection reset by peer
Downloading https://raw.githubusercontent.com/r-a-y/mobile-hosts/master/AdguardMobileSpyware.txt
wget: error getting response: Connection reset by peer
Downloading https://raw.githubusercontent.com/XionKzn/PiHole-Lists/master/PiHole_HOSTS_Spyware.txt
wget: error getting response: Connection reset by peer
Downloading https://gitlab.com/ZeroDot1/CoinBlockerLists/raw/master/list.txt
wget: error getting response: Connection reset by peer
Downloading https://raw.githubusercontent.com/XionKzn/PiHole-Lists/master/Cerber_Ransomware.txt
wget: error getting response: Connection reset by peer
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,120
Punkte für Reaktionen
1,343
Punkte
113
Das mit dem "auch keine HTTP-Verbindungen" glaube ich erst dann, wenn man auch (durch verbose-Logs) sieht, daß da keine Redirection erfolgt ... beim BusyBox-wget kann man aber zumindest HSTS-Header als Ursache für eine Umschaltung auf TLS ausschließen, afaik. Ich glaube nicht, daß ein einfaches wget http://localhost/index.html tatsächlich nicht funktioniert, denn irgendwo am Anfang war ein HTTP-Versuch zu sehen, der auf HTTPS "umgeleitet" wurde - zumindest sollte man das annehmen, auch wenn da keine ausführlichen Ausgaben zu sehen waren. Auf die Idee, dann einfach HTTPS zu nutzen, sollte so ein BusyBox-Applet jedenfalls nicht von selbst kommen und dann müßte es zuvor eine (korrekte) HTTP-Antwort gegeben haben, die für diesen zweiten Versuch mit HTTPS verantwortlich war/ist.

Ansonsten würde ich hier erst mal korrekt testen (ja, ich weiß, daß ich die Aufgabe, die richtigen Optionen für den OpenSSL-Aufruf zu ermitteln, Dir selbst überlassen habe - aber mit Absicht), denn die (extra noch von mir erwähnte) Option -servername sehe ich in den Deinen Versuchen gar nicht. Ein korrekter Aufruf (der bei mir auch funktioniert) sollte eher so in etwa aussehen:
openssl s_client -connect winhelp2002.mvps.org:443 -debug -showcerts -msg -servername winhelp2002.mvps.org - aber das verrät einem auch der Aufruf von openssl s_client -help und/oder "DAS Internet". Auf den Fehlercode 2008F002 würde ich jedenfalls noch nichts geben - zumindest nicht als Resultat der oben gezeigten Versuche, das mit OpenSSL direkt zu probieren.

Wenn ich raten sollte (was ich nur sehr ungern mache, wenn es bessere Alternativen gibt und das wäre hier der Fall), könnte sogar noch eine fehlende Certificate-Chain, die dann kein Verifizieren von Zertifikaten zuläßt, das eigentliche Problem sein - oder die Dateien werden an der falschen Stelle gesucht, etc. pp. ... alles ohne entsprechende Tests nicht auszuschließen. Das Einzige, was sicher scheint, ist die Tatsache, daß es so - zumindest bei Dir - nicht funktioniert.

Jetzt kann man versuchen, die Ursache alleine durch Seancen zu ermitteln oder man macht sich - nachdem man weiß, daß es mit wget eben nicht klappt - daran, die Ursache zu ermitteln. Das kann das wget, das openssl-Paket oder irgendetwas ganz anderes sein - das Stück für Stück ausschließen, kannst Du nur selbst. Schon ein Test mit curl oder dem bereits erwähnten GNU-wget (kann man beide einfach bauen und die Binaries dann (alles aber!) in das laufende System kopieren oder man macht sich halt ein neues Image) würde ja zeigen, ob bei denen das Problem auch auftritt oder nicht - das mit dem BusyBox-Applet jetzt für immer neue Server zu probieren, scheint mir wenig zielführend bzw. vielversprechend. Dennoch bleibt für mich der einfachste und aussagekräftigste Test der direkte Versuch mit openssl (das obendrein auch noch bereits vorhanden ist) und wenn nicht einmal der funktioniert, wird der Rest auch nicht klappen, denn die anderen Programme greifen i.d.R. auf dieses Paket zurück (solange man das nicht mit anderen TLS-Stacks bauen läßt zumindest - und das wäre (für mich zumindest) erst der allerallerletzte Test zur Bestätigung, daß das OpenSSL-Paket Schrott ist ... was es - auf anderen Systemen - aber deutlich anders unter Beweis stellt).
 

sf3978

IPPF-Promi
Mitglied seit
2 Dez 2007
Beiträge
7,983
Punkte für Reaktionen
26
Punkte
48
... und dann müßte es zuvor eine (korrekte) HTTP-Antwort gegeben haben, die für diesen zweiten Versuch mit HTTPS verantwortlich war/ist.
Ja, die HTTP-Antwort gibt es:
Code:
:~ $ /bin/busybox wget -S -c http://winhelp2002.mvps.org/hosts.txt
Connecting to winhelp2002.mvps.org (198.187.28.133:80)
  HTTP/1.1 301 Moved Permanently
  Content-Type: text/html; charset=UTF-8
  Location: https://winhelp2002.mvps.org/hosts.txt

Connecting to winhelp2002.mvps.org (198.187.28.133:443)
  HTTP/1.1 200 OK
  Content-Type: text/plain
  Last-Modified: Sat, 06 Mar 2021 11:41:27 GMT
  Accept-Ranges: bytes
  ETag: "f01cbea47d12d71:0"
  Server: Microsoft-IIS/10.0
  X-Powered-By: ASP.NET
  Strict-Transport-Security: max-age=3600
  Date: Sat, 28 Aug 2021 17:25:24 GMT
  Connection: close
  Content-Length: 334861
  
hosts.txt            100% |**************************************************************************|  327k  0:00:00 ETA
 

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via

IPPF im Überblick

Neueste Beiträge

Website-Sponsoren


Kontaktieren Sie uns bei Interesse