Über wlan keine Verbindung zu lokalen Rechnern

[mat6937]

So, jetzt gabs wieder Probleme mit dem NAS (192.168.16) ...

Code: Alles auswählen

ping   -c 1 192.168.0.16
PING 192.168.0.16 (192.168.0.16) 56(84) bytes of data.
--- 192.168.0.16 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Code: Alles auswählen

arping -c 1 192.168.0.16
ARPING 192.168.0.16 from 192.168.0.31 wlp1s0
Sent 1 probes (1 broadcast(s))
Received 0 response(s)

Code: Alles auswählen

lana.home.net (192.168.0.16) auf cc:5d:4e:c9:fc:fc [ether] auf wlp1s0

Leider hast Du beim testen, vor dem ping/arping auf 192.168.0.16, nicht die Ausgabe von "arp -av" gezeigt.
Wie ist bzw. war der ping/arping auf 192.168.0.16, nach dem "lana.home.net (192.168.0.16) auf cc:5d:4e:c9:fc:fc" im arp-cache richtig eingetragen ist?

[jba]

Leider hast Du beim testen, vor dem ping/arping auf 192.168.0.16, nicht die Ausgabe von "arp -av" gezeigt.
Wie ist bzw. war der ping/arping auf 192.168.0.16, nach dem "lana.home.net (192.168.0.16) auf cc:5d:4e:c9:fc:fc" im arp-cache richtig eingetragen ist?

Ich habe da selber nichts eingetragen. Alle Befehle standen in einem Script und wurden direkt hintereinander ausgeführt. ich glaube nicht, dass sich zwischen ping/arping und "arp -av" etwas geändert hat. Nach Ausführung des Scripts ging der ping immer noch nicht.

Aber wenn ich das richtig interpretiere, ist der arp-cache correct gefüllt. Da etwas permanent einzutragen, würde also nichts ändern. Oder übersehe ich da etwas?

Jürgen

[mat6937]

Nach Ausführung des Scripts ging der ping immer noch nicht.

Aber wenn ich das richtig interpretiere, ist der arp-cache correct gefüllt.

Wie muss man das jetzt verstehen? Obwohl der arp-cache-Eintrag:

Code: Alles auswählen

lana.home.net (192.168.0.16) auf cc:5d:4e:c9:fc:fc [ether] auf wlp1s0

so ist, funktioniert der ping bzw. der arping noch immer nicht, auf die IP-Adresse 192.168.0.16?

[jba]

Wie muss man das jetzt verstehen? Obwohl der arp-cache-Eintrag:
CODE: ALLES AUSWÄHLEN

lana.home.net (192.168.0.16) auf cc:5d:4e:c9:fc:fc [ether] auf wlp1s0
so ist, funktioniert der ping bzw. der arping noch immer nicht, auf die IP-Adresse 192.168.0.16?

Exakt.

[mat6937]

Exakt.

Auf welchen lauschenden Port des NAS greifst Du (vom Laptop aus) zu?

[jba]

Habs mit http, NFS und ping versucht.

[mat6937]

Habs mit http, NFS und ping versucht.

Naja ping braucht keinen Port.

Wie ist jetzt auf deinem Laptop die Ausgabe von:

Code: Alles auswählen

nc -zv 192.168.0.16 80

?

EDIT:

Wenn Du erneut das Problem hast, dass Du dein NAS per tcp (Port 80) nicht erreichen kannst, dann teste/prüfe mal _ohne dein Script_ , wie folgt:

1. Kein ping oder arping!

2. arp-cache-Eintrag anschauen:

Code: Alles auswählen

arp -av

3. Jetzt erst den ping/arping:

Code: Alles auswählen

ping -c 3 192.168.0.16

Code: Alles auswählen

arping -c 3 -I wlp1s0 -s 192.168.0.31 192.168.0.16

4. Jetzt erneut den arp-cache-Eintrag anschauen:

Code: Alles auswählen

arp -av

5. und erneut ping, arping und nc ausführen:

Code: Alles auswählen

ping -c 3 192.168.0.16
arping -c 3 -I wlp1s0 -s 192.168.0.31 192.168.0.16
nc -zv 192.168.0.16 80

Die Ergebnisse hier posten.

