WLAN per systemd

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • 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

  • Hallo Michael,


    Moinsens ...


    soweit sind wir noch nicht ... ist erst 23:43


    ... Stromversorgung erfolgt über ein 2A-Netzteil ...


    Da bist Du aber sehr optimistisch ...
    Ohne jetzt Deine ausführliche Beschreibung ( sehr löblich :thumbs1: ) genau durchgelesen zu habe, wäre das jetzt der erste Ansatzpunkt: probier mal eine andere Art der Stromversorgung.
    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.

    Hast Du da eine Möglichkeit, was anderes zu probieren?
    cu,
    -ds-

  • 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

  • Servus Michael,


    ... Ne, nich wirklich...

    Der RasPi lief ... auch schon der GUI ...


    ne, schon klar, alles in Butter ... wenn Du das sagst ... :s
    Wie sagt man so schön: wer nicht will der hat schon ...

    cu,
    -ds-

  • 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

  • Hi MIchael,


    Möchtest Du mir sagen, ...

    nein, ich habe gesagt, dass mir Deine Stromversorgung als sehr optimitisch ausgelegt erscheint, und es sicher eine Idee wäre, das mal zu checken. Das wiederum ist ein Erfahrungswert aufgrund der Tatsache, dass, ich würd' sagen in 90% aller Fälle, in denen das System instabil wird, diese Istabilität auf die Stromversorgung zurückzuführen ist.
    Wenn Du meinst, das brauchts nicht ... na dann halt nicht ... kann ja auch sein, dass ich falsch liege.


    cu,
    -ds-


  • Im "echten" Betrieb soll die Kiste dann aber über wlan0 arbeiten und eth0 nur bei Bedarf zulassen.

    "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?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (20. Januar 2017 um 19:47)

  • "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

  • 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.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (20. Januar 2017 um 21:07)

  • 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

  • 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

  • Hi Michael,


    ...
    a) In der resolv.conf steht 192.168.1.1 2x drin.


    das dürfte egal sein ...


    ...
    b) Ich bekomme mit "route" ja auch 2x eine "UG"-Zeile, für eth0 und wlan0, angezeigt.


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

    cu,
    -ds-

  • 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

  • Ah siehste ... das dachte ich mir.
    Dass das nicht funktioniert ist klar ... welches Interface soll er denn nehmen? eth0 oder wlan0?
    Wenn Du mal die beiden Einträge für wlan0 löscht, geht's wieder, oder?
    Bzw. wenn Du die für eth0 löscht, funktioniert's wohl auch.

    Generell sind die Einträge ja korrekt ... dumm ist, dass beide Interfaces im selben Netzsegment liegen.
    Ich weiß das jetzt nicht mehr so genau ... ich glaube, das kann man über die metric beeinflussen.
    Aber da das zudem systemd ist, bin ich an dieser Stelle raus ... mit dem kenne ich mich noch gar nicht aus.

    Jedenfalls dürfte das das Problem sein. Evtl. findest Du ja im Netz einen Lösungsansatz ... Du hast ja mal ein paar Stichpunkte zur Suche.

    cu,
    -ds-

  • 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


  • 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?

    Nein, das ist nicht richtig. Auf meinem PI3, sieht es z. B. so aus:

    Code
    :~ $ route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.178.1   0.0.0.0         UG    303    0        0 wlan0
    192.168.177.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
    192.168.178.0   0.0.0.0         255.255.255.0   U     303    0        0 wlan0

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Servus,


    ... Tipp-Ex auf den Monitor fällt aus, oder? ;)


    Dremel mit Diamantscheibe zum Ausschneiden? :lol:


    ... einige Abende in Zusammenarbeit mit Google damit beschäftigt.


    das wollte ich damit auch nicht anzweifeln. Ich hatte gehofft, dass Du die Suche dann konkreter gestalten kannst.


    ... per if-up / if-down die default-route auf das jeweils andere Interface umzustellen. ...


    das wäre jetzt auch meine Idee gewesen. Oder pre- bzw. post- ...
    Ich wüsste sonst auch nicht, wo ich reinlangen sollte :s
    rpi444 hat Dir ja seine Ausgabe der routing tabelle gepostet:


    ...
    Nein, das ist nicht richtig. Auf meinem PI3, sieht es z. B. so aus:

    Code
    ...
    0.0.0.0         192.168.178.1   0.0.0.0         UG    303    0        0 wlan0
    ...

    rpi444: wie bekommst Du es hin, dass Du nur eine default-route hast?
    Michael müsste ja jetzt den passenden Eintrag raussuchen und den anderen löschen:


    ...
    default speedport.ip 0.0.0.0 UG 0 0 0 wlan0
    default speedport.ip 0.0.0.0 UG 0 0 0 eth0
    ...

    Nur was, wenn beide Interfaces online sind? Dann wären es ja wieder zwei default-routen :s

    cu,
    -ds-


  • rpi444: wie bekommst Du es hin, dass Du nur eine default-route hast?

    In dem ich dem eth0-Interface kein gateway zuweise. Das eth0-Interface hat ja eine IPv4-Adresse aus einem anderen Subnetz (als das wlan0-Interface) und in diesem anderen Subnetz gibt es keinen DHCP-Server und auch keinen Router, deshalb ist nur eine definierte route erforderlich. Dieses eth0-Interface wird lediglich für direkte (d. h. nicht über einen Router) Verbindungen zu meinem PI3 genutzt, wenn das WLAN aus welchen Gründen auch immer, mal ausfallen sollte. Diese direkte Verbindung über das eth0-Interface kann man aber auch parallel (permanent) zur WLAN-Verbindung nutzen, denn wegen der unterschiedlichen Subnetzen, stören die sich nie gegenseitig.

    So sieht die Konfiguration aus:

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (21. Januar 2017 um 09:27)

Jetzt mitmachen!

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