[gelöst] ein unerreichbarer Host

[smutbert]

Hallo liebe Leute,

ich habe da ein kleines Problem mit meinem kleinen Netzwerk mit momentan
- einem stationärem PC
- einem Laptop
- einem Cubietruck
- und einem System das mit hostapd und dnsmasq als Router/AP läuft

Soweit funktioniert alles, DHCP, Namensauflösung und jeder Host erreicht jeden. Nur den Cubietruck nicht! Der ist nach dem Start weder vom stationären PC noch vom Laptop aus erreichbar

Code: Alles auswählen

pc $ ping 192.168.1.247
PING 192.168.1.247 (192.168.1.247) 56(84) bytes of data.
From 192.168.1.200 icmp_seq=1 Destination Host Unreachable
From 192.168.1.200 icmp_seq=2 Destination Host Unreachable
...

sehr wohl aber vom Router/AP aus

Code: Alles auswählen

router $ ping 192.168.1.247
PING 192.168.1.247 (192.168.1.247) 56(84) bytes of data.
64 bytes from 192.168.1.247: icmp_seq=1 ttl=64 time=169 ms
64 bytes from 192.168.1.247: icmp_seq=2 ttl=64 time=191 ms
^C
--- 192.168.1.247 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 169.015/180.418/191.822/11.411 ms

Erst nach diesem erfolgreichen ping vom Router aus, ist er auch von PC und Laptop aus zu erreichen.

Nun weiß nicht einmal wo ich mit der Fehlersuche anfangen soll, weil sich alle anderen Hosts untereinander problemlos erreichen.

[BenutzerGa4gooPh]

2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 169.015/180.418/191.822/11.411 ms

Sind zwar nur 2 pings, aber der 2. braucht auch viel zu lange. Sollte so 2 ms sein.

Code: Alles auswählen

From 192.168.1.200 icmp_seq=1 Destination Host Unreachable

ARP-Request erfolglos oder keine Route.

Würde zuerst Netzwerk auf Cubie prüfen (ping, Logs), Routen (so er 2 NW-Anschluesse hat) und dann per
https://wiki.ubuntuusers.de/ethtool/
den NW-Adapter des Cubies mit Direktanschluss (fixe IPs) Laptop - Cubies. Der Cubie ist doch per Kabel und nicht per WLAN angeschlossen?

[guennid]

Ich hatte mal was Ähnliches. Die unerreichbare Maschine vergaß irgendwie, das sie in einem (Sub-)Netz war. Ist zu lange her, um mich genauer zu erinnern. Ist aber hier dokumentiert.

würgaround: ich hatte einen Dauerping (alle 5sec.) von dieser Maschine auf den Router (im Hauptnetz) eingerichtet. Das hat ihr Gedächtnis deutlich verbessert.

[dufty2]

würgaround: ich hatte einen Dauerping (alle 5sec.) von dieser Maschine auf den Router (im Hauptnetz) eingerichtet. Das hat ihr Gedächtnis deutlich verbessert.

Und selbst wenn, - wie Jana schon schrieb - 180 ms sind viel zu hoch, selbst für wireless.
Oder das Kistchen steht in Los Angeles

[TBT]

Im Router die Option "Geräte dürfen untereinander kommunizieren" ausgeschaltet? Bei einer Fritzbox gibt es so was z.B.

[MSfree]

Im Router die Option "Geräte dürfen untereinander kommunizieren" ausgeschaltet? Bei einer Fritzbox gibt es so was z.B.

Wenn sich diese Kommunikationssperre durch ein paar Pings umgehen ließe, kann man sie auch gleich weglassen. Ich habe da aber keine Ahnung, ob diese Sperre wirklich in der WLAN-Spezifikation enthalten ist oder ob das nur eine Beruhigungspille wie das "unsichtbare" WLAN sein soll.

Mein Verdacht wäre eher, daß irgendwelche Powersaving-Geschichten aktiv sind. Die sind oft viel zu aggresiv auf Strom sparen abgestimmt.

[smutbert]

@TBT
Das kann es eigentlich fast nicht sein. Der Router ist ein PC mit hostapd, dnsmasq (und iptables). Fehler oder Schwächen bei der Konfiguration gibt es da bestimmt, aber wie gesagt alle anderen Hosts reden auf Anhieb miteinander und ich hab in iptables und dnsmasq rein gar nichts hostspezifisches in der Konfiguration.

@Jana
Der Cubietruck hängt schon mit dem integrierten WLAN-Adapter im Netz. Die 180ms haben mich nicht geschreckt, der Cubietruck hat, möglicherweise auch wegen der niedrigen Taktfrequenz im Idle (?) stark schwankende Antwortzeiten zwischen etwa 20 und 300 ms.

Das mit den arp-Tabellen und Routen kann ich erst prüfen, wenn der Router wieder ausgeschaltet war, denn nach dem ersten Ping vom Router aus funktioniert ja alles (auch über einen Neustart den Cubietruck hinaus).

