Beiträge von Maddeen

Ihr müsst (klappt bei den meisten DynDNS Anbietern) die Update-URL anpassen

Meine sieht z.B. so aus: http://www.goip.de/\/nic/update?hostname=%h&myip=%i

Leider ist es nicht bei jedem Anbieter gleich -- aber hier findet ihr weitere Konstellationen für die bekanntesten Anbieter:

https://community.ui.com/quest…-8323-debe2af55879?page=3

Man sollte das hier etwas besser definieren

IPTV != Streaming/WebTV

Waipu, Joyn, Netflix, Amazon usw.. sind alles Streaming-/WebTV-Anbieter - keiner von denen bietet (echtes) IPTV an.

Das merkt man auch schon an der Qualität -- ein Bild was über IPTV in HDTV oder 4k ankommt, hat eine ganz andere Qualität, als über Streaming.

Jeder der Sky hat, kann das bestätigen . guckt euch den gleichen Film einmal via SkyGo und einmal via Sky (Satellit) an .. der Unterschied ist enorm!

Achja - und was das auch bestätigt - warum bekommt man bei keinem der Anbieter IPTV mit einer 6Mbit Leitung, kann aber bei Netflix mit 6Mbit HD Content sehen?!?

IPTV betrifft aber nicht nur MagentaTV sondern auch GigaTV (Vodafone) oder auch 1&1TV (1&1) - oder jeden anderen echten IPTV Anbieter auf der Welt.

Unsere Nachbarn (Österreich/Schweiz) haben nämlich auch Probleme mit Unifi + IPTV. Weil die nach dem gleichen Prinzip vorgehen -- VLAN A für Internet -- VLAN B für IPTV

Das hat auch was mit QoS zu tun, was natürlich besser funktioniert, wenn der IPTV Traffic vom normalen Internettraffic gekapselt ist -- denn beim IPTV dürfen keine "kleinen Aussetzer" oder ähnliches passieren.

Hier ist das ganze noch mal gut erklärt: https://fernsehempfang.tv/post/unterschied-iptv-und-webtv/

Angeblich ist das notwendige Feature bzgl. IPTV für Version 1.9 in Planung.

Frage ist nur, wann die raus kommt - Beta ist aktuell bei 1.8.3

Mich nervt aktuell nur, dass wirklich teilweise rudimentäre Features, die jeder 20€ Router kann, die die UDM Pro (zum Schnapperpreis von 300€) nicht kann.

Hauptsächlich brennt bei mir das IPTV Thema, da ich innerhalb dern nächsten 12 Monate umziehe und im Haus eigentlich komplett auf IPTV - auf Grund der Vorteile - schwenken will.

Ansonsten kann ich nur diese Liste teilweise immer wieder unterstreichen - alles Features, die vorher umsetzbar waren (die meisten mit einer config.gateway.json) und jetzt nicht vorhanden sind.

Also ich habe schon vor x-ig Monaten (als ich noch ein USG und den CK+ hatte) Bilder gemeldet - da passiert nichts.

Ehrlich gesagt haben die Jungs (für mich) auch noch zu viele echte Baustellen -- die sollen sich mal lieber um IGMP usw. kümmern..

Guckt euch mal die FR-Liste an...

https://community.ui.com/quest…6b-41ae-8c3b-4ef418e88028

Da ist auch nach über einem Jahr nicht viel durchgestrichen

P.S Gibt auch wieder einen neuen Thread, weil der alte geschlossen wurde ...

https://community.ui.com/quest…-bede-adcbecc37048?page=2

Ahhh also war mein "Knoten im Kopf" berechtigt. Hatte mich schon gewundert, wie das gehen kann, wenn noch kein Gerät "eingewählt" ist

Doppeltes NAT ist mir in der Tat eigentlich zu aufwendig, das Problem ist aber, dass die Anleitung leider nicht für die UDM funktioniert und ich vermutlich (wenn Unifi sich nicht bewegt) dann doch nur diesen Weg habe.

Denn bei der UDM ist ja nichts mit config.gateway.json Das ist ja das, warum sich alle bei UI im Forum aufregen.

Es gibt quasi keinen IGMPv3 Support UND man hat die Möglichkeit genommen, diesen manuell via config.gateway umzusetzen

Mit einem USG geht das einwandfrei - ich hatte hier schon MagentaTV und USG. Aber das USG ist einfach

a) scheiße für Rackeinbau - will auch keine 3D geprinteten Halter (sieht billig aus)

