Blockieren von UDP 17

schmidtze

Cadet 1st Year
Registriert
Aug. 2017
Beiträge
9
Hallo,

ich habe in unserem Netzwerk u.a. einen AV-Receiver (Denon AVR-X1000) und 2 Amazon-Echo-Geräte. Na ja, zumindest hätte ich diese Echo-Geräte gerne im Netzwerk. Leider fällt bei deren Vorhandensein immer wieder die Musikwiedergabe über AirPlay (kommend von einem Synology-NAS) auf dem AV-Receiver aus. Nun habe ich dies dazu gefunden: amazon_echo_intermittently_knocks_hardwired/ Die Echo-Geräte versenden also immer wieder ein "UDP 17", was z.B. der Receiver anscheinend nicht verträgt. Momentan habe ich die Echos in unserem Gast-WLAN, dann passiert das natürlich nicht. Nur lassen sich dann über die Echos z.B. keine Geräte steuern, wie z.B. die Beleuchtung.

Meine Frage: Ich brauche ja nun wohl einen Managed Switch. Auf was genau muss ich da achten? Kann z.B. ein Gerät der unteren Preisklasse, z.B. von Netgear, für um die 30 bis 40 Euro solch ein Signal blockieren? Gibt es vielleicht eine Empfehlung für ein günstiges Gerät, welches das kann? Ich habe keinen blassen Schimmer auf welchen Fachbegriff ich bei den Spezifikationen der angebotenen Geräte achten muss... Vielleicht "Broadcast-Sturmkontrolle"?

Liebe Grüße und herzlichen Dank im Voraus
Schmidtze
 
Zuletzt bearbeitet von einem Moderator: (Zitat des unmittelbar vorangestellten Beitrags entfernt)
1. bei allen betroffenen Geräten Firmware aktualisieren falls vorhanden.
2. Tritt das Problem auch auf, wenn der Echo nicht im Netz hängt? Falls nein: Händler von dem du das Echo hast, also idR Amazon nicht nur darauf hinweisen sondern das Produkt reklamieren und erklären, dass es einen Mangel hat. Diesen deutlich beschreiben und eine Frist zur Behebung setzen (ausreichende Frist sind 3-4 Wochen). Amazon sollte da schon was schaffen als so großer Technikkonzern. Ggf. schlägst ja ne Preisminderung raus.

Broadcast-Sturm ist das falsche. Was du suchst nennt sich ACL (Access Control List) und ist nur bei managebaren Switchen verfügbar. Dort musst du dann per ACL einstellen, dass am Port wo dein Receiver hängt die IP des Echo nicht per UDP (Protocol) 17 (Port Number) hin darf. Das sieht beispielsweise dann so aus: https://kb.netgear.com/21714/How-do-I-set-up-an-IP-Access-Control-List-ACL-with-two-rules-using-the-web-interface-on-my-managed-switch.

Ich würde also bei Netgear oder TP-Link nach den einfachen managebaren Switchen suchen, heißt oft smart managed oder so. Zur Sicherheit dann noch im Datenblatt und/oder Handbuch nachlesen ob das Gerät wirklich ACLs kann.
 
Hallo,

super, danke für Deine Antwort, ACL ist ein Begriff mit dem ich dann was anfangen kann.

snaxilian schrieb:
2. Tritt das Problem auch auf, wenn der Echo nicht im Netz hängt?

nee, dann nicht. Kaum nehme ich so einen Echo wieder rein, dann fällt nach spätestens 1/2 oder ganzen Stunde wieder die Musik aus. Es sind definitiv die Echos. Der Receiver "erholt" sich dann auch nach etwa 10 Sekunden. Nur dann ist die Musik unterbrochen und die zuspielenden Programme (iTunes, MediaMonkey oder eben das NAS) bekommen das aber nicht mit.

snaxilian schrieb:
Diesen deutlich beschreiben und eine Frist zur Behebung setzen (ausreichende Frist sind 3-4 Wochen). Amazon sollte da schon was schaffen als so großer Technikkonzern. Ggf. schlägst ja ne Preisminderung raus.

Das ist aber nicht wirklich Dein Ernst, oder? Natürlich wird Amazon das Gerät zurücknehmen, da gehe ich mal von aus. Davon habe ich aber nüscht. Es scheint ja auch nur ganz wenige zu betreffen, habe länger suchen müssen, bis ich die genannte Webseite gefunden habe.

