Vorweg: bin blutiger Anfänger in allen µP Dingen 🥺 Während der Suche nach einem plötzlichen Fehler in meiner Haussteuerung HomeMatic (deren eigentliche Ursache sich gestern als Software Bug in allen letzten Versionen herausgestellt hat) wollte ich die Zentrale als Ursache ausschließen und einen nagelneuen Raspberry Pi 3B+ dafür aufsetzen. Mit dem Raspberry Pi Imager habe selbst ich das hinbekommen und der Pi meldet sich auch in der Fritzbox mit einer LAN Adresse. Will man den Pi jedoch darüber ansprechen findet Firefox diese Adresse nicht. Mit etwas Mühe habe ich per Netzwerkleitung direkt von der Fritzbox in den Raspberry SSH nachgeschaut und siehe da: sowohl die LAN Adresse als auch eine WLAN sind richtig vergeben. Was kann ich da falsch gemacht haben? Blockiert die FritzBox 7490 evtl.? OS ist 7.61 und wir sind kurz vor Weihnachten mit Installationscode von Telekom auf Vodafone gewechselt.....
Thomas R. schrieb: > Mit dem Raspberry Pi Imager habe selbst ich das hinbekommen und der Pi > meldet sich auch in der Fritzbox mit einer LAN Adresse. Was hast Du denn mit dem Imager draufgeladen? Um mit dem Firefox einen Rechner ansprechen zu können, muss auf diesem ein Webserver laufen (und richtig konfiguriert sein). Daher ist die oben gefragte Information essentiell.
Angehängte Dateien:
-
Raspberry_SD.jpg
180 KB
Der Imager fragt mich Schritt für Schritt ab, auch nach einem Passwort für den SSH Zugang etc. WAS er dann genau installiert: keine Ahnung. Im Anhang ein Screenshot von dem was ich mit einem Windows Rechner auf der SD Karte sehen kann.
Thomas R. schrieb: > Der Imager fragt mich Schritt für Schritt ab, auch nach einem Passwort > für den SSH Zugang etc. Ja, aber solange Du keinen Webserver auf dem Raspberry Pi installierst, kannst Du nicht mit diesem Webserver reden - und das will Firefox.
Harald K. schrieb: > Ja, aber solange Du keinen Webserver auf dem Raspberry Pi installierst, > kannst Du nicht mit diesem Webserver reden - und das will Firefox. Wenn irgendwas auf Port 80 (Standard für HTTP) eines LAN-Teilnehmers antwortet, zeigt das die Fritzbox übrigens an.
Hast du schon mal mit Putty versucht, eine Verbindung zum Raspi aufzubauen? Das sollte immer gehen. Oder auch Ping bietet sich an, Netzwerkteilnehmer zu testen. Die IP kennst du ja.
:
Bearbeitet durch User
Wenn doch der Webserver fehlt? Ich hatte erwartet daß ein originaler Imager der Raspberry Foundation so etwas gleich zu Anfang mit aufspielt? Aber danke für die Hinweise, dann liegt es wohl daran.
Thomas R. schrieb: > Will man den Pi jedoch darüber ansprechen findet Firefox diese Adresse > nicht. Welche Fehlermeldung liefert der Firefox denn? Timeout oder 404? Ich rate mal: Er liefert Timeout. Er sagt damit lediglich, dass unter dieser Adresse kein Webserver antwortet und eine Webseite, also ein Bild zum Anzeigen, liefert. Was für ein Bild erwartest du denn? Selbst wenn der Imager einen Webserver installieren würde, woher kämen denn die anzuzeigenden Webseiten bzw. was sollten die zeigen?
:
Bearbeitet durch User
Firefox sagt nur "Webserver nicht erreichbar" Mittlerweile habe ich die eigentliche Anwendungssoftware aufgespielt und damit antwortet die Homematic GUI unter der Adresse. Mein Fehler: ich hatte erwartet daß zumindest ETWAS als Antwort kommt wenn nur das Basissystem aufgespielt ist. Kann geschlossen werden, danke!
Thomas R. schrieb: > Mein Fehler: ich hatte erwartet daß zumindest ETWAS als Antwort kommt > wenn nur das Basissystem aufgespielt ist. Dann hättest du Ping nehmen müssen oder mit Putty eine Telnet-Session öffnen. Das geht immer.
Vielleicht mit der falschen Sprache angesprochen? Deutsch, statt Englisch? Beim Raspi- Betriebssystem sind die remoten Zugriffe seit einiger Zeit per default gesperrt. Auf der Konsole mit raspberrpi-config musst Du das erst aktivieren.
Nur für später: Ein nmap auf die IP-Adresse zeigt einem was verfügbar ist.
Dieter D. schrieb: > Beim Raspi- Betriebssystem Ohne die Aktivierung erreicht man auch nicht den Webserver von aussen, aber intern ueber lokalhost...
Der Befehl lautet:
1 | sudo raspi-config |
2 | |
3 | Dort unter dem Punkt: |
4 | |
5 | 3 Interface Options Configure connections to peripherals |
6 | |
7 | ───┤ Raspberry Pi Software Configuration Tool (raspi-config) ├──────────┐ |
8 | │ │ |
9 | │ I1 SSH Enable/disable remote command line access using SSH │ |
10 | │ I2 RPi Connect Enable/disable Raspberry Pi Connect │ |
11 | │ I3 VNC Enable/disable graphical remote desktop access │ |
12 | │ I4 SPI Enable/disable automatic loading of SPI kernel module │ |
13 | │ I5 I2C Enable/disable automatic loading of I2C kernel module │ |
14 | │ I6 Serial Port Enable/disable shell messages on the serial connection │ |
15 | │ I7 1-Wire Enable/disable one-wire interface │ |
16 | │ I8 Remote GPIO Enable/disable remote access to GPIO pins |
Helmut -. schrieb: > oder mit Putty eine Telnet-Session > öffnen. Das geht immer. Du meinst, das im Grundzustand des Images ein telnetd gestartet wird? Wird das heutzutage nicht als Sicherheitsproblem angesehen?
Also ich verbinde mich mit meinen RasPis immer über SSH, auf dem Windows-PC aus MobaXTerm heraus. LG, Sebastian
Thomas R. schrieb: > Ich hatte erwartet daß ein originaler Imager der Raspberry Foundation so > etwas gleich zu Anfang mit aufspielt? Warum sollte er? Der aktviviert auch nicht alle möglichen anderen Netzwerkdienste, die auf einem Raspberry Pi laufen könnten - Mailserver, Newsserver, ftp-Server, SMB/CIFS-Server, NFS-Server, DNS-Server, VPN-Server, DHCP-Server etc. pp.
Thomas R. schrieb: > Der Imager fragt mich Schritt für Schritt ab, auch nach einem Passwort > für den SSH Zugang etc. Verzeihung, aber auch wenn ich diesen Imager nicht kenne: nein, das tut er ganz sicher nicht. In Wirklichkeit fragt nach dem Paßwort nicht für den SSH-Zugang, sondern für den Benutzer, den er anlegt, womöglich "root". Das liest sich vielleicht zu pedantisch, ist es aber nicht. Dieses Paßwort gilt nämlich unabhängig davon, wie der Benutzer sich anmeldet: am Terminal oder, wenn die betreffenden Serversoftware eingerichtet ist und läuft, mit einem grafischen Login, oder über das Netzwerk zum Beispiel mit SSH, SCP oder SFTP. Der Raspi kann auf Anfragen aus dem Netzwerk nur antworten, wenn auf dem Raspi die passende Serversoftware läuft und auf dem angesprochenen Port läuft. Die Serversoftware muß die passende sein, damit sie das Protokoll (die Sprache) verstehen und beantworten kann, mit der der Client -- also zum Beispiel Dein Webbrowser -- sie anspricht. Für einen Webbrowser, der HTTP spricht, muß also eine Serversoftware auf dem Raspi laufen, die HTTP-Anfragen verstehen und beantworten kann, solche Software nennt man üblicherweise "Webserver". Das Protokoll HTTP, das Webserver und Webbrowser sich verständigen, wird in der Regel an Port 80 gebunden, die TLS-verschlüsselte Version an Port 443. Es ist aber auch möglich, einen Webserver auf einem anderen Port lauschen zu lassen, der dann aber im Webbrowser spezifiziert werden muß -- aber das würde hier zu weit führen, fürchte ich. Leider ist das, was Helmut -. (dc3yc) sagt, auch nicht richtig. Putty (oder, korrekt: SSH) geht nicht immer, sondern genauso wie beim Webserver nur dann, wenn die passende Serversoftware auf dem RasPi läuft und auf dem betroffenen Port (bei SSH üblicherweise Port 22) auf Verbindungswünsche lauscht. Auch der OpenSSH-Server kann dabei natürlich so konfiguriert werden, daß er auf einem anderen Port lauscht; dieser Port muß dann vom SSH-Client angegeben werden, beim unter Linux üblichen OpenSSH-Client ssh(1) mit dem Parameter "-p", bei den SCP- und SFTP-Clients scp(1) und sftp(1) mit "-P". Selbst wenn die korrekte Serversoftware auf den angesprochenen Ports lauscht, kann die Kommunikation aber noch von einer weiteren Komponente verhindert werden, nämlich einem Firewall. Unter Linux ist immer ein Firewall im Kernel aktiv, ein sogenannter Paketfilter, ohne weitere Konfiguration läßt der aber jeden Datenverkehr normalerweise zu. Nichtsdestotrotz habe ich leider schon Menschen verzweifeln sehen, weil ihre Software völlig korrekt konfiguriert war, aber dennoch keine Verbindungen zustande kamen, weil deren Distributor (Hersteller ihrer Linux-Distribution) standardmäßig den Paketfilter-Firewall aktiviert hatte und der jeden Datenverkehr unterbunden hat.
Rolf schrieb: > Thomas R. schrieb: >> Will man den Pi jedoch darüber ansprechen findet Firefox diese Adresse >> nicht. > > Welche Fehlermeldung liefert der Firefox denn? > Timeout oder 404? > > Ich rate mal: Er liefert Timeout. Er sagt damit lediglich, dass unter > dieser Adresse kein Webserver antwortet Unwahrscheinlich. Wenn der Rechner korrekt konfiguriert ist -- also kein Irrer am Paketfilter herumgeschraubt hat -- dann liefert der IP-Stack des Kernels auf das TCP-SYN-Paket ein TCP-RST-Paket (Reset) zurück, sagt dem Client also klar und eindeutig: "hier lauscht nix, geh weg". Das ist also explizit KEIN "Timeout", sondern ein "Connection refused". Wenn allerdings ein Irrer am Paketfilter herumgeschraubt hat und entweder die Policy der INPUT-Chain oder eine spezifische Regel in dieser Chain auf "DROP" gesetzt hat, weil er Firewalling grundsätzlich nicht verstanden hat, dann wird kein TCP-RST-Paket zurückgeschickt und er Client deshalb nicht benachrichtigt, daß hier keine Verbindung stattfinden kann. Das ist ziemlich dumm, denn die meisten Clients gehen dann davon aus, daß das Paket irgendwo verloren gegangen ist, und versuchen den Verbindungsaufbau noch einige Male. Wenn ein kluger Firewall ausdrücklich keine Kommunikation auf einem bestimmten Port (und womöglich für bestimmte Clients) ablehnen will, kann der Paketfilter so konfiguriert werden (Target REJECT), daß auf Verbindungsversuche ein Fehler über das ICMP-Protokoll zurückgesendet wird, meist vom Typ 3 ("Destination unreachable") mit einem Code wie 9 ("Network administratively prohibted"), 10 ("Host administratively prohibited") oder 13 ("Communication administratively prohibited"). Auch dabei wird der Client korrekt darüber benachrichtigt, daß diese Kommunikation ausdrücklich unerwünscht ist, so daß er keine weiteren Versuche zum Verbindungsaufbau unternehmen wird.
Dieter D. schrieb: > Vielleicht mit der falschen Sprache angesprochen? > Deutsch, statt Englisch? Ehrlich, Dieter... ein bisschen Quatsch sabbeln geht ja noch, aber Anfänger mit solchem Unfug zu verwirren find' ich echt Kacke von Dir.
Ein T. schrieb: > aber Anfänger mit solchem Unfug zu verwirren find'... Dass Du Dich betroffen fuehlst, versteht hier jeder. Denn eindeutig bist Du hier gegenueber dem TO ein Forumsanfaenger. Der TO versteht so kleine Wortspielwitze seit mindestens einem Jahrzehnt.
:
Bearbeitet durch User
Thomas R. schrieb: > Im Anhang ein Screenshot > von dem was ich mit einem Windows Rechner auf der SD Karte sehen kann. Das ist die erste Partition auf dem Stick. Die Zweite kannst Du unter Windows ohne Weiteres nicht sehen. Dort befindet sich das eigentliche System. Thomas R. schrieb: > Wenn doch der Webserver fehlt? Mit der Fritzbox kommunizierst Du oben doch auch per ssh, warum versuchst Du es bei einem (blanken) Pi mit dem Browser? Dieter D. schrieb: > Auf der Konsole mit raspberrpi-config musst Du das erst aktivieren. Dazu reicht es völlig aus, eine leere Datei 'ssh' in der ersten Partition anzulegen. Das geht dann auch wieder mit Windows und man muss nie eine Tastatur und einen Monitor an den Pi anschließen. Dieter D. schrieb: > Der TO versteht so kleine Wortspielwitze seit mindestens einem Jahrzehnt. Wie gut, dass das niemand anders liest, weil alle Foreneinträge automatisch immer nur für eine Person sind. War außerdem nicht witzig. Gruß Jobst
Jobst M. schrieb: > Dazu reicht es völlig aus, eine leere Datei 'ssh' in der ersten > Partition anzulegen. Diese Datei wird beim nächsten Neustart gelöscht. Man muss also nach dem ersten Login SSH dauerhaft aktivieren.
Thomas R. schrieb: > Firefox sagt nur "Webserver nicht erreichbar" Du musst mit F12 den Debugger öffnen, dann auf den Netzwerk Tab und dann due Seite laden. Dort siehst du mehr Details zum Fehler.
Aber warum kann der Firefox das nicht gleich sagen? Die überaus nützlichen Tipps wie "Try again later" kann er ja trotzdem anzeigen. Das ist die blödeste Idee seit der Lokalisierung von Fehlermeldungen.
Bauform B. schrieb: > Aber warum kann der Firefox das nicht gleich sagen? Weil deren Entwickler das offenbar nicht mehr wollen. Auch andere Browser verbergen inzwischen die Details zum Fehler. Das ist halt voll der Microsoft Style.
:
Bearbeitet durch User
Nemopuk schrieb: > Weil deren Entwickler das offenbar nicht mehr wollen. Der Grund liegt darin, dass der Firefox außerhalb localhost per Default nicht mehr http sondern nur noch https akzeptiert, wenn dieses durch ein anerkanntes Zertifikat gegengeprüft werden kann. Das dient zugleich auch Vorbereitung für eine Trennung des Internets von nichterwünschten Inhalten über die Zertifikatshierarchien.
Dieter D. schrieb: > Das dient zugleich auch Vorbereitung für eine Trennung des Internets von > nichterwünschten Inhalten über die Zertifikatshierarchien. Schwurbelei. Oder: "Dieter lügt sich was zusammen".
Angehängte Dateien:
-
enotconn.webp
48 KB
Nemopuk schrieb: > Bauform B. schrieb: >> Aber warum kann der Firefox das nicht gleich sagen? > > Weil deren Entwickler das offenbar nicht mehr wollen. Auch andere > Browser verbergen inzwischen die Details zum Fehler. Also ich seh den Fehler: "Firefox konnte keine Verbindung [...] aufbauen". > Das ist halt voll der Microsoft Style. ?
Firefox lässt sich so konfigurieren, dass nur bestimmte Zertifizierungsstellen (CAs) mit einem bestimmten CoC akzeptiert werden, die nur Seiten streng gemäß dem CoC noch Zertifakte geben, indem Sie entweder den integrierten Zertifikatsspeicher nutzen, oder den Zertifkatsmanager nutzen um welche zu löschen, zu importieren, bzw. zuzuulassen. Harald K. schrieb: > Oder: ... Nö, das stammt aus einer Diskussion zum CoC der Foundation, wie die Zertifikate genutzt werden könnten um das Browswn auf CoC-konforme Inhalte zu beschränken. Aber es gibt ein paar Threads auf Reddit, dass es Probleme mit dem eigenen Zertifikaten bei Zugriffen im LAN gibt. Vielleicht sollte man prüfen, ob man da noch einen Tipp findet, der weiterhilft.
Ein T. schrieb: > Also ich seh den Fehler: "Firefox konnte keine Verbindung [...] > aufbauen" Ja, die Meldung kennen wir alle. Sie sagt nichts konkretes aus. Das ist der Punkt, den Bauform B. kritisiert. > Das ist halt voll der Microsoft Style. ? Microsoft Programme sind schon immer mit schlechten Fehlermeldungen aufgefallen. Man sagt dem User oft nur "irgendwo ist irgendwas schief gelaufen". Damit kann niemand etwas anfangen. In Folge wurde der Spruch "Reboot tut gut" zum Running Gag. Und wenn das nicht hilft kommt als nächstes oft "Hast du schon alles neu installiert"?
:
Bearbeitet durch User
Nemopuk schrieb: > Weil deren Entwickler das offenbar nicht mehr wollen. Auch andere > Browser verbergen inzwischen die Details zum Fehler. > > Das ist halt voll der Microsoft Style. Vielleicht auch, weil Browser nicht nur für Menschen da sind, die sich mit solchen Geschichten auskennen?! Wenn man als Entwickler Fehler suchen will / muss, dann bietet Firefox (und vermutlich auch andere Browser) entsprechende Möglichkeiten, die für den (willentlichen) DAU nicht notwendig sind.
Dieter D. schrieb: > Nö, das stammt aus einer Diskussion zum CoC der Foundation, wie die > Zertifikate genutzt werden könnten um das Browswn auf CoC-konforme > Inhalte zu beschränken. Dieter zündet den Schwurbelturbo. Das wird ja immer schlimmer. Hör auf, solche LÜGEN zu verbreiten.
Nemopuk schrieb: > Microsoft Programme sind schon immer mit schlechten Fehlermeldungen > aufgefallen. Das ist doch Usus, nicht nur bei MS. Ein Hubschrauberpilot hat sich über New York verflogen. Da sieht er auf der Dachterrasse eines Büro-Towers eine Gruppe von Leuten, die offensichtlich Mittagspause machen. Er geht auf 50 Meter runter und fragt über den Bordlautsprecher: "Wo bin ich?" Daraufhin legen die Leute aus Sneakers eine Schrift: "Sie sind in einem Hubschrauber". Denkt der Pilot: "Hm, korrekte, aber unbrauchbare Antwort. Nun weiß ich, wo ich bin, das kann ja nur der Microsoft-Tower sein!"
Nemopuk schrieb: > Ein T. schrieb: >> Also ich seh den Fehler: "Firefox konnte keine Verbindung [...] >> aufbauen" > > Ja, die Meldung kennen wir alle. Sie sagt nichts konkretes aus. Das ist > der Punkt, den Bauform B. kritisiert. Aber mal unter uns: was soll der Feuerfuchs denn da sagen? "...weil auf Deinem RasPi kein Webserver läuft" oder "...weil der Paketfilter keine Verbindung zum Ziel erlaubt" oder ...? Firefox ist ein Webbrowser, keine Glaskugel. Der sieht nur, daß keine Verbindung zustande gekommen ist, und meldet das zurück. >> Das ist halt voll der Microsoft Style. > ? > > Microsoft Programme sind schon immer mit schlechten Fehlermeldungen > aufgefallen. Man sagt dem User oft nur "irgendwo ist irgendwas schief > gelaufen". Damit kann niemand etwas anfangen. Das war jedenfalls früher so, aber ich hatte für meine Windows nutzenden Mitmenschen gehofft, daß sich das geändert hätte... hat es nicht?
Ein T. schrieb: > Der sieht nur, daß keine Verbindung zustande gekommen ist, > und meldet das zurück. Oder "Das Netzwerkkabel des Raspberry Pi steckt nicht richtig drin, und sein WLAN ist gar nicht eingeschaltet."
Harald K. schrieb: > Das wird ja immer schlimmer. Nee, mit Dir wird das immer schlimmer. Es wurde als eine Lösung zur Erreichung eines solchen Ziels diskutiert. Warum ist das für Dich so wichtig, dass es das nicht gab? Oder hast Du Angst, dadurch kommt erst jemand auf so eine Idee oder die KI bringt das als Vorschlag auf die Tapete? Es gibt von vielen Dinge, auch in der IT, wo es Diskussionen gibt, ob das auch für etwas anderes dienlich sein könnte, was einem nicht so gefällt. Man kann Messer ja auch positiv wie auch negativ einsetzen. Dein Krakele hier ist nichts anderes, als wenn jemand behauptet im Netz hätten welche diksutiert mit welchen Messer in der Kantine am Besten abstechen ginge, und du schreist, das wäre rein erfunden. Denke mal, dass sowas zutreffen könnte: Hallo, wir haben ein neues Problem im Browser mit selbst erzeugten Zertifikaten und Schlüsseln für die SSL und SSH Zugriffe, lokal und extern. ....
Rahul D. schrieb: > Oder "Das Netzwerkkabel des Raspberry Pi steckt nicht richtig drin, und > sein WLAN ist gar nicht eingeschaltet." Und das sollte der Webbrowser diagnostizieren? Wie soll er das tun?
Ein T. schrieb: > Der sieht nur, daß keine Verbindung zustande gekommen ist, und meldet > das zurück. Der Browser kann zumindest melden ob es an der Namensauflösung hängt, ob der Server die Verbindung abgelehnt hat, ob das TLS handshake fehlgeschlagen ist (und warum), ob der Request nach erfolgreichem Verbindungsaufbau abgewiesen wurde (und mit welchem HTTP Status und Text), oder welcher Schritt in einen Timeout gelaufen ist. Der Browser könnte auch antesten, ob die Internetanbindung insgesamt ausgefallen ist, und ob wenigstens der Router (z.B. Fritzbox) erreichbar ist. Wie gesagt, früher waren die Fehlermeldungen mal informativer.
Jack V. schrieb: > Und das sollte der Webbrowser diagnostizieren? Wie soll er das tun? Bein Betriebssystem abfragen. Das ist durchaus möglich. Zumindest in den übliczen Konstellationen, die 99,9% aller User haben.
Nemopuk schrieb: > Der Browser kann zumindest melden ob es an der Namensauflösung hängt, > ob der Server die Verbindung abgelehnt hat, ob das TLS handshake > fehlgeschlagen ist (und warum), ob der Request nach erfolgreichem > Verbindungsaufbau abgewiesen wurde (und mit welchem HTTP Status und > Text), oder welcher Schritt in einen Timeout gelaufen ist. Ein guter Teil davon liefert eindeutige Fehlermeldungen, und wer’s genauer braucht, der kann mit F12 weitere Infos anzeigen lassen. Wenn mir mein Browser mitteilt, dass unter der angegebenen Adresse keine Verbindung aufgebaut werden kann, wie im Screenshot, dann heißt das recht eindeutig, dass unter der angegebenen Adresse auf dem angegebenen Port nicht zurückkommt. Warum das so ist, kann ich dann bei Bedarf in Erfahrung bringen. Wenn er mir mitteilt, dass der Server unbekannt ist, dann heißt das recht eindeutig, dass die Namensauflösung fehlgeschlagen ist. Warum das so ist, kann ich dann bei Bedarf in Erfahrung bringen. Wenn er mir einen Zertifikatsfehler meldet, dann ist das ebenfalls recht eindeutig, und ich kann den Grund bei Bedarf in Erfahrung bringen. Wenn […] Ein Browser ist keine Netzwerkdiagnosesoftware – und mal ganz ehrlich: Wenn TE mit einem Webbrowser auf eine von ihm aufgesetzte Maschine verbinden will, auf der er aber keinen Webserver eingerichtet hat, dann würde ihm auch die detaillierteste Fehlermeldung nicht weiterhelfen, weil er sie nicht verstünde.
Nemopuk schrieb: > Der Browser kann zumindest melden ob es an der Namensauflösung hängt, Tut er. Blöd nur, wenn der Name nicht das Problem ist, weil existent, aber der Port 443 nicht reagiert.
Nemopuk schrieb: > Bein Betriebssystem abfragen. Das ist durchaus möglich. Zumindest in den > übliczen Konstellationen, die 99,9% aller User haben. Das ist aber ein Webbrowser und kein Netzwerk-Analysewerkzeug.** Von einem Webbrowser erwarte ich detailliertere Information, sobald die IP Verbindung zum Web-Server etabliert ist und dann etwas schief geht. **Sonst müssen wir das ganze Gelumpe in jedes Netzwerk-fähige Werkzeug einbauen.
Norbert schrieb: > Sonst müssen wir das ganze Gelumpe in jedes Netzwerk-fähige Werkzeug > einbauen. Keine Angst, das kommt. Wenn die KI in den Systemen schon an dieser Stelle mitspielt.
Jack V. schrieb: > und wer’s genauer braucht, der kann mit F12 weitere Infos anzeigen > lassen. Ach was! Wirklich? Da bin ich ja noch gar nicht drauf gekommen. Norbert schrieb: > Das ist aber ein Webbrowser und kein Netzwerk-Analysewerkzeug. Weiss ich, deswegen habe ich auch nur geschrieben, dass es möglich wäre (nachdem Jack danach fragte), nicht dass es getan werden soll.
:
Bearbeitet durch User
Nemopuk schrieb: > Da bin ich ja noch gar nicht drauf gekommen. Wenn man deine Wortmeldungen liest, könnte man allerdings durchaus auf den Gedanken kommen, dass das nun nicht ironisch gemeint ist ;)
Mario M. schrieb: > Diese Datei wird beim nächsten Neustart gelöscht. Korrekt. > Man muss also nach dem ersten Login SSH dauerhaft aktivieren. Musste ich nie machen um dauerhaft darauf zugreifen zu können. Wird die Datei gelöscht, wird diese Einstellung nämlich automatisch ebenfalls vorgenommen. Gruß Jobst
Jobst M. schrieb: > Musste ich nie machen um dauerhaft darauf zugreifen zu können. Aus IT-Sicherheitsgründen müssen bei der Raspi-Software der remote Zugriff per default deaktiviert sein. Aus gleichem Grunde muss beim ersten Start ein Username und Passwort vergeben werden. Beides traf mich beim neuen Raspi 5 aus heiterem Himmel vollkommen unvorbereitet.
Dieter D. schrieb: > Vielleicht mit der falschen Sprache angesprochen? Schwachsinn. Dieter D. schrieb: > Deutsch, statt Englisch? Schwachsinn. Dieter D. schrieb: > Beim Raspi- Betriebssystem sind die remoten Zugriffe seit einiger Zeit > per default gesperrt. Darum geht es nicht. Es geht um Webserver. Dieter D. schrieb: > Auf der Konsole mit raspberrpi-config musst Du das erst aktivieren. Davon gibt es aber auch keinen Webserver. Dieter D. schrieb: > Ohne die Aktivierung erreicht man auch nicht den Webserver von aussen, Es gibt standardmäßig keinen Webserver. Dieter D. schrieb: > aber intern ueber lokalhost... Schwachsinn. Dieter D. schrieb: > Der Befehl lautet: Schwachsinn. Das installiert keinen Dienst, der einen Webserver beinhaltet. Dieter D. schrieb: > Der Grund liegt darin, dass der Firefox außerhalb localhost per Default > nicht mehr http sondern nur noch https akzeptiert, wenn dieses durch ein > anerkanntes Zertifikat gegengeprüft werden kann. Schwachsinn. Dieter D. schrieb: > Das dient zugleich auch Vorbereitung für eine Trennung des Internets von > nichterwünschten Inhalten über die Zertifikatshierarchien. Schwachsinn. Dieter D. schrieb: > Vielleicht sollte man > prüfen, ob man da noch einen Tipp findet, der weiterhilft. Schwachsinn. Dieter D. schrieb: > Aus IT-Sicherheitsgründen müssen bei der Raspi-Software der remote > Zugriff per default deaktiviert sein. Schwachsinn. Erstaunlich viel Bullshit für so ein einfaches Problem mit so einer einfachen Lösung.
:
Bearbeitet durch User
Jack V. schrieb: > dann > würde ihm auch die detaillierteste Fehlermeldung nicht weiterhelfen, > weil er sie nicht verstünde. Die 'Entscheidung' sollte meiner Meinung dann doch ehr die Person vor dem Monitor selbst übernehmen. Jack V. schrieb: > Nemopuk schrieb: >> Da bin ich ja noch gar nicht drauf gekommen. > > Wenn man deine Wortmeldungen liest, könnte man allerdings durchaus auf > den Gedanken kommen, dass das nun nicht ironisch gemeint ist ;) Er hat F12 nur wesentlich früher als Du in einer seiner Wortmeldungen erwähnt, wodurch man auf den Gedanken kommen könnte, dass Du sie nicht einmal gelesen hast. Dieter D. schrieb: > Aus IT-Sicherheitsgründen müssen bei der Raspi-Software der remote > Zugriff per default deaktiviert sein. Schreibt wer vor? Das ist ein Linux, das kann man konfigurieren, wie man will. Ich habe hier einige RasPis mit ssh und default User/Passwort liegen. Ich arbeite seit 30 Jahren mit Linux, vielleicht gehe ich ja auch anders an die Einstellungen heran als für den typischen User vorgesehen ... Gruß Jobst
Sebastian R. schrieb: > Schwachsinn. > Schwachsinn. > Schwachsinn. > Schwachsinn. > Schwachsinn. > Schwachsinn. > Schwachsinn. > Schwachsinn. Hast du ein neues Wort gelernt?
Jobst M. schrieb: > Die 'Entscheidung' sollte meiner Meinung dann doch ehr die Person vor > dem Monitor selbst übernehmen. Ja. Sie kann sich jederzeit dazu entscheiden, die detaillierte Fehlermeldung und zusätzliche Daten anzeigen zu lassen. Das ist ja der Punkt an der Sache: Es ist alles da, von dem behauptet wird, dass es nicht da wäre. Es ist halt einen Tastendruck entfernt. Wenn selbst das jemandem zuviel ist, dann kann man, denke ich, mit einiger Sicherheit davon ausgehen, dass demjenigen die Meldung auch dann nichts gebracht hätte, wäre sie nicht einen Tastendruck entfernt. Ich frage mich eben: Wenn der Jemand auch nicht weiß, dass ein Webbrowser einen Webserver als Gegenseite benötigt, um eine Verbindung aufbauen und etwas anzeigen zu können – welche Fehlermeldung würde ihm dann etwas bringen? Dass unter der angegebenen Adresse kein Webserver erreichbar ist, wurde ihm ja schon mitgeteilt – soll dann da eine lange Liste mit möglichen Ursachen angezeigt werden, oder was ist hier die Forderung? Jobst M. schrieb: > Er hat F12 nur wesentlich früher als Du in einer seiner Wortmeldungen > erwähnt, wodurch man auf den Gedanken kommen könnte, dass Du sie nicht > einmal gelesen hast. Ich weiß, dass er sie erwähnt hat. Deswegen ja mein Unverständnis.
:
Bearbeitet durch User
Nemopuk schrieb: > Hast du ein neues Wort gelernt? Jep. Normalerweise bevorzuge ich "Bullshit", aber das wird auch irgendwann langweilig.
Jack V. schrieb: > Rahul D. schrieb: >> Oder "Das Netzwerkkabel des Raspberry Pi steckt nicht richtig drin, und >> sein WLAN ist gar nicht eingeschaltet." > > Und das sollte der Webbrowser diagnostizieren? Wie soll er das tun? Just darauf wollten vermutlich Rahul und jedenfalls ich hinaus. :-)
Jobst M. schrieb: > Schreibt wer vor? https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/raspberry-pi-os-wird-sicherer "In erster Linie heißt das, den User pi mit dem Passwort raspberry gibt es mit dem neuesten Image nicht mehr. Vielmehr muss man nun, wie bei allen gängigen Betriebssystemen, einen Root- bzw. Administrator-User anzulegen." Zum Beispiel bei Giga gibt es noch Autoren, die das Ende 2024 nocht nicht gemerkt haben. Hinweis: Aus Sicherheitsgründen ist bei Raspberry Pi OS SSH standardmäßig deaktiviert. Die Deaktivierung von SSH per Default ist leicht nachvollziehbar. Durch SSH ist eine Fernwartung und Fernbedingung möglich, die man explizit einschalten sollte, wenn man sie braucht. Das Aktivieren setzt voraus, dass man weiß, was man tut. https://www.elektronik-kompendium.de/sites/raspberry-pi/1906281.htm Die Grundlage hierfür ist der Cyber Resilience Act (CRA). Default Secure Settings: This implies that functionalities like remote access should be disabled by default or require explicit user action to enable, often with strong authentication.
Ein T. schrieb: > Jack V. schrieb: >> Rahul D. schrieb: >>> Oder "Das Netzwerkkabel des Raspberry Pi steckt nicht richtig drin, und >>> sein WLAN ist gar nicht eingeschaltet." >> >> Und das sollte der Webbrowser diagnostizieren? Wie soll er das tun? Er kann sich am Switch anmelden und den Link-Status vom RPi-Port abfragen ;) Ein anderes Beispiel: vom DNS kommt NXDOMAIN. Dann kann er genau das anzeigen und mit einer whois Abfrage rausfinden, ob es vielleicht ein DNS-Problem ist. Und so weiter. Wenn man bedenkt, wie viel SchnickSchnack in so einem Browser eingebaut ist, wäre das Mehraufwand im ppm Bereich. Im Ernst: ich wäre schon zufrieden, wenn er die Fehlermeldungen anzeigen würde, die er gratis vom System bekommt.
Angehängte Dateien:
-
dns-error.webp
47 KB -
enotconn.webp
48 KB -
tls-error.webp
67 KB -
conn_reset.webp
50 KB
Nemopuk schrieb: > Ein T. schrieb: >> Der sieht nur, daß keine Verbindung zustande gekommen ist, und meldet >> das zurück. > > Der Browser kann zumindest melden ob es an der Namensauflösung hängt, > ob der Server die Verbindung abgelehnt hat, ob das TLS handshake > fehlgeschlagen ist (und warum), ob der Request nach erfolgreichem > Verbindungsaufbau abgewiesen wurde (und mit welchem HTTP Status und > Text), oder welcher Schritt in einen Timeout gelaufen ist. Okay, dann schauen wir uns doch einmal genauer an, wie der Webbrowser die von Dir aufgezählten Fehler anzeigt: Fehler bei der Namensauflösung? Browser zeigt "dns-error.webp". Die Verbindungsanfrage wurde abgelehnt? "enotconn.webp". Es ist ein TLS-Fehler aufgetreten? "tls-error.webp". Gegenseite hat Verbindung geschlossen? "conn_reset.webp". Das mit dem Timeout hätte mir jetzt zu lange gedauert. Hier findest Du ein einfaches Testprogramm zum selbst Ausprobieren:
1 | package main |
2 | |
3 | import ( |
4 | "log" |
5 | "time" |
6 | . "net/http" |
7 | ) |
8 | |
9 | func main() {
|
10 | HandleFunc("/",
|
11 | func(w ResponseWriter, r *Request) {
|
12 | time.Sleep(time.Duration(100000) * time.Hour) |
13 | w.Write([]byte("foo"))
|
14 | }, |
15 | ) |
16 | |
17 | log.Fatal(ListenAndServe(":4444", nil))
|
18 | // log.Fatal(ListenAndServeTLS(":4444", "s.crt", "s.key", nil))
|
19 | } |
> Der Browser > könnte auch antesten, ob die Internetanbindung insgesamt ausgefallen > ist, und ob wenigstens der Router (z.B. Fritzbox) erreichbar ist. Bitte korrigiere mich, wenn ich flashc liege, aber ich glaube irgendwie, daß ein Browser kein Werkzeug zur Diagnose von Netzwerkproblemen ist. ;-) > Wie gesagt, früher waren die Fehlermeldungen mal informativer. Leider kann ich mich noch an Benutzer erinnern, die sich über unverständliche und viel zu ausführliche Fehlermeldungen beklagt haben. Und ich befürchte daß das ein Dilemma ist, vor dem jeder Entwickler steht, sobald seine Software in Kontakt mit real existierenden Benutzern kommt.
Sebastian R. schrieb: > Schwachsinn. Leider befürchte ich, daß Deine Worte ebenso wahr wie nutzlos sind. :-(
Dieter D. schrieb: > Der Befehl lautet: Braucht man nicht, wenn man den "Raspberry Pi Imager" verwendet. Das ist eine Art Wizard / Konfigurationsprogramm, mit dem man ein RaspiOS-(ISO-)Image auf eine SD-Karte schreibt. Damit kann man dann auch den SSH-Zugang einschalten (entweder per Password oder public key), die Ländereinstellung ("Deutsch") und die Lokalisierung ("Berlin, Deutschland") vornehmen und den Hostnamen vergeben. Dann wird ein entsprechendes Betriebssystem auf die SD-Karte geschrieben. Einen Webserver muss man händisch einrichten, da man da eine gewisse Auswahl hat (Apache braucht etwas mehr Platz als "lighttpd" oder "nginx"). Dafür gibt es aber auch viele Tutorien für eine erste Konfiguraion. Dieter D. schrieb: > Vielleicht mit der falschen Sprache angesprochen? > Deutsch, statt Englisch? Eher HTTP/HTTPS statt IP / SFTP (SSH).
Thomas R. schrieb: > Kann geschlossen werden, danke! Übrigens, wenn jemand weitergelesen haben sollte, das Problem des TO ist seit dem 14.01.26 gelöst. Aber zurück zu der Regelung vor kurzem waren einige Admins auch überrascht, als eine größere Anwendung als Container geupdated auch nicht ansprechbar war. Gemäß "Good guidelines for Securing docker containers" konform mit dem Cyber Resilience Act (CRA) waren die Fernzugriffe auf die Anwendung per default auf deaktiviert gesetzt worden. Seit dem Update von gestern verhält sich der Firefox auf dem Raspi auch anders und bekomme diese Fehlermeldung: Something went wrong, but don’t fret — let’s give it another shot. ⚠️ Firefox’s Enhanced Tracking Protection (Strict Mode) is known to cause issues on x.com
Dieter D. schrieb: > Firefox’s Enhanced Tracking Protection (Strict Mode) is known to > cause issues on x.com Zensur! Kreisch! Zeter!
Dieter D. schrieb: > Übrigens, wenn jemand weitergelesen haben sollte, das Problem des TO ist > seit dem 14.01.26 gelöst. und nun? Warum schreibst du hier dann noch dein Geschwurbel?
Rahul D. schrieb: > Warum schreibst du hier dann noch dein Geschwurbel? Das ist bei ihm schriftliche Diarrhoe, das muss raus. Da hat er einen enormen Druck aufgebaut. So sieht das aus: https://i.ytimg.com/vi/JTUP1WKjh20/hqdefault.jpg
Ein T. schrieb: > Bitte korrigiere mich, wenn ich flashc liege, aber ich glaube irgendwie, > daß ein Browser kein Werkzeug zur Diagnose von Netzwerkproblemen ist. > ;-) Wie gesagt: ich habe auch nicht gefordert, das ein Webbrowser das tun soll. Ich habenur geschrieben was möglich wäre, weil Jack danach fragte. Zuvor stand die falscge Behauptung im Raum, daß Webbrowser keine hilfreichen Meldungen ausgeben können, selbst wenn sie wollten.
:
Bearbeitet durch User
Nemopuk schrieb: > Ich habenur geschrieben was möglich wäre, weil Jack danach > fragte. Falls du dich darauf beziehst: Jack V. schrieb: > Rahul D. schrieb: >> Oder "Das Netzwerkkabel des Raspberry Pi steckt nicht richtig drin, und >> sein WLAN ist gar nicht eingeschaltet." > > Und das sollte der Webbrowser diagnostizieren? Wie soll er das tun? Könntest du bitte darlegen, wie ein Browser denn erkennen soll, ob das Netzwerkkabel am Pi richtig eingesteckt oder das WLAN nicht eingeschaltet ist? Mit meinem jetzigen Kenntnisstand bin ich mir ziemlich sicher, dass er lediglich erkennen kann, dass das Ziel nicht erreichbar ist (und das meldet er auch genau so zurück). Nicht jedoch, woran es liegt. Nemopuk schrieb: > Zuvor stand die falscge Behauptung im Raum, daß Webbrowser keine > hilfreichen Meldungen ausgeben können, selbst wenn sie wollten. Zumindest FF gibt aus, was er halt mit seinen Informationen kann. Was Googles und Microsofts Spyware an dieser Stelle machen, weiß ich nicht.
Harald K. schrieb: > Zensur! Kreisch! Zeter! Harald, verbreite hier mal keine falschen Neuigkeiten. Das kommt nur von Deiner dejustierten Wahrnehmung.
Dieter D. schrieb: > Thomas R. schrieb: >> Kann geschlossen werden, danke! Übrigens, wenn jemand weitergelesen haben sollte, das Problem des TO wurde am 14.01.26 gelöst. Jack V. schrieb: > Könntest du bitte darlegen, wie ein Browser denn erkennen soll, ob das > Netzwerkkabel am Pi richtig eingesteckt oder das WLAN nicht > eingeschaltet ist? Es gibt verschiedene Fehlermeldungen, die über das Netzwerk und auch von dem Treiber, der mit der HW versuchte seine Pakete lozuwerden. Diese helfen natürlich nur weiter, wenn sie in passende http-Error-Codes umgesetzt werden. https://www.dotcom-monitor.com/wiki/de/knowledge-base/http-status-codes/ https://profitserver.net/de/knowledge-base/codes_http_error/ Die Liste zeigt, dass es eine ganze Menge an Fehlernummern gibt. Die Beispiele von Ein T vom 17.01.26 zeigen einige Textausgaben des Browsers. Der Fehlercode wird nicht ausgegeben. Ohne den Fehlercode mit der Suchmaschine nach Tipps zur Lösung zu suchen, dauert länger.
Wenn kein http-Server läuft, kann kein http-error-code ausgegeben werden.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.