[Problem] Plötzlich für einzelne WLAN Geräte keine Kommunikation mehr mit LAN Geräten möglich

[mohel_online]

Hallo an alle,

ich verzweifel hier seit ein paar Monaten, dass meine Fritzbox komische Faxen macht, die ich nicht erklären kann und wozu ich auch bisher nichts derartiges im Internet gefunden habe. Auch ein Hardwaretausch hat leider nicht geholfen.

Ich versuche euch mal mein Problem zu beschreiben:

Folgende Geräte sind direkt an der Fritzbox (kein Switch, Repeater) angeschlossen:
Gerät 1: Galaxy A5 (2017) mit Android 7.0 (Android-Sicherheitspatches 1.2.2018) verbunden per WLAN (5 und 2,4 GHz)
Gerät 2: Synology DS213+ mit DSM 6.1.5-15254 Update 1 mit 1Gbit LAN direkt an Fritzbox angeschlossen
Gerät 3: Dreambox DM800SE per LAN Kabel mit 100Mbit direkt an Fritzbox angeschlossen
Gerät 4: Hama DIR3101MS Internetradio und UPnP Client verbunden per 5 GHz WLAN
Gerät 5: Windows 10 Laptop verbunden per WLAN (5 und 2,4 GHz)
Gerät 6: Raspberry PI 3 Modell B mit Standard Raspbian per LAN mit 100MBit verbunden

Folgende zwei Problem-Fälle treten ca. alle 2 Tage bis 2 Wochen unabhängig voneinander auf. Manchmal gemeinsam, manchmal einzeln.
Alle können mit einem Restart der Fritzbox gefixed werden.
Ich konnte die Fälle leider noch nicht wiederholbar reproduzieren.
Zugriff auf Internet ist von allen Geräten in allen Fällen möglich.
Anbei finden Sie drei Fritzbox Support-Dateien:
1. Problem Fall 1
2. Problem Fall 2
3. Kein Problem nach Restart

Fall 1:
Kein Zugriff von Gerät 1 auf alle LAN Geräte (2,3,6) mehr möglich (u.a. Ping, CIFS, HTTP,..)
Gleichzeitig ist der Zugriff von Gerät 1 auf andere WLAN Geräte (4,5) und Internet ohne Einschränkungen möglich (Ping, http,...)
Mit deaktiviertem WLAN und Einwahl über Fritzbox-VPN über mobile Daten ist der Zugriff von Gerät 1 auf alle Geräte ohne Einschränkung möglich
Alle per LAN verbundenen Geräte (2,3,6) können Gerät 1 nicht pingen. Allerdings kommen von Gerät 6 auf 1 einige sehr wenige Ping-Pakete (ungefähr jedes 30. Paket) doch an:
pi@raspi:~ $ ping 192.168.22.151
PING 192.168.22.151 (192.168.22.151) 56(84) bytes of data.
64 bytes from 192.168.22.151: icmp_seq=31 ttl=64 time=10.0 ms
64 bytes from 192.168.22.151: icmp_seq=61 ttl=64 time=61.5 ms
64 bytes from 192.168.22.151: icmp_seq=91 ttl=64 time=94.5 ms
64 bytes from 192.168.22.151: icmp_seq=121 ttl=64 time=6.41 ms
64 bytes from 192.168.22.151: icmp_seq=151 ttl=64 time=293 ms
64 bytes from 192.168.22.151: icmp_seq=182 ttl=64 time=70.9 ms
64 bytes from 192.168.22.151: icmp_seq=213 ttl=64 time=19.1 ms
64 bytes from 192.168.22.151: icmp_seq=242 ttl=64 time=65.5 ms
64 bytes from 192.168.22.151: icmp_seq=272 ttl=64 time=65.2 ms
64 bytes from 192.168.22.151: icmp_seq=302 ttl=64 time=98.6 ms
64 bytes from 192.168.22.151: icmp_seq=332 ttl=64 time=26.0 ms

