Lösung: Unable to resolve hostname

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo Himbeer-Fans, Linux-Freaks und Forumsbewohner,

    vor ein paar Wochen habe ich mir ein kleines Programm geschrieben, das still und ressourcenschonend im Hintergrund läuft, ein paar Dateien überwacht und "korrigiert", wenn dadurch die Verbindung zum LAN / Internet verloren geht, weil die Fehlermeldung "Unable to reselve hostname" dazwischen funkt.

    Wenn's mal wieder hakt, behebt das Programm auf Knopfdruck den Fehler - und es läuft wieder - oder es behebt den Fehler automatisch und der Anwender merkt gar nichts, außer dass ein Zähler bei jeder Korrektur hochzählt.

    Version 1: mit GUI:


    Version 2: ohne GUI:

    Das Programm ist in der Programmiersprache Icon geschrieben. Ihr könnt es gern in andere Sprachen übertragen. Aber denkt daran, Eure eigene IP-Adresse einzugeben - nicht meine darin zu lassen.

    Link zum Tutorial, diese Sprache auf dem Raspberry zum Laufen zu bringen: Icon: Teil 1, Tutorial zum Erlernen der Programmiersprache Icon: Installation (EDIT: 08-OKT-2017 Link im alten Forum)

    Link zum Tutorial, Geany zu einer IDE für Icon zu konfigurieren: Programmiersprache Icon, Teil 2: Installation und Konfiguration von Geany (EDIT: 08-OKT-2017 Link im alten Forum)

    Viel Erfolg und beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (8. Oktober 2017 um 12:20)

  • Hm, kannst du bitte den Hintergrund erläutern? :s
    Also, warum bzw. wie es dazu kommt, dass die Situation eintritt, die dein Script erforderlich machen. :-/

    Normalerweise ist ja der DHCP Client als daemon aktiv, so dass ein Restart nicht notwendig erscheint.
    Wenn das Kabel gezogen wird, behält das System die IP Adressen, die es bezogen hat, ja erstmal bei, der dhclient versucht weiterhin, zu connecten, um seine leases zu verlängern...
    Klar, alle Netzverbindungen fallen ab, wenn das Kabel wieder gesteckt wird, sollte aber alles wieder gehen... bzw. die "intelligenteren" Dienste reconnecten und machen weiter...

    ==> jedenfalls ist es bein meinen RPi's so, sowohl per LAN als auch per WLAN..

  • Hallo Zentris,

    google mal nach "raspberry pi unable to resolve hostname" - da erhältst Du zahlreiche Fragen zahlreicher User, die anscheinend Probleme haben - mich betrifft dieses auch gelegentlich mal.

    In englischsprachigen Foren werden als eine von mehreren Ursachen auch Probleme mit der Stromversorgung geäußert. Egal, was jetzt die Ursache ist, der Fehler passiert häufiger als man denkt. Auch gibt es viele User, die einfach nur "Probleme mit dem Internet" oder Nichterreichbarkeit von einzelnen Links schildern, ohne nähere Informationen geben zu können. Fast immer, wenn ich dann

    Code
    ifconfig

    eingegeben habe, wurde keine IP-Adresse angezeigt. Logisch, dann kann nichts funkionieren!

    Dieses Programm behebt nun die Linux-seitigen Ursachen, indem zunächst geprüft wird, ob die Gateway-Adresse und / oder die IP-Adresse verloren gegangen ist. Diese Einträge werden dann in /etc/resolv.conf (Gateway-Adresse) und oder über sudo dhclient eth0 (IP-Adresse des Pi) wieder eingetragen.

    Seit bei mir dieses Programm im Hintergrund läuft, habe ich keinerlei Verbindungsprobleme - der mitlaufende Zähler zeigt mir an, wie häufig das Programm in Aktion getreten ist.

    OK. Das Programm löst Probleme, die man ohne Raspberry Pi nicht hätte - aber auch dazu sind solche Tools gedacht, einfache irgendwelche blöden Probleme zu lösen.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (27. März 2016 um 23:10)

  • Moin Andreas,

    sorry, das Programm löst keine Probleme sondern das Programm "repariert" Symptome.
    Und das ist - zumindest in meiner Welt - etwas, was man niemals zum Regelfall werden lassen darf, weil man dadurch die Probleme erst gar nicht mehr findet.
    Und wenn weitere Symptome ähnlicher/anderer Art an anderer Stelle durch die ja immer noch bestehende Problematik auftauchen, hat man m.E. überhaupt keine Chance, das eigentliche Problem jemals zu finden.

    Eine IP Adresse verschwindet nicht so einfach ... wäre jetzt sein Netz noch nach aussen sichtbar, würde ich mir ernsthaft sorgen machen, statt das Fehlverhalten zu kaschieren :fies: ...
    Mach solche Sachen nicht bei Deinem Chef ... ich zumindest würde Dich, falls es ums Firmennetzwerk geht, standrechtlich erschiessen lassen ...

    cu,
    -ds-

  • Hallo Dreamshader,

    ja, das Programm behebt nur Symptome - der Anwender merkt aber von den Störungen nichts, und kann normal weiter arbeiten.

    Bevor ich dieses Programm eingesetzt habe, ist häufig die Verbindung unterbrochen worden. Da half teilweise weder sudo tee .. nach sudo dhclient ... - da half nur ein Neustart und Hoffnung, dass es danach besser läuft.

    Ich den einschlägigen Foren gibt es zahlreiche User, die dieses Fehlerbild geschildert haben - weitere sollte man dazu zählen, weil deren Fehlerbeschreibung sehr viel Platz für Spekulation bietet. Aber die Auswirkungen sind die gleichen.

    Ich fände es auch besser, die Ursachen für dieses Problem zu kennen - aber irgendwie ist da noch keiner tief genug vorgedrungen. Eine Erklärung (unzureichende Stromversorgung aus einem englischen Forum) mag einleuchtend sein, erklärt aber auch nicht weshalb man an einem Abend drei bis fünf Störungen beobachtet, dann wieder wochenlang gar nichts.

    Ich für meinen Fall halte Probleme mit der Stromversorgung für denkbar - ich wohne oben auf einem Berg, auf den es noch fünf weitere Häuslebauer verschlagen hat. Die Stromleitungen, die Wasser- und Abwasserleitungen sehen aus, wie von Nachbars Auszubildendem (z.B. Bäcker) einstens verlegt. Da kann ich mir auch vorstellen, wenn ein schweres Fahrzeug den Berg hoch- oder herunterdonnert, so manche Leitung Freudensprüge vollführt - und mir die Verbindung nimmt.

    Für mich ist der Fehler "Unable to resolve hostname" noch nicht abgeschlossen - ich würde auch gern die Kernursache kennen.

    Zum Glück bin ich für kein Firmennetzwerk zuständig - Du darfst mich gern noch ein wenig leben lassen.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Ja hey Andreas ...

    Also ich finde, das schreit geradezu nach Hijacking :fies:
    na gut ... Glück gehabt - Du wirst nicht an die virtuelle Wand gestellt ;) ...
    Das Dumme an diesen Workarounds ist halt, dass es dann "ja funktioniert" und niemand der Sache mal nachgeht.

    Ich kenne diesen Effekt nur im WLAN ... nach dem Durchfilzen der Logfiles kam heraus, dass es sich hier wohl ein bekanntes issue handelt.
    Das muss doch zu finden sein.
    Alternative, die ich evtl. noch akzeptieren könnte: den watchdog aktivieren und damit überwachen/rebooten.


    Salve,
    -ds-

  • Hm, wie @dreamshader@ schon schrieb: Symtombehandlung.
    Ist wie: "Schütt mal ab und zu 'n Eimer Wasser auf die glühenden Bremsen, damit die nicht verbrennen" (an die angezogene Handbremse denkt keiner) :lol:

    Ok, also mal Butter bei die Fische, wie man so sagt:
    Was steht denn so in den Log-Files? Also dmsg, messages usw...
    Der Verbindungsabbruch (um einen solchen handelt es sich ja offensichtlich) muss ja eine Ursache haben:

    Stromversorgung (häufig) wäre vielleicht schon mal durch
    * Wechsel des Netzteils
    * temporäre Versorgung aus einem Labornetzteil oder mit einem Akku (+ Spannungsanpassung) zu finden
    * Falls deine Speisespannung (230V) zu instabil ist (du deutest ja sowas an), solltest du eher mal eine stabilere Versorgung ("richtiges" Netzteil) planen (Kauf oder Eigenbau mit ordentlichen Stützkondensatoren/Stützakkus, nahe an einer USV eben)

    Treiberprobleme eventuell auch, aber wenn auch die LAN Verbindung zusammenbricht...

    Kannst du Spannungsdifferenzen auf der LAN-Leitung zwischen den beiden Enden des LAN-Kabels ausschliessen?
    Sowas kann passieren, wenn in einem 3-phasig gespeisten Haushalt die Haushaltssteckdosen auf den Etagen an unterschiedliche Phasen geklemmt sind (was normal ist) und die Erdungs/Nullleiter vom "Bäckerlehrling" verdrahtet wurden :lol:
    (Ich hatte das mal in einem steinaltem Industrie-Altbau noch zu Zeiten von "Yellow Cabel" Verdrahtung, falls das jemandem was sagt ... uns flogen allerdings da alle ca. 6 Wochen die kompletten Netzwerkkarten weg wegen 70 - 110(!)V Spannungsdifferenzen...)

    Dann noch die simple Software an sich:
    Läuft da vielleicht ein Dienst, der meint, alle paar (Stunden/Minuten) das Netzwerk zu rekonfigurieren? WPA-Supplicant ist da so ein Kandidate, falls du WLAN hast... prüf mal, ob der Dienst bei dir läuft... wenn du kein WLAN an hast, sollte der normalerweise nicht da sein....

    Und nochmal: Was steht in den Logs?

    Ach ja: Wegen dem Hijacking: Auf'm Berg?? Och nö, ist mir zu anstrengend... :lol:

  • Hallo Zentris, hallo Dreamshader,

    vielen Dank für Deine Anregungen und Eure Anteilnahme.

    Einerseits gebe ich auch Dir Recht - statt an Symptomen zu arbieten, sollte man die Ursachen beseitigen. Da ich die Ursachen nicht kenne, muss es mir zunächst genügen, mir irgendwie selber zu behelfen, indem eine selbst erstellte Software rechtzeitig den fehlerhaften Zustand erkennt und soweit aktiv wird und nach Möglichkeit den fehlerfreien Zustand wieder herstellt.

    Zitat

    Was steht denn so in den Log-Files? Also dmsg, messages usw...


    Sobald der Fehler mal wieder passiert, stelle ich die Ausgaben von dmesg etc. hier rein

    Zitat

    Stromversorgung (häufig) wäre vielleicht schon mal durch
    * Wechsel des Netzteils
    * temporäre Versorgung aus einem Labornetzteil oder mit einem Akku (+ Spannungsanpassung) zu finden
    * Falls deine Speisespannung (230V) zu instabil ist (du deutest ja sowas an), solltest du eher mal eine stabilere Versorgung ("richtiges" Netzteil) planen (Kauf oder Eigenbau mit ordentlichen Stützkondensatoren/Stützakkus, nahe an einer USV eben)

    Gelegentlich entwickle ich industrielle Anwendungen, die einen RaspberryPi enthalten. Hierbei verbaue ich recht hochwertige Netzteile - auch hier hat sich der Fehler des öfteren ereignet weshalb ich das Netzteil als solches ausschließen kann. Die Anwendungen selber werden dann beim Auftraggeber ohne Netztwerk eingesetzt, weshalb sich der Fehler auch gar nicht mehr erkennen ließe.


    Zitat

    Treiberprobleme eventuell auch, aber wenn auch die LAN Verbindung zusammenbricht...

    Bei Treiberproblemen würde ich eigentlich erwarten, dass eine Fehlermeldung kommt, die auf fehlerhaften Code in Datei xyz hinweist, oder dass eine Datei xyz nicht gefunden wird etc. Oder einfach einen klassischen Absturz.

    Zitat

    Kannst du Spannungsdifferenzen auf der LAN-Leitung zwischen den beiden Enden des LAN-Kabels ausschliessen?

    Nö, aber alle beteiligten Geräte (Raspberry Pi, Monitor, LAN-Switch und Router) sind an die gleiche Steckdose angeschlossen.

    Zitat

    Dann noch die simple Software an sich:


    Keine Cron-Jobs, kein WLAN vorhanden - der Fehler ereignet sich auch vollkommen ohne erkennbare Systematik. Mal direkt nach dem Aufruf von Midori, dann nach Anklicken irgendwelcher Seiten passiert nichts mehr (das "System hängt" - aber eigentlich liegt das hier erörterte Fehlerbild vor) - mal nach einigen Minuten, Stunden oder gar nicht innerhalb von 4 bis 8 Stunden.


    Zitat

    Das Dumme an diesen Workarounds ist halt, dass es dann "ja funktioniert" und niemand der Sache mal nachgeht.

    Ich kenne diesen Effekt nur im WLAN ... nach dem Durchfilzen der Logfiles kam heraus, dass es sich hier wohl ein bekanntes issue handelt.
    Das muss doch zu finden sein.

    Wie gesagt, in den englischsprachigen Foren wird dieser Fehler sehr häufig geschildert - wesahlb auch ich davon ausgehe, dass es sich um einen bekannten Fehler handelt. Was mich wundert: Was veranlasst das System - so mir nix Dir nix - in /etc/resolv.conf die IP-Adresse des Gateway zu entfernen? Oder warum steht mal die IP-Adresse des Raspberry Pi im Ergebnis von ifconfig eth0 - und dann mal nicht.

    Demzufolge muss es irgendeinen noch zu identifizierenden Vorgang geben, der aufgrund irgendeines Ereignisses zu einer programmierten - aber störenden - Handlung führt, möglicherweise in einer Kaskade an Dateifolgen ursprünglich bekannte Informationen zu löschen.

    Und solange ich keine blasse Ahnung davon habe, was da passiert, nutzt das Programm mir mehr als das Betriebssystem - oder die vom "Bäckerlehrling" verlegten Strippen - verhindert.

    Ich habe das Programm um eine Zeile ergänzt:

    Code
    system("dmesg > host-repair.log")

    und teile die Ergebnisse beim nächsten Fehlerereignisses mit.


    Wie der Zufall so will, gerade beim Hochladen dieser Antwort passierte der Fehler erneut. Hier das Ergebnis:

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (31. März 2014 um 20:28)

  • 1. Analyse: (ohne Pistole!) :lol:
    Es scheint, als ob sich der USB Controller aus dem System aushängt.
    Da an dem USB Kontroller auch die Netzwerkinterface hängen, werden die ausgehängt und die Interface runtergefahren (sieht man so im Log).

    Das System erkennt das USB Problem und startet den USB Controller Daemon neu, der connectet (auch) die Netzwerkinterface, die haben alledings keine Daten mehr. Nun müsste eigendlich ein Netzwerk-reconfigure starten, "keiner" tut das ==> Die Interface bleiben unversorgt, die Netzwerk-Connection ist weg.

    Verdacht 1: :angel:
    Du hast eine (PS2 -> USB) Maus dran?
    Wenn ja: möglicher Fehler im Mauskontroller im Zusammenspiel mit dem USB Kontroller. Tausch mal die Maus aus, wenn möglich.

    Verdacht 2: :angel:
    Wie wird der RPi mit Strom versorgt? Per Mini-USB-Buchse, über die Doppel-USB-Buchse aus einem Hub oder per GPIO-Pin? In den Foren werden bisweilen die Kabel zum Mini-USB-Port als "unstable" bezeichnet... was immer das bedeuten soll... Bei einigen hat das austauschen der Kabel geholfen (die hatten allerdings die Fehlernummer 4xx). Könnte natürlich auch ein "kühle" Lötstelle an der Buchse sein...

    hm... :s

  • Hallo Zentris,

    der Fehler hatte sich (häufiger als aktuell) ereignet, als in dem einen USB-Port eine USB-Maus und im anderen eine USB-Tastatur befand.

    Momentan (seit mehreren Monaten) befindet sich (zu Testzwecken) an einem USB-Port ein USB-Adapter (Stecker - Stecker), daran eine USB-Einbaubuchse (Buchse - Buchse), daran ein Y-Kabel (USB auf 2x PS2), daran je ein Adapter PS2 auf USB, und daran die oben erwähnte Tastatur und Maus.

    Die Maus ist von Logitech (Modell nicht identifizierbar) - und verrichtet seit Jahren an diversen PCs ihre Arbeit zuverlässig.

    Die Tastatur ist von MS-Tech (Modell LT-300U). Anfänglich hing auch mal eine große Sherry-Tastatur dran (auch da gab es den bewussten Fehler sporadisch)

    Der Raspberry Pi wird über die Micro-USB-Buchse mit Strom versorgt.

    Mäuse habe ich hier genug - ich hänge mal eine andere dran.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Hallo zusammen,

    nach einer 77-Stunden-Woche musste ich einfach mal wieder beim Programmieren entspannen.

    Ich habe mein Programm HostRepair vorgenommen und bzgl. WLAN erweitert.

    Dabei sind mir ein paar Merkwürdigkeiten aufgefallen. Unter anderem scheinen einige Linux-Kommandos, auf die ich zugreife, ihren Ausgabe-Text geändert zu haben. Darauf habe ich dann auch reagiert.

    Dann ist mir aufgefallen, dass das Programm bei Verbindungsproblemen rund 1 Minute mit

    Code
    sudo dhclient ...

    beschäftigt ist. Diesen Befehl habe ich gleich in den Hintergrund geschickt. Wäre das im März auch so dösig gelaufen, hätte ich's damals auch schon getan.

    Dann habe ich mir überlegt, eine Verbindung, die nicht besteht und auch nicht softwaremäßig repariert werden kann, muss nicht regelmäßig immer wieder betrachtet werden. Dann habe ich zwei Auswahl-Buttons spendiert, die im Fehlerfall deaktivert werden.

    Langer Reder kurzer Sinn: Das Programm ist jetzt um einiges flotter geworden - insbesondere wenn kein LAN-Kabel steckt, der Router ausgeschaltet ist, der WLAN-Stick dann doch nicht existiert, bekommt das Programm das recht schnell mit.

    Zu den Bedienelementen:
    Text-Eingabefeld [font="Courier"]Nameserver[/font]: enthält die IP des Routers / Gateway
    Text-Eingabefeld [font="Courier"]Host IP LAN[/font]: enthält die IP-Adresse des RPI bzgl. LAN (oder eine Meldung)
    Text-Eingabefeld [font="Courier"]HOST IP WLAN[/font]: enthält die IP-Adresse des WLAN-Adapters (oder eine Meldung)
    Falls kein LAN-Anschluss ermittelt wurde oder kein WLAN-Stick gefunden wurde, wird der entsprechende Button deaktiviert.

    Der Button [font="Courier"]Repair[/font] kann gedrückt werden und löst dann einen Programm-Durchlauf aus.

    Die beiden Buttons [font="Courier"]LAN[/font] bzw. [font="Courier"]WLAN[/font] dienen der Auswahl, ob WLAN / LAN-Anschluss geprüft / repariert werden soll.

    Mit dem Rollbalken kann die Zeit zwischen zwei Durchläufen festgelegt werden. Mit dem Rollbalken können Zeiten von 0 bis 60 Sekunden gesetzt werden.

    Mit dem Selektionsfeld kann schließlich festgelegt werden, ob das Programm automatisch aktiv wird (An) und gemäß der eingestellten Zeit prüft und ggf. repariert - oder gar nichts macht und auf ein Ereignis wartet (z.B. Button [font="Courier"]Repair[/font] oder [font="Courier"]Quit[/font] angeklickt). Die anderen Bedienelemente können auch entsprechend bedient werden. Änderungen werden aber erst wirksam, wenn das Programm denn auch in Aktion tritt.

    Der letzte Button ([font="Courier"]Quit[/font]): Hmm, was war das jetzt wieder?

    Na, egal ... viel Spaß damit!

    Andreas

    EDIT (19.03.2015): Enthält Änderungen aus #21

    Dateien

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (19. März 2015 um 12:19)

  • Klasse Sache, tolle Arbeit.
    Hat das Script mal jemand in eine andere Sprache übersetzt? Ich wollte gern eine Lösung für mein Freeze Problem und müsste mich so noch wieder in was neues reinlernen, nur um ein Symptom auszumerzen.... hmpf... Wenn nicht, bleibt mir ja dann nichts anderes übrig...

    ---------------
    Aktuelles Projekt: Steuerung einer Heizungsanlage und eines Reifeschranks für Salami und Schinken mit dem Raspberry Pi, diversen Sensoren und Relais Boards.

  • Hi,

    habe mich durchgewühlt...

    Bekomme beim compilieren deines aktuellen Programms folgende Hinweise:

    Und jedes Mal, wenn ich was mit iconx ausführen möchte kommt

    Code
    pi@BeeHive ~/icon9_51/bin $ iconx host-repair
    -bash: iconx: Kommando nicht gefunden.

    Irgendwie hat er iconx wohl nicht mit installiert, es gab auch Fehler, auch als ich genau nach Anleitung vorgegangen bin.

    Hast du eine Idee?

    Wenn ich mich durch die Anleitung arbeite kommt bei den Make Befehlen sowas hier:

    Code
    collect2: ld returned 1 exit status
    Makefile:32: recipe for target 'iconx' failed
    make[1]: *** [iconx] Error 1
    make[1]: Leaving directory '/home/pi/icon9_51/src/runtime'
    Makefile:63: recipe for target 'Icont' failed
    make: *** [Icont] Error 2

    ... :(

    ---------------
    Aktuelles Projekt: Steuerung einer Heizungsanlage und eines Reifeschranks für Salami und Schinken mit dem Raspberry Pi, diversen Sensoren und Relais Boards.

    Einmal editiert, zuletzt von Dionysios (17. März 2015 um 23:11)

  • Hallo Dionysios,

    diese Fehlermeldung deutet darauf hin, dass Du die Installation der Programmiersprache Icon nicht vollständig durchgeführt hast.

    Denn die Datei ist eine vorcompilierte Datei, die im Quellcode eingebunden wird. Siehe den anderen Thread, in dem Du die gleichen Fehlermeldungen gepostet hast. Alle relevanten Dateien werden innerhalb der normalen Installationsprozedur vorcompiliert. Dieser Schritt wurde nicht durchgeführt.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Ist ja "nur" meine Meinung:

    Ein stabiles LAN/WLAN ist kein Hexenwerk. Wenn auch manchmal etwas mühsam, insbesondere für den sog. noob.

    Dieser immer wieder favorisierte sog. "workaround" in einer ungebräuchlichen Programmiersprache - so ein Unsinn!! Der Einsteiger meint natürlich, es wäre die Ideallösung. In Wirklichkeit werden Fehler favorisiert, die keine sind!

    Sorry, aber nachdem ich es jetzt schon so oft gesehen habe ...

    Wie gesagt - nur meine Meinung!

    Gruß, mmi

  • Hallo Andreas,

    ich muss mich 1000 Mal entschuldigen... ich habe das ganze Zeug von gestern gelöscht und bin ganz frisch nochmal angefangen. Ergebnis: Läuft wie ne Eins!

    mein Fehler: Ich hatte zunächst versucht anhand deiner 1. PDF Anleitung zu installieren und habe dann an den falschen Stellen selbst mitgedacht (z.B. sudo ...) und das gab dann wohl Berechtigungsprobleme.

    Nun lief alles fehlerfrei durch und ich gehe davon aus, dass ich gleich mein gewünschtes Script kompiliert bekomme!

    Danke

    ---------------
    Aktuelles Projekt: Steuerung einer Heizungsanlage und eines Reifeschranks für Salami und Schinken mit dem Raspberry Pi, diversen Sensoren und Relais Boards.

    Einmal editiert, zuletzt von Dionysios (18. März 2015 um 08:15)

  • Hallo mmi,

    es steht jedem frei, den Quellcode in eine "gebräuchlichere" Programmiersprache umzuschreiben, meinetwegen C oder Python.

    Dieses Workaround hat aus meiner Sicht lediglich die Aufgabe gehabt, in Abhängigkeit irgendwelcher Gegebenheiten (Stromversorgung, Auslastung, ...) Informationen zu liefern, inwieweit sich dies auf die Netzwerkstabilität auswirkt. Ergebnis war überwiegend, dass das Hauptproblem eine mangelhafte Stromversorgung war.

    Du hast aber absolut Recht, wenn jemand eine schrottige Netzwerkkonfiguration verwendet, dann hilft alles nichts. Dann nützt auch mein Workaround nicht viel, wenn er beispielsweise melden sollte, dass er am Tag 200mal die Verbindung wieder hergestellt hatte.

    Das Programm ist dann super geeignet, wenn gelegentliche Netzwerkverbindungen verloren gehen, der Anwender dies aber toleriert und der Ursache nicht weiter auf den Grund gehen möchte. Für mich persönlich sind das max. 4 Ausfälle im Monat, die vom Workaround behoben werden. Wenn es mehr werden sollten, würde ich mir auch Gedanken über die Urasachen machen.

    In meinem Fall betreibe ich übrigens alle USB-Verbraucher in einem stabilen aktiven USB-Hub. Seitdem gibt's keinerlei Problemchen mehr.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (27. März 2016 um 23:25)

  • Hallo Dio,

    sag mal, warum postest Du Deine Anfragen immer in zwei Threads?

    Diese Frage habe ich Dir gerade ausführlichst in dem ersten Thread beantwortet, in dem Du diese Frage gestellt hast.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (18. März 2015 um 09:39)

  • Ja, ist mir aufgefallen. Ich habe nach meinem Post gesucht, habe aber vergessen, den anderen Thread zu abonnieren. Als es mir aufgefallen war, hab ich den Doppelpost schnell versucht zu löschen, durfte ich leider nicht.

    Es hängen sehr viel Nerven an diesem Projekt, sorry dafür. War nicht meine Absicht. Ich schätze deine Beiträge hier sehr. Die Lösung ist in Sicht. Ich bleibe dazu jetzt in deinem anderen Thread.

    ---------------
    Aktuelles Projekt: Steuerung einer Heizungsanlage und eines Reifeschranks für Salami und Schinken mit dem Raspberry Pi, diversen Sensoren und Relais Boards.

  • So Andreas, nun ist der Fehler aufgetreten und dein Skript lief.

    Ergebnis siehst du im Anhang. Das Skript konnte den Fehler nicht beheben, sondern gab eine Fehlermeldung.

    Kannst du damit was anfangen?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!