Über wlan keine Verbindung zu lokalen Rechnern

[jba]

Ich habe seit einiger Zeit immer wieder das Problem, dass ich von meinem Laptop (Xiaomi Air 12 mit Debian Stretch) über wlan zwar auf das Internet und meinen Router zugreifen kann, ansonsten aber lein anderes Gerät im lokalen Netz erreiche. Dieses Problem tritt unregelmäßig auf und dauert dann ein paar Minuten, während es die meiste Zeit aber keine Probleme gibt (d.h. normalerweise kann ich sowohl auf Internet als auch auf lokale Rechner zugreifen).

Ich bin mir jetzt nicht sicher, wo ich bei der Fehlersuche ansetzen muss: Bei meinem Laptop oder beim Router. Was könnte ich denn am Laptop überprüfen um zu schauen, woran es liegt?

Am Router habe ich schon überprüft, ob "wireless isolation" eingeschaltet ist. Ist es aber nicht. Diese Option würde nämlich genau das Fehlerbild erzeugen, dass ich manchmal habe.

Gruß,

Jürgen

[mat6937]

Ich bin mir jetzt nicht sicher, wo ich bei der Fehlersuche ansetzen muss: Bei meinem Laptop oder beim Router. Was könnte ich denn am Laptop überprüfen um zu schauen, woran es liegt?

Ich denke es wird so sein, dass wenn Du keinen Zugriff hast, auch kein (oder kein vollständiger) arp-cache-Eintrag für das entsprechende Gerät in deinem Laptop vorhanden ist. Du könntest z. B. einen statischen (permanenten) arp-cache-Eintrag konfigurieren.

[jba]

Danke für den Hinweis. Vom arp-cache habe ich noch nie etwas gehört aber jetzt herausgefunden, dass unterhalb der IP-Schicht des Netzwerks nicht mit IP-Adressen, sondern mit MAC-Adressen adressiert wird. Ich nehme an, der arp-cache ist dann der Zwischenspeicher der MAC-Adressen zu den IP Adressen. Richtig soweit?

Das ich mich noch nie damit beschäftigen musste spricht ja dafür, dass es sich um eine Basisfunktionalität der Netzwerk-Funktionen handelt, die normalerweise einfach nur funktioniert. Was könnte da denn schief gehen?

Und wie würde ich einen permanenten arp-cache erstellen? Das wäre dann ja auch nur ein workaround der mir auch nur bei meinen lokalen Geräten hilft, von denen ich ja IP und MAC kenne. Aber vielleicht wäre es ein Weg, um das Problem einzugrenzen. Funktioniert es mit permanentem arp-cache, muss man in dieser Richtung weiter suchen.

Deinem Post entnehme ich, dass der arp-cache auf meinem Laptop liegen müsste und eventuell nicht vollständig ist. Demnach wäre es also wirklich eine Problem des Laptops/debian und nicht des Routers, korrekt?

Gruß,

Jürgen

[mat6937]

Demnach wäre es also wirklich eine Problem des Laptops/debian und nicht des Routers, korrekt?

Ja. Siehe auf deinem Laptop die Ausgabe von:

Code: Alles auswählen

arp -av

oder die von:

Code: Alles auswählen

ip n s

Permanenter arp-cache-Eintrag kannst Du mit arp (oder gleichwertig) machen. Z. B.:

Code: Alles auswählen

arp -i <Interface> -d <IP-Adresse> && arp -i <Interface> -s <IP-Adresse> <MAC-Adresse>
arp -av

[jba]

Das sieht schon mal sehr eigenartig aus:

Code: Alles auswählen

root@lina:/home/jba# arp -av
? (192.168.0.10) auf 00:fc:8b:be:a0:5c [ether] auf wlp1s0
? (192.168.49.1) auf 00:fc:8b:be:a0:5c [ether] auf wlp1s0
? (192.168.0.1) auf b0:4e:26:66:32:bb [ether] auf wlp1s0
lisa.home.net (192.168.0.2) auf 80:ee:73:b8:00:19 [ether] auf wlp1s0
lana.home.net (192.168.0.16) auf cc:5d:4e:c9:fc:fc [ether] auf wlp1s0
Einträge: 5   Ignoriert: 0   Gefunden: 5
root@lina:/home/jba# 
root@lina:/home/jba# ip n s
192.168.0.10 dev wlp1s0 lladdr 00:fc:8b:be:a0:5c STALE
192.168.49.1 dev wlp1s0 lladdr 00:fc:8b:be:a0:5c STALE
192.168.0.1 dev wlp1s0 lladdr b0:4e:26:66:32:bb REACHABLE
192.168.0.2 dev wlp1s0 lladdr 80:ee:73:b8:00:19 STALE
192.168.0.16 dev wlp1s0 lladdr cc:5d:4e:c9:fc:fc REACHABLE
fe80::b24e:26ff:fe66:32bb dev wlp1s0 lladdr b0:4e:26:66:32:bb router STALE

