5 Port Switch der mit SAT IP funktioniert ?

[Starfoxfs]

Hallo zusammen,

ich suche einen 5 Port Switch der mit SAT IP Servern funktioniert.

Es gab hier schon einmal das Problem das bestimmte Switche nicht mit dem SAT IP Header zurecht kommen.

https://community.netgear.com/t5/Smart-Plus-Smart-Cloud-Switches/SAT-IP-und-diverse-Switche-IGMP-Pro... 

Ich habe derzeit einen 5 Port Switch von der Konkurrenz SG105E von TP-Link (neu gekauft), dieser hat im Monitoring der Ports immer wieder Bad Packets und somit bekomme ich Bildfehler im Fernsehprogramm "Fragmente".

Jetzt möchte ich mir einen anderen Switch zulegen, weil die Firma TP-Link mich relativ schnell im Support abgefertigt hat und einfach gesagt hat "Leider ist dies nicht möglich, und wir können nicht garantieren, dass andere Switch Ihre Anforderungen erfüllen."

Damit war für mich klar viel Hilfe kann ich hier nicht erwarten und der Switch geht wieder zurück.

Welche 5 Port Switches von der Firma Netgear würden hier funktionieren ?

Anscheined gibt es Probleme mit dem Header bei den SAT IP Servern in meinem Fall ein Megasat SAT IP Server 3.

Vielen Dank im voraus

[Starfoxfs]

Hier nochmal ein TCP Dump vom jeweiligen Gerät beim übertragen des Fernsehprogramms:

10:01:09.156190 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.156633 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.157102 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.157581 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.158046 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.172308 IP SAT-IP-Server.fritz.box.6971 > pi.hole.38401: UDP, length 180
10:01:09.174496 ARP, Request who-has SAT-IP-Server.fritz.box tell pi.hole, length 28
10:01:09.175110 ARP, Reply SAT-IP-Server.fritz.box is-at x:x:x:x:x:x (oui Unknown), length 46
10:01:09.175950 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.176392 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.176849 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.177315 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.177789 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.178258 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.196159 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328
10:01:09.196606 IP SAT-IP-Server.fritz.box.6970 > pi.hole.38400: UDP, length 1328

Dieser ARP Request gehört wohl zum Unicast/Multicast Header und ist wohl das Problem was der TP-Link eben nicht korrekt übertragen hat oder als RXBadPkt gekennzeichnet hat.

Jetzt eben meine Frage, welcher Netgear 5 Port Switch kann das korrekt bzw. wo kann man das einfach durchschleifen ohne Überprüfung Stichwort SGMP-Header Validation (disabled) ?

Würde das damit funktionieren ?

Ich frage vor dem Kauf weil ich nicht dauernd zurückschicken will.

[schumaku]

Was immer an so einem SAT-IP speziell sein soll? Eigentlich nichts, die Switchen müssen mit IGMP Multicast v2 (IPv4) und v3 (IPv4 und IPv6[==MLD!]) umgehen können, und ggf. IGMP Multicast für das entsprechende VLAN aktiviert haben.

Das können alle Netgear Smart und Managed Switches soweit perfekt.

Wozu immer der Pi-hole in dem IGMP Multicast Daten-Stream gut sein soll? Spätestens wenn die TV_Schauer beim Zappen sind wird es wohl schweierig...

Um welche TP-Link switches geht es denn hier wirklich?

Leider schnittpelst Du hier alles was informativ (MAC Adresse, OUI, ...) sein könnte raus... 

10:01:09.174496 ARP, Request who-has SAT-IP-Server.fritz.box tell pi.hole, length 28
10:01:09.175110 ARP, Reply SAT-IP-Server.fritz.box is-at x:x:x:x:x:x (oui Unknown), length 46

...und die Kristallkugel ist schon im Osterurlaub.

Grüsse aus der Schweiz,

-Kurt

PS. Das funktioniert alles auch perfekt auf einem sehr kleinen Non-Managed aber Konfigurierbaren Plus Switch - wobei ich diesen auf Grund der nötigen Leistung (nicht nur für IGMP Snooping) nur an den Endpunkten (nicht in der grösseren Infrastruktur) empfehlen kann.

[Starfoxfs]

