WLAN Netzwerkverkehr für Diagnosezweck mithören

[cc_aero]

Hallo Liebe Leute,

ich habe in meinem Heimnetzwerk ein seltsames Problem:
Immer wenn eines unsere Android-Smartphones mit aktiver WLAN-Verbindung nach einiger Zeit herumliegen "entsperrt" wird, hängt sich die Netzwerksektion meines Denon AVR's auf. Das sich die Netzwerksektion aufhängt, erkenne ich daran das erstens die Verbindung am AVR weg ist und zweitens das das Portlämpchen am Switch erschlischt.
Der Support von Denon meint das ich den AVR einschicken solle, auf hifi-forum.de berichten jedoch mehrere Personen vom den selben Probem. Daher glaube ich (noch) nicht an einen einzelen Hardware-Defekt seitens des AVRs.
Das Problem ist zu 90% Reprodzierbar. In 10% der Reproduktionsversuche, blieb der AVR "wach".

Nun möchte ich gerne Herausfinden, welche Art von Netzwerkverkehr das ist, der den AVR zum Absturz bring. Nun möchte ich gerne den WLAN Netzwerkverkehr mitscheiden um eben das Problem zumindest finden zu können.

Für WLAN ist bei mir ein eigener AP Zuständig (D-Link DAP-2310 glaub ich), dieser hängt an meinem "Hauptswitch". Zwischen dem Denon AVR und meinen "Hautpswitch" hängt noch ein weiterer Switch. Die Switches sind gewöhnliche "dumme" Desktop-Switches ohne Management-Funktionen.

Wie kann ich nun den Netzwerkverkehr, der vom WLAN aus geht und bis zu meinem AVR reicht am besten mitscheiden/abhören? Software, Wireshark, wird klar sein. Kann ich den Verkehr von jedem anderen WLAN-Client mitscheiden? Oder benötige ich irgendeine Arte "Abzweigung" zwischen meinen AVR zu dem Switch?

Vielen Dank im Voraus

 

[Lawnmower]

Du brauchst ein Switch der es Dir erlaubt den Verkehr von Port X (z.B. wo der AP dran hängt) an einen anderen Port zu spiegeln (da wo dann der Diagnose Client dran hängt). Das geht aber nur mit Managed Switchs.

Aber um ehrlich zu sein wirst Du mit ein "bisschen Wireshark" das Problem nicht lösen können weil da werden soviele Infos angezeigt werden dass man da schon sehr erweiterte Netzwerk-Kenntnisse haben muss um da durchzublicken was überhaupt passiert. Und selbst wenn - die eigentliche Problematik lässt sich damit nicht lösen weil Du kannst damit weder das Verhalten bei Android noch bei Denon ändern.

Ich würde mir einen günstigen Full-Managed Switch kaufen und dann die Android Phones sowie den Denon in getrennte VLANs konfigurieren - das hilft vermutlich schon. Falls der D-Link kein VLAN Tagging unterstützt, dann eben nur den Denon isolieren (ich gehe davon aus der hängt per Netzwerkkabel im LAN weil Du schreibst ja die Port LEDs am Switch gehen aus).

https://geizhals.at/mikrotik-router...-managed-switch-rb260gs-a1147479.html?hloc=de
https://geizhals.at/tp-link-t2500g-...h-t2500g-10ts-tl-sg3210-a1623491.html?hloc=de
https://geizhals.at/tp-link-tl-sg32...managed-switch-tl-sg3216-a657270.html?hloc=de

 

[razzy]

du kannst dich mit deinem WLAN verbinden und alles mit Wireschark mithören, was auf dem selben AP an Verkehr im WLAN passiert.

Um den Traffic zu finden, der an deinem AVR ankommt und evtl. diesen zum Absturz bringt, müsstest du eigentlich einen SPAN - Port haben, denke aber nicht, dass dein "dummer" Switch so einen hat.

-> Ein AP funktioniert wie ein "HUB". Deshalb kannst du hier alles mitsniffen.
-> Ein Switch ist hier leider nicht so einfach mitzusniffen.