[jba]

Wie ist jetzt auf deinem Laptop die Ausgabe von:

Hier die Ausgabe. Allerdings funktioniert gerade auch alles.

Code: Alles auswählen

root@lina:/home/jba# nc -zv 192.168.0.16 80
lana.home.net [192.168.0.16] 80 (http) open

Wenn Du erneut das Problem hast, dass Du dein NAS per tcp (Port 80) nicht erreichen kannst, dann teste/prüfe mal _ohne dein Script_ , wie folgt:

Ok, kann ich machen. Aber was spricht dagegen, das Ganze in ein neues Script zu packen?

Wenn das Problem auftritt merke ich es typischerweise daran, dass ich nicht per NFS auf das NAS oder meinen SAT-Receiver zugreifen kann, obwohl wlan läuft und Internet-Zugang gegeben ist. Oder daran, dass ich auf die web-Oberfläche der Geräte nicht zugreifen kann. Wenn das nicht klappt, teste ich meistens den ping. Ich kann mir aber nicht vorstellen, dass der ping irgendetwas ändert. Aber beim nächsten mal werde ich beim Auftreten von Problemen die genannten Tests durchführen.

Allerdings bin ich mir inzwischen ziemlich sicher, dass es am arp-cache nicht liegt. Gäbe es denn noch eine andere Möglichkeit, die am Laptop schief laufen kann? Und wenn ja, welche? Würde es helfen, mal einen backport-kernel zu installieren und damit zu testen? Stretch hat 4.9 und als backport gibt es 4.18.

Ich vermute aber, dass es garnicht am Laptop liegt, sondern am Router. Wahrscheinlich muss ich da mal weiter forschen.

Gruß,

Jürgen

[habakug]

Hallo,

zunächst ein Hinweis: Dieses home.net ist keine so gute Idee, das gibt es nämlich da draussen:

Code: Alles auswählen

$ dig lana.home.net

;; ANSWER SECTION:
lana.home.net.		300	IN	A	162.249.18.116

Weiterhin ist erst noch IPv6 des Providers im Spiel:

Code: Alles auswählen

2: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether a0:c5:89:95:5f:b5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.31/24 brd 192.168.0.255 scope global wlp1s0
       valid_lft forever preferred_lft forever
    inet6 2a01:c22:b42d:6e01:8e15:483f:4328:d7c6/64 scope global noprefixroute dynamic                <------------- Provider IPv6
       valid_lft 292sec preferred_lft 112sec
    inet6 fe80::6fe9:1c77:5582:8b05/64 scope link 					<---------- Local Link
       valid_lft forever preferred_lft forever

Später sind da nur noch LocalLink-Adressen und das DAD (Duplicate Adress Detection) springt an:

Code: Alles auswählen

2: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether a0:c5:89:95:5f:b5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.31/24 brd 192.168.0.255 scope global wlp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::9146:c039:c454:5d4f/64 scope link tentative dadfailed                                             <------------ DAD schlägt an
       valid_lft forever preferred_lft forever
    inet6 fe80::dbe3:aaf8:2f9b:c35e/64 scope link tentative dadfailed                                              <------------ DAD schlägt an
       valid_lft forever preferred_lft forever
    inet6 fe80::6fe9:1c77:5582:8b05/64 scope link tentative dadfailed                                              <------------ DAD schlägt an 
       valid_lft forever preferred_lft forever

Im netz gibt es einen Router mit DHCP und einen wlan-Extender (ist per Kabel am Router angeschlossen), bei dem dann DHCP abgeschaltet ist. kann es vielleicht mit IPV4/6 zu tun haben?

Der "wlan-Extender" ist wahrscheinlich nicht richtig konfiguriert und verursacht die Konflikte.

Gruss, habakug

[jba]

zunächst ein Hinweis: Dieses home.net ist keine so gute Idee, das gibt es nämlich da draussen:

OK, könnte das der Grund sein? Ich werde das mal ändern und dann weiter versuchen. "home.net" kommt aus /etc/hosts. Ich habe mich immer gefragt, was ich da eintragen soll, überall hieß es, dass es eigentlich egal ist. hab dann einfach home.net genommen. Wenn es aber zu Problemen führt, wenn man eine Domäne nimmt, die es schon gibt, ist es wohl doch nicht egal. Was wäre denn dann ein sicherer Eintrag? Etwas kryptisches, um sicher zu sein, dass es die Domäne nicht gibt?