Hallo,

naja speziell ist am SAT IP gar nix. Nur die Tatsache das er mit dem TP-Link SG105E nicht funktioniert hat.

Im Monitoring bekam ich für den SAT IP Server RXBadPackets.

Sobald diese RXBadpackets auftraten hatte ich Bildfehler in Form von Artefakten und Streifen.

Aktiviert war beim TP-Link Switch auch nur IGMP Snooping, ein VLAN war eigentlich gar nicht konfiguriert.

Aber es ging auch mit deaktiviertem IGMP Snooping nicht.

Ich hatte dann den SAT IP Server wieder direkt an meine Fritzbox 7590 angeschloßen und alles ging einwandfrei.

Mein Problem ist eben nur das ich im Wohnzimmer einen Switch für den SAT IP Server brauche weil noch mehr Geräte (TV, Nvidia Shield TV Pro) am Netzwerk hängen.

Der TP-Link Support verwieß eigentlich nur auf einen Forumsbeitrag:

Das war die Lösung von TP-Link:

Zitat: "

When the switch receives packets of 64 bytes, the untagged packet will be considered as "RxGoodPkt", while the tagged packet will be taken as "RxGoodPkt" and "RxBadPkt" together (the switch will still forward the tagged packets of 64 bytes). Thus you could see the "RxBadPkt" but not notice any bad performance on the switch. Please do not worry about this "RxBadPkt" on your switch, it will not block the network or affect the performance. "

Das ist toll das es den Network traffic nicht blocked oder die Performance beeinflusst.

Nur führt das eben zu Bildfehlern bei mir.

Deswegen die Frage welcher Netgear Switch funktioniert ? der TP-Link ist längst zurückgeschickt.

[schumaku]

---

@Starfoxfs wrote:

naja speziell ist am SAT IP gar nix. Nur die Tatsache das er mit dem TP-Link SG105E nicht funktioniert hat.

---

Macht denn dieser grosse unbekannte SAT IP Server denn auch wirklich IGMP Multicast, über den dann die TV- oder TV-Boxen den richtigen Live-Stream (per IGMP Multicast) bzw. Video-on-demand (VOD, UDP unicast) aktivieren können? Das sind so die grundsätzlichen Techniken, wie sie auch im Bereich IPTV von der Telekom, Swisscom, usw. benutzt werden.

---

@Starfoxfs wrote:

Im Monitoring bekam ich für den SAT IP Server RXBadPackets.

Sobald diese RXBadpackets auftraten hatte ich Bildfehler in Form von Artefakten und Streifen.

---

Ohne die Systeme näher zu kennen - schwierig eine Aussage zu machen.

---

@Starfoxfs wrote:

Aktiviert war beim TP-Link Switch auch nur IGMP Snooping, ein VLAN war eigentlich gar nicht konfiguriert.

Aber es ging auch mit deaktiviertem IGMP Snooping nicht.

---

Spannerderweise sagst Du ja, dass keine VLANs im Einsatz sind. Eine der Möglichkeiten scheidet also sofort aus.

Ob denn bei Deinem SAT IP Server wirklich IGMP Multicast verwendet wird bleibt also im Moment noch offen.

Falls das System dann wirklich ICMP Multicast verwendet, und der Anwender jetzt noch hingeht und IGMP Multicast dekativiert, führt das dazu, dass alle vom Server ausgesendeten Pakete (Frames) auf allen Ethernet (LAN) Ports heraus kommen, und perfiderweise auch auf alle Wireless Access Point Radios, somit nicht nur auf alle Netzwerkkabel, sondern auch in die Luft.

Diese Pakte schlagen in diesem Fall auch auf allen Geräten auf, dem Router, allen PCs, allen drahtlosen Geräten usw. auf. 

---

@Starfoxfs wrote:

Der TP-Link Support verwieß eigentlich nur auf einen Forumsbeitrag:

Das war die Lösung von TP-Link:

Zitat: "

When the switch receives packets of 64 bytes, the untagged packet will be considered as "RxGoodPkt", while the tagged packet will be taken as "RxGoodPkt" and "RxBadPkt" together (the switch will still forward the tagged packets of 64 bytes). Thus you could see the "RxBadPkt" but not notice any bad performance on the switch. Please do not worry about this "RxBadPkt" on your switch, it will not block the network or affect the performance. "