192.168.0.10 ist ein fire-Stick. 192.168.49.1 demnach auch. Die IP des Routers ist aber 192.168.0.1 und die SubNetmask 255.255.255.0. Demnach sollte es also keine 192.168.49.1 geben (ich benutze DHCP). Ganz abgesehen davon, dass der Fire-Stick nicht zweimal auftreten sollte.

Scheint also wirklich was auf dieser Ebene schief zu laufen. Wenn ich das gleiche an meinem Desktop mache (auch debian stretch), wird mit 192.168.49.1 nicht angezeigt.

Liegt das Ganze jetzt am Laptop? Ist das ein Kernel-Fehler oder ein Problem mit dem Netzwerk-Treiber?

Jürgen

[mat6937]

Das sieht schon mal sehr eigenartig aus:

Scheint also wirklich was auf dieser Ebene schief zu laufen.

Das wissen wir noch nicht. Der arp-cache-Eintrag ist nicht eigenartig. Welche IP-Adresse hat das Gerät. auf das Du sporadisch nicht sofort zugreifen kannst?

[jba]

Welche IP-Adresse hat das Gerät. auf das Du sporadisch nicht sofort zugreifen kannst?

Habs mit verschiedenen probiert. Gingen alle nicht außer der 192.168.0.1 (Router). Z.B. die 192.168.0.16 ging nicht.

Der arp-cache-Eintrag ist nicht eigenartig.

Ok, in Bezug auf den Cache ist das nicht eigenartig. Aber woher kommt diese komische IP? Mein Router sollte die eigentlich nicht vergeben. Woher kommt die also? Und warum hat das Gerät zwei IPs?

Das ist ja auch nur der momentane Schnappschuss. Vielleicht passiert das gleiche ja auch manchmal mit anderen Geräten. Wenn z.b mein NAS (die 192.168.0.16) auf einmal unter einer falschen IP (192.168.49.x) geführt wird, kann ich es ja nicht mehr unter der richtigen erreichen. Ich denke, ich muss die Abfrage mit arp unbedingt dann noch einmal machen, wenn das Problem auftritt.

Jürgen

[mat6937]

Ok, in Bezug auf den Cache ist das nicht eigenartig

Du solltest den arp-cache-Eintrag immer sofort dann anschauen (und hier posten), wenn eine Verbindung nicht zustande kommt.

. Aber woher kommt diese komische IP? Mein Router sollte die eigentlich nicht vergeben. Woher kommt die also? Und warum hat das Gerät zwei IPs?

Hat das Gerät evtl. auch 2 NICs oder hat das Gerät Zugang zu einem 2. DHCP-Server?
Hat dein Laptop evtl. auch ein konfiguriertes Routing zum Subnetz dieser ominösen (2.) IP-Adresse? Siehe auf dem Laptop die Ausgabe von:

Code: Alles auswählen

ip a
ip -4 r

[jba]

Du solltest den arp-cache-Eintrag immer sofort dann anschauen (und hier posten), wenn eine Verbindung nicht zustande kommt.

Ok, mache ich und poste es dann.

Hat das Gerät evtl. auch 2 NICs oder hat das Gerät Zugang zu einem 2. DHCP-Server?

Meinst du das laptop oder den Fire Stick? Sollten beide nicht haben. 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?

Hat dein Laptop evtl. auch ein konfiguriertes Routing zum Subnetz dieser ominösen (2.) IP-Adresse? Siehe auf dem Laptop die Ausgabe von:

Code: Alles auswählen

root@lina:/home/jba# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
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 
       valid_lft 292sec preferred_lft 112sec
    inet6 fe80::6fe9:1c77:5582:8b05/64 scope link 
       valid_lft forever preferred_lft forever
root@lina:/home/jba# ip -4 r
default via 192.168.0.1 dev wlp1s0 proto static metric 600 
192.168.0.0/24 dev wlp1s0 proto kernel scope link src 192.168.0.31 metric 600 

Wenn ich das richtig interpretier nicht.

Jürgen

[mat6937]

Meinst du das laptop oder den Fire Stick?

Das Laptop, aber es ist nicht der Fall.

Evtl. ist die IP-Adresse 192.168.49.1 im Fire-Stick hard-codiert und wird dann auch den Geräten die mit dem Fire-Stick verbunden sind mitgeteilt, so dass diese IP-Adresse in deren arp-cache aufgenommen wird. Evtl. findest Du etwas dazu, in der Anleitung für den Fire-Stick.