b) der Durchsatz mit aktiviertem IDS/IPS ist viel zu wenig, weil ich am neuen Ort min. 250Mbit habe

Aber trotzdem danke für die Infos - hat mir schon geholfen.

Hi alex

wie schon angekündigt, bräuchte ich hier noch mal den Alex-Erklärbär

Da du ja offensichtlich ziemlich bewandert bist, was Netzwerk angeht - könntest du mir das hier mal auf Deutsch erklären.

Alles was jetzt folgt ist aus englischen Foren zusammengelesen und kann (wird) vermutlich auch Fehler enthalten.

Wir werden nächstes Jahr umziehen - dabe beabsichtige ich auch, Sky endgültig die kalte Schulter zu zeigen und auf MagentaTV (IPTV) zu wechseln.

Das Problem ist aber weiterhin (und vermutlich noch nächstes Jahr) dass die UDM und auch die UDM Pro ja kein IGMPv3 (oder kein IGMP Proxy?!?? - keine Ahnung ) kann - und daher man nicht IPTV gucken kann.

In den u.a. Threads hat ein netter Mensch "Ueberseehandel" eine Anleitung geschrieben - das Bild habe ich mal weiter unten dazugepackt.

HIER https://community.ui.com/quest…-9d93-2396e78a3b1e?page=2

und HIER: https://community.ui.com/quest…ac-4b2f-9d93-2396e78a3b1e

Im Endeffekt soll die Lösung sein, dass man VOR der UDM PRO "einfach" einen Switch positioniert, der dann die VLAN splittet.

Aber auch hier hab ich jetzt einen Knoten im Kopf.

Wie können denn die STBs Internet haben, wenn ich die vor der UDM abzweige, aber die Einwahl ins Internet die UDM macht?!?

Im Endeffekt ist selbst diese Lösung natürlich maximal "dämlich" - wenn die Lösung (Integration IGMPv3) so einfach wäre.

Aber ich habe lieber einen zusätzlichen Switch im Schrank, als wieder 1x USG, 1x CloudKey Plus und den schlechteren Durchsatz plus Wegfalll der Möglichkeit Unifi Access zu nutzen.

Vielleicht überrascht uns ja auch Unifi -- aber da die jetzt nach fast einem Jahr noch nichts gemacht haben, bin ich irgendwie eher pessimistisch

Dank dir noch mal und schon mal schönes Wochenende

Wireshark ist aber wohl ne Kunst für sich oder? Oder hast du dazu gute Anleitungsvideos oder so?

Im Endeffekt kann man damit sicherlich noch einiges optimieren - aber bei mir im Kopf ist schon ein Knoten, weil ich gar nicht wüsste, wo man den laufen lassen soll...

Er muss ja an einer Stelle laufen, wo er jeglichen Traffic auch mitbekommt - was aus meiner (nicht Netzwerk-Spezi) Sicht ja nur auf dem UDM sein kann.

Aber da kann ich ja nicht einfach Wireshark (oder überhaupt ein anderes Programm) drauf installieren.

P.S Ich mache gleich noch einen neuen Thread (MagentaTV) wo ich dich mal um Aufklärungsarbeit bitten würde.. da hab ich auch ein Knoten im Kopf

Moin - ich hatte die Regel, aber unter LAN IN

Ich habe jetzt mal auf nur ICMP geschaltet - läuft.

Trotzdem kapiere ich nicht, warum wirklich jedes andere Gerät - selbst das billigste SmartHome-Steckdosen-China-Drissteil damit klar kommt - aber ein 200€ teurer Receiver nicht...

alex

UPDATE: Ich habs endlich geschafft. Jedenfalls glaub ich das

Aus einem mir nicht erkenntlichen Grund müssen die Receiver Zugriff auf das Gateway haben.

Ich habe in jedem VLAN die Verbindung zu dem Gateway (UDM) verboten und nur 3 Geräten (Admin-Devices) den Zugriff erlaubt.

Jetzt habe ich eine neue Allow-Regel hinzugefügt, sodass die SkyQ-Receiver auf das Gateway zugreifen dürfen und zack - läuft alles.

Kapieren tue ich das nicht, weil wie gesagt alle anderen Geräte (ca. 30!) auch keinen Zugriff auf das Gateway haben und trotzdem alle im Netz sind.

Zudem ist mir die Regel aktuell noch zu löchrig ... bzw. habe ich die nicht weiter eingeschränkt.

Konfig ist aktuell:

Accept

All Protocols

From "Group SkyQ-Receivers"

To "Local Gateways"