---

Das ist eine "wunderbare" implementierung, bei der zwei Zähler nach oben gehen, z.B. auch wenn Getaggte-VLAN Pakete oder JumboFrames über den Switch gehen 8-) Sinn und Unsinn bleibt den Erfindern, den Supportern dieser Firma bzw. den geneigten Lesern überlassen.

Es handelt sich gemäss unbestätigten Informationen weitgehend um Switches, welche Unmanaged sind, also ohne Managed Switch Core auskommen müssen. Die Kontrolle (Web UI oder App) erfolgt durch einen uC der 8051-Klasse, dieser "hört" dauernd den gesamten Netzwerkverkehr ab, kann dann dem Unmanaged Switch (wie er auch in vielen Geräten wie auch den meisten Routern verbaut sind) ganz einen oder meherere Ports einfach einem bestimmten VLAN zuweisen. So wird auf praktisch allen Routern sowohl LAN wie auch WAN/Internet über einen clever konfigurierten Switch geführt, und so sichergestellt, dass da eben nur der jeweilen erlaubte LAN- oder Internet-, (oder z.B Gast-Netzwerk-)Verkehr durchgeht. Ja, auch die einfachen Netgear Plus Switches (GSxxxExx, MSxxxExx) sind genauso aufgebaut. 

So muss ich Dich jetzt enttäsuchen - ich kann Dir also Deine Frage nicht sofort beantworten - ohne mehr über Dein unbekannten SAT IP Server, den oder due zugehörigen "Empfänger", und dessen Konfigurationen zu erfahren.

Ebenfalls im Dunkel bleiben die zwei ARP Dignes, welche Du weiter oben erwähnt hast, aber eisern über die OUI oder die MAC Adresse (den Hersteller-Teil) schweigst.

In diesem Sinne wünsche ich Dir mal schöne Ostern!

[Starfoxfs]

Die Geräte sind kein Geheimnis.

Der SAT IP Server ist der Megasat SAT-IP-Server3

Umwandlungsgerät ist ein Raspberry Pi4B mit TVHeadend

Endgerät eine Nvidia Shield TV Pro 2019er Modell

Der SAT IP Server 3 steht im Wohnzimmer und geht dann über den Switch und die Fritzbox 7590 an den Raspberry Pi, dieser schickt die htsp Signale zurück über den Switch ins Wohnzimmer an die Nvidia Shield TV Pro mit Kodi drauf.

Das ist die Ausgangslage.

Ob der SAT IP Server 3 Multicast, Unicast oder sonstiges schickt kann ich nicht sagen. Die Übertragung der Signale findet über UDP zum Raspberry PI statt.

Das oben war nur ein Ausschnitt von tcpdump was auf dem Raspberry zum mitschneiden der gesendete Daten des SAT-IP-Server gemacht wurde.

Es war nur eine Vermutung von mir das diese 2 Pakete zu diesem RXBadpacket geführt haben weil beide kleiner 64 bytes sind.

Pihole spielt dabei eine Rolle weil alle eingehenden Netzwerkdaten beim Raspberry erstmal durch das Pihole laufen. Die MAC Adresse habe ich halt mal rausgekürzt, ist aber der SAT IP Server.

Ebenfalls schöne Ostern 🙂

[schumaku]

Ganz kurz nochmals. TVheadend verwendert UDP Unicast, ohne Multicast (d.h. ohne gleichzeitige Verteilung des identischen Signales), so sich das in den letzten Jahrzehnte nicht grundsätzlich geändert hat (soweit ich das sehe). Wenn also im ganzen Haus sagen wir ARD live läuft, wird der RTP-Stream mehrfach vom Headend ausgesendet, also leicht zeitlich versetzt. Jeder handelsübliche Switch sollte damit klar kommen, so der Megasat SAT-IP-Server3 als RTP-"Sender" und RTP-"Verteiler" das auch packt. All das "moderne" ICMP Multicast ist also unbeteiligt, es braucht wohl auch keine Switches, welche damit umgehen müssen - anders als wenn IPTV zu Dir über Deinen Internet-Anschluss kommt.