Ein Vorschlag von mir, was du versuchen könntest:

-> Falls du noch einen HUB zuhause hast, diesen einfach zwischen Switch und AVR stecken und deinen PC mit Wireshark einfach zusätzlich in den HUB, dann sollte es auch möglich sein, den Traffic zum AVR mitzusniffen

 

[Atkatla]

Die Aussagen, dass ein AP wie ein Hub funktioniert und dass man alles mithören könne, sind so nicht richtig.

Software, Wireshark, wird klar sein. Kann ich den Verkehr von jedem anderen WLAN-Client mitschneiden?

Theoretisch nur, wenn:
- der WLAN-Traffic nicht verschlüsselt ist und
- deine WLAN-Schnittstelle am abhörenden Client den Promiscious Mode ordentlich unterstützt (was bei manchen WLAN-Clients nicht immer der Fall ist) und
- du mit allen vorhandenen Funkschnittstellen assoziiert bist (was normalerweise mit regulären Clients nicht geht, da ein Client sich nur mit einer BSSID assozieren kann).

Wenn der Traffic verschlüsselt ist, kannst du die anderen Geräte am AP nicht abhören (von ein paar 802.11 Management Frames mal abgesehen.) Nur den Pre-Shared-Key zu haben, reicht nicht, da bei WPA zum eigentlichen Verschlüsseln und Entschlüsseln Pairwise Master und Transient Keys verwendet werden, die normalerweise für jedes assoziierte Endgerät unterschiedlich sind. Die KRACK-Attacke die vor ein paar Wochen durch die Meldungen geisterte, setze an dieser Stelle an. Du müsstest also die Verschlüsselung dann mal deaktivieren.

Ein AP funktioniert auch nicht wie ein Hub. Er forwarded oder filtert anhand der Destination-MAC-Adresse zwischen seinen (meist) drei Schnittstellen (LAN, WLAN 2.4 Ghz, 5 GHz), agiert also wie ein Switch oder eine Bridge. Ein Hub-ähnliches Verhalten tritt nur innerhalb der Clientgruppe auf, die sich an einer der Funkschnittstellen befinden. Wenn ein Paket von einem 2,4 Ghz Gerät zu einem anderen 2,4 GHz-Gerät gesendet wird, dann kann man dies nicht am LAN oder 5 GHz Port hören, außer das Paket ist ein Broadcast oder es wird geflutet (z.B. ARP-Anfragen). Nur wenn die Verschlüsselung deaktiviert ist und du nur eine Funkschnittstelle aktiv hast (z.B. 5 GHz deaktivieren) und du sicher bist, dass auf dem abhörenden Gerät der promisciusos mode ordentlich funktioniert, lohnt es sich an der WLAN-Seite mitzuhören.

Falls das nicht geht, wäre das Abhören auf der LAN Leitung zielführender. Hast du da Gigabit oder Fast Ethernet? Für Gigabit gibt es keine Hubs. Dort müsstest du wie bereits beschrieben, auf einen intelligenten Switch zurückgreifen und alle den Switch durchlaufende Daten auf einen Mirror-Port hinausspiegeln und @Lawnmovers Ansatz verfolgen, wobei sein zweiter Absatz aber das eigentliche Problem auf den Punkt bringt.

 

[Raijin]

Mal unabhänig vom sniffen des Traffics: Wenn der Hersteller dir vorschlägt, das Gerät einzuschicken und auch andere Besitzer das Problem haben, wäre es gar nicht so verkehrt, das Gerät einzuschicken. Kann ja auch ein Seriendefekt, o.ä. sein.

Normalerweise sollte kein Netzwerk-Traffic dieser Welt einen Port elektrisch abschalten. Höchstens durch massive DOS Attacken, die irgendwann den LAN-Controller zum Absturz bringen, o.ä.