Weiterhin ist erst noch IPv6 des Providers im Spiel:

Später sind da nur noch LocalLink-Adressen und das DAD (Duplicate Adress Detection) springt an:

Interessant, hilft mir jetzt aber nicht wirklich weiter. Was folgt daraus? kann ich das überprüfen?

Der "wlan-Extender" ist wahrscheinlich nicht richtig konfiguriert und verursacht die Konflikte.

Achso. Und in wiefern? Was könnte da falsch eingestellt sein?

Gruß,

Jürgen

[mat6937]

Aber was spricht dagegen, das Ganze in ein neues Script zu packen?

Du kannst es auch mit einem Script machen, wenn Du die Reihenfolge (siehe oben) einhälst

Und ja, ein Ping kann auch dafür sorgen, dass ein Gerät (IP-Adresse + MAC-Adresse) sofort in den arp-cache eingetragen wird. Deshalb verfälscht ein sofortiger Ping, den Test bzw. das Ergebnis.

[jba]

Wie ist es denn mit der Domäne in /etc/hosts? Bei der Debian Installation muss (oder kann?) man eine angeben. ich habe immer "home.net" angegeben, weil ich dachte, es macht eh keinen Unterschied.

Das einzige Problem, dass ich mirt vorstellen kann, ist, das ich den Rechner "lana.home.net", den es wohl irgendwo im Internet gibt, nicht mehr erreichen kann. Über meine hosts datei wird das immer auf meine lokale lana umgebogen. Aber mehr kann doch nicht passieren, oder?

Bisher sieht meine /etc/hosts so aus:

Code: Alles auswählen

127.0.0.1       localhost
127.0.1.1       lina.home.net   lina

192.168.0.16    lana.home.net           lana            # Fileserver / Zyxel

# weitere Einträge für lokale Rechner

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Sollte ich das wie folgt ändern?

Code: Alles auswählen

127.0.0.1       localhost
127.0.1.1       lina

192.168.0.16    lana            # Fileserver / Zyxel

# weitere Einträge für lokale Rechner

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

[mat6937]

Aber mehr kann doch nicht passieren, oder?

Ja, es ist ein "Schönheitsfehler". Die IP-Adresse 192.168.0.16 muss im (W)LAN trotzdem erreichbar sein.
Die Zeile in der "/etc/nsswitch.conf" entscheidet was zu erst abgefragt wird:

Code: Alles auswählen

hosts:          files dns

[habakug]

Hallo,

du solltest dich nicht an dem Hinweis zu dem Namen für dein Intranet festbeissen. Es ist nur ein Hinweis.

Was könnte da falsch eingestellt sein?

Hier wissen wir gerade mal, das dein Notebook eine IP von deinem "wlan-Extender" erhält. Mehr hast du ja bis jetzt nicht verraten.

Gruss, habakug

[jba]

du solltest dich nicht an dem Hinweis zu dem Namen für dein Intranet festbeissen. Es ist nur ein Hinweis.

Ok, d.h. das scheint es nicht zu sein. Trotzdem wärs ganz gut zu wissen, auf was du hinweist. Ist das jetzt ein Problem oder nicht? Meines Wissens ist das keins (läuft so schon seit ca. 15 Jahren), aber wenn doch, dann änder ich das natürlich.

Hier wissen wir gerade mal, das dein Notebook eine IP von deinem "wlan-Extender" erhält. Mehr hast du ja bis jetzt nicht verraten.

Die IP stammt nicht vom wlan-Extender. An dem ist DHCP abgeschaltet. Nur der Router vergibt IPs über DHCP.

Beide Geräte erzeugen 2,4/5 GHz wlans, alle mit der selben ssid.

Was wäre sonst noch wichtig?

Jürgen

[mat6937]

Was wäre sonst noch wichtig?

M. E. wäre es wichtig, den Mechanismus bzw. den Prozess zu kennen der bei Linux dafür sorgt, dass die anderen Geräte im (W)LAN, korrekt in den arp-cache (automatisch) eingetragen werden.