@Msfree
Das mit dem Stromsparen muss ich wohl auch noch überprüfen, auf mich erweckt es aber nicht den Eindruck als wäre das das Problem.

Der einzige Unterschied bei der Konfiguration ist, dass auf cubietruck und Router systemd-networkd zum Einsatz kommen, während auf PC und Laptop network-manager zuständig ist.

[smutbert]

Das einzige was mir auffällt ist auf dem Laptop

Code: Alles auswählen

# arp -a
router (192.168.1.1) at dc:81:da:9d:4f:15 [ether] on wlp2s0
cubietruck (192.168.1.247) at <incomplete> on wlp2s0

wohingegen auf dem Router

Code: Alles auswählen

# arp -a
cubietruck (192.168.1.247) at 98:3b:11:a1:14:a4 [ether] on wlp2s0
laptop (192.168.1.175) at a1:af:24:49:a7:19 [ether] on wlp2s0

Dieses Mal habe ich auf dem Router den Cubietruck ein paar Sekunden lang anpingen (ca 25 Pakete) müssen bevor es auf dem Laptop richtig ausgesehen hat (bis jetzt ist es meistens etwas schneller gegangen)

Code: Alles auswählen

# arp -a
router (192.168.1.1) at dc:81:da:9d:4f:15 [ether] on wlp2s0
cubietruck (192.168.1.247) at 98:3b:11:a1:14:a4 [ether] on wlp2s0

Netzwerkmäßig bin ich halt ein absoluter Noob und habe keine Ahnung was hier vorgeht.
Aber nachdem der Router/AP kein Problem hat den Cubietruck anzupingen, kann es doch nicht an den Stromsparmechanismen des Cubietruck liegen?

[BenutzerGa4gooPh]

Dieses Mal habe ich auf dem Router den Cubietruck ein paar Sekunden lang anpingen (ca 25 Pakete) müssen bevor es auf dem Laptop richtig ausgesehen hat (bis jetzt ist es meistens etwas schneller gegangen)

Aber nachdem der Router/AP kein Problem hat den Cubietruck anzupingen, kann es doch nicht an den Stromsparmechanismen des Cubietruck liegen?

Finde den Widerspruch (auch)!
So wie ich verstehe, ist der Cubie iausschließlich per WLAN ueber den Eigenbau-Router angeschlossen. Wobei LAN <-> WLAN "bridged" wurde.

Mir faellt derzeit ein:
Im Netz wird bei etlichen WLAN-Adaptern geraten, das Stromsparen per Konfig des Adapters/Treibers/Firmware auszuschalten.
Eher unwahrscheinlich: Das Spanning Tree Protocol (STP) der Bridge könnte nach Einschalten des Cubies etwas dauern (2...3 Minuten?), muss sich aber alleine finden. Bei Direkt-Anschluss von Hosts (also keine Netzwerkkomponenten/Schleifenmöglichkeit) an Switches (sind auch nur Bridges) schaltet man STP an den reinen Accessports oft ab.
Also:
Um Fehler am Router auszuschließen, verpasse doch mal deinem Lappi einen Hotspot und teste den Cubie daran.
Dann google mal nach dem WLAN-Adapter vom Cubie wegen Feinheiten, Stromsparen.

Die 180ms haben mich nicht geschreckt, der Cubietruck hat, möglicherweise auch wegen der niedrigen Taktfrequenz im Idle (?) stark schwankende Antwortzeiten zwischen etwa 20 und 300 ms.

Bissel extrem ... mit Hotspot auf Laptop desgleichen?

[dufty2]

So wie ich verstehe, ist der Cubie iausschließlich per WLAN ueber den Eigenbau-Router angeschlossen. Wobei LAN <-> WLAN "bridged" wurde.

Bin da bei Dir, nur da er auf dem PC bei der arp-Anzeige "wlp2s0" gepostet habe, vermute ich mal,
alle (Clients) sind in einem wlan.
Würde alternativ mal versuchen, den cubie per ethernet oder usb-tethering anzuschließen am router.

[mat6937]

Das einzige was mir auffällt ist auf dem Laptop

Code: Alles auswählen

# arp -a
router (192.168.1.1) at dc:81:da:9d:4f:15 [ether] on wlp2s0
cubietruck (192.168.1.247) at <incomplete> on wlp2s0

Teste mal von deinem cubietruck aus alle 2 Minuten, mit einem cronjob und dem _richtigen_ arping-Tool, ins (W)LAN einen (kostenlosen) arp-reply per broadcast zu senden. Z. B.:

Code: Alles auswählen

*/2 *	* * *	root /usr/bin/arping -q -c 3 -A -I <Interface> -s 192.168.1.247 255.255.255.255 > /dev/null 2>&1

Evtl. wird der cubietruck dann richtig in den arp-cache des Laptops eingetragen.

EDIT:

Ob der Laptop im (W)LAN den kostenlosen arping des cubietruck sieht, kannst Du auf dem Laptop mit z. B.:

Code: Alles auswählen

tcpdump -vvveni wlp2s0 arp

(oder gleichwertig) anzeigen lassen.

[smutbert]