Greifen die Smartphones denn auf den Receiver zu? Also steuert ihr den Receiver mit einer App, streamt ihr Musik hin und her, etc? Wenn ja, dann löse diese Verbindungen mal, App deinstallieren und ggfs auch mal testweise die IP des Receivers ändern. Wenn sich dann herausstellt, dass Remote-App xy das Problem verursacht, ist man zumindest schon mal ein bischen schlauer und kann a) mit dem App-Hersteller Kontakt aufnehmen und b) dem Receiver-Hersteller Infos für ein Update zukommen lassen.

 

[Atkatla]

Normalerweise sollte kein Netzwerk-Traffic dieser Welt einen Port elektrisch abschalten. Höchstens durch massive DOS Attacken, die irgendwann den LAN-Controller zum Absturz bringen, o.ä.

Es könnte viel simpler sein: mit einem Bug in der Firmware des AVR. Das Android broad- oder multicastet irgendwas beim Entsperren, der AVR verschluckt sich dran und setzt seinen LAN-Port auf down. Das kann dann aber auch nur AVR fixen.

 

[cc_aero]

Liebe Leute,

vielen Dank für eure Antworten.
Zum besseren Verständnis, hier mal meine Netzwerktopologie (schnell skizziert):

Wenn der Hersteller dir vorschlägt, das Gerät einzuschicken und auch andere Besitzer das Problem haben, wäre es gar nicht so verkehrt, das Gerät einzuschicken.

Das möchte ich erst alls letztes machen. Von machen Leuten habe ich schon gehört, das das Gerät bei anderen Problemen eingeschickt wurde und es mit der Meldung "kein Problem gfunden" + Kostenersatz für die Analyse zurückgekommen ist.

Greifen die Smartphones denn auf den Receiver zu? Also steuert ihr den Receiver mit einer App, streamt ihr Musik hin und her, etc?

Ja - zum einen gibt es die App von Denon zum steuern des AVRs und zum anderen verwenden wir die Spotify-App und via Spotify Connect zum AVR zustreamen. Allerdings wurden beide Apps schon deinstalliert und die Smartphones neu gestartet -> Problem ist geblieben.

Aber um ehrlich zu sein wirst Du mit ein "bisschen Wireshark" das Problem nicht lösen können weil da werden soviele Infos angezeigt werden dass man da schon sehr erweiterte Netzwerk-Kenntnisse haben muss um da durchzublicken was überhaupt passiert. Und selbst wenn - die eigentliche Problematik lässt sich damit nicht lösen weil Du kannst damit weder das Verhalten bei Android noch bei Denon ändern.

Ich würde zumindest gerne wissen wo das Problem herkommt. Ist es irgendein spezieller Port der das Problem verursacht? Evlt. ein Broadcast...? Mir ist klar das ich damit das Problem wahrschindlich nicht beheben kann, aber das "warum" interessiert mich brennend.

Ich würde mir einen günstigen Full-Managed Switch kaufen und dann die Android Phones sowie den Denon in getrennte VLANs konfigurieren

An sowas in die Richtung hab ich auch schon gedacht, mein AP würde auch VLANs unterstützen. Allerdings würde ich lieber den AVR von restlichen Netz isolieren. Da würde ich wahrscheinlich beide Switches (siehe Skizze) ersetzen müssen, oder? Der AVR sollte zumindest weiter ins Internet können und auf meine Musik Sammlung auf meinem Server zugreifen können (VLAN-Umgang unter Linux & PfSense ist mir halbwegs bekannt).

Falls du noch einen HUB zuhause hast, diesen einfach zwischen Switch und AVR stecken und deinen PC mit Wireshark einfach zusätzlich in den HUB, dann sollte es auch möglich sein, den Traffic zum AVR mitzusniffen

Irgendwo sollte ich noch einen alten 10Mbit HUB herumliegen haben -> Würde das zum testen reichen? Die Methode würde ws am besten sein, so sollte ich, wegen dem vorgeschalteten Switch, nur mehr Pakete erhalten die den AVR und den Sniffer-Client betreffen, oder?

EDIT:

