WLAN per systemd

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


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


    Ist aber nicht so. Z. B.:

    Code
    :~ $ ls -la /etc/systemd/network
    total 24
    drwxr-xr-x 2 root root 4096 Oct  9 20:01 .
    drwxr-xr-x 7 root root 4096 Jan 17 09:16 ..
    -rw-r--r-- 1 root root  175 Nov 13 17:45 mylan.network
    -rw-r--r-- 1 root root  139 Mar 23  2016 mywlan.network_bak
    -rw-r--r-- 1 root root  116 Sep 17 23:14 mywlanif.network


    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.

    Das geht z. B. mit:

    Code
    ipv6.disable=1


    in der Zeile der /boot/cmdline.txt

    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 10:02)

  • 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


  • ... damit ist IPv6 dann gants deaktiviert? Die gänse Konfiguration kann sich dann auf IPv4 beschränken?


    2x ja.

    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

  • 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

    Einmal editiert, zuletzt von miriki (22. Januar 2017 um 15:48)


  • Und wenn .40 auf "ping" antwortet, obwohl kein Netzkabel in der Buchse steckt, dann ist das auch irgendwie nicht richtig.

    Schau mal in der FritzBox nach, ob der Ping ohne Kabel zu .40, evtl. über das wlan0-Interface (.41) umgeleitet wird. Mit tcpdump kannst Du es auch auf deinem PI anschauen:

    Code
    sudo tcpdump -vvveni eth0 icmp

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

    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

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


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

    Hast Du auf deinem PI:

    Code
    sudo tcpdump -vvveni eth0 icmp


    vor dem:

    Code
    ping -c 3 -W 2 192.168.1.40


    (von einem anderen Gerät), gestartet? Wenn ja, dann poste mal die Ausgabe von "ping".

    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

  • 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


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

    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.

    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

  • 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


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

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

    EDIT:

    Poste mal die Ausgaben von:

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

    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 (23. Januar 2017 um 09:18)

  • 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


  • Er jammert aber über falsche Einträge "IPv6LL" und "LinkLeasedAddressing" in section "Network".


    Dann lasse diese Einträge in der Section [Network], einfach weg.

    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

Jetzt mitmachen!

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