Ja, alles WLAN.
Etwas noch, die Installation auf dem Cubietruck habe ich ziemlich weit abgespeckt, aber arp kann man dadurch doch nicht beeinträchtigen (oder doch)?

Darf ich noch eine kleine Zwischenfrage stellen, wie das mit der arp-Tabelle funktioniert:
Wird die nur aufgrund gezielten Nachfragens im Netz aufgebaut oder auch mit zufällig empfangenen Broadcasts oder anderen Paketen, die mitgehört werden?

und wie es scheint, hilft auch etwas Geduld:

Code: Alles auswählen

# ping cubietruck
PING cubietruck.localnet (192.168.1.247) 56(84) bytes of data.
From laptop.localnet (192.168.1.175) icmp_seq=1 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=2 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=3 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=4 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=5 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=6 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=7 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=8 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=9 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=10 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=11 Destination Host Unreachable
From laptop.localnet (192.168.1.175) icmp_seq=12 Destination Host Unreachable
64 bytes from cubietruck.localnet (192.168.1.247): icmp_seq=13 ttl=64 time=1086 ms
64 bytes from cubietruck.localnet (192.168.1.247): icmp_seq=14 ttl=64 time=63.0 ms
64 bytes from cubietruck.localnet (192.168.1.247): icmp_seq=15 ttl=64 time=83.6 ms
64 bytes from cubietruck.localnet (192.168.1.247): icmp_seq=16 ttl=64 time=150 ms
^C
--- cubietruck.localnet ping statistics ---
16 packets transmitted, 4 received, +12 errors, 75% packet loss, time 15300ms
rtt min/avg/max/mdev = 63.011/345.982/1086.515/428.774 ms, pipe 4

Vor dem ping gab es gar keinen, nach dem Ping einen korrekten arp-Eintrag für den cubietruck.

Den Rest muss ich noch ausprobieren.

[mat6937]

..., aber arp kann man dadurch doch nicht beeinträchtigen (oder doch)?

Nein, kann man nicht.

..., wie das mit der arp-Tabelle funktioniert:
Wird die nur aufgrund gezielten Nachfragens im Netz aufgebaut oder auch mit zufällig empfangenen Broadcasts oder anderen Paketen, die mitgehört werden?

Nein, die gezielten Nachfragen bzw. die Broadcasts funktionieren erst dann, wenn vorher die arp-requests/-replys funktioniert haben (... bzw. der arp-cache-Eintrag bereits zustande gekommen ist). D. h., kein Ping ohne vorherigem "arp-ping". Nicht der Ping hat den arp-cache-Eintrag veranlasst, sondern der "arp-ping". Für solche Zwecke kann man auch auf den Ping (icmp's) verzichten und gleich "arp-pings" (arp-Protokoll) machen. Sollte auch etwas schneller sein, als mit icmp.

Das kann man alles mit z. B. tcpdump (oder gleichwertig) veranschaulichen.

EDIT:

BTW: Wenn erforderlich bzw. sinnvoll, kann man arp-cache-Eintrage auch statisch (permanent) konfigurieren.

[BenutzerGa4gooPh]

Kleine Ergänzung zu ARP: Auch der Zielrechner (ARP-Reply-Sender) sollte seine ARP-Tabelle erweitern um einen Eintrag für Anfragerechner (ARP-Request-Sender). Nach einem erfolgreichen (ar)ping vom Router sollte dieser in Cubies ARP-Cache zu finden sein.

Übrigens hatten wir kürzlich ARP-Problem mit Broadcom-WLAN-Adapter und Tethering zu Windows Phone. Die Installation des richtigen Treibers hat geholfen. viewtopic.php?f=30&t=167734&hilit=Win+p ... 0#p1155468

[smutbert]

Vielen lieben Dank für die Hilfe und Aufklärung.

Es ist mir etwas peinlich das nicht schon früher ausprobiert zu haben, aber MSfree hat den Nagel bereits in Beitrag #6 auf den Kopf getroffen.
(Erst jetzt nach dieser merkwürdigen Verzögerung wollte ich das unbedingt prüfen. Ich hab allerdings auch etwas gebraucht um herauszufinden wie man das Stromsparen des WLAN-Controller am Cubietruck überhaupt deaktiviert, noch dazu auf einem dermaßen abgespeckten System, bei dem ungefähr jeder zweite Befehl, den ich gern verwenden würde, nur ein "command not found" zur Folge hat.)

Nun sind auch die ping-Zeiten auf etwa 1/100 bis 1/50 der davor üblichen gesunken.

Ein Nachteil ist, dass nun die Temperatur des SoC etwas höher ist, aber ich denke das kann ich verschmerzen.

edit:
meine Lösung ist eine systemd-unit »/etc/systemd/system/wlan-powersave.service« mit dem Inhalt

Code: Alles auswählen

[Unit]
Description=disable WIFI powersaving
After=network.target
Wants=network.target

[Service]
Type=oneshot
ExecStart=/sbin/iw dev wlan0 set power_save off

[Install]
WantedBy=multi-user.target