[jba]

M. E. wäre es wichtig, den Mechanismus bzw. den Prozess zu kennen der bei Linux dafür sorgt, dass die anderen Geräte im (W)LAN, korrekt in den arp-cache (automatisch) eingetragen werden.

Meinst du Network-Manager? Das ist alles out-of-the-box. Nichts spezielles.

Oder vermutest du den Fehler im kernel/Treiber? dann könnte ein neuerer Kernel (backport) eventuell helfen.

Jürgen

[mat6937]

Oder vermutest du den Fehler im kernel/Treiber?

Nein, das liegt nicht am Kernel/Treiber und auch nicht an deinem Gerät. Ich habe auch so ein "Problem" und es nur mit dem workaround (statischer arp-cache-Eintrag) gelöst.

[habakug]

Hallo,

Im netz gibt es einen Router mit DHCP und einen wlan-Extender (ist per Kabel am Router angeschlossen), bei dem dann DHCP abgeschaltet ist.

Ich versuche es nochmal.
Wenn du das vorhandene WLAN mit einem "WLAN-Extender" erweiterst, benötigst du kein Kabel das zum Router führt. Das ist an diesen Geräten verbaut, damit zusätzlich auch ein Gerät per Kabel angeschlossen werden kann.
Was passiert denn wenn du das Kabel absteckst?

Gruss, habakug

[jba]

Ich versuche es nochmal.
Wenn du das vorhandene WLAN mit einem "WLAN-Extender" erweiterst, benötigst du kein Kabel das zum Router führt.

Ok, wahrscheinlich war mein wording falsch. Es handelt sich aber nicht um einen Repeater, wie du zu gleuben scheinst. Der bräuchte natürlich kein Kabel.

Access-Point ist wahrscheinlich die richtige Bezeichnung. Er ist über Ethernet mit dem Router verbunden. Bekommt eine IP vom Router zugeteilt und macht selber kein DHCP. Er baut nur ein eigenes wlan mit der gleichen ssid auf. Je nachdem, welches dieser wlans (Router oder Access-Point) nun an einer bestimmten Stelle stärker ist, verbinden sich die Clients mit dem Router oder dem Access-Point. Der leitet dann den Verkehr an den Router weiter. Auch das funktioniert schon jahrelang ohne Probleme.

Das ist an diesen Geräten verbaut, damit zusätzlich auch ein Gerät per Kabel angeschlossen werden kann.
Was passiert denn wenn du das Kabel absteckst?

Garnichts. Der Access-Point ist in der ersten Etage und die Probleme traten bisher immer in ziemlicher Nähe des Routers auf. Das Laptop war also über das wlan des Routers verbunden. Würde ich das Kabel abziehen, wenn sich mein laptop mit dem Access-Point verbunden hat, habe ich zwar weiterhin noch wlan, kann aber weder das Internet noch die lokalen Geräte erreichen. Am Access-Point ist dann Schluss. Hatten wir auch schon, als eine Katze das Kabel durchgebissen hat.

Außerdem ist es ja so, dass das Problem nur sporadisch auftritt. Ich kann es nicht reproduzieren. D.h. wenn ich den AP abklemme und alles ok ist, weiß ich natürlich nicht, ob es irgendwann doch noch mal kommt. Außerdem müsste ich den AP ausschalten, denn sonst habe ich das oben beschriebene Problem.

Gruß,

Jürgen

[jba]

So, jetzt gabs wieder das Problem. Eigenartigerweise immer nach 23:00.

Code: Alles auswählen

arp -av
? (192.168.0.8) auf 3c:bd:d8:fc:fe:1d [ether] auf wlp1s0
lana (192.168.0.16) auf cc:5d:4e:c9:fc:fc [ether] auf wlp1s0
vusolo2 (192.168.0.27) auf 00:1d:ec:04:e9:35 [ether] auf wlp1s0
? (192.168.0.1) auf b0:4e:26:66:32:bb [ether] auf wlp1s0
? (192.168.0.9) auf 3c:5c:c4:f7:a2:14 [ether] auf wlp1s0
Einträge: 5   Ignoriert: 0   Gefunden: 5