Neustart von Gerät 1 bzw. WLAN Neuverbinden oder Neustart anderer Geräte bringt keine Besserung.
Nach einem Restart der Fritzbox sind alle in Fall 1 beschriebenen Probleme behoben. Pings und andere Verbindungen sind wieder möglich.

Fall 2:
Gerät 4 kann Gerät 2 nicht per UPnP (SSDP) finden
Laut Fritzbox Capture (Netzwerkschnittstelle -> lan) sind die SSDP Pakete in Wireshark in beide Richtungen enthalten (M-SEARCH und NOTIFY), dennoch findet der Client den Server nicht
Gerät 4 findet aber Gerät 5 als UPnP Server (Windows Media Player Standardfunktion)
Gerät 5 kann per UPnP-Client auf Gerät 2 als uPnP Server zugreifen
Alle per LAN verbundenen Geräte (2,3,6) können Gerät 4 nur sehr schlecht pingen, es kommen nur sehr wenige Anfragen durch (ungefähr jedes 30. Paket). Hier ein Beispiel von Gerät 6 auf 4:
pi@raspi:~ $ ping 192.168.22.52
PING 192.168.22.52 (192.168.22.52) 56(84) bytes of data.
64 bytes from 192.168.22.52: icmp_seq=31 ttl=60 time=5.92 ms
64 bytes from 192.168.22.52: icmp_seq=65 ttl=60 time=5.52 ms
64 bytes from 192.168.22.52: icmp_seq=95 ttl=60 time=6.00 ms
64 bytes from 192.168.22.52: icmp_seq=125 ttl=60 time=5.56 ms
64 bytes from 192.168.22.52: icmp_seq=155 ttl=60 time=5.59 ms
64 bytes from 192.168.22.52: icmp_seq=185 ttl=60 time=5.52 ms
64 bytes from 192.168.22.52: icmp_seq=215 ttl=60 time=5.45 ms
64 bytes from 192.168.22.52: icmp_seq=245 ttl=60 time=5.45 ms

Die restlichen WLAN Geräte können ohne Probleme mit den LAN Geräten kommunizieren.
Die WLAN bzw. LAN Geräte untereinander können sich auch ohne Probleme pingen.
Auch der Ping von WLAN und LAN zur Fritzbox oder ins Internet selbst geht von allen Geräten ohne Probleme.
Neustart von Gerät 1 bzw. WLAN Neuverbinden oder Neustart anderer Geräte bringt keine Besserung.
Nach einem Restart der Fritzbox sind alle in Fall 2 beschriebenen Probleme behoben. Pings und UPnP Verbindungen sind wieder möglich.

Danke, mohel

 

[sf3978]

Allerdings kommen von Gerät 6 auf 1 einige sehr wenige Ping-Pakete (ungefähr jedes 30. Paket) doch an:

pi@raspi:~ $ ping 192.168.22.151
PING 192.168.22.151 (192.168.22.151) 56(84) bytes of data.
64 bytes from 192.168.22.151: icmp_seq=31 ttl=64 time=10.0 ms
64 bytes from 192.168.22.151: icmp_seq=61 ttl=64 time=61.5 ms
64 bytes from 192.168.22.151: icmp_seq=91 ttl=64 time=94.5 ms
64 bytes from 192.168.22.151: icmp_seq=121 ttl=64 time=6.41 ms
64 bytes from 192.168.22.151: icmp_seq=151 ttl=64 time=293 ms
64 bytes from 192.168.22.151: icmp_seq=182 ttl=64 time=70.9 ms
64 bytes from 192.168.22.151: icmp_seq=213 ttl=64 time=19.1 ms
64 bytes from 192.168.22.151: icmp_seq=242 ttl=64 time=65.5 ms
64 bytes from 192.168.22.151: icmp_seq=272 ttl=64 time=65.2 ms
64 bytes from 192.168.22.151: icmp_seq=302 ttl=64 time=98.6 ms
64 bytes from 192.168.22.151: icmp_seq=332 ttl=64 time=26.0 ms

Installiere mal auf deinem PI3 arping und arp-scan:

sudo apt-get install arp-scan iputils-arping tcpdump

