WiFi geht nur wenn eth0 verbunden

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • DerTitel sagt es schon, WLAN0 geht nur wenn ETH0 per Kabel verbunden

    Konfiguration

    Raspi 3 B+

    Aktuellstes Rasbian BUSTER tiny aktuellste patches

    Zusätzlich installiert CAN und Python

    headless Installation

    feste IP Adressen für eth0 und wlan0 via /etc/dhcpcd.conf

    solange das Kabel dran ist kann ich beide Adressen pingen oder per ssh conecten , sobald das Kabel ab ist keine Verbindung zu wlan0.

    Nachstehend die Ausgabe von ifconfig

    Google findet zig Einträge zu diesem Problem quer durch so gut wie alle raspi Versionen und Betriebssystem, aber alles ohne rechte Lösung. Da wird von Routing etc. gesprochen.

    Hier ist nix mit Routing, sowohl mein Arbetsplatz als der raspi als das WLAN sind im selben Netz. Andere Geräte ob PC via Kabel oder Smartphone oder Notebook funktionieren. Auch m ein Notebook mit Debian das sowohl WLAN als ETH konfiguriert hat geht mit und ohne Kabel.

    Es muss doch eine sinnige Lösung für dieses Problem geben.

    Danke für Hilfe

    :danke_ATDE:

  • Code
    ....
    interfcae eth0
    
    ...

    Ein Schreibfehler?

    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

  • feste IP Adressen für eth0 und wlan0 via /etc/dhcpcd.conf

    solange das Kabel dran ist kann ich beide Adressen pingen oder per ssh conecten , sobald das Kabel ab ist keine Verbindung zu wlan0.

    OK, dann teste mal mit der Kabelverbindung, ob Du das wlan0-Interface direkt erreichst oder ob das via eth0-Interface geht.

    Z. B. auf deinem PI:

    Code
    sudo tcpdump -c 30 -vvveni eth0 icmp

    und danach machst Du einen Ping von einem anderen Gerät in deinem (W)LAN, zur IP-Adresse des wlan0-Interfaces.

    Poste von deinem PI, mit und ohne Kabelverbindung, auch die Ausgaben von:

    Code
    ip a
    route -n
    ip n s
    arp -av

    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

  • zu 1) die 172.16.1.251/24 ist eth0 die 172.16.1.250 ist wlan0, die 172.16.1.101 ist mein Smartphon mt eier Ping App

    Code
    pi@CAN:~ $ sudo tcpdump -c 30 -vvveni eth0 icmp
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    05:34:27.194376 40:3f:8c:1a:a3:0f > b8:27:eb:63:2c:f2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 56343, offset 0, flags [DF], proto ICMP (1), length 84)
        172.16.1.101 > 172.16.1.250: ICMP echo request, id 5, seq 1, length 64
    05:34:27.194467 b8:27:eb:63:2c:f2 > 40:3f:8c:1a:a3:0f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 56559, offset 0, flags [none], proto ICMP (1), length 84)
        172.16.1.250 > 172.16.1.101: ICMP echo reply, id 5, seq 1, length 64
    05:34:28.192398 40:3f:8c:1a:a3:0f > b8:27:eb:63:2c:f2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 56407, offset 0, flags [DF], proto ICMP (1), length 84)

    zu 2a. verbunden über Kabel dh. mit ssh pi@172.16.1.251

    zu 2b. verbunden über Kale, nur WLAN geht ja nicht, mit ssh pi@172.16.1.250

    Danke für Deine Hilfe

  • zu 1) die 172.16.1.251/24 ist eth0 die 172.16.1.250 ist wlan0, die 172.16.1.101 ist mein Smartphon mt eier Ping App

    Code
    pi@CAN:~ $ sudo tcpdump -c 30 -vvveni eth0 icmp
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    05:34:27.194376 40:3f:8c:1a:a3:0f > b8:27:eb:63:2c:f2, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 56343, offset 0, flags [DF], proto ICMP (1), length 84)
        172.16.1.101 > 172.16.1.250: ICMP echo request, id 5, seq 1, length 64
    05:34:27.194467 b8:27:eb:63:2c:f2 > 40:3f:8c:1a:a3:0f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 56559, offset 0, flags [none], proto ICMP (1), length 84)
        172.16.1.250 > 172.16.1.101: ICMP echo reply, id 5, seq 1, length 64

    zu 2a. verbunden über Kabel dh. mit ssh pi@172.16.1.251

    Wie ist dein Smartphone, von dem Du den Ping gemacht hast, mit deinem Heimnetz verbunden? Ich gehe davon aus, dass das per WLAN mit dem Router verbunden ist.

    Aus den Ausgaben von ping und arp -av sieht man, dass der Ping zum wlan0-Interface via eth0-Interface geht (die MAC-Adresse :63:2c:f2 ist die von eth0, obwohl der Ping an die IP .250 (die des wlan0) geht.

    In der Ausgabe von arp -av sieht man auch, dass für den Router (IP .253) kein arp-cache-Eintrag für das wlan0-Interface vorhanden ist. Das alles wird auch deshalb so sein, weil die Routen (definierte und default) über das eth0-Interface richtigerweise eine günstigere metric (202) haben, als die metric (304) über das wlan0-Interface.

    So eine (zweifache bzw. gleichzeitige) Verbindung (wlan0 _und_ eth0) zum Router, ist auch unüblich. Du kannst jetzt versuchen, das mit sysctl auf deinem PI zu optimieren bzw. zu testen:

    Code
    net.ipv4.conf.all.arp_filter = 1
    net.ipv4.conf.all.arp_announce = 1
    net.ipv4.conf.all.arp_notify = 1
    net.ipv4.conf.all.arp_accept = 1
    net.ipv4.conf.all.src_valid_mark = 1

    in die "/etc/sysctl.conf"-Datei und danach rebooten.

    Wenn Du einen guten Router hast, sollte dieser in seinem Web-IF dir aber anzeigen, dass bzw. wann das wlan0-Interface via eth0-Interface (und nicht direkt) erreicht wird. Eine FritzBox z. B., kann das.

    EDIT:

    BTW: Du hast ja sehr ungenau beschrieben:

    Zitat

    ... , sobald das Kabel ab ist keine Verbindung zu wlan0.

    Wie ist es wenn Du deinen PI mit _nicht_ vorhandener Kabelverbindung zum Router, startest/bootest? Kommt dann auch keine WLAN-Verbindung zwischen deinem Router und deinem PI zustanden?

    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 (24. März 2020 um 10:32)

  • Genau das Smartphone ist per WLAN mit der Fritzbox 7690 verbunden. Von Früher kenne ich, dass ich die PIs in der Regel über Kabel einrichte und denen eine zweite Adresse für das WLAN gebe. Je nach Standort werden die dann über Kabel oder WLAN betrieben. Über Kabel einrichten, weil ich zu 99% headless arbeite und beim Aufsetzen ja noch kein WLAN konfiguriert ist, das passiert ja dann erst im raspi-config.

    Die Fritzbox kennt beide Interfaces mit den richtigen IP Adressen und wichtig den richtigen MAC Adressen.

    "..., sobald das Kabel ab ist" heisst ich ziehe das LAN Kabel ab und versuche dann via WLAn zu verbinden. Auch wenn ich den PI ohne Kabel neu starte bekomme ich ein keine Verbindung. Ich habe auch testhalber mal die feste Konfiguration mal für die eth0 mal für die wlan0 rausgenommen, keine Verbesserung.

    Bin aber etwas weiter, habe um mir meine CAN Installation nicht zu versauen nochmal einen SD karte mit den selben Rasbian vom 26-09-2019 bestückt und im raspi-config nur das wlan eingerichtet. Die eth0 hat von der Fritzbox die ursprüngliche feste IP bekommen, das wlan0 eine neue. Kann auf beide Adressen pingen und verbinden, ziehe ich das Kable ab, geht nach wie vor das WLAN, so wie es sein sollte, kein Neustart erforderlich.

    Deine Idee mit der Metric ist ja nicht ganz falsch, nur soweit ich IP und TCP kenne, und ich glaube das tu ich recht gut, müsste sich das metric ja automatisch ändern, wenn eine in diesem Fall Alternative Verbindung ausfällt oder langsamer wird.

    Jedenfalls werde ich jetzt mal Schritt für Schritt den Raspi so konfigurieren wie ursprünglich. Es muss doch rauszubekommen sein was da falsch läuft. Ich würde ja sagen ich habe da wo Mist gebaut, aber das es laut Google diese Problem relativ häufig gibt und auch schon seit Jahren, als auch mit älteren Raspis und älteren OS Versionen muss das zu lösen sein.

    Erst mal Danke für Deine Hilfe, werde weiter berichten.

    • Offizieller Beitrag

    Sorry ich habe hier nur überflogen, weil es sich schlecht am Telefon überblicken lässt. Nur zwei Fragen in der Hoffnung, dass ich das nicht übersehen habe.

    Ist ein Mac-Filter in der Fritte aktiv (WLAN-Geräte dürfen miteinander reden)?

    Und hast Du am RPi das WLAN Land eingestellt?

  • Deine Idee mit der Metric ist ja nicht ganz falsch, nur soweit ich IP und TCP kenne, und ich glaube das tu ich recht gut, müsste sich das metric ja automatisch ändern, wenn eine in diesem Fall Alternative Verbindung ausfällt oder langsamer wird.

    Nein, dann kennst Du das nicht richtig bzw. nicht ausreichend. Du benutzt dhcpcd und der legt hier die metric fest. Z. B. aus seiner manpage:

    Zitat
    Code
    -m, --metric metric
    Metrics are used to prefer an interface over another one, lowest wins.  dhcpcd will supply a default metric of 200 + if_nametoindex(3).  An extra 100 will be added for wireless interfaces.

    D. h. die metric ist hier abhängig davon, ob es ein lan- oder ein wlan-Interface ist und vom Interface-nametoindex.

    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

  • Es muss doch rauszubekommen sein was da falsch läuft. Ich würde ja sagen ich habe da wo Mist gebaut, ...

    BTW: Das hast Du doch schon raus bekommen. Es gibt keinen arp-cache-Eintrag im PI für die FritzBox (Router und default gateway) via wlan0-Interface. Wenn Du diesen arp-cache-Eintrag manuell setzt oder evtl. mit einem arping vom PI zur FritzBox dafür sorgst, dass dieser arp-cache-Eintrag zustande kommt, sollte die WLAN-Verbindung vom PI zur FritzBox auch ohne Kabelverbindung funktionieren.

    Das ist dann aber auch nur ein workaround (d. h. die Erklärung was schief/falsch läuft) und nicht die richtige Lösung. Die richtige Lösung wäre m. E. die, den PI und die FritzBox so zu konfigurieren bzw. von Anfang an so zu nutzen, dass eine Verbindung zum wlan0-Interface des PI, niemals via eth0-Interface (des PI) zustande kommen kann. Wie man das macht, musst Du raus bekommen oder bei AVM nachfragen. ;)

    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 ist etwas komplexer. Die 172.16.1.253 ist ein virtueller Debian Buster Server auf einen ESX, der ein Wireguard VPN zu meiner kleinen virtuellen Serverfarm im Rechenzentrum aufbaut. d.h. dieser ist der zentrale Router für alle Rechner im 172.16.1.0/24 Netz. Der 172.16.1.253 hat eine default Route zur Fritzbox (Fritzbox hat die 172,16,1,254). Die Fritzbox hat ein entsprechenden Portforwarding für das VPN sowie u.a. auf meinen sekundären DNS Server. Der primäre steht im Rechenzentrum. Da der Fritzbox für das DHCP nur der Bereich und die DNS Server beizubringen ist aber kein default Router (der will sie selber sein, hat sie für das VPN Netz und das Netz dahinter entsprechende Routing Einträge. An meinem alten Standort war das einfacher, da hatte ich nur ein DSLModem und den Rest hat der DEBIAN Linux Router mit entsprechender Firewallkonfig gemacht. Jetzt mit den schönen schnellen VDSL bin ich auf die Fritzbox angewiesen oder auf einen 500 EUR teueren LANCOM Router, der ist mir zu teuer.

    Aber wie gesagt bin ja am Stückwiesen Aufbau eines zweiten Systems, ich poste das Log hier sobald ich durch bin.

    Ansonsten bin ich schon am überlegen das DHCP von der Fritzbox runter zu nehmen und auf einen der Server zu installieren. Wobei da ich das DHCP ja nur im WLAN für Smartphone und mal eine Gast bzw. Notebook brauche gibt das nicht viel Sinn. Alles andere hat ja feste Adressen, wie auch der PI sie bekommen sollt bzw. hat.

    Die Verbindungen in die weite Welt funktionieren ja auch über den Umweg über den .253, wobei der ja ein Reroute mach, d.h. er gibt den System das raus will an, dass der bessere Weg direkt über die Fritzbox geht, sieht man schön beim Ping.

  • Die 172.16.1.253 ist ein virtueller Debian Buster Server auf einen ESX, der ein Wireguard VPN zu meiner kleinen virtuellen Serverfarm im Rechenzentrum aufbaut. d.h. dieser ist der zentrale Router für alle Rechner im 172.16.1.0/24 Netz. Der 172.16.1.253 hat eine default Route zur Fritzbox (Fritzbox hat die 172,16,1,254).

    Ok, das ändert nichts an dem was ich geschrieben habe. Der PI hat auch via wlan0-Interface, keinen arp-cache-Eintrag für die IP-Adresse der FritzBox (172.16.1.254):

    Code
    pi@CAN:~ $ ip n s
    172.16.1.104 dev wlan0 lladdr 68:5b:35:be:db:a1 STALE
    
    172.16.1.242 dev eth0 lladdr 00:0c:29:ef:6b:48 STALE
    172.16.1.254 dev eth0 lladdr f0:b0:14:b7:cd:bb REACHABLE
    172.16.1.104 dev eth0 lladdr 68:5b:35:be:db:a1 REACHABLE
    172.16.1.101 dev eth0 lladdr 40:3f:8c:1a:a3:0f STALE
    172.16.1.253 dev eth0 lladdr 00:0c:29:43:09:9d STALE
    
    172.16.1.101 dev wlan0 lladdr 40:3f:8c:1a:a3:0f STALE

    Teste mal (auf deinem PI) mit und ohne Kabelverbindung und immer vorhandener WLAN-Verbindung von deinem PI zur FritzBox, ob die IP-Adresse 172.16.1.254 der FritzBox, direkt erreicht werden kann:

    Code
    sudo arping -c 3 -I wlan0 172.16.1.254

    Evtl. arping noch installieren:

    Code
    sudo apt-get install iputils-arping

    Wie ist nach dem arping, auf deinem PI die Ausgabe von:

    Code
    arp -av

    ?

    EDIT:

    Teste mal auf deinem PI bei vorhandener WLAN-Verbindung, mit und ohne Kabelverbindung, ob das eapol-Rekeying (... im Zeitabstand i. d. R. von 10 Minuten) statt findet bzw. angezeigt werden kann:

    Code
    sudo tcpdump -vvveni wlan0 ether proto 0x888e

    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

    2 Mal editiert, zuletzt von rpi444 (24. März 2020 um 14:19)

  • Also weitere Erkenntnis, solange in der dhcpcd.conf nichts eingetragen ist kann ich Kabel ziehen und anstecken ohne dass es der WLAN Verbindung was macht. Sobald die festen Konfigurationen eingetragen sind ist das WLAN nach abziehen des Kabels tot, fängt sich aber sofort nach Reboot oder nach einiger Zeit ohne Reboot. Wenn ich die Fritzbox direkt eintrage dauert es nur nicht so lange.

    OK bei reiner DHCP Konfiguration ist ja die Fritzbox der Router.

    Das alles erst mal mit dem neu aufgebauten PI.

    Jetzt habe ich nochmal auf die ursprüngliche SD umgestellt und ich verstehe die Welt nicht mehr es tut mit und ohne Kabel mit und ohne Neustart. Ohne Neustart, Wartezeit die tut nicht weh. im Produktion wir da eh nichts umgesteckt.

    Danke nochmal für Deine Mühe und Zeit. Sollte das Installationslog noch interessieren bitte melden.

    Rainer

  • Jetzt habe ich nochmal auf die ursprüngliche SD umgestellt und ich verstehe die Welt nicht mehr es tut mit und ohne Kabel mit und ohne Neustart.

    Weil es jetzt tut, zeige auch mit und ohne Kabel, die Ausgabe von:

    Code
    arp -av

    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

  • Neu gebootet ohne Kabel. ssh Verbindung va WLAN

    Code
    pi@CAN:~ $ arp -av
    ? (172.16.1.104) at 68:5b:35:be:db:a1 [ether] on wlan0
    ? (172.16.1.242) at 00:0c:29:ef:6b:48 [ether] on wlan0
    Entries: 2      Skipped: 0      Found: 2

    Kabel angesteckt zusätzliche ssh Verbindung via Kabel

    Code
    pi@CAN:~ $ arp -av
    ? (172.16.1.242) at 00:0c:29:ef:6b:48 [ether] on eth0
    ? (172.16.1.242) at 00:0c:29:ef:6b:48 [ether] on wlan0
    ? (172.16.1.253) at 00:0c:29:43:09:9d [ether] on eth0
    igate.gerdakloos.de (172.16.1.254) at f0:b0:14:b7:cd:bb [ether] on eth0
    ? (172.16.1.104) at 68:5b:35:be:db:a1 [ether] on eth0
    ? (172.16.1.253) at 00:0c:29:43:09:9d [ether] on wlan0
    igate.gerdakloos.de (172.16.1.254) at f0:b0:14:b7:cd:bb [ether] on wlan0
    ? (172.16.1.104) at 68:5b:35:be:db:a1 [ether] on wlan0
    Entries: 8      Skipped: 0      Found: 8

    Neustart mit Kabel ssh Verbindung via Kabel

    Code
    pi@CAN:~ $ arp -av
    ? (172.16.1.242) at 00:0c:29:ef:6b:48 [ether] on eth0
    igate.gerdakloos.de (172.16.1.254) at f0:b0:14:b7:cd:bb [ether] on eth0
    ? (172.16.1.104) at 68:5b:35:be:db:a1 [ether] on eth0
    ? (172.16.1.253) at 00:0c:29:43:09:9d [ether] on eth0
    Entries: 4      Skipped: 0      Found: 4
    pi@CAN:~ $ 

    Die 242 ist der Nameserver die 104 mein MAC

  • Neustart mit Kabel ssh Verbindung via Kabel

    Code
    pi@CAN:~ $ arp -av
    ? (172.16.1.242) at 00:0c:29:ef:6b:48 [ether] on eth0
    igate.gerdakloos.de (172.16.1.254) at f0:b0:14:b7:cd:bb [ether] on eth0
    ? (172.16.1.104) at 68:5b:35:be:db:a1 [ether] on eth0
    ? (172.16.1.253) at 00:0c:29:43:09:9d [ether] on eth0
    Entries: 4      Skipped: 0      Found: 4
    pi@CAN:~ $ 

    Die 242 ist der Nameserver die 104 mein MAC

    Erst der Neustart mit ssh-Verbindung via Kabel, zeigt auf deinem eth0-Interface, eine _direkte_ Verbindung zur FritzBox (IP-Adresse 172.16.1.254 und MAC-Adresse f0:b0:14:b7:cd:bb) an.

    Welches Subnetz hat dein WireGuard-VPN?

    Warum löst in deinem FritzBox-Subnetz die domain "igate.gerdakloos.de" auf die interne IP-Adresse 172.16.1.254 der FritzBox auf?

    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 (24. März 2020 um 15:27)

  • Logisch solange kein Kabel dran steckt ghat die eth0 auch noch keine IP Adresse.

    Wireguard Subnet ist 10.222.0.0/24

    gerdakloos.de ist eine meiner Domains, 172.16.1.254 hat historisch den Namen igate (Internetgateway, ist es ja auch), alle meine internen Server haben Namen und sind per DNS auflösbar. IP Adressen zu merken trainiert zwar die grauen Zellen, finde ich aber lästig. Das macht der 242, wobei der nur die Domains verwaltet von denen es sowohl lokal hier als auch per offizieller IP erreichbare Maschinen gibt und was der nicht kennt fragt er bei Google an.Die "offizelle" Namesauflösung für alle von mir verwalteten Domain privat und Kunden macht einer meiner Server im Rechenzentrum, der sekundäre offizielle DNS steht hier, ist aber nicht der 242.

    Einmal editiert, zuletzt von muekno (24. März 2020 um 16:24)

  • Logisch solange kein Kabel dran steckt ghat die eth0 auch noch keine IP Adresse.

    Dann hast Du nicht verstanden auf was ich hinaus will.

    Du schreibst:

    Zitat


    Neu gebootet ohne Kabel. ssh Verbindung va WLAN

    Das heißt jetzt aber nicht, dass auch der PI, erfolgreich nur per WLAN mit der FritzBox verbunden ist. Denn vom PI zeigst Du folgenden arp-cache-Eintrag:

    Code
    pi@CAN:~ $ arp -av
    ? (172.16.1.104) at 68:5b:35:be:db:a1 [ether] on wlan0
    ? (172.16.1.242) at 00:0c:29:ef:6b:48 [ether] on wlan0
    Entries: 2      Skipped: 0      Found: 2

    Für eine erfolgreiche WLAN-Verbindung, fehlt auf deinem PI zu diesem Zeitpunkt, noch folgender arp-cache-Eintrag:

    Code
    ? (172.16.1.253) at 00:0c:29:43:09:9d [ether] on wlan0

    Aber per Kabel ist dein PI auch nicht verbunden. Stellt sich die Frage, wie bzw. mit was warst Du auf deinem PI eingeloggt?

    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

  • Zitat

    Aber per Kabel ist dein PI auch nicht verbunden. Stellt sich die Frage, wie bzw. mit was warst Du auf deinem PI eingeloggt?

    für was soll er den Router brauchen? Eingelogt bin ich von meinen MAC aus via SSH mit der Adresse vom wlan0 des PI. Sowohl das Kabelgebundene Netz als auch das WLAN sind im 172.16.1.0/24. somit geht die Kommunikation direkt zwischen MAC und PI, damit reicht dem PI in seiner ARP Tabelle die MAC Adresse meines MAC, die zweite Adresse in der ARP Tabelle, die 242, ist die vom DNS Server, die holt er sich vermutlich gleich beim Start. Ich vermute Du gingst davon aus, dass das WLAN in einem anderen Subnetz als das kabelgebunden liegt.

Jetzt mitmachen!

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