ping -c 3 192.168.0.16
PING 192.168.0.16 (192.168.0.16) 56(84) bytes of data.

--- 192.168.0.16 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2055ms


arping -c 3 -I wlp1s0 -s 192.168.0.31 192.168.0.16
ARPING 192.168.0.16 from 192.168.0.31 wlp1s0
Sent 3 probes (3 broadcast(s))
Received 0 response(s)

arp -av
? (192.168.0.8) auf 3c:bd:d8:fc:fe:1d [ether] auf wlp1s0
lana (192.168.0.16) auf cc:5d:4e:c9:fc:fc [ether] auf wlp1s0
vusolo2 (192.168.0.27) auf 00:1d:ec:04:e9:35 [ether] auf wlp1s0
? (192.168.0.1) auf b0:4e:26:66:32:bb [ether] auf wlp1s0
? (192.168.0.9) auf 3c:5c:c4:f7:a2:14 [ether] auf wlp1s0
Einträge: 5   Ignoriert: 0   Gefunden: 5

ping -c 3 192.168.0.16
PING 192.168.0.16 (192.168.0.16) 56(84) bytes of data.

--- 192.168.0.16 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2046ms


arping -c 3 -I wlp1s0 -s 192.168.0.31 192.168.0.16                                                                                                                     
ARPING 192.168.0.16 from 192.168.0.31 wlp1s0                                                                                                                           
Sent 3 probes (3 broadcast(s))                                                                                                                                         
Received 0 response(s)                                                                                                                                                 
                                                                                                                                                                       
nc -zv 192.168.0.16 80                                                                                                                                                 
lana [192.168.0.16] 80 (http) : No route to host 

Der arp cache scheint vor und nach dem ping gefüllt zu sein.

Jürgen

[mat6937]

So, jetzt gabs wieder das Problem. Eigenartigerweise immer nach 23:00.

Code: Alles auswählen

arp -av
lana (192.168.0.16) auf cc:5d:4e:c9:fc:fc [ether] auf wlp1s0

Code: Alles auswählen

arping -c 3 -I wlp1s0 -s 192.168.0.31 192.168.0.16
ARPING 192.168.0.16 from 192.168.0.31 wlp1s0
Sent 3 probes (3 broadcast(s))
Received 0 response(s)

Code: Alles auswählen

                                                                                                                                                                                                                                                                                                           
nc -zv 192.168.0.16 80                                                                                                                                                 
lana [192.168.0.16] 80 (http) : No route to host 

[/code]
Der arp cache scheint vor und nach dem ping gefüllt zu sein.

Ja, am arp-cache liegt es nicht. Wie ist jetzt auf deinem Laptop die Ausgabe von:

Code: Alles auswählen

route -n

? Kannst Du jetzt von einem anderen Gerät in deinem (W)LAN, auf die IP-Adresse 192.168.0.16 zugreifen (... per Ping/arping oder per TCP-Port 80)?

[jba]

Kannst Du jetzt von einem anderen Gerät in deinem (W)LAN, auf die IP-Adresse 192.168.0.16 zugreifen (... per Ping/arping oder per TCP-Port 80)?

Kurz danach hats wieder funktioniert. Morgen werd ich das mal testen. Muss mir was überlegen, wie ich das mit dem Zugriff von einem anderen Gerät überprüfe. Am einfachsten ist es wohl, ich lass an meinem Laptop den ganzen abend pings durchlaufen und gebe dazwischen immer die Uhrzeit aus. dann kann man das gut erkennen.

Jürgen

[mat6937]

Am einfachsten ist es wohl, ich lass an meinem Laptop den ganzen abend pings durchlaufen ...

Ich denke nicht, dass das ein guter Test ist mit dem Dauerping, denn das könnte dazu führen, dass die Verbindung von diesem Laptop immer funktioniert. Oder ist das ein 2. Laptop?

[jba]

Ich denke nicht, dass das ein guter Test ist mit dem Dauerping, denn das könnte dazu führen, dass die Verbindung von diesem Laptop immer funktioniert. Oder ist das ein 2. Laptop?

Nein, ist der Desktop-Rechner. Ansonsten könnte ich dann einfach schnell hingehen und schauen, ob es vom Desktop aus funktioniert.

Jürgen