Es könnte viel simpler sein: mit einem Bug in der Firmware des AVR. Das Android broad- oder multicastet irgendwas beim Entsperren, der AVR verschluckt sich dran und setzt seinen LAN-Port auf down.

Sowas in die Richtung vermute ich auch, allerdings habe ich die Firmware schon zu einer Version Downgegraded wo mir das Problem vorher nicht aufgefallen wäre -> Leider bleibt das Problem vorhanden.

 

[razzy]

Zum Thema HUB, ja, da haste nur den Traffic von und zu der MAC vom AVR.

Frage ist nur ob es funktioniert, da 10 Mbit. manche Switche gehen runter, manche nicht.

Einfach mal ausprobieren

 

[cc_aero]

Also die Idee mit dem HUB hat leider nicht so funktioniert, wie ich mir das vorgestellt hab. Der HUB kann zwar scheinbar mit dem Switch, aber der AVR bekommt über den HUB keine Verbindung.

Interessant war der Versuch trotzdem:
Der Hub hat eine Reihe von LEDs die die Netzwerkauslastung anzeigen sollen. Als ich den HUB versuchsweiße am Switch hängen hatte, ist die Auslastungsanzeige sofort auf 80-100% gegangen, sobald ich mein Handy entsperrt habe -> Sollten also Multicasts/Broadcasts sein.

Und tatsächlich: Wireshare am Laptop angeschmissen und etwas mal wenn das Android Handy entsperrt wurde kamen von dessen IP am laufenden Band Multicasts an die Adresse 224.0.0.251 -> also über das Protokoll MDNS mit Query auf *googlecast*

Hier ein Screenshot davon:


Wenn man das Smartphone entsperrt feuert also googe/chromecast los und der AVR dürft sich daran verschlucken. Eher eine Firmware-Problem als Hardware-Problem, oder?

 

[Raijin]

Multicasts werden von Switches, die eben keine Multicasts beherrschen, auf Broadcasts umgesetzt und können das Netzwerk daher fluten. So arbeitet beispielsweise Entertain von der Telekom mit Multicasts und wenn der Receiver an einem Switch ohne IGMPv3 angeschlossen ist, dann flutet dieser Switch das komplette Netzwerk mit dem gebroadcasteten Stream anstelle dass der Stream explizit nur an den Receiver ausgeliefert wird.

Wenn in deinem Netzwerk mit Multicasts gearbeitet wird, solltest du daher darüber nachdenken, deine Switches gegen IGMPv3-fähige Switches auszutauschen, zB den Netgear GS108E @ 40€. Es reicht, alles Switches, die in der Kommunikationskette des Multicasts liegen, durch solche Geräte auszutauschen.

Kurzes Beispiel:

Entertain. Am Router-LAN1 hängt ein Receiver. Ruft dieser einen TV-Stream ab, wird ein Multicast-fähiger Router den Stream nur an LAN1 ausliefern, den Receiver. An LAN2 hängt ein Switch und an diesem ein weiterer Receiver, an Port 7. Ruft der zweite Receiver einen Stream ab, würde der Router den Stream nur an LAN2 ausliefern und der dortige Switch wiederum nur an Port 7, wo der Receiver letztendlich angeklemmt ist. Hängt nun am Router-LAN3 noch ein Switch, dahinter aber kein Receiver, muss dieser auch kein IGMPv3 können, da bei ihm niemals ein Multicast ankommen würde, weil der Router ja schon nur an LAN1 bzw. LAN2 ausliefert, aber nicht an LAN3.

 

[cc_aero]

Meine Switches sind definitiv nicht IGMPv3 fähig, aber wissentlich verwende ich echte Multicast-Anwendungen nicht. Die Pakete die hier vom Android-Smartphone abgehen, sind Multicast DNS Anfragen um scheinbar GoogleCast-fähige Geräte im Netzwerk zu finden -> das diese Pakete schon das Netzwerk auslasten können?
An allen anderen Geräten (TVs/PCs) habe ich keinerlei Probleme und auch keine Geschwindigkeitsprobleme