und teste von deinem PI3 (mit arp statt mit icmp):

sudo tcpdump -vvveni <Interface-PI3> arp
sudo arping -c 30 -I <Interface-PI3> -s <IP-Adresse-PI3> <IP-Adresse-Gerät-im W/LAN>
sudo arp-scan --interface=<Interface-PI3> -RN --localnet
arp -av
ip n s

(ohne spitze Klammern).

 

[mohel_online]

Hi sf3978,

hier mal mein output, ich hoffe das hilft irgendwie

pi@raspi:~ $ sudo tcpdump -vvveni eth0 arp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:17:14.679906 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:16.455937 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:17.194090 b8:27:eb:f9:XX:XX > c0:25:06:36:XX:XX, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.1 tell XXX.XXX.XXX.12, length 28
20:17:17.194847 c0:25:06:36:XX:XX > b8:27:eb:f9:XX:XX, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply XXX.XXX.XXX.1 is-at c0:25:06:36:XX:XX, length 46
20:17:17.455923 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:18.455915 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:20.231958 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:21.231957 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:22.231931 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:23.455973 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:24.455935 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:25.455950 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:27.779981 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:28.779874 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:29.392587 d8:fc:93:a8:XX:XX > b8:27:eb:f9:XX:XX, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.12 (b8:27:eb:f9:XX:XX) tell XXX.XXX.XXX.124, length 46
20:17:29.392829 b8:27:eb:f9:XX:XX > d8:fc:93:a8:XX:XX, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply XXX.XXX.XXX.12 is-at b8:27:eb:f9:XX:XX, length 28
20:17:29.779965 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:31.296023 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:32.295938 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:33.295917 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:35.331965 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:36.331920 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:37.331927 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:38.427981 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:39.427900 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:40.427905 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
20:17:41.715955 c0:25:06:36:XX:XX > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has XXX.XXX.XXX.68 tell XXX.XXX.XXX.1, length 46
^C
27 packets captured
27 packets received by filter
0 packets dropped by kernel

pi@raspi:~ $ sudo arping -c 30 -I eth0 -s XXX.XXX.XXX.12 XXX.XXX.XXX.151
ARPING XXX.XXX.XXX.151 from XXX.XXX.XXX.12 eth0
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  76.554ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  98.715ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  23.843ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  46.392ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  70.331ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  196.283ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  16.229ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  41.294ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  269.357ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  190.733ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  112.349ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  33.316ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  56.963ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  80.325ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  104.036ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  25.791ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  50.086ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  176.692ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  106.772ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  22.176ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  3.425ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  66.854ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  90.170ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  114.012ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  36.329ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  61.078ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  84.741ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  313.837ms
Unicast reply from XXX.XXX.XXX.151 [90:97:F3:98:XX:XX]  235.261ms
Sent 30 probes (2 broadcast(s))
Received 29 response(s)


pi@raspi:~ $ sudo arp-scan --interface=eth0 -RN --localnet
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
XXX.XXX.XXX.1    c0:25:06:36:XX:XX       AVM GmbH
XXX.XXX.XXX.10   00:11:32:15:XX:XX       Synology Incorporated
XXX.XXX.XXX.52   00:22:61:53:XX:XX       Frontier Silicon Ltd
XXX.XXX.XXX.11   00:09:34:2b:XX:XX       Dream-Multimedia-Tv GmbH
XXX.XXX.XXX.202  c0:25:06:36:XX:XX       AVM GmbH
XXX.XXX.XXX.106  a0:e4:53:b8:XX:XX       (Unknown)
XXX.XXX.XXX.106  a0:e4:53:b8:XX:XX       (Unknown) (DUP: 2)
XXX.XXX.XXX.124  d8:fc:93:a8:XX:XX       (Unknown)
XXX.XXX.XXX.201  c0:25:06:36:XX:XX       AVM GmbH

10 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9: 256 hosts scanned in 3.390 seconds (75.52 hosts/sec). 9 responded