Oder Du konfigurierst manuell ein Gerät (bzw. dessen NIC) so, dass dieses eine Verbindung zu 192.168.49.1 herstellen kann und gibst im Browser diese IP-Adresse ein. Evtl. auch einen Portscan auf 192.168.49.1 und die Ports 80 und 443 machen.

[habakug]

Hallo,

die IP 192.168.49.1 ist für die Fernbedienung des Fire (siehe auch Google-Chromecast).
Auch Software wie Kodi dockt da an.

Gruss, habakug

[jba]

die IP 192.168.49.1 ist für die Fernbedienung des Fire (siehe auch Google-Chromecast).
Auch Software wie Kodi dockt da an.

OK, das scheints zu sein. Ist aber trotzdem eigenartig, wenn der Router per DHCP eine IP zuweist, dass sich der Fire-Stick einfach mal eine zweite genehmigt, und das außerhalb des erlaubten Adressbereichs.

Aber egal, mit meinem ursprünglichen Problem scheint das nichts zu tun zu haben. Wenn das Problem wieder auftritt, werde ich mit arp und Co. Daten sammeln und hier posten.

Jürgen

[mat6937]

Ist aber trotzdem eigenartig, wenn der Router per DHCP eine IP zuweist, dass sich der Fire-Stick einfach mal eine zweite genehmigt, und das außerhalb des erlaubten Adressbereichs.

Ich denke nicht, dass diese IP vom Router per DHCP zugewiesen wird. Evtl. kommt die direkt aus dem Firestick, mit avahi/Zeroconf/Netbios oder gleichwertig.

[jba]

So, jetzt gabs wieder Probleme mit dem NAS (192.168.16) während der Router (192.168.0.1) erreichbar war:

Code: Alles auswählen

#!/bin/sh -v

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


arping -c 1 192.168.0.1
ARPING 192.168.0.1 from 192.168.0.31 wlp1s0
Unicast reply from 192.168.0.1 [B0:4E:26:66:32:BB]  3.773ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

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)

arp -av
? (192.168.0.10) auf <unvollständig> auf wlp1s0
? (192.168.0.8) auf 3c:bd:d8:fc:fe:1d [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
lana.home.net (192.168.0.16) auf cc:5d:4e:c9:fc:fc [ether] auf wlp1s0
Einträge: 5   Ignoriert: 0   Gefunden: 5

arp 192.168.0.1
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.0.1              ether   b0:4e:26:66:32:bb   C                     wlp1s0

arp 192.168.0.16
Address                  HWtype  HWaddress           Flags Mask            Iface
lana.home.net            ether   cc:5d:4e:c9:fc:fc   C                     wlp1s0

cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.0.10     0x1         0x0         00:fc:8b:be:a0:5c     *        wlp1s0
192.168.0.8      0x1         0x2         3c:bd:d8:fc:fe:1d     *        wlp1s0
192.168.0.1      0x1         0x2         b0:4e:26:66:32:bb     *        wlp1s0
192.168.0.9      0x1         0x2         3c:5c:c4:f7:a2:14     *        wlp1s0
192.168.0.16     0x1         0x2         cc:5d:4e:c9:fc:fc     *        wlp1s0

ip route show
default via 192.168.0.1 dev wlp1s0 proto static metric 600 
192.168.0.0/24 dev wlp1s0 proto kernel scope link src 192.168.0.31 metric 600 

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
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 
       valid_lft forever preferred_lft forever
    inet6 fe80::dbe3:aaf8:2f9b:c35e/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
    inet6 fe80::6fe9:1c77:5582:8b05/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

ip -4 r
default via 192.168.0.1 dev wlp1s0 proto static metric 600 
192.168.0.0/24 dev wlp1s0 proto kernel scope link src 192.168.0.31 metric 600 

ip n s
192.168.0.10 dev wlp1s0  FAILED
192.168.0.8 dev wlp1s0 lladdr 3c:bd:d8:fc:fe:1d STALE
192.168.0.1 dev wlp1s0 lladdr b0:4e:26:66:32:bb REACHABLE
192.168.0.9 dev wlp1s0 lladdr 3c:5c:c4:f7:a2:14 DELAY
192.168.0.16 dev wlp1s0 lladdr cc:5d:4e:c9:fc:fc REACHABLE
fe80::b24e:26ff:fe66:32bb dev wlp1s0 lladdr b0:4e:26:66:32:bb router STALE

[dufty2]

Denke, dass einfachste wird sein, wie bereits mat6937 in seinem ersten Beitrag geschrieben hat,
einen permanenten arp-cache-Eintrag zu machen.
So häufig wirst Du vermutlich die MAC/NIC Deines NAS nicht ändern.
Zur Sicherheit könntest Du die Liste um das Default-Gateway, firebird, laptop auch noch erweitern.

Ist nicht schön "workaround", aber bevor Du Dich in die Tiefen des WLAN stürtzt und ewig Zeit investierst ...

[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