Du hast mir sehr geholfen, danke nochmals!

Viele Grüße
Schmidtze
Ergänzung ()

Hätte nämlich tatsächlich für knapp 40 Euro den falschen bestellt. Mit ACL wird es etwa 20 Euro teurer... :)
Ergänzung ()

Noch eine Ergänzung: Nee, das wird wohl so um die 100 Euro kosten. Na ja... :(
 
Es ist trotzdem ein Fehler und allein als Nettigkeit gegenüber anderen Kunden solltest du den Fehler melden. Oder das Gerät wirklich zurück geben und mal nen Google Home testen :)

Edit: Ein Netgear GS108T mit 8 Ports gibts für ca 60-65 € und sollte bereits mit ACLs umgehen können.
 
Zuletzt bearbeitet:
snaxilian schrieb:
Es ist trotzdem ein Fehler und allein als Nettigkeit gegenüber anderen Kunden solltest du den Fehler melden. Oder das Gerät wirklich zurück geben und mal nen Google Home testen :)

es ist nicht so einfach, da eine Stelle zu finden, an der man so einen Fehler melden kann. Sicher kann ich das Gerät reklamieren und den Grund angeben. Oder ich kann es in einem Amazon-Echo-Forum schildern. Das kann ich natürlich machen! Du glaubst doch aber selbst nicht, dass das dann in der Entwicklungsabteilung landet. Diese Geräte werden zu hunderttausenden verkauft, und ich hatte nur diese eine einzige Webseite über das Problem gefunden. Es gibt also nur sehr sehr wenige, die das Problem anscheinend haben. Bei einer Reklamation würde ich die Geräte zurückschicken und dann mein Geld wieder bekommen, bei Amazon würde sich da ansonsten gar nix tun, da bin ich sicher..

snaxilian schrieb:
Edit: Ein Netgear GS108T mit 8 Ports gibts für ca 60-65 € und sollte bereits mit ACLs umgehen können.
[/QUOTE]

Und schon wieder ein toller Tipp! :) Danke! Den hatte ich mir ja auch schon rausgesucht, war aber zu dem Schluss gekommen, dass der das nicht kann. Als günstigstes Gerät hatte ich dann den TP-Link TL-SG3210 gefunden, für 100 Euro. Aber Du hast wohl recht, der Netgear kann das wohl doch...

Viele Grüße
Schmidtze
 
WIe kommt man eigentlich auf den Gedanken, dass der Echo Schuld ist, wenn der Receiver abschmiert, wenn normaler Traffic im LAN ist?
 
Wenn etwas funktioniert und plötzlich nicht mehr, dann guckt man, was sich zwischenzeitlich geändert hat und der ein oder andere Nerd/IT'ler packt früher oder später Wireshark aus und dann fällt irgendwann auf dass kurz vor Aussetzer bestimmter Traffic vom Echo kommt.
 
aranax schrieb:
WIe kommt man eigentlich auf den Gedanken, dass der Echo Schuld ist, wenn der Receiver abschmiert, wenn normaler Traffic im LAN ist?

also hör mal, die Frage ist nicht wirklich ernst gemeint, oder? :D Da muss man kein Nerd sein und auch kein ITler. Echo rein ins Netz, Musik geht aus, Echo raus aus dem Netz und Musik bleibt an, so einfach ist das ;) Und was verstehst Du unter "normalem Traffic"? Was ist schon "normal"? Habe doch geschrieben, die Echos senden wohl etwa halbstündlich dieses UDP-17-Signal ("Quote of the Day"). Das mag "normal" sein, aber anscheindend eher ungewöhnlich, zumindest verträgt es halt der Receiver nicht... und mein Receiver (3 Jahre alt) ist nicht der einzige.

Gruß
Schmidtze
 
Mit UDP17 dürfte hier die Protokoll-ID 17 von UDP gemeint sein und nicht Port 17 (das wäre QOTD und hat keine Bedeutung mehr heutzutage).
 
Protokoll-ID 17 ist ganz allgemein UDP.

Bezüglich Fehler melden muss man sich vor allem darüber im Klaren sein welches Gerät nun wirklich fehlerhaft ist. Nur weil das Problem beim Receiver entsteht, sobald man die Echos ins Netzwerk einbindet, heißt es noch lange nicht, dass die Echos schuld sind. Es ist eben die Frage ob die Echos den Receiver in irgendeiner Form mit Unsinn bombardieren und ihn so aus dem Tritt bringen oder es ist der Receiver selbst, der völlig legitimen Traffic fehlerhaft bearbeitet - zB wenn er mit UDP 17/QOTD nicht umgehen kann obwohl das im IP-Standard RFC-definiert ist.

