Beiträge von dreamshader

    Hi,
    ich will ja nicht unken, aber wenn es wirklich nur um das triviale Problem des routings zum VPN geht, dann täte es aus meiner Sicht ein simples "route add ip.server.des.vpn gw ip.des.ras.pi" bzw. "route add ip.des.vp.network gw ip.des.ras.pi mask bla.blubb.x.y." auf allen Clients im privaten "Heim-"Netz - zumindest wenn mich meine rudimentären Netzwerk-Kenntnisse nicht im Stich lassen.
    Dadurch läuft sämtlicher traffic bezüglich des VPN über den raspi, der nun seinerseit die Verbindung auf-/abbauen kann, das IP-Forwarding resp. IP-Masquerading usw. falls nötig übernimmt usw.

    Mit DHCP-Servern, ... zu arbeiten, wäre imho mit Spatzen auf Kanonen zu schiessen ...

    Wie gesagt, vorausgesetzt ich hab' das jetzt richtig verstanden ...

    cu,
    -ds-


    Es geht hier nur darum den Rechner den passenden Ausgang aus dem Netz zuzuweisen, ein ganz normales Routingproblem.
    Weil man auf dem AVM-Router wenig einstellen kann macht man das alles auf dem Pi.

    Und ganz nebenbei, wer das da nicht hinbekommt braucht sich keine Cisco/Alcatel/Enterrasys/sonstige Switches/Router ansehen.

    Hmm ...
    wenn es so trivial ist, dann täte es imho doch auch ein stinknormals subnet mit gateway pi ...

    // Edit
    der dann, falls sie nicht steht, die VPN-Verbindung aufbaut
    //

    Wie gesagt - ich glaube ich hab das noch nicht kapiert,
    mea culpa

    -ds-


    Was sollten solche Switches hier können, was der Pi nicht kann?
    Das Problem sind auch keine IP-Adressen die maskiert werden müssten, die kann er so zuweisen wie er sie braucht. Den Rest kann man über passende Routen machen.
    Ich hab nur noch nicht ganz verstanden, wer jetzt wann auf das vpn oder die Fritzbox zugreifen soll.


    Hab ich irgendwann mal gemacht ...

    Hi,
    vielleicht habe ich das auch noch nicht ganz kapiert, aber ich sehe hier u.U. einen Höllenaufwand mit einem ganzen Sack Seiteneffekt.
    Ich denke, dass die Lösung nur sein kann, möglichst wenige Änderungen/Anpassungen in/an den lokalen Geräten vorzunehmen.
    Und diese intelligenten Switches/Router die es da gibt, könnten das evtl. alles leisten, ohne großartige Veränderungen vorzunehmen. Ausserdem müsste es mit dem Teufel zugehen, wenn solch ein Teil nicht günstig über ebay & Co. zu erwerben wäre.
    Routen, Adressen, DNS zentral zu filtern und zu ändern ... dafür sind diese Teile doch da, oder seh ich das falsch?

    Spätestens wenn es daran geht, evtl. an der Fritzbox irgendwas ein-/umzustellen dürfte es imho Probleme geben, denn da sind die Möglichkeiten (irgendwas automatisiert zu machen) dann doch eher beschränkt.
    Aber vielleicht habe ich das Problem auch noch nicht ganz verstanden ...

    grüssle,
    -ds-

    Hi,

    kann imho nicht funktionieren, weil Du immer dann, wenn der String leer ist - also nix über die Leitung kommt - den Pin wieder auf low setzt.
    Abhilfe (ad hoc) statt:

    Code
    while True:
            line =  readLine(ser)
            if line == 'SContactr' :
                    GPIO.output(11,GPIO.HIGH)
    
    
            else:
                    GPIO.output(11,GPIO.LOW)

    irgendwas in der Art:
    if( line != "")
    {
    if(line =="SContactr")
    GPIO.output(11,GPIO.HIGH)
    else
    GPIO.output(11.GPIO.LOW)
    }

    Oder eben einen weitere Befehl zum Lösen übermitteln. dann wäre es noch eindeutiger.

    cu,
    -ds-

    PS: was mir gerade noch einfiel
    Gönn dem Kerlchen doch mal ne Pause ... gibts in python keinen sleep, poll oder so. Du dürftest sonst so einiges an CPU-Leistung abfackeln.

    Hi,

    mir fiel da gerade noch was ein:
    Es gibt doch diese professionellen Switches die man per speziellem Protokoll programmieren kann.
    Ich denke, mittels so einem Teil könnte das eher funktionieren, denn die könnten dann ein masquerading der IP-Adressen durchführen. Evtl. erreichst Du das auch durch einen "vorgeschalteten" Pi quasi als "intelligentes Gateway" oder "Verteiler".
    Wenn ich mir das so überlege, wirst damit evtl. am wenigsten Aufwand und damit die kleinste Anzahl Fehlerquellen haben.
    Aber zu dem Thema muss ich leider passen, da brauchst Du Input von einem Netzwerk-Admin eines wirklich großen Netzwerks.

    cu,
    -ds-

    Hi,
    klingt interessant. Ich denke, das sollte - zumindest irgendwie - auch realiserbar sein.
    Mir ist nur ein Punkt nicht klar:


    Code
    Sobald man bei einem Gerät im Netzwerk aber das Gateway auf FritzBox(192.168.0.[b]1[/b]) ändert sollte das auch noch gehen und der Traffic eben NICHT mehr über die USA laufen.

    Du kannst natürlich jederzeit das Gateway ändern. Nur: soll das dann Auswirkungen auf andere Geräte im Netz haben? Das dürfte schwierig werden.
    Wie sieht es mit der IP-Adresse des Endgeräts aus? Ändert die sich auch oder bleibt die?
    Wie ist es mit DNS? Ändert sich da was?
    Diese Informationen stellst Du ja per DHCP zur Verfügung. Das würde u.U. einen neue DHCP-Request von allen Geräten bedeuten und im Falle einer Umkehr (ausklinken vom US-Netzwerk) ebenfalls.
    Oder hab' ich da was falsch verstanden?

    ciao,
    -ds-

    Yep, meine Zugriffe sind natürlich auch "mmap(ped)". Wie das genau läuft - da habe ich mich bisher noch nicht damit beschäftigt.
    Was passiert, wenn das mehrmals ausgeführt wird:

    Threadsicher erscheint mir das zunächst nicht, aber maßgeblich ist wohl, wie der Kernel damit umgeht ??

    Hi,
    vereinfacht würde ich sagen: jedes Gerät hat reale Adressen, über die man auf es zugreifen kann. Diese sind aber i.d.R. in einer Anwendung nicht verfügbar, sondern darüber liegt der Treiber im Kernel. Will ich nun aber direkt auf z.B. Register zugreifen, dann ich das aus meinen "Userspace" nicht tun, weil nur Zugriffe innerhalb des Speicherbereichs erlaubt sind, den ich vom System zugewiesen bekommen habe (sonst gib's den berühmten memory fault). Um Registerzugriffe direkt aus Anwendungen trotzdem zu ermöglichen erstellt mmap quasi ein Abbild der Register in Deinem Speicherbereich und regelt dann die realen I/O Zugriffe über das OS.
    Mehrfache Aufrufe erzeugen eben mehrere maps und der Zugriff auf diese maps kannst Du über die Flags regeln.
    Ist, meines Wissens, eine komfortable Weiterentwicklung von IPC, das meinerzeit noch überwiegend mit shm() & Co. auskommen musste.

    Näheres dazu findest Du z.B. hier ...

    Grüssle aus dem Bayernland,
    -ds-

    Moin zusammen,

    Hast Du bereits an irgendwelchen Einstellungen herumgeschraubt und die nicht zurückgesetzt?
    Es wäre wünschenswert, dass Du in der Lage bist, deine Änderungen wieder rückgängig zu machen, sonst wird das eine Sysiphus-Aufgabe.

    Ich hab' hier eine unmodifiziert Version der Apache2 Installation laufen.
    Ein script - in meinem Fall ein kleines C-Programm, das nur ein Hallo ausgibt - wird bei mir unter /usr/lib/cgi-bin nur dann gefunden, wenn ich in der URL http://pi/cgi-bin/<scriptname> eingebe. Bei der URL http://pi/<scriptname> kommt ein simples 404.
    Frage: was hast Du da verändert?
    Kannst Du mal bitte alle Deiner Änderungen rückgängig machen oder notfalls den Apache oder zumindest die Konfigurationsfiles neu installieren oder auf "Werkseinstellungen" zurüketzen?
    Wie hast Du den Apache installiert? Per Hand oder über apt-get?
    Was für eine Sprache verwendest Du in Deinem script?

    so, genug erstmal ...
    ciao und bis später in die Runde ...

    -ds-


    Ich habe ein ähnliches Problem beobachtet: Ich bin dabei, ein Tachometer für mein Motorrad zu bauen und wollte ein zweites Programm (beides C, auf der Basis von winigPI) zum Simulieren verwenden - die Pins lassen sich schalten, aber das Signal ist sehr instabil... Einer meiner Kollegen meinte, die Software-mässige Anschaltung könnte das Problem sein, aber es kann natürlich gut auch die doppelte Initialisierung sein...

    Nur so eine Idee: Pullup verwenden?
    ciao,
    -ds-


    Ich nutz die bmc2835-Library von Mike McCauley, aus dem einfachen Grund, daß die SPI-Unterstützung früher verfügbar war und ich dann dabei geblieben bin.

    Moin, moin ...

    ich tendiere gefühlsmäßig ebenfalls eher zur bcm2835-lib.
    Nach einigen Recherchen habe ich vermutlich auch den Grund für den Hänger gefunden. Der schlägt nämlich erst dann zu, wenn tatsächlich ein entsprechendes Signal am GPIO-Pin anliegt.
    Scheinbar gibts da ein Problem bezüglich Kernel-Interrupt-Handling und der bcm2835 Bibliothek.
    Wär jetzt nicht so schlimm - müsste ich halt einen workaround mittels poll und so stricken.

    Die wiringPI hat was - die ist ziemlich übersichtlich und einfach zu benutzen, der Interrupt-Mechanismus funktioniert ebenfalls.
    Die bcm2835 Bibliothek ist imho näher an der Hardware und daher vermutlich flexibler, hat aber wohl - zumindest ein - versteckte(s) Problem(e).

    Ich hasse es einfach über Fallstricke aufs Maul zu fallen, mit denen sich andere schon herumgeärgert haben. Und leider tendiere ich wohl dazu ;> ...

    Aber danke erstmal und mal sehen, was hier noch kommt.
    Ich werd' dann wohl zwischenzeitlich erstmal ein bisserl trial and error praktizieren ...

    greetz,
    -ds-


    Bei beiden Bibliotheken kann man davon ausgehen, daß direkt mit den CPU- bzw. Peripherieregistern gearbeitet wird (angesehen habe ich mir es aber bis jetzt nicht).

    Da muß es crashen, wenn mehrere Programme gleichzeitig zugreifen (auch wenn es verschiedene GPIOs sind: die Initialisierung für z.B. Timer, Speicher, etc. werden dann mehrfach aufgerufen). Selbst wenn Du in beiden Programmen mit derselben Bibliothek arbeiten würdest, gäbe es vermutlich denselben Effekt.
    Die Lib müsste als shared lib für den gleichzeitigen Zugriff mehrerer Prozesse ausgelegt werden, ich bezweifle aber, daß das derzeit schon so realisiert ist. Falls in den Libs eine Lock-/Unlock Funktion vorgesehen ist, wäre das ebenso hilfreich.

    Ich würde mich für eine Lib entscheiden und alle Zugriffe auf GPIOs aus einem Programm machen, das spart vermutlich viel Ärger. ;)

    Gruß, mmi

    P.S.: Vieleicht findet sich ja noch jemand, der bereits einen Blick in den Quellcode geworfen hat. Ich habe meine GPIO Zugriffe nach den Beispielen auf elinux.org selbst realisiert.

    Hi,
    merci für Deine Meinung ...
    Allerdings denke ich, dass die Zugriffe über mmap gemacht werden, und das sollte thread-sicher sein.
    Ich wollte jetzt auch keine großartige Analyse hier lostreten. Das Problem mit dem Hänger habe ich vermutlich eh entdeckt.

    Alles über ein Programm zu managen wird spätestens beim Interrupt-Handlung problematisch.
    Scripte kommen für mich als alteingesessener Assembler- und C-Freak eher nicht in Frage. Lieber schreibe ich dann noch ein KLM zum Handling der GPIO-Pins via ioctl() und /dev/gpio ;)

    Aber das, denke ich, wäre wirklich nur die ultima ratio.

    Also Quellcode buddeln ist eher nicht angesagt, sondern eher Eure Erfahrung(en) mit den verschiendenen APIs.

    Thnx und cul8er,
    -ds-

    Hi und guten Abend,

    muss es unbedingt "diese" Lösung sein?
    Ich hatte das ebenfalls mal so angedacht - allerdings über apache und phpmyadmin. Das war alles andere als amüsant und grottenlangsam.
    Ich habe jetzt eine - für mich perfekte - Lösung gefunden:
    mysql läuft auf dem raspi und als Oberfläche verwende ich "MySQL Administrator" - kann auch alles und verbraucht kaum CPU des raspi, da wohl alles über die mysql-API gemanaged wird.

    BTW: Du könntest auch phpmyadmin remote verwenden ... wie, das weiss ich nicht mehr so genau, war wohl ein Eintrag in irgendeiner .ini Datei. Damit sparst Du Dir ebenfalls php-Interpreter und Webserver. google müsste da was passendes Ausspucken.

    ciao, und einen schönen Abend noch,
    -ds-

    Guten Abend Community,

    nachdem ich mein letztes Problem durch Eure Unterstützung lösen konnte, nun das nächste:

    Wie im letzten Thema von mir beschrieben soll der raspi im Keller befestigt werden, über ein Kabel seine Daten per S0-Protokoll erhalten und diese dann in (s)einer mysql-Datenbank ablegen. Die Auswertung erfolgt dann zu einem späteren Zeitpunkt über das Netz mittels php und voraussichtlich auf einem anderen Rechner.

    Um das Ganze im Trockenlauf zu testen habe ich jetzt ein Programm, das Pin 11 (GPIO 17) als Ausgang schaltet und zyklisch zwischen high und low toggled und ein weiteres, das Pin 12 (PIO 18) als Eingang definiert, einen Interrupt-Handler auf Rising-Edge-Events installiert und in diesem Handler derzeit nur eine Meldung ausgibt.

    Das erste habe ich mit der wiringPi-API geschrieben, für das zweite habe ich die bcm2835-Library verwendet.
    Wenn ich nun das erste Programm starte, kann ich über Webiopi sehen, dass der Pin wunderbar zwischen high und low wechselt.
    Nun nehme ich ein Breadboard und verbinde Pin 11 und Pin 12. Klappt wunderbar - in der Oberfläche sehe ich nun beide Pins blinken.

    Sobald ich aber das zweite Programm aufrufe, friert der Raspi ein und kurz drauf rebootet er (wegen des watchdog-Timers).
    Edit: verwende ich in beiden Programmen nur die wiringPI API dann funktionieren beide Programme anstandslos. Das problem ist also zur Realisierung eher marginal, könnte aber aufgrund des massiven Hängers doch ganz interessant sein, falls man mal einen Mix aus solchen Anwendungen benötigt oder zufällig einsetzt. Vielleicht liegt die Lösung auch in der Mitte - sprich direkt auf die Register zuzugreifen?

    Ich habe schon im web gesucht, aber leider nichts gefunden.
    Gibt es da Unverträglichkeiten zwischen den beiden APIs und ist evtl. jemandem schon mal so was untergekommen?

    Ich werde mal die statische Variante von wiringPI probieren und das Ergebnis dann hier posten.
    In diesem Zusammenhang hätte ich eine Bitte: würdet ihr mir verraten für welche Variante ihr euch entschieden habt und warum?
    Wie gesagt - es geht nicht um ein Script sondern ein C-Programm!


    Vielen dank schon mal und viele Grüße aus dem nächtlichen Rosenheim,
    -ds-

    Hallo ...

    ich habe den Übeltäter entdeckt ... Stein vom Herzen fall ...

    Das Problem war der Micro-USB-Stecker an der Stromzufuhr. Das Kabel war nagelneu und wurde seinerzeit mit dem Netzteil geliefert.
    Da soll man erst mal drauf kommen ...

    Die Sicherung hatte ich auch schon in Verdacht, aber nachdem auch an der - also direkt nach dem Stromstecker - nur 3,85 Volt anlagen und über die Sicherung nur ca. 0,09 V abfielen, war das Thema schnell erledigt.
    Blieb nur noch das Kabel ... und da hat der Stecker scheinbar einen Wackler oder was weiss ich.
    Ich hab' das jetzt getauscht und siehe da: 4,88 V zwischen TP1 und TP2.

    Der Teufel ist echt ein Eichhörnchen ...

    Damit ist dieses Problem jetzt wirklich erledigt inkl. Erklärung und der raspi hat nach wie vor die Chance auf ein Leben im Keller.

    ciao,
    danke für Euer Interesse und Eure Hilfestellung

    -ds-

    Hi,

    mag sein, dass die Stromversorgung ein Schwachpunkt ist. Das erklärt aber nicht folgendes:
    Wenn ich mein "stärkstes" Netzteil anschließe, dann habe zwischen den Messpunkten TP1 und TP2 eine Spannung von 3,85 und 3,86 V.
    Das Netzteil selbst liefert aber am Stecker nach wie vor 5,12 V.

    Das heißt doch: nicht die Spannung des Netzteils bricht ein, sondern es fehlen einfach knapp 1,3 Volt.
    Lege ich am Stecker 6V an, dann fehlen ebenfalls etwa 1,5 Volt.

    Das Problem liegt hier, aus meiner Sicht, eher am raspi selbst und nicht am Netzteil ...

    Also: wenn Du jetzt sagst, nicht mehr als 5,3 Volt einspeisen, weil sonst die Elektronik leidet, ich mit diesen 5,3 Volt aber nur so knapp 4 Volt zwischen den Messpunkten erreiche, dann kann ich machen, was ich will, ich werde den raspi niemals stabil zum Laufen bekommen.
    Um die knapp 5 V zu erreichen, müsste ich nämlich - nach meiner Logik - weit über 6 Volt einspeisen.

    Oder seh' ich da was falsch???

    Ich könnte es jetzt auf die Spitze treiben und ein Labornetzteil anschliessen und dann nachschauen, was der Winzling so an Strom zieht und wie hoch ich die Eingangsspannung austarieren muss, um die notwendigen 4,5 bis 4,7 Volt zwischen TP1 und TP2 zu erreichen.

    Aber ich weiß nicht, ob sich lohnt.
    Das scheint ein satter Designfehler zu sein, der - auch lt. Internet - nur mit zwei workaraounds behoben werden kann:
    1. "Besseres Netzteil" - was nix bringt, weil bei 5V die 4,5/4,7 V TP1/TP2 Spannung nicht erreicht wird (zumindest nicht bei mir)
    2. "Stärkeres Netzteil" - z.B. 6-6,5 Volt - was ebenfalls nix bringt, weil vermutlich auf Dauer die Chips gegrillt werden

    Mal ne Frage: welches Netzteil verwendest Du und hast Du die 4,5/4,7 Volt?
    Vielleicht ist ja in der Tat irgendwas auf meinem Board nicht in Ordnung. Ich würde mir als ultima ratio ein Netzteil besorgen, wie Du es verwendest und wenn dann die Spannung zwischen den Messpunkten nicht stimmt, mal von einem Boardfehler ausgehen.

    Alles andere wäre jedenfalls das Todesurteil für mein Projekt der Stromverbrauchsmessung, denn das, was am wichtigsten dabei ist, ist robuste und pflegeleichte Hardware.

    ciao, den Regenschirm aufspannend,
    -ds-

    Hi,

    ich kenne jetzt die API nicht, daher
    Mutmaßung: die Funktion erwartet einen String, keinen Zahlenwert ...
    Lösung evtl.: Versuch mal port.write("0x0A")

    du wirst allerdings auf der Gegenseite dann statt Zahlenwerten einen String 0x0A empfangen.

    Abhilfe: ich denke, Du könntest
    1. Auf der Gegenseite den String wieder nach Zahlenwert konvertieren
    2. mal nachsehen, ob es eine Funktion port.write.binary oder so ähnlich gibt, mit der man Zahlenwerte übertragen kann.

    ciao und Grüsse aus dem nassen Chiemgau,
    -ds-

    Hi,
    ok, ok ... ich neh'm alles zurück was die Stromversorgung betrifft ...

    Nachdem ich mich in der Vergangenheit schon öfter mit dem Thema rumgeschlagen, aber nur die Netzadapter getauscht habe, habe ich auf die Spannungsmessung nicht mehr viel Wert gelegt.
    Warum auch? Ich hab' hier mittlerweile Netzadapter mit 1000 mA, 1500 mA, 2600 mA und 3600 mA und war der Überzeugung, dass das einfach reichen muß. Leider hat mich der Griff zum Multimeter gerade eines besseren belehrt.

    An den Messpunkten liegen nur ca. 3,8 / 3,9 V an, und immer wenn die Netzwerk-Lämpis aufleuchten scheint die Spannung nochmals einzubrechen.
    Jetzt habe ich ein Netzteil verwendet, das einstellbar ist.
    Jetzt liegen an den Messpunkten 4,43 Volt an, obwohl ich das Netzteil auf 6 Volt eingestellt habe und diese am Stecker auch anliegen (+/- 0,15 V) - aber: Netzwerk leuchtet und ist verfügbar, rlogin geht raspi läuft. Ich zieh' später mal die logs und poste sie. Wer weiss, wem das mal helfen mag ...

    Sonderbar aber, woher der Spannungsabfall kommt (da fehlen immerhin 1,5 V) und noch sonderbarer, warum die Konstellation vorher wochenlang keine Probleme machte (trotz der 3,8 V).

    Das würde evtl. auch das Problem mit SD-Karten über 4GB erklären, das ich hatte (immer "no route to host").
    Ich bleib da mal dran ... und schliesse, falls keine weiteren Sonderbarkeiten auftreten, dieses Thema dann als erledigt.
    Danke jedenfalls,
    man sieht sich ...

    Fazit: Manche buchen für 4000,- Euro einen Abenteuer-Urlaub. Mir reichen 40,- Euro für einen Raspi ...

    So, kleiner Nachtrag:
    Nachdem der raspi mit den 6V Netzteil so weit wieder "normal" gebootet hat (logs, wie angekündigt, mal als Attachment), habe ich aus Jux und Dollerei noch einmal das "ursprüngliche" Netzteil angeschlossen, mit dem der raspi nicht mehr wollte.
    Wunder, über Wunder ... selbst mit dem bootet er wieder ...

    Und genau das ist es, was an meiner Substanz nagt: der Zwerg verhält sich so, wie ihm gerade ist. Irgendwie ist sein Verhalten nicht vorhersehbar.

    Nun denn ... Problem zumindest erstmal zeitweise gelöst. Über Ursachen, glaube ich, lässt sich höchstens spekulieren. Ich für meinen Teil finde es sehr schade, dass der raspi so unberechenbar ist. Das ist in gewisser Weise schon ein Argument gegen ihn.

    Bis später mal,
    -ds-

    PS: boandlkramer: wia schaugts aus ... woima a poar Joahr ausschnapseln ?? I spui an Brandner Kasper ...

    Der letzte macht das Licht aus ... bzw. ich setze das Thema dann auch erledigt.

    Hallo zusammen,
    zunächst mal danke für die schnellen Lösungsansätze, aber ich denke, Euch fehlen noch folgende Hintergrund-Informationen:
    Der raspi hat normalerweise gar keine USB-Peripherie angeschlossen, auch keine Tastatur oder sonstwas. Geplant ist ihn im Keller an die wand zu schrauben und als Zähler für den aktuellen Stromverbrauch zu verwenden. Er bekommt dann seine Daten als Impulse per Kabel im S0 Protokoll - also z.B. 1000 Ticks pro Kilowatt pro Stunde. Die sollen in eine mysql-Datenbank gespeichert werden, und damit die SD-Karte wegen der hohen Schreibzugriffe nicht so bald den Geist aushaucht, werden die Daten dann später entweder über Netz in einer externen Datenbank gespeichert oder die lokale Datenhaltung auf eine externe USB-Platte ausgelagert.
    Demzufolge ist ein manueller Eingriff vor Ort praktisch nicht nötig. Als einziges Gimmick habe ich den watchdog-Timer aufgezogen, der im Falle eines Absturz des raspi diesen automatisch rebootet.
    Fakt ist, dass er tagelang lief, und ich ihn auch problemlos neu booten konnte, bis er eben eines Morgens vor sich hin dohdelte ... ähm, sich halt tot stellte. Der reboot (hardware unverändert) ließ zwar dann die Netzwerk-Lämpis leuchten, aber der raspi hatte eben keine IP-Adresse ( wie bereits beschrieben).

    Nun hab ich - wegen der besseren Übersicht - die logs geleert und dann das Teil nochmals neu gebootet. Dabei habe ich die Tipps von hier: elinux usb issues mit einfliessen lassen.
    Verhalten: bootet -> kerneldebugger
    watchdog agiert -> reboot
    bootet -> keine Netzwerk-Lämpis, lt. Bildschirm scheint er zu laufen

    Die logs (enthalten nur diesen einen Bootvorgang) hänge ich mal wieder als attachment an.

    Mir ist aufgefallen, dass der raspi den Netzwerkchip scheinbar als USB-Gerät behandelt:

    Code
    Apr 22 22:17:17 raspberrypi kernel: [   16.105272] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:d2:a6:4b
    Apr 22 22:17:17 raspberrypi kernel: [   16.106304] usb 1-1: USB disconnect, device number 7
    Apr 22 22:17:17 raspberrypi kernel: [   16.106327] usb 1-1.1: USB disconnect, device number 8
    Apr 22 22:17:17 raspberrypi kernel: [   16.106522] smsc95xx 1-1.1:1.0: eth0: unregister 'smsc95xx' usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet

    Und dass er wohl irgendwelche Probleme mit USB hat:


    Warum das jetzt plötzlich so ist, kann ich mir trotzdem nicht erklären.

    Ich werde jetzt mal nach und nach die Stromversorgungen tauschen ( was imho meist nix bringt, wenn man - wegen den 500 mA pro Port - nicht übersieht dass man eine separate Stromversorgung für raspi und hub benötigt, falls man einen verwendet ) und mal die Spannung messen.

    Viele Grüße aus dem grauen Alpenvorland,
    -ds-

    Hallo Gemeinde,
    zunächst einmal "Griass eich, beinanda"
    Nachdem ich mich jetzt einige Monate mit dem raspi beschäftige und so einiges an Zeit und Nerven in das Teil investiert habe ist jetzt ein Problem aufgetaucht, bei dem ich beim besten Willen nicht mehr weiter weiß.
    Nach vielem Probieren hatte ich eine SD-Karten / Netzadapter / powered hub Kombination gefunden, mit der der raspi problemlos einige Tage am Stück durchlief und nach jedem Aus-/Einschalten auch wieder sauber hochfuhr.
    Vorgestern morgen jedoch waren die Netzwerk-Lämpis aus, gingen aber nach einem Reset bzw. Aus-/Einschalten wieder an.

    Mein Versuch mich per ssh beim raspi einzuloggen schlug mit der Meldung

    Code
    dirk@saturn:~/RaspBerry_Pie/pi@raspberrypi$ rlogin pi_lan -l pi
    ssh: connect to host pi_lan port 22: No route to host


    fehl.
    Tastatur angestöpselt, raspi rebootet, ifconfig aufgerufen:


    Wie unschwer zu erkennen ist, hat eth0 keine IP-Adresse bekommen. Die interfaces in /etc/network so aus:


    Naja ... ich hab' eth0 dann manuell konfiguriert:


    ssh-login funktionierte auch.

    Mmmh ... Problem mit dhcp? Alle anderen Rechner im Netz funktionieren und bekommen ihre Adresse.
    Nochmal auf Anfang - alles rebootet ... Router, Rechner, ... und den raspi.
    Pustekuchen ... gleiches Verhalten wie vorher: Lämpis brennen, no route to host, keine IP auf dem raspi, manuell eingestellt: funzt!

    Lösungsansatz statische IP vergeben! interfaces in /etc/network editieren:

    1. Reboot -> kerneldebugger
    2. Reboot -> keine Eingabe über Tastatur möglich, Netzwerklämpis aus
    3. Reboot -> Netzwerklämpis an aber keine IP-Adresse
    rlogin schlägt fehl (logisch)
    Versuch, die IP manuell einzustellen schlägt fehl, keine weiteren Eingaben über Tastatur möglich

    So, nun die Preisfrage: ist evtl. jemandem schon mal so ein Verhalten untergekommen? Wie gesagt, das Image habe ich über Wochen verwendet und es lief bis vor ein paar Tagen anstandslos. Es basiert auf dem wheezy-Image vom 16.12.2012.
    Ethernet-Hardware (smc-chip) scheint auch ok, sonst würde wohl die manuelle Konfiguration fehlschlagen.

    Tja, blieben dann noch die logs ... aber der kleine Kerl ist so geschwätzig, dass ich die mal als Attachment anhänge.

    Ich wäre wirklich für jeden Hinweis dankbar. Ich fürchte nämlich, dass irgendein Hardware-Teil das Zeitliche gesegnet hat.

    Schöne Zeit noch an alle und schon mal danke für euer Interesse ...
    -ds-