Was natürlich jetzt alle Ports offen macht.... jetzt geht es ans rausfinden, welchen Port das Teil wirklich braucht.

Erster Versuch wird mal sein von "all protocols" auf "ICMP" umzuschalten... bin gespannt.

So - alles erledigt, alex - siehe Screenshots - sollte stimmen.

Bzgl. Ports -- die sind ja automatisch in WAN IN frei durch das gesetzte Port Forwarding. Mehr muss ich ja hoffentlich nicht machen.

Was ist eigentlich mit dem IGMP Snooping? Wenn ich danach google, lese ich überall, dass man das aktivieren sollte. In Unifi ist das aber per default deaktiviert?!?

Wer hat Recht?!

Leider hat das übrigens nichts gebracht - jedenfalls nicht auf Dauer.

Wie du an dem Bild erkennen kannst, scheint er kurz nach dem Reboot Internet zu haben (Startseite voll mit Empfehlungen usw) und ein paar Sekunden danach (rechte Seite) nicht mehr (Hinweis bzgl. Internetverbinden)

alex - Setup ist eigentlich ganz simple.
VIGOR 165 (als reines Modem) --> UDM PRO (PPPoE) --> USW 16 Port Gens 2 --> AP HD inWall

Die Sky Boxen hängen am USW - nicht an der UDM.

Und für das IoT-VLAN (in dem sich die SkyBoxen befinden) ist IGMP Snooping deaktiviert.

Da ich nicht weiß, was dieses Feature genau macht (trotz der Erklärung in der GUI ) habe ich das übrigens in allen meinen VLANs deaktiviert (ist glaub ich auch die default Einstellung)

alex sind die Regeln überhaupt korrekt? Ich würde die auch sonst nämlich wieder deaktivieren, weil ja sonst hier "offen Holland" herrscht

Keine Eile -- funktioniert ja schon mehrere Wochen nicht (seit der Umstellung von USG auf UDM und Aufteilung in x-ig VLANs )

Ich habe ja auch keine Einschränkungen, weil ich weder über den Receiver netflixe (oder andere Apps) oder mir VoD lade - ich würde es nur gerne verstehen ...

Hier mal die "Any"-Regel (WAN IN) und die ICMP Regel (LAN IN)

Hat beides keine Änderung gebracht -- hoffe die Regeln sind auch korrekt.

ICMP-REGEL

ANY-REGEL

Auch hier vielen Dank alex - schön das es hier jemanden gibt, der das nicht nur hobbymäßig macht, sondern wirklich tief drin steckt in der Materie.

Was ich aus deinen Erklärungen rauslese ist folgendes

Tagged VLAN ist eher eine Client-seitige Einstellung, korrekt? Die proprietäre Lösung via Mac lasse ich hier jetzt mal raus. Was proprietär = schlecht - jedenfalls in den meisten Fällen

Wobei ein "Client" nach deiner Erklärung aber auch ein andere Switch oder ein AP sein könnte.

Wichtigste Info ist aber die -->

Zitat

Kurz gesagt: Wenn ein Switch ein Tagged Vlan hat erfordert es immer ein Eingriff auf dem Client, dass er in dieses vlan kommt

Denn das bedeutet, dass das bei mir schon mal nie vorkommen wird. Normale Clients (Consumer-Endgeräte wie iPads, iPhones, Smart-Home Geräte usw) haben diese Einstellungsmöglichkeiten gar nicht - jedenfalls ist mir noch nie eines unter die Augen gekommen.

Zitat von alex

Du vermischt nun zwei Sachen das eine ist DHCP und das andere ist vlan. DIe Port Einstellung welches vlan machst Du immer noch auf dem Switch

Ok - das wusste ich z.B. nicht. Ich dachte, dass jedes VLAN automatisch auch seinen eigenen Adressbereich bekommen muss, der natürlich nicht in einem bereits bestehenden Adressbereich liegt.

Das bedeutet aber auch, dass man (kabelgebundene) Endgeräte nur in ein definiertes VLAN bekommt, wenn man die "untagged" Variante wählt - da ja (wie oben erklärt) die Clients gar keine Möglichkeiten bieten, diese via tagged VLAN anzubinden... korrekt?

Bei den WLAN Clients ist es ja einfach, weil man einfach der SSID ein VLAN zuordnet und der Client sich dann automatisch beim Verbinden in das richtige VLAN bewegt.

alex - das ist zwar noch nicht die Lösung, aber du bist definitiv nah dran