pi@raspi:~ $ arp -av
dreambox.fritz.box (XXX.XXX.XXX.11) auf 00:09:34:2b:XX:XX [ether] auf eth0
Galaxy-A5-2017.fritz.box (XXX.XXX.XXX.151) auf 90:97:f3:98:XX:XX [ether] auf eth0
fritz.box (XXX.XXX.XXX.1) auf c0:25:06:36:XX:XX [ether] auf eth0
DiskStation.fritz.box (XXX.XXX.XXX.10) auf 00:11:32:15:XX:XX [ether] auf eth0
laptop.fritz.box (XXX.XXX.XXX.124) auf d8:fc:93:a8:XX:XX [ether] auf eth0
Einträge: 5   Ignoriert: 0   Gefunden: 5

pi@raspi:~ $ ip n s
XXX.XXX.XXX.11 dev eth0 lladdr 00:09:34:2b:XX:XX REACHABLE
XXX.XXX.XXX.151 dev eth0 lladdr 90:97:f3:98:XX:XX STALE
XXX.XXX.XXX.1 dev eth0 lladdr c0:25:06:36:XX:XX STALE
XXX.XXX.XXX.10 dev eth0 lladdr 00:11:32:15:XX:XX STALE
XXX.XXX.XXX.124 dev eth0 lladdr d8:fc:93:a8:XX:XX REACHABLE

 

[sf3978]

hier mal mein output, ...

Der output (... beim bzw. nach dem arp-scan/arping) zeigt, dass die 5 Geräte, vom PI aus auch ohne ein Restart der FritzBox erreicht werden können:

Gerät 1: Galaxy A5 (2017) mit Android 7.0 (Android-Sicherheitspatches 1.2.2018) verbunden per WLAN (5 und 2,4 GHz)
Gerät 2: Synology DS213+ mit DSM 6.1.5-15254 Update 1 mit 1Gbit LAN direkt an Fritzbox angeschlossen
Gerät 3: Dreambox DM800SE per LAN Kabel mit 100Mbit direkt an Fritzbox angeschlossen
Gerät 4: Hama DIR3101MS Internetradio und UPnP Client verbunden per 5 GHz WLAN
Gerät 5: Windows 10 Laptop verbunden per WLAN (5 und 2,4 GHz)

XXX.XXX.XXX.10   00:11:32:15:XX:XX       Synology Incorporated
XXX.XXX.XXX.52   00:22:61:53:XX:XX       Frontier Silicon Ltd
XXX.XXX.XXX.11   00:09:34:2b:XX:XX       Dream-Multimedia-Tv GmbH
XXX.XXX.XXX.106  a0:e4:53:b8:XX:XX       (Unknown)
XXX.XXX.XXX.124  d8:fc:93:a8:XX:XX       (Unknown)

Wenn diese Geräte von PI aus, auch ohne arping/arp-scan permanent erreichbar sein sollen, dann mach mal für jedes dieser Geräte, einen statischen arp-cache-Eintrag in deinem PI.

 

[mohel_online]

ok, dann werde ich das mal probieren.

Ich habe heute leider die Fritzbox einmal neu starten müssen, d.h. es funktioniert jetzt erstmal wieder. Das dauert jetzt wieder so 2-14 Tage bis es wieder Probleme gibt, und dann werd ich das gleich testen. Und mich dann hier wieder melden...

Aber eine Frage: Glaubst du wirklich dass es da am arp-cache liegt? Weil ich habe ja auf allen LAN Geräten das gleiche Problem, d.h. ich müsste dort überall den Cache manuell pflegen. Beim PI ist das noch ohne Probleme möglich, bei der Synology NAS, Dreambox schon etwas schwerer
Ist da irgendwas bekannt, dass bei der Fritzbox da mit der Zeit ein Cache überläuft oder sonstiges?

Ich habe heute übrigens vor dem Neustart nochmal ein Test mit dem Laptop (jeweils alles per DHCP) gemacht:
1. Anschluss per WLAN: Ping auf Galaxy A5 ist möglich
2. WLAN deaktiviert
3. Anschluss per LAN: Ping auf Galaxy A5 ist nicht möglich
4. LAN abgesteckt, WLAN aktiviert
5. Ping ist wieder möglich

