Beiträge von miriki

    Wenn von extern ein Ping an die .40 (auch ohne Kabelverbindung) funktioniert hat, dann muss tcpdump (mit dem Filter icmp) diesen Ping auch anzeigen.

    Ich krieg's ums Verrecken nicht mehr nachgestellt. Ich boote frisch mit LAN + WLAN, route zeigt alles richtig an, tcpdump reagiert auf ping von außen. Und dann, irgendwann... ist das Netz tot, komplett, alles wech. Ich find nur keinen direkten Auslöser, zumindest nicht reproduzierbar.

    Wenn der RasPi am Prompt steht, kann ich eine Stunde lang ping auf .40 und .41 absetzen, alles bleibt ok.

    Starte ich aber tcpdump, dann ist das Netz mehr oder weniger schnell weg.


    Zitat

    Poste mal die Ausgaben von:

    Code
    systemctl status systemd-networkd networking
    ls -la /etc/init.d/networking
    systemctl is-enabled networking


    a) sagt "Loaded: loaded ... enabled", "active (running)" und "Processing requests...". Er jammert aber über falsche Einträge "IPv6LL" und "LinkLeasedAddressing" in section "Network". Ansonsten sind lo, eth0 und wlan0 "link configured" und "gained carrier".
    Dann kommt aber im letzten Abschnitt ein "Loaded: loaded ..." (ohne "enabled") und ein paar Zeilen drunter "Active: Inactive (dead)".
    Pings on der .10 auf den RasPi .40/.41 werden aber nach wie vor beantwortet.

    b) ergibt

    Code
    -rwxr-xr-x 1 root root 4760 Dez 14 2014 /etc/initd/networking

    c) Und zuletzt dann:

    Code
    Failed to get unit file state for networking service: No such file or directory

    Kein "networking" Service? Und wer antwortet dann auf die Pings?

    Gruß, Michael

    OK, d. h. Du hast immer die Pings auf sich selbst gemeint und nicht Pings von einem anderen Gerät (aus dem WLAN des Routers)? Dann hatte ich das nicht richtig verstanden.

    Nein, nein, schon richtig. Es sei denn, ich versteh Dich jetzt falsch.

    Der .10 ist ein Win10-Rechner. Dieser hängt per LAN an einem Switch, der Switch wiederum am SpeedPort-Router.

    Der .40 ist der RasPi, per LAN über den gleichen Switch im LocalNet, per WLAN als .41 direkt über den SpeedPort im LocalNet.

    Die pings "von außen" waren immer von .10 (an dem sitz ich gerade und tippe diesen Beitrag) auf .40/.41 gemeint. Dieser "auf sich selbst" ping war jetzt nur der Vollständigkeit halber mit aufgeführt.

    Gruß, Michael

    Hast Du auf deinem PI:

    Code
    tcpdump [...]

    vor dem:

    Code
    ping [...]

    gestartet?

    Natürlich, sonst macht das ja wenig Sinn. ;)

    Ich hab jetzt mal ganz frisch den RasPi mit LAN + WLAN neu gestartet, "route" zeigt alles sauber an.

    Dann tcpdump gestartet.

    Dann vom Win10-DOS das "ping" auf .40 (eth0) gestartet

    Ergebnis: 4 Antworten vom RasPi, 8 (wenn ich das richtig sehe) 3-zeilige Reaktionen auf dem RasPi parallel dazu.

    Dann vom Win10 noch den ping auf .41 (wlan0)

    Ergebnis: 4x Zeitüberschreitung, keine Reaktion auf dem RasPi.

    Nach Ctrl-C sagt tcpdump auch noch was von 8 packets.

    Danach war auf dem RasPi das Netz tot. Er war auch auf .40 nicht mehr erreichbar und "route" machte auch wieder Mucken, ping raus auf 192.168.1.1 ergibt nur noch "Destination Host Unreachable".

    Ein ping auf sich selbst, also vom RasPi auf .40 oder .41, funktioniert.

    Das ganze spielte sich innerhalb 1 Minute nach Reboot des RasPi ab.

    Gruß, Michael

    Schau mal in der FritzBox nach, ob der Ping ohne Kabel zu .40, evtl. über das wlan0-Interface (.41) umgeleitet wird.

    Ich wüßte jetzt nicht, wo ich das auf meinem SpeedPort-Router nachsehen könnte. Ich wüßte aber auch nicht, wo ich das vorher auf meiner Fritz!Box (7270v3) hätte nachsehen können.

    Zitat

    Mit tcpdump kannst Du es auch auf deinem PI anschauen:

    Code
    sudo tcpdump -vvveni eth0 icmp

    Nachdem ich das nachinstallert habe, erzeugt der Befehl _null_ Reaktion auf dem Bildschirm. Also irgendwie fühlt sich da rein gar nichts angesprochen. Auch nach Ctrl-C kommt nur "0 packets ..." in den 3 Zeilen der Ausgabe.


    Zitat

    BTW: Es heißt ja nicht umsonst, dass man auf einem Gerät, keine 2 Interfaces in einem Subnetz konfigurieren soll.

    Hups? Das hör ich jetzt zum ersten mal. Und ich hab früher schon mehrere Interfaces unter Linux auf einer Kiste betrieben. Das war allerdings noch Anfang der 90er unter SUSE mit bis zu 4 Ethernet (3Com) in einem Rechner. Und die liefen alle im selben Subnetz.

    Da hatte ich dann aber "der Ordnung halber" dann später irgendwann die NICs in verschiedene Subnetze verschoben. Und deswegen meinte ich auch, daß man dann die Netzmaske anpassen muß. Ich erinner mich, daß ich mit /24 dann Probleme hatte und auf /16 ändern mußte. Aber ist lange her und die Erinnerung trübe.

    Gruß, Michael

    PS: Jetzt ist es wieder so weit: Boot mit WLAN und LAN, alles ging, dann LAN abgezogen, ping machte fröhlich weiter, aber jetzt dann nach einiger Zeit: Komplettes Netz tot, auch nach Einstöpseln vom LAN bleibt das Netz weg.

    Boot mit LAN alleine macht Pause beim Boot, aber Netz ist stabil. Boot mit WLAN alleine macht keine Pause, aber auch kein Netz danach.

    Das verd... WLAN ist alleine einfach nicht überlebensfähig.

    Die Seite kannte ich schon, aber die Erklärungen sind dort etwas "dünne". Auf elektronik-kompendium wird der gleiche Inhalt, soweit ich das erkennen kann, beschrieben, aber eben in den kleinen Details etwas ausführlicher. Während auf der Wiki nur steht "Dienst abschalten" steht auf EK eben auch, mit welchem Befehl oder in welcher Datei das geschieht.

    Zumindest konnte ich im eigentlichen Inhalt keinen Unterschied zwischen den beiden Seiten sehen. Oder hab ich was übersehen? Wie gesagt, mein Ablauf (1. Post) ist von EK. Wenn ich da was ggü. dem Wiki anders machen sollte, hab ich das nicht gesehen.

    Gruß, Michael
    Automatisch zusammengefügt:

    Code
    root@raspi002:~# route
    
    
    Kernel-IP-Routentabelle
    Ziel          Router         Genmask         Flags   Metric   Ref   Use   Iface
    default       speedport.ip   0.0.0.0         UG      0        0     0     wlan0
    default       speedport.ip   0.0.0.0         UG      0        0     0     eth0
    192.168.1.0   *              255.255.255.0   U       0        0     0     wlan0
    192.168.1.0   *              255.255.255.0   U       0        0     0     eth0

    So sieht's aus, nachdem ich mit LAN + WLAN frisch gebootet habe.

    Ich bin mir nicht sicher, ob es jetzt stabil ist, aber ein paar Tests heute nachmittag verheißen Gutes, wenn auch nicht unbedingt Richtiges. ;)

    Status jetzt: Nach dem Boot wie oben beschrieben, alles geht, der RasPi ist von einem anderen Rechner (Windows 10 auf 192.168.1.10 im DOS-Fenster) per "ping" auf beiden Adressen erreichbar. Alles gut...

    Jetzt kommt die Twilight Zone... Ein Zustand, mit dem ich leben kann, der mir aber nicht richtig erscheint... Ich ziehe das eth0 vom RasPi ab und rufe (mehrmals, 2 Minuten lang) "route" auf. Das Ergebnis bleibt unverändert das obige, die beiden eth0-Zeilen verschwinden nicht aus dem Routing. Und: Der RasPi ist nach wie vor auf _beiden_ IPs per "ping" erreichbar. und liefert Antworten innerhalb 2..3ms. Warum?

    Dann stöpsel ich das eth0 wieder ein und rufe wieder 2 Minuten lang "route" auf. Es bleibt nach wie vor unverändert - alle 4 Zeilen werden aufgelistet. Auch "ping" liefert von beiden IP des RasPi eine Antwort. Der RasPi hat vom Ein- und Ausstöpseln des eth0 irgendwie überhaupt nichts mitbekommen. Welcher Wichtel hat aber ohne eth0-Kabel den "ping" auf der .40 beantwortet? Und über welches Interface (kann ja nur noch wlan0 gewesen sein)? Und warum?

    Jetzt der "hakelige" Teil: Es wird wlan0 abgezogen. Prompt fliegen zwei Zeilen aus der "route" Anzeige, es bleiben nur noch die beiden für eth0 erhalten. Das sieht schonmal richtig aus. Der RasPi scheint aber bummelig 30 Sekunden zu brauchen, um mit der neuen Situation klar zu kommen. Zunächst ist ein "ping" auch auf der .41 (wlan0) noch teilweise erfolgreich. Aber es kommt schon mal ein "Host nicht erreichbar". Aber auch auf der .40 (eth0) kommt es jetzt zwischendurch zu Timeouts. Aber nach ca. 30..40 Sekunden hat sich das eingespielt, .40 antwortet stabil und .41 nicht (mehr) auf "ping".

    Und als letztes kommt wlan0 jetzt wieder ran: Die 2 Zeilen im "route" werden prompt wieder mit angezeigt, alle 4 sind wieder da und es wird auch nach wie vor "default" und "speedport.ip" (statt "0.0.0.0" und "192.168.1.1") angezeigt. Letzteres wäre, zusammen mit der Anlauf-Pause von "route" ja wieder das Zeichen, daß das Netzwerk nicht mehr erreichbar ist. Aber nein: Beide IPs sind, zumindest nach 30..40 Sekunden stabil, wieder per "ping " erreichbar und auch der RasPi selbst kann sauber nach z.B. http://www.google.de pingen.

    Im Moment läuft es also. Ich weiß bloß mal wieder nicht, warum... Die letzte Änderung dürfte das Deaktivieren von IPv6 gewesen sein. Und wenn .40 auf "ping" antwortet, obwohl kein Netzkabel in der Buchse steckt, dann ist das auch irgendwie nicht richtig.

    Aber vielleicht gibt's hier ja noch 'n schlauen Kopf, der da Licht ins Dunkel bringen kann.

    Gruß, Michael
    Automatisch zusammengefügt:

    Im Moment läuft es also.

    Zu früh gefreut...

    Nachdem ich jetzt nochmal das eth0 abgezogen hatte, war auch wlan0 ohne Funktion. Im Routing wurde "default" und "192.168.1.1" (schlechtes Zeichen) angezeigt, aber alle 4 Zeilen aufgelistet. Der RasPi war aber auf beiden IPs nicht mehr erreichbar und ein "ping" vom RasPi aus ging auch nicht mehr.

    Aber: Nachdem eth0 wieder eingestöpselt war, lief wieder alles rund. Alle 4 Zeilen im "route", auch wieder mit "speedport.ip" (gutes Zeichen), das "ping" auf beide IPs usw.

    Gna gna gna

    Gruß, Michael

    Das geht z. B. mit:

    Code
    ipv6.disable=1


    in der Zeile der /boot/cmdline.txt


    Ah, damit ist IPv6 dann gants deaktiviert? Die gänse Konfiguration kann sich dann auf IPv4 beschränken? Das klingt dann ja gans einfach so, werd ich gleich mal ausprobieren. Danke! ;)

    Gruß, Michael

    pi@raspberrypi:~ $ cat /etc/systemd/network/mylan.network

    Mal 'ne grundsätzliche Frage: Braucht man nicht für jedes Interface eine .network Datei? Ich hab eine
    "eth0.network" und eine "wlan0.network". Beide sehen fast gleich aus, unterscheiden sich nur in "Name" und "Address":

    Die Namensgebung Deines .network Files klingt ja eher so, als wenn es nur _eine_ Konfiguration für das gesamte Netzwerk gibt.

    Beim DHCP Eintrag sind sich die Leute wohl uneinig über "no" oder "none", deswegen habe ich beide drin. ;) Deine beiden Einträge für IPv6LL und LinkLocalAddressing werd ich mal übernehmen und mal nachschauen, was sie bewirken.

    IPv6 würde ich sowieso erstmal ganze gerne irgendwie komplett aus der ganzen Geschichte heraus bekommen. Da fehlt mir aber noch ein bißchen der Leitfaden.

    Gruß, Michael

    welches Interface soll er denn nehmen? eth0 oder wlan0?


    Is' mir doch egal! ;)

    Ne, im Ernst: Genau mit _dieser_ Situation funktioniert es ja gerade eben noch so. Ich kann zwar nicht sagen, über welches Interface der ping jetzt raus und wieder zurück kommt, aber es liefert Antworten.

    "ip r" sagt dazu:

    Code
    default via 192.168.1.1 dev wlan0
    default via 192.168.1.1 dev eth0
    192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.41
    192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.40


    Und das wiederum, denke ich mal, sieht ja geradezu wieder gut aus, oder? Source .40 geht über eth0 und Source .41 über wlan0 - so wie gewollt.

    Zitat

    Wenn Du mal die beiden Einträge für wlan0 löscht, geht's wieder, oder?


    Da wäre meine Frage: Wie? Tipp-Ex auf den Monitor fällt aus, oder? ;)

    Wie gesagt: So wie o.a. funktioniert es ja. Und wenn ich wlan0 abstöpsel, geht's ebenfalls noch - und die beiden wlan-Zeilen bei "route" sind dann auch weg.

    Zitat

    dumm ist, dass beide Interfaces im selben Netzsegment liegen.


    Ich hatte schon überlegt, ob es (hier generell) Sinn macht, die WLAN-Geräte pauschal in ein anderes Netz zu packen. Also 192.168.1.* für LAN und 192.168.2.* für WLAN. Dann muß aber überall die Netzmaske auf 255.255.0.0 bzw /16 angepaßt werden, richtig?


    Zitat

    ich glaube, das kann man über die metric beeinflussen.


    Tja, die metric... Da hab ich auch mal versucht, ein bißchen mehr drüber zu verstehen. Das war, als ich versucht habe, per if-up / if-down die default-route auf das jeweils andere Interface umzustellen. Das war noch, als ich das Netz über die "interfaces" Datei konfiguriert hatte. Und da sollte, wenn beides aktiv ist, das eth0 über die metric priorisiert werden. Klappte aber auch nicht. Auf meinem raspi001 sind noch die ganzen Versuche dieser Methode in den Files zu sehen. Deswegen wollte ich jetzt mal raspi002 "stilgerecht" nach aktueller Technik über systemd konfigurieren.


    Zitat

    Evtl. findest Du ja im Netz einen Lösungsansatz ... Du hast ja mal ein paar Stichpunkte zur Suche.


    Glaub mir, bevor ich hier gefragt habe, hatte ich mich einige Abende in Zusammenarbeit mit Google damit beschäftigt. Da wird gerne immer wieder mal darauf hingewiesen, daß "interfaces" seit Jessie "deprecated" ist und im gleichen Atemzug wird die Konfiguration über genau diesen Weg erklärt. Das elektronik-kompendium bot bislang die m.M.n. sauberste Anleitung für systemd. Aber leider will ja auch die nicht so recht. Und dabei habe ich ja nicht mal exotische Hardware. Nach meinen anfänglichen Problemen mit meinen alten Fritz!-Sticks habe ich mir ja extra mal 2 der "official" gekauft, um zumindest das Problem auszuschließen. Pustekuchen...

    Gruß, Michael

    aber das könnte ein Problem sein. Sind die targets auch identisch? Poste doch vielleicht mal die Ausgabe ...

    Ok, ich tipp mal ab:

    Code
    root@raspi002:~# route
    Kernel-IP-Routentabelle
    Ziel          Router         Genmask         Flags   Metric   Ref   Use   Iface
    default       speedport.ip   0.0.0.0         UG      0        0     0     wlan0
    default       speedport.ip   0.0.0.0         UG      0        0     0     eth0
    192.168.1.0   *              255.255.255.0   U       0        0     0     wlan0
    192.168.1.0   *              255.255.255.0   U       0        0     0     eth0

    So sieht's aus, nachdem ich mit LAN + WLAN frisch gebootet habe.

    Je nach Ein- und Ausstöpseln von LAN oder WLAN verschwinden dann die 2 Zeilen für das entsprechende Interface (oder auch mal nicht, eth0 ist da ziemlich renitent) und dann ist auch irgendwann "speedport.ip" weg und wird durch "192.168.1.1" ersetzt. Dann braucht "route" (ohne -n) ein paar Sekunden nach Aufruf und ein "ping" geht dann auch nirgendwo mehr durch.

    Gruß, Michael

    also wenn bei mir ein Problem erst bei einem bestimmten Wechsel von einem Interface auf ein anderes auftrat, dann war das meist das routing (z.B. zwei default routen) oder der Inhalt der /etc/resolv.conf ...

    Die resolv.conf wird automatisch generiert, zumindest scheint mir irgendwas das Ding immer wieder zu überschreiben. (Oder ist das nach Deinstallation von dhcpcd5 nicht mehr so? Kann ich jetzt nicht sagen.) Tatsächlich aber interessant:
    a) In der resolv.conf steht 192.168.1.1 2x drin.
    b) Ich bekomme mit "route" ja auch 2x eine "UG"-Zeile, für eth0 und wlan0, angezeigt.

    Das mag ein Problem sein. Aber zum einen bin ich mir da nicht sicher und vor allem: Ich hätte keine Ahnung, was ich dagegen tun könnte. Deswegen frage ich hier ja schließlich... ;)

    Gruß, Michael

    Halbwegs moderne Computer (mit Gigabit-Ethernet NICs) und auch RPis unterstützen Auto MDI-X, da braucht man kein Cross-over-Kabel mehr zur direkten Verbindung 2er Endgeräte.


    Ah, danke, gut zu wissen.

    Ob mein ca. 6 Jahre altes Notebook (Medion), das glaube ich nur 100er-LAN hat, das dann auch schon kann, weiß ich zwar nicht. Aber wenn es der Fehlersuche dient (und nicht nur weitere Fallstricke einbaut), kann ich das gerne mal ausprobieren.


    Gruß, Michael

    "eth0 nur bei Bedarf zulassen" immer über den Router oder hast Du evtl. auch die Möglichkeit, eine direkte Kabelverbindung zwischen deinem PI und deinem Gerät (auf dem sich Putty befindet) herzustellen?

    Gemeint war das so: Der RasPi soll autark per WLAN irgendwo irgendwas machen. Kleinere Änderungen an der Konfiguration, Software-Updates (mal 'n neues Script oder so) und das übliche Gedöns sollen dann wie gehabt auch über WLAN laufen.

    Aber wenn es mal notwendig sein sollte, dann kommt der RasPi auch mal zurück an den Schreibtisch und soll dort per LAN eine schnellere und stabilere Verbindung ins Netz bekommen, weil, was weiß ich, irgendwas größeres an Wartung angesagt ist.

    Die Anbindung ans Netz geschieht dann über einen Hub/Switch, an dem auch weitere stationäre Rechner (und RasPi) hängen, der Speedport dann als quasi Uplink. (Genau genommen hängen hier auch noch 2 Switches aneinander, der Vollständigkeit halber...)

    Eine direkte Verbindung z.B. vom Notebook an den RasPi wäre ggf. auch möglich, aber ein cross-over-Kabel hab ich nicht. Obwohl... könnte sein, daß irgendwo in der Kiste mit den alten ISDN/DSL-Geräten noch ein rotes oder gelbes Kabel (eins von denen war cross-over, glaube ich) von den alten Fritz!-Boxen herumfliegt.

    Gruß, Michael

    Wie sagt man so schön: wer nicht will der hat schon ...


    Möchtest Du mir sagen, daß der RasPi an der CLI mit WLAN in der Stromversorgung zusammenbrechen kann, während er in der GUI mit IDLE und aktivierter Kamera 48 h stabil laufen kann? Nicht wirklich, oder? ;)

    Ich kann gerne noch ein 2,5A Netzteil ausprobieren, das aber wirklich nur ein "Ladegerät" mit 3 USB-Ports ist. Keine Ahnung, ob das jetzige, was ja explizit als Netzteil ausgezeichnet ist, bei Spitzen sauberer ist, als es das Ladegrät wäre. Aber z.Z. sehe ich diese Spitzen noch nicht mal in gefährlicher Nähe.

    Und wenn ich ein 5A-Trumm brauche, um einen Desktop-Kalender/Uhr mit Wetterstation zu betreiben, dann wäre das ganze eh witzlos. Dann hängt ein zierliches 7"-Display im schlanken Gehäuse an der Wand neben dem Schaltschrank für die Stromversorgung, oder wie? ;)

    Können wir vielleicht nicht erstmal schauen, was an der Konfiguration vielleicht noch an Finetuning notwendig ist?

    Gruß, Michael

    Da bist Du aber sehr optimistisch ...


    Ne, nich wirklich...

    Der RasPi lief mit einer anderen SD bereits in dieser Konfiguration, nicht nur in der CLI, sondern auch schon der GUI und mußte sich dabei Eclipse und IDLE3 gefallen lassen. Per Python hab ich auch schon Langzeit-Zeitraffer mit 10-Sekunden-Snapshots und MP4-Konvertierung über avconv laufen lassen. Und im Hintergrund lief ein Python-Script, daß Licht, Temperatur und Luftfeuchtigkeit im 10-Sekunden-Takt gemessen und weggespeichert hat. Die Sensoren wurden auch noch vom Port versorgt, beinahe vergessen...


    Ich hab nicht darauf geachtet, wieviel Last der RasPi da effektiv hatte und wieviel Grad der so produziert hat, aber es lief reibungslos.

    Zitat

    Was Du da alles aus dem Netzteil (möglicherweise auch noch ein Ladegerät?) ziehst ... das ist so rein vom Gefühl her viel zu viel.


    Das Netzteil ist Teil eines kleinen Kits mit einem Klarsicht-Gehäuse (Wovon ich z.Z. nur die untere Häfte nutze), 3 kleinen Kühkörpern (die ich nicht aufgeklebt habe) und eben diesem Stecker-Netzteil.


    Gruß, Michael

    Moinsens, allerseits!

    Ich hab hier u.a. einen RasPi 2b mit "official" 7-Zoll-Touchdisplay und "official" WLAN-Stick, dazu noch ein Tastatur/Maus-Gespann von hama über Funk-Dongle und ein v1 Kamera-Modul (wahlweise auch eine NoIr-Variante). Das ganze steckt in einem Smarti-Pi (o.s.ä.) Gehäuse. Die Stromversorgung erfolgt über ein 2A-Netzteil, das über ein Y-Kabel den RasPi und das Display getrennt versorgt.

    Ich hab eine fabrikneue 16GB-Karte mit dem entpackten Zip des frisch geladenen NOOBS bestückt und den RasPi gestartet. Die Installation bietet (während sie "Raspbian" als Auswahl anzeigt) oben in der Mitte einen Button "WLAN". Nachdem ich den gedrückt und die Einstellungen (Funknetz usw.) eingestellt habe, zeigte sie mir auch diverse andere mögliche Installationen (RaspBmc usw.) an. Ich blieb beim Raspbian und ließ die Installation durchklötern.

    Letztendlich erschien die GUI und ich hab nur flüchtig ein paar Einstellungen zu Land, Tastatur usw. gemacht. Außerdem hab ich die meisten Schnittstellen, vor allem Kamera, aktiviert und den Boot-Vorgang auf CLI umgestellt.

    Nach dem Reboot habe ich versucht, das Netzwerk einzurichten. Ich bin mir nicht sicher, ob ich zu dem Zeitpunkt neben dem WLAN-Stick auch noch das LAN-Kabel eingesteckt hatte. Aber spätestens direkt vor dem Reboot hätte ich es abgezogen. Kann aber sogar sein, daß LAN von Anfang an nicht dran war.

    Nach dem Reboot habe ich die u.a. Konfiguration durchlaufen. Der Haupt-Anteil davon ist von der Seite elektronik-kompendium, aber einige zusätzliche Feinheiten von anderen Seiten mögen auch eingeflossen sein.

    Das Ziel ist: Die Interfaces sollen die statische IP eth0 192.168.1.40/24 und wlan0 192.168.1.41/24 (SpeedPort-Router ist 192.168.1.1, wlan heißt "miriki") bekommen. Beide Interfaces sollen parallel funktionieren und "hotplug" in die eine oder andere richtung verkraften. Solange ich am Konfigurieren, Programmieren und Testen bin, ist das eth0 verbunden, über das ich per Putty einlogge. Ggf. zupf ich hier dann auch mal wlan0 ab. Im "echten" Betrieb soll die Kiste dann aber über wlan0 arbeiten und eth0 nur bei Bedarf zulassen.

    Folgendes habe ich also gemacht:


    Und was soll ich sagen? Es funktioniert natürlich nicht...

    Ich bekomme die merkwürdigsten Ausgaben bei "route -n", z.B. jeweils 2 Zeilen für eth0 und wlan0 (gateway und broadcast), nur "route" (also ohne -n) macht erstmal eine bedenkpause und gibt dann auch nur IP-Adressen aus, statt 192.168.1.1 durch "speedport.ip" zu ersetzen. Und erwartungsgemäß bringt jeder ping außer auf localhost und die eigene IP dann ein Netzwerk oder Host "unreachable".

    Mittlerweile hab ich einige weitere Tips in die Konfiguration eingespielt (und tlw. auch wieder entfernt) und schlußendlich sogar mit "apt-get remove dhcpcd5" den dhcpcd komplett entfernt, falls der irgendwo noch reinflanken sollte. Aber irgendwie hilft alles nichts.

    Wenn ich mit LAN und WLAN boote, scheint es zu gehen. Zupf ich WLAN ab, scheint es ebenfalls noch zu gehen. Steck ich WLAN wieder an und entferne LAN, geht nichts mehr. Auch wenn ich danach LAN wieder einsteck, bleibt das Netzwerk tot.

    Boote ich nur mit WLAN, zeigt "route" mir trotzdem alle 4 Zeilen an, auch die für eth0. Er macht aber keine 1:30 Pause während des Bootvorgangs. Außerdem zeigt er mir ohne Bedenkpause "speedport.ip" in der Tabelle an. ping auf 8.8.8.8 und google.de gehen dann auch.

    Ansonsten nur mit LAN: 1:30 Pause (start job ... wlan0.device) beim Boot, danach nur die 2 Zeilen für eth0 bei "route", auch gleich mit korrekter Anzeige von "speedport.ip". Stöpsel ich dann WLAN mit ein, krieg ich wieder die 4 Zeilen. Ping geht weiterhin. Aber wenn ich jetzt LAN abzieh, braucht "route" wieder ein bißchen, zeigt die IP statt "speedport.ip" an, gibt aber nach wie vor alle 4 Zeilen aus. Ein ping nach "draußen" geht ab jetzt nicht mehr (destination host unreachable).

    Menno... Wo kann / muß ich jetzt noch schrauben, um das Zeuchs endlich mal stabil zum Laufen zu kriegen? Mit LAN ist das ja alles "out of the box" beinahe, aber dieses @!#~ WLAN treibt mich noch in den Wahnsinn.

    Gruß, Michael

    nein keinen Vorwiederstand. Davon ist in der Anleitung (siehe Anhang) keine Rede.


    Uhoh, ganz schlechte Idee...
    siehe elektronik-kompendium.de

    Versuch mal in der Art wie im Anhang. Da ist allerdings Pin 11 benutzt. Das kannst Du gerne auf Pin 7 umstöpseln.

    Den Wert des Widerstands berechnet man an Hand der Daten der LED (auch in o.a. Artikel verlinkt). Für eine 5mm rote LED sollte i.a. 180 Ohm passen. Damit wird der Strom auf ca. 10 Milliampere (Uled = 1,7 Volt) begrenzt und die LED leuchtet gut. Die kann zwar auch bis zu 20 mA, das leuchtet nicht viel heller, überlastet aber den RasPi-Port.

    Und ohne Widerstand zieht die LED, was sie kriegen kann, was ohne weitere Schutzmechanismen entweder die LED oder den RasPi durchbrennen läßt.

    Gruß, Michael

    Ich hoffe Ihr habt einen Tipp.

    Das Script sieht soweit eigentlich ganz ok aus. Ich tippe also mal eher auf einen Verdrahtungsfehler. Überprüf mal ganz genau:

    Vom RasPi Pin (IO) auf das Breadboard per Jumperkabel
    Auf der Senkrechten des Breadboard dann weiter in einen Vorwiderstand
    Hinter dem R dann weiter an das lange Beinchen der LED
    Die LED waagerecht, das kurze Beinchen auf einer anderen Bahn
    Vom kurzen Beinchen per Jumperkabel zum RasPi Pin (GND)

    (7) ----- R1 ----- LED1> ----- (9)

    Gruß, Michael

    Ich habe noch eine Klammer am Ende gesetzt und jetzt funktioniert es.


    Ok, läuft bereits, aber ich hatte noch ein Test-Script gebastelt. das Dir vielleicht trotzdem noch als Vergleich dienen kann:

    Ich habe die ruhige Zeit mal genutzt um meinen Raspberry neu aufzusetzen und ein bisschen herumzuspielen.


    Das ware für Dich die "ruhige" Zeit? Ich bin froh, wenn ich nächste Woche wieder zur Arbeit kann und es dann nach den Feiertagen wieder etwas ruhiger (und geregelter) wird. ;)


    Zitat

    i2cdetect funktionierte, i2cset und i2cget funktionierten nicht.


    Yep, so wie hier. Wobei, nach i2cdetect funktionieren dann auch i2cset/get. Nur, wenn ich den Sensor eine gewisse Zeit in Ruhe lasse, geht irgendwas in standby und das war's dann. Und i2cdetect ist dann das einzige, was den Sensor (oder den i2c-Bus?) wieder aufweckt.

    Ich hab ja mittlerweile den Verdacht, daß es weniger am Sensor, als vielmehr am Bus liegt. Denn zwei unterschiedliche Sensoren (BME250 und BH1750FVI) zeigen an diesem RasPi das gleiche Verhalten, während ich das (zumindest bislang mit dem BH1750FVI) an einem anderen RasPi noch nicht erlebt habe.

    Zitat

    Bei mir war es die Hardware (schlechter Kontakt zu GND) hast Du mal alle Kabel / Steckplätzte auf dem Breadboard getauscht? Nimm evtl auch mal einen anderen GND und anderen 3,3V Pin.


    Ich nehm mal neue Kabel und ein anderes Breadboard. Ich hab da noch etwas massivere Breadboards im Regal liegen, die vielleicht etwas kontakt-stabiler sind.

    Gruß, Michael