Ich hatte erst nur deine genannten Ports im Port Forwarding und in einer WAN-IN Regel definiert.

Da ging leider nichts.

Auf Grund der drei Ports, kam ich aber auf diesen Beitrag, der mich dann dazu brachte, noch den Port 3700 mit aufzunehmen.

Und jetzt kommts -- es hatte gerade tatsächlich für ca. 1 Minute funktoniert... es wurden Serienvorschläge usw. alles einwandfrei angezeigt -- und plötzlich überall wieder der gleiche Fehler

Den Hinweis des Users in dem o.a. Beitrag mit ICMP wäre ggf. noch eine Lösung - aber irgendwie doch abwegig oder? Und selbst wenn, wüsste ich aktuell nicht, wie ich die umsetzen sollte.

Hier jetzt mal meine Konfiguration, die wie gesagt, immerhin für 1 Minute zum Erfolg geführt hat - was 1 Minute länger ist, als es bisher jemals funktioniert hatte

Hi zusammen

gefühlt kommt die Frage etwas spät, aber Unwissenheit soll man ja bekanntlich auflösen.

Zudem könnte ich je nach Antwort noch einen anderen Ansatz bei meinem Problem mit meinen SKY-Q Receivern fahren ... doch fangen wir mal von vorne an - nämlich mit ...

Was ist der Unterschied zwischen einem tagged VLAN und einem untagged VLAN und das wichtigstes - woran erkenne ich, was was ist?

Ich bin kein Netzwerktechniker und bisher dachte ich, dass allem, dem ich eine VLAN-ID gebe, es sich automatisch um ein TAGGED VLAN handelt.

Wenn ich mir aber diverse Beiträge und die Infos aus Google angucke, scheint das ja gar nicht der Fall zu

Zudem kommt noch erschwerend dazu, dass ich diese ergoogleten Infos ja noch mit der Konfig der UDM-Pro übereinander bekommen muss.

Ich speichere jetzt einfach mal mein Wissen aus und würde mich freuen, wenn der eine oder andere hier Aufklärungsarbeit leisten könnte. Konkrete Fragen sind hellblau markiert

Ich versuche auch (für die Nachwelt) mit so wenig wie möglich Fachbegriffen um mich zu schmeißen, damit es "einfach verständlich" bleibt, ohne sich weiter in irgendwelche Netzwerkkommunikationsthemen einlesen zu müssen

Los gehts

Informationen zu meiner Konfig: VIGOR --> UDM PRO --> USW 16 PoE Gen 2... Die Verbindung zwischen UDM Pro und dem USW ist per SFP realisiert. Beide Ports stehen bei Switch Profile. auf "ALL" sodass diese (wenn ich es richtig verstanden habe) mit allen VLANs sprechen können bzw. ich sowohl in der UDM-Pro als auch im USW untagged VLANs für Clients nutzen kann, ohne jemanden "auszusperren"

TAGGED VLANs sind "softwarebasiert". Sprich die Pakete (also den Inhalt den man von A nach B transferieren möchte) die ein Client im Netzwerk verschickt bekomme beim Weg über den Switch zusätzliche Informationen.

Die Erkennung welcher Client welches "Tag" bekommt, basiert dabei auf der MAC-Adresse. Somit kann man z.b. über einen physikalischen Port, mehrere VLANs betreiben.

UNTAGGED VLANS sind "hardwarebasiert". Hier wird ein physikalischer Port fest einem VLAN zugeordnet.

Der Vorteil dabei ist, dass egal welches Gerät den Port nutzt, es automatisch dem hinterlegten VLAN zugeordnet wird. z.B. gut für Hotels oder so, wo die Ports für die Gäste frei zugänglich sind, aber man natürlich nicht möchte, dass ein Gast sich in ein andere VLAN "einwählen" kann.

Das wäre schon meine erste Hypothese, die man mir bestätigen oder korrigieren könnte.

Wie gesagt, verzichte ich extra auf weitere Fachbegriffe wie Ethernet Frames usw... es sollen einfache Erklärungen für die Nachwelt sein

Kommen wir jetzt zu dem Bezug mit der UDM bzw. mit den Unifi Produkten

UNTAGGED VLANS kann ich direkt am jeweiligen Port setzen. Sprich ich gehe auf die Konfig der jeweiligen Komponente (UDM / USW / AP usw) wähle im Reiter "Ports", wähle dann den jeweiligen physischen Port aus und setze unter "Switch Port Profile" das VLAN, welches ich dem Port fest zuweisen will. (siehe Screenshot = Beispiel_config_untagged.png)