Also das ist echt sehr sehr komisch...

 

[sf3978]

Aber eine Frage: Glaubst du wirklich dass es da am arp-cache liegt?

Ja, denn es ist in meinem (W)LAN mit einer FritzBox (als Router) und Linux-Clients, schon immer so wie jetzt bei dir. Das Problem ist nicht die FritzBox, sondern die Clients (ohne avahi, zeroconf, etc.).

 

[mohel_online]

Aber ich hatte doch beim letzten Test auch einen Windows 10 Client per LAN direkt mit der Fritzbox verbunden und da hatte ich das gleiche verhalten. Wie passt das dann zusammen? Hat Windows 10 da ähnliche Probleme?

Ich habe heute übrigens vor dem Neustart nochmal ein Test mit dem Laptop (jeweils alles per DHCP) gemacht:
1. Anschluss per WLAN: Ping auf Galaxy A5 ist möglich
2. WLAN deaktiviert
3. Anschluss per LAN: Ping auf Galaxy A5 ist nicht möglich
4. LAN abgesteckt, WLAN aktiviert
5. Ping ist wieder möglich

 

[sf3978]

Hat Windows 10 da ähnliche Probleme?

Du kannst ja den arp-cache-Eintrag, bei deinem WIN10 anschauen. Ist dort ein Eintrag für das LAN-Interface und für das zu erreichende Gerät (IP-Adresse + MAC-Adresse) vorhanden?

 

[mohel_online]

Also seit heute Abend tritt das Problem wieder auf, also habe ich glaube den statischen ARP Eintrag gesetzt:

sudo arp -i eth0 -s XXX.XXX.XXX.53 90:97:F3:98:XX:XX

pi@raspi:~ $ sudo arp-scan --interface=eth0 -RN --localnet
#Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/                                                                                                                                                             )
XXX.XXX.XXX.202  c0:25:06:36:XX:XX       AVM GmbH
XXX.XXX.XXX.52   00:11:32:15:XX:XX       Synology Incorporated
XXX.XXX.XXX.54   00:09:34:2b:XX:XX       Dream-Multimedia-Tv GmbH
XXX.XXX.XXX.124  d8:fc:93:a8:XX:XX       (Unknown)
XXX.XXX.XXX.1    c0:25:06:36:XX:XX       AVM GmbH
XXX.XXX.XXX.53   90:97:f3:98:XX:XX       (Unknown)
XXX.XXX.XXX.201  c0:25:06:36:XX:XX       AVM GmbH

Leider habe ich beim Ping immer noch das gleiche Problem:

pi@raspi:~ $ ping XXX.XXX.XXX.53
PING XXX.XXX.XXX.53 (XXX.XXX.XXX.53) 56(84) bytes of data.
64 bytes from XXX.XXX.XXX.53: icmp_seq=31 ttl=64 time=56.0 ms
64 bytes from XXX.XXX.XXX.53: icmp_seq=61 ttl=64 time=88.7 ms
64 bytes from XXX.XXX.XXX.53: icmp_seq=91 ttl=64 time=18.8 ms
64 bytes from XXX.XXX.XXX.53: icmp_seq=121 ttl=64 time=50.0 ms
64 bytes from XXX.XXX.XXX.53: icmp_seq=151 ttl=64 time=82.3 ms
64 bytes from XXX.XXX.XXX.53: icmp_seq=181 ttl=64 time=113 ms
64 bytes from XXX.XXX.XXX.53: icmp_seq=211 ttl=64 time=178 ms
64 bytes from XXX.XXX.XXX.53: icmp_seq=243 ttl=64 time=46.7 ms

Ich finde es immer noch verwunderlich, dass fast immer genau jedes 30. Ping Paket durchkommt. Wenn ich parallel noch anderen Traffic verursache, dann werden es immer weniger.

PS: Nicht verwirren lassen, ich habe beim letzten Restart die DHCP IP Zuweisungen gelöscht, d.h die Geräte haben jetzt neue Adressen bekommen.