[Starfoxfs]

Ich hab mir jetzt mal den Netgear GS105E bestellt, mal sehen ob es damit funktioniert.

Wie gesagt mit dem TP-Link gab es Bildfehler und es lag definitiv am TP-Link Switch.

Aktuell läuft das System einwandfrei ohne Switch, das Netzwerksignal geht halt momentan über WLAN an die Nvidia Shield TV Pro.

Der SAT-IP-Server3 hängt an der Fritzbox7590 mit CAT6 Kabel.

Ich werde berichten, am Mittwoch kommt der Netgear Switch an.

[Starfoxfs]

So heute ist der Netgear GS105Ev2 gekommen.

Leider das gleiche Problem wie beim TP-Link Switch.

Sobald ich unter System->Management->Port Status den Port 2 in diesem Fall der MegaSat Sat-IP-Server 3 auf 100M Full stelle gehen die Bildfehler los.

Ich möchte halt gerne die einzelnen Geräte nur auf 100Mbit laufen haben und den Uplink zur Fritzbox 7590 auf den vollen 1000Mbit

Port 1 aktuell Uplink zur Fritzbox 7590 (Router) mit 1000M Full auf AUTO

Port 2 MegaSat IP Server 3 mit 100M Full Manuell

Port 3 Nvidia Shield TV Pro mit 100M Full Manuell

Netgear Monitor sagt auch CRC Error Packets für Port 2 und Port 3

Wenn ich Port 2 auf AUTO stelle also 1000M Full geht es, aber warum ?!?

[schumaku]

---

@Starfoxfs wrote:

Sobald ich unter System->Management->Port Status den Port 2 in diesem Fall der MegaSat Sat-IP-Server 3 auf 100M Full stelle gehen die Bildfehler los.

Ich möchte halt gerne die einzelnen Geräte nur auf 100Mbit laufen haben und den Uplink zur Fritzbox 7590 auf den vollen 1000Mbit

Port 1 aktuell Uplink zur Fritzbox 7590 (Router) mit 1000M Full auf AUTO

Port 2 MegaSat IP Server 3 mit 100M Full Manuell

Port 3 Nvidia Shield TV Pro mit 100M Full Manuell

Netgear Monitor sagt auch CRC Error Packets für Port 2 und Port 3

---

Leider ist das ein untauglicher Ansatz, um die Bandbreite einer Verbindung zu begrenzen.

@Starfoxfs wrote:

Wenn ich Port 2 auf AUTO stelle also 1000M Full geht es, aber warum ?!?

---

Auf seriellen Leitungen  (RS-232 usw.) wurde mal ein Flow-Control mittels RTS-CTS und dazu XON-XOFF Signalisierung eingesetzt. Etwas ähnliches gibt es auch für Datennetzwerke inklusive Ethernet eingeführt. Man bezeichnet das als hier als Backpressure, oder eben Ethernet Flow Control. Des bedingt eine durchgängige Implementierung, vom Sender (hier Dein TVheadend) bis zum Empfänger (Deine TV-Boxen). Wenn da einer nicht mitmacht entstehen sehr schnell Kollisionen oder nur partiell übertragene Frames, was sich dann  in CRC-Fehlern niederschlägt - und die Ethernet-Switches erkennen solche Fehler eben.

[Starfoxfs]

Guten Morgen,

ich hab es inzwischen zum laufen bekommen.

Es läuft aber nur mit Port Speed 100Mbit Half oder eben auf AUTO , das sind dann 1000mbit Full Duplex.

Auf 100Mbit Full Duplex schmeißt der Switch Fehler aus und ich habe wieder die Bildschirmfehler im Bild.

Theoretisch kann ich auch das Datenlimit limitieren auf 128Mbit/s was ebenso ohne Fehler funktioniert solange der Port eben nicht auf die 100Mbit Full Duplex gesetzt ist.

Der Netgear kann aber wenigstens die 100Mbit Half Duplex ohne Fehler, denn das konnte der TP-Link auch nicht.

[schumaku]

---

@Starfoxfs wrote:

Theoretisch kann ich auch das Datenlimit limitieren auf 128Mbit/s was ebenso ohne Fehler funktioniert solange der Port eben nicht auf die 100Mbit Full Duplex gesetzt ist.