Das ist auch die Variante, die ich für meinen Server und MacMini (Home_VLAN) und meine PS4, meine ATVs und meine SkyQ Receiver (IoT_VLAN) gewählt habe.

Hier kann ich neben einer 1:1 Zuweisung zu einem bestehenden Netzwerk auch noch ALL / DISABLED auswählen. (siehe Screenshot Switch_Profiles)

Hier wäre schon die nächste Frage - nämlich was bewirkt "Disabled"? Läuft der Port dann als "freier Radikaler" ohne eine Verbindung zu einem Netzwerk oder wird der Port tatsächlich "physisch" disabled - also abgeschaltet?

Zu den o.a. default Einstellungen kann man sich aber auch VLAN-Gruppen bauen. Das geht über sog. "Switch-Profiles" (siehe SW_Profile_config)

Hier kann man dann (sofern ich das richtig verstanden habe) mehre Netzwerke zu einer Gruppen zusammensetzen, sodass das man einem Port nicht nur 1:1 zu einem Netzwerk sondern 1:n Netzwerken verbinden kann.

Hier wäre die Frage nach dem Unterschied/Sinn zwischen Native Network und Tagged Network.

Wo wäre der Unterschied, wenn ich als native Network = Home_LAN nehme und dann bei tagged Network das Häckchen bei IoT_LAN setze im Vergleich zu native Network = IoT_LAN und tagged Network = Home_LAN nehmen?

Kommen wir jetzt zu den TAGGED VLANs.

Hier verstehe ich ehrlich gesagt schon gar nicht, wo ich das einstellen muss/kann oder ich befürchte eine doppelte Konfiguration.

Denn das einzige, was ich gefunden habe, wo man noch etwas mit VLANs machen kann, ist am Client selber. Wenn ich nämlich (und das habe ich für alle meine Geräte) eine feste DHCP Konfiguration setze.

Ich kann nämlich (warum auch immer) nicht bei VLAN = ALL setzen - sondern wenn ich eine feste IP vergeben will, muss ich auch zwangsläufig, ein VLAN definieren. (siehe Skyq_config)

Sollte also das die Lösung für TAGGED VLAN sein, frage ich mich, wie es sich in diesem Fall verhält, da ich den Port ja schon untagged auf ein festes VLAN gesetzt habe.

Und die nächste Frage ist (wie man auch in meinem Sky-Problempost lesen kann) warum - wenn das die tagged VLAN lösung ist, ich meine SKY Receiver nicht in das korrekte VLAN damit bekomme.

Ich muss quasi immer den port fest zuweisen, damit die SKY Receiver ins gewünschte VLAN gehen.
wenn ich das nicht mache und das nur hier in der client-config mache, kommen die Geräte immer ins Mgmt-VLAN... selbst mit der falschen IP.

Ich hoffe ihr könnt mir hier etwas Aufklärungsarbeit liefern... lieben Dank und ein schönes Wochenende.

Dank dir.. leider ist weder in der 1.8.1 noch 1.8.2 irgendwas bzgl. IGMP Proxy... wie lange kann man eigentlich für ein Feature brauchen!?

Zitat von DieselSt

Nun habe ich die aktuellste BETA V1.8.2 drauf.

Hast du Zugang zum BETA-Channel oder wie bist du an die BETA gekommen?

Ich frage, weil sich bei der UDM PRO (im Stable-Channel) ja auch schon ewig nichts tut - es aber wohl schon lange eine BETA 1.8.x gibt.

Je nach Changelog würde mich die nämlich sehr interessieren

Da ja jetzt sicher ist, dass du das Geld wieder zurück bekommst.... irgendwie ist das ja wie im Film.

Person A wird regelmäßig beklaut - kauft sich daher eine Kamera - die ihm der Dieb aber wiederum auch klaut..
Die Frage ist jetzt, wie klug ist der Dieb - reicht die Masse zwischen den Ohren aus, um zu kapieren, WARUM der Empfänger eine Kamera gekauft hat?

Oder haben wir hier bald was zu lachen, weil die nächste Kamera nicht geklaut sondern erfolgreich in Betrieb genommen wird und dann den Idioten beim nächsten Diebstahl aufnimmt?!?

Da ich ja sehe, was aktuell im TV so gezeigt wird, wette ich 10€ auf ein Live-Feed beim nächsten Diebstahl... wenn ich verliere, spende ich die 10€ ... wenn ich gewinne, ist das TV-Programm ein Spiegel der Gesellschaft