QOTD mag veraltet sein - wenn es denn überhaupt die Ursache ist - aber es ist nach wie vor gültig und wenn ein Gerät damit nicht umgehen kann (sei es als Sender oder Empfänger), dann ist das ein Fehler des Herstellers.
 
Evil E-Lex schrieb:
Mit UDP17 dürfte hier die Protokoll-ID 17 von UDP gemeint sein und nicht Port 17 (das wäre QOTD und hat keine Bedeutung mehr heutzutage).

Ja, das kann gut sein! Da mir das nix gesagt hat, hatte ich das unter Wikipedia - Liste der standardisierten Ports so gefunden. Oha, bekomme ich das denn dann wohl auch über ACL blockiert mit dem neuen Switch, wenn es kein Port sondern eine Protokoll-ID ist?

Gruß
Schmidtze
Ergänzung ()

Raijin schrieb:
Bezüglich Fehler melden muss man sich vor allem darüber im Klaren sein welches Gerät nun wirklich fehlerhaft ist.

Ja, da hast Du natürlich völlig Recht! vermutlich wird es tatsächlich eher der Receiver sein, könnte ich mir vorstellen. Übrigens gerät der ja auch nicht vollends aus dem Tritt, nach ein paar Sekunden ist wieder alles gut. Aber die zuspielende Software hat dann bereits das Signal erhalten, dass der Abspieler mal nicht mehr da war und bricht das Abspielen ab. So sind es schon 3 Beteiligte :D Vermutlich ließe sich da also schon in der abspielenden Software (wie gesagt z.B. iTunes oder MediaMonkey oder AudioStation auf dem NAS) lösen. Theoretisch. Umso mehr Beteiligte, je kleiner die Wahrscheinlichkeit, dass es einer löst, man kann es ja immer auf den anderen schieben. Keiner macht so richtig was falsch...

Ich muss nun die Geräte und die Software so nehmen wie sie sind und kann das Problem ja hoffentlich lösen...

Gruß
Schmidtze
 
Raijin schrieb:
QOTD mag veraltet sein - wenn es denn überhaupt die Ursache ist - aber es ist nach wie vor gültig und wenn ein Gerät damit nicht umgehen kann (sei es als Sender oder Empfänger), dann ist das ein Fehler des Herstellers.
Ich kann mir bei bestem Willen nicht vorstellen, dass irgendein Hersteller noch einen Server oder Client dafür implementiert. Sollte es sich tatsächlich um Traffic auf UDP-Port 17 handeln ist das natürlich trotzdem ein krasser Fehler im Gerät. Ich halte das aber für sehr unwahrscheinlich. Die Bezeichnung "UDP17" kommt so aus dem Reddit-Thread. Da halt wohl jemand schlicht Protokoll-ID und Port verwechselt.

Edit: Hab den Reddit-Eingangspost nochmal gelesen. Mit UDP17 scheint im Managed-Switch das UDP-Protokoll gemeint zu sein. Wenn man natürlich sämtlichen UDP-Traffic ausgehend von der IP-Adresse des Echos an bestimmte Switchports blockt, wird das zweifellos funktionieren, schön ist das aber nicht. Wie dort auch schon steht, ist das nur ein Workaround und keine Problemlösung. Schade, dass niemand dem Problem auf den Grund gegangen ist.
 
Zuletzt bearbeitet:
Ob nun Protokoll-ID oder Port, werde ich denn wohl beides über ALC ausfiltern können? Ja, ich seh das dann ja wohl, aber die Bestellung braucht noch etwas und ich würde mich schon gerne etwas beruhigen ;-)
 
Evil E-Lex schrieb:
Ich kann mir bei bestem Willen nicht vorstellen, dass irgendein Hersteller noch einen Server oder Client dafür implementiert. Sollte es sich tatsächlich um Traffic auf UDP-Port 17 handeln ist das natürlich trotzdem ein krasser Fehler im Gerät. Ich halte das aber für sehr unwahrscheinlich. Die Bezeichnung "UDP17" kommt so aus dem Reddit-Thread. Da halt wohl jemand schlicht Protokoll-ID und Port verwechselt.
Versteh mich nicht falsch, ich kann es mir auch nicht vorstellen. Wenn QOTD via UDP 17 nicht implementiert ist, sollte es auch keinerlei Probleme verursachen, weil eingehender Traffic einfach verworfen wird. Wenn es aber doch implementiert ist, dann muss man damit auch umgehen können. Das gilt sowohl für den Echo wie auch für den Receiver. Alle Geräte, die diese Funktion nicht implementiert haben, sollten einfach alle eingehenden Pakete verwerfen.

Evil E-Lex schrieb:
Mit UDP17 scheint im Managed-Switch das UDP-Protokoll gemeint zu sein. Wenn man natürlich sämtlichen UDP-Traffic ausgehend von der IP-Adresse des Echos an bestimmte Switchports blockt, wird das zweifellos funktionieren, schön ist das aber nicht.
UDP hat in der Tat die offizielle Protokoll-ID 17 wie oben schon festgestellt. So wirklich nachvollziehen kann ich das Problem jedoch immer noch nicht. Ich hab zwar den Traffic meines Echos nicht per Wireshark verfolgt, aber grundsätzlich sind sowohl UDP als auch TCP zielgerichtet. Heißt: Ein Echo und jedes andere Gerät, das mit UDP arbeitet, schickt UDP-Pakete an ein bestimmtes Ziel. Andere Geräte bekommen in einem geswitchten Netzwerk davon überhaupt nichts mit, weil der Switch die Pakete ausschließlich an dem Port ausgibt, über den das Ziel zu erreichen ist.
Stecken Echo und Receiver also am selben Switch, sollte der Receiver kein einziges Paket vom Echo sehen können, das nicht an ihn selbst gerichtet ist. Die vermeintliche UDP-Lösung erschließt sich mir daher auch nicht, weil der Echo dann ja völlig unmotiviert an irgendwelche IPs im Netzwerk irgendwelche Daten senden müsste.

Interessant finde ich den Hinweis auf Multicasts in dem Thread. Es kann natürlich sein, dass Echo und Receiver sich dort um Multicast-Adressen streiten oder, was in dem Falle wahrscheinlicher ist, ein Switch/Router im Netzwerk kann nicht mit Multicasts umgehen und setzt sie folglich als Broadcasts um. Das ist ein klassiches Problem bei der Verwendung von Multicasts in einem nicht-multicast-fähigen Netzwerk (zB bei IPTV). In dem Falle werden nämlich die eigentlich zielgerichteten Multicast-Streams als Broadcast-Streams verbreitet und fluten somit das komplette Netzwerk, was zu massiven Problemen führen kann.
Inwiefern Echo Multicasts nutzt, weiß ich aber nicht. Muss ich bei Gelegenheit mal mit WireShark analysieren.
 
Ist ja jetzt eine interessante Diskussion :)

Raijin schrieb:
was in dem Falle wahrscheinlicher ist, ein Switch/Router im Netzwerk kann nicht mit Multicasts umgehen und setzt sie folglich als Broadcasts um

wir haben tatsächlich mehrere Switches in der Wohnung verteilt, ich glaube 4. Ich könnte tatsächlich mal den Receiver direkt an den Router (Fritzbox) anschließen und die anderen Netzwerkstränge abnabeln und sehen was passiert...
 
Das ist natürlich nur ein Schuss ins Blaue, weil in dem Thread das Stichwort Multicast fiel. Ich habe keine Ahnung ob die Echos mit Multicast arbeiten. Wenn sie es tun, kann das aber zu beliebigen Problemen kommen, wenn ein Switch auf dem Weg des Multicasts nicht damit umgehen kann.

Fritzboxxen und Speedports können das von Haus aus, weil sie für IPTV geeignet sind. Ebenso alle anderen Alternativrouter für zB Telekom Entertain. Bei normalen Switches ist das schon etwas anderes. Bei 08/15 Switches (zB 8er @ <20€) ist das in der Regel nicht der Fall. Diese Switches bekommen dann den Multicast, wissen nicht was sie damit tun sollen und wandeln ihn in einen Broadcast um, der im gesamten Subnetz verteilt wird und es somit mit dem Stream flutet..
 
Raijin schrieb:
Bei 08/15 Switches (zB 8er @ <20€) ist das in der Regel nicht der Fall.

oh, will ich nicht ausschließen, dass ich da teils nicht das beste genommen habe, ich teste das einfach mal :)
 
Zurück
Oben