---

Definitiv sinnvoller als einfach einen Link auf 100 Mb/s zu forcieren..

@Starfoxfs wrote:

Der Netgear kann aber wenigstens die 100Mbit Half Duplex ohne Fehler, denn das konnte der TP-Link auch nicht.

---

Das sieht für mich mehr nach einer Bekämpung von Symptomen denn nach einer Lösung aus.

[Starfoxfs]

Der SAT-IP-Server3 kann anscheined kein 100Mbit Full Duplex über den Switch.

Aber wie soll die Lösung aussehen ?

Ich müsste mal probieren ob es auch Fehler gibt wenn der SAT-IP-Server3 über die Fritzbox 7590 mit einer Limitierung von 100Mbit für den Port läuft.

:Edit: Auf der Fritzbox 7590 läuft der SAT-IP-Server3 auf 100Mbit/s allerdings kann man hier nicht erkennen ob Half oder Full Duplex.

[schumaku]

Eine Lösung zu welchem Problem denn bitte?

Einfach nur um die TV-Boxen unter 100 Mb/s Bandbreite halten zu können?

Und alles im Wissen dass es eher wahrscheinlich ist, weder SAT IP Server wie auch die TV-Boxen mit der begrenzen Bandbreite oder dem Ethernet Flow Control auch umgehen können?

Jeder Einschnitt, jede Begrenzung wird mit Sicherheit einen Einfluss auf den RTP-Stream haben. Und jeder nicht korrigierte oder korrigierbare Fehler wird auf einem Fernseher sichtbar. 

Schon für eine einfache Live-TV-Produktion mit vier SDI-3G (alle mit vMIX Live Replay, also dauernde Aufzeichnung von vier Kameras auf einer Samsung T9 SSD) und zusätzlichen zum Test für die nächste Sasion hinzugefügten  NDI-HX-Kameras nutzen einen (kleinen) Notebook, aber mit zwei uabhängigen Thunderbolt-4 Kanälen, einer auch für einen 2.5 GbE Netzwerk-Port. Dabei wird werden parallel drei unterschiedliche (!) Programme für TV, Spielstatistik (49ing.ch) und Wetten (IMG Arena) relisiert. Dabei macht es keinen Unterschied, ob wir über STMPE 2110 oder SDI-3G produzieren. Alle drei Stream werden über einen einfachen GbE-Internet-Anschluss nach aussen gestreamt. Es fliessen also Kamera-Inputs wie auch ausgehende Streams über dasselbe kleine Netzwerk und einen einzelnen 2.5 GbE Port. Ja, und wenn ich etwas zu viel von dem kleinen PC fordere, rattert es eben mal kurz im Gebälk.

[Starfoxfs]

Ok, verstehe ich das die Begrenzung Einfluss haben soll, das erklärt aber nicht das 100MB/s Portbegrenzung auf der Fritzbox 7590 einwandfrei funktionieren und 100MB/s Half Duplex auf dem GS105E ebenso einwandfrei funktionieren.

Half Duplex ist ja theoretisch noch langsamer als Full Duplex.

Die gesendete Bandbreite vom Raspberry PI mit TVHeadend (HTSP Stream) ist niemals über 10MB/s eher darunter.

Da ist also viel viel Luft nach oben.

Der SAT-IP-Server UDP Stream der in den Raspberry reinkommt ist auch nicht viel höher und es hängt aktuell nur 1 Abnehmer nämlich die Nvidia Shield TV Pro am TVHeadend Raspberry PI.

Für mich ist das eben nicht plausibel warum ausgerechnet nur 100MB Full Duplex nicht geht.

[Starfoxfs]

Das einzige was ich mir vorstellen könnte das der SAT-IP-Server3 kein 100MBFullDuplex kann und dadurch die Fehler entstehen.

Bleibt aber dann auch wieder die nächste Frage, warum kann er dann 1GB/s Full Duplex.

Egal es funktioniert ja soweit mit Half Duplex oder Auto Mode.

[Wojciech_K]

Hallo @Starfoxfs!

Hättest du weitere Fragen zum Thema?

Mit freundlichen Grüßen
WojciechKrz
NETGEAR Team