Beiträge von luxlicht

kurzes Update zum Vigor 167: läuft bis jetzt sehr stabil (ohne Ausfall oder reboot bislang)

Hallo,

Es liegt klar an der folgenden Meldung:

...
Aug 05 08:07:21 ubnt udm-iptv[21417]: udhcpc failed to get a DHCP lease
...

und dann:

...
Aug 05 08:07:21 ubnt igmpproxy[21417]: There must be at least 1 Vif as upstream.
...

aber wieso dass jetzt nicht mehr funktionniert ist so schwer zu sagen. Irgendwas hat zwangsläufig geändert an deiner Konfiguration

Und was sagt udm-diag ?

Nachdem Update der UDM, so blöd es klingt, einfach mal UDM IPTV komplett neu installieren mit download der neusten Version. Falls du das noch nicht gemacht hast.

Hallo,

Hast zu zufällig ein Update der UDM gemacht?

Hallo,

Das sollte zu lösen sein, da UDM-IPTV Magenta TV ja unterstützt. Ich habe bis vor ein kurzem selbst mit Fabian an einer Lösung für die sehr speziellen Anforderungen meines IPTV Anbieters gearbeitet und mittlerweile ist diese sogar Teil von UDM IPTV geworden (das PostTV Profil). Melde dich gerne per PN bei mir dann können wir das durch gehen, gerne auch per Zoom Meeting (da es schneller und einfacher geht wenn man sieht wovon der andere spricht). Soweit ich helfen kann, gerne.

Zitat von taxman

…. Funktionieren die mit dem UniFi-Komponenten? Glaube nicht, oder?

Gibt hier eine Anleitung wie man UniFi vorgaukeln kann dass es eine Ubiquiti Kamera ist.

Warum eigentlich Ubiquiti Kameras und nicht zB welche von Axis? Die haben auch welche in der Kategorie 400-500 EUR für den Aussenbereich.

Hallo,

Kleines Update, ich hab's am Laufen. Ja, IPTV mit 10er Source Adresse im WAN.

Ausgehender normale Internettraffic geht mit PPPoE Tag raus und Multicastanfragen gehen über eine 10.xx.xx.xx.er Adresse raus ins WAN und ohne PPPoE Tag. Läuft, IPTV funktionniert seit gestern Abend. Hab's zusammen mit "Fabianishere" hinbekommen (derjenige der das Package erstellt hat um den immer noch fehlenden IGMP Proxy usw auf einer UDM zu installieren).

Die Netwerkapplikatioun 7.0.23 ist übrigens immer noch voller Anfängerbugs. So hat sich zB herausgestellt dass die zusätzliche IP Adresse welche man für ein WAN festlegen kann überhaupt nicht angewendet wird wenn man PPPoE konfiguriert hat. Hab's mit dem UI Support durchgespielt samt Support Files. In der alten GUI kann man sich noch einem Netzwek zuweisen, nicht mal das funktionniert in der neuen GUI, aber am Ende wird sie halt keinem Interface hinzugefügt so dass das über den normalen Weg schon mal nicht funktionniert. Und nach 7 Tagen ohne mir bei dem eigentlichen Problem zu helfen und nachdem klar war dass hier noch ein weiterer Bug vorhanden ist kommt der Support dann mit der tollen Idee: schalten sie doch ein Gerät vor die UDM welche PPPoE und DHCP übernimmt und stellen sie in der UDM von PPPoE auf DHCP um....Hallo? Geht's noch. Ein Gerät voller Bugs und dann schlägt man mir im Prinzip vor ich soll doch die Fritzbox wieder davor setzen weil's die UDM nicht gebacken bekommt? Hab jetzt mal vorgeschlagen dem Level3 Support oder Developper Team per Screensharing meine funktionnierende Konfiguration zu zeigen, samt IGMP Proxy den sie ja auch seit Jahren nicht gebacken bekommen.

Es geht übrigens grob in dem man den IGMP Proxy installiert, dort dann eth8.xx nutzt anstatt ppp0 und eben beim eth8 manuell die 10.xx.xx.xx er Adresse über CLI vergibt. eth8 ist ja der WAN1 Port auf der UDM. ppp0 wird halt genutzt für den normalen Internetverkehr und wenn man anstatt ppp0 dem IGMP Proxy dann eth8.xx als WAN angibt fährt er für alles was IGMP Multicast ist über diese Device und nutzt damit 10.xx.xx.xx als Source und keinen PPPoE Tag, und schon läuft's. "Fabianishere" wird eventuell sein Projekt anpassen um diese Art von Konfiguration einfacher zu ermöglichen als manuell (ich muss jetzt noch sehen wie ich die manuell gesetzte IP nach jedem reboot per Skript setzen kann und auch nach jeder Änderung am Netzwerk oder der FW, da die GUI dann die Device Settings für eth8.xx wieder überschreibt).

Demnach, gute 3 Wochen oder so gebraucht und mit etwas Hilfe links und rechts geht's jetzt.

Kennt sich jemand mit den Fritzbox Konfigurationsdateien aus? Ich habe jetzt nochmal meine alte FB angeschlossen, dort (a) mal über die Captureseite der FB Traces gezogen und (b) die Konfigurationsdatei im Mono-VC Setup abgespeichert. Man erkennt dort zB sehr klar dass

die Fritzbox 2 Internetschnittstellen definiert hat: "internet" und "iptv" (unter dslifaces). Und iptv hat die Adresse 10.10.10.10.

In den Traces der Fritzbox sehe ich auch dass 10.10.10.10 als SRC Adresse für die Multicast Anfragen genutzt wird. Und anschliessend startet dann auch der Stream IPTV funktionniert.

Ausgehend von der Konfigurationsdatei der FB kann jemand der diese gut versteht mir vielleicht helfen abzuleiten was für die UDM SE gebraucht wird.
Ich habe ein Ticket bei Ubiquiti auf, aber das dauert da ja immer Tage zwischen jeder Antwort, so dass ich auch selbst versuche mich einzuarbeiten.

Der Anbieter hier ist einen komplett anderen Weg gegangen als zB Magenta, Telekom usw. Die Implementation ist komplett anders, wodurch aber eine Skalierung weit über dem was bei Magenta usw machbar ist. Ich kenne keine Details weil dies natürlich zu sehr in die Firmeninterne des Anbieters geht.

Ich weiss auch dass ein 10.xx.xx.xx er Netz ein privates ist und nicht ins Internet geroutet wird. Ich habe aber Packetrace Screenshots vum Anbieter bekommen welche Schritt für Schritt den kompletten "handshake" über PPPoE vom FastChannelChange,über den Join request, kurzem Unicast Stream und dann multicast stream mit abschliessendem FastChannelChange Exit zeigen. Man sieht hier ganz klar dass beim Join Request die 10.xx.xx.xx.xx Adresse als SRC Adresse steht.
Leider hat man mir gesagt dass ich die Screenshots nicht veröffentlichen darf.

Der Join request auf eine multicast Adresse ist wie gesagt mit der 10.xx.xx.xx er Adresse.

Mir erschliesst sich das auch noch nicht so ganz, ich habe aber Grund anzunehmen dass man seitens des Anbieters weiss wovon man spricht da ich mit jemandem in Kontakt stehe der das System mit aufgebaut hat und tagtäglich deepdive Support/Analysen macht - und halt nicht mit dem Standard Support.

Ich denke dass es PPPoE die Sache verkompliziert.

Ich habe noch die Info bekommen dass was für den JOIN wichtig ist:

• IGMPv2 ist ok
• VLAN TAG 35 muss benutzt werden (das ist der gleiche wie beim WAN Netzwek eh angegeben)
• Es darf kein PPPoE Tag gesetzt sein (spätestens hier stellt sich mir die erste Frage....)
• Die Source Adresse muss 10.xx.xx.xx sein

Zitat von KJL

Dazu kommt noch die Tatsache dass dieses Vorgehen in dem Moment Loadbalancing benötigt und das kann die UDM / UDM PRO / UDM SE nicht.

Warum Loadbalancing? Es ist ja nur beim "Join request" wo es diese SRC Adresse braucht. Anschliessend läuft also ganz normal.
Die 10.er Adresse ist auf WAN1 definiert, zusätzlich zu der vom ISP vergebenen öffentlichen Adresse.

Hallo,

Hat schon jemand von euch es hinbekommen dass Traffic aus einem bestimmten Netwerk (VLAN) mit einer spezifischen IP als Source Adresse über ppp0 ins WAN geht?

Mein IPTV Provider hat mir erklärt dass dies nötig ist damit das IPTV funktionniert, das heisst meine IPTV Receiver sind alle im gleichen VLAN und wenn sie nun aus diesem VLAN heraus
die Multicast Anfragen zum Anbieter schicken (über WAN) muss dies mit einer 10.x.x.x er Adresse (einer spezifischen) passieren.

Dazu habe ich im WAN erstmal diese Adresse als zusätzliche IP Adresse eingetragen, was soweit ging, und ich kann diese auch anpingen somit sollte sie in der Konfig genommen worden sein.
In den Netzwerksettings des VLANs habe ich dann unter "Internet Source IP" für WAN1 eben genau diese 10.x.x.x Adresse ausgewählt (legacy GUI). Apply settings.

Trotzdem sehe ich die Multicast Anfragen per Trace auf ppp0 dort immer noch mit der Default Internet Source Adresse anstatt der 10.x.x.x. somit funktionniert mein IPTV "Handshaking" weiterhin nicht. Leider ist es auch so dass die neue GUI den gesetzten Wert für "Internet Source IP" nicht anzeigt, das scheint mir ein Bug in der GUI, sollte aber denke ich keinen Einfluss auf die Funktion haben da ich ha über die alte GUI konfiguriert habe.

Hier brauche ich denke ich Hilfe von denjenigen die sich tiefer mit der Netwerkkonfiguration der UDM PRO / UDM SE auskennen, gerne auch über CLI.

UDM SE: 2.0.15
Netwerk App: 7.0.23
DSL über PPPoE, alles über ein einziges VLAN mit ID35 (also keine Trennung IPTV, Internet, VOIP etc)

Zitat von BlackSpy

taxman

Seltsam......aber Unifi.

Bei mir in der Firma habe ich bisher die 7.20 , 22 und 23 als offizielle FW angeboten bekommen, wobei ich eigentlich nie eine Beta oder RC in unserem Firmennetz haben wollte.

Oben genannter Fehler wird in einer zukünftigen FW Version behoben, für die UDM/Pro ist letztens erst eine Beta erschienen die das unterbindet.

Was ich gänzlich seltsam finde: dieser Fehler ist auf einmal da, nur wenn EA und Remote aktiviert und betrifft nur RC Versionen......jetzt aber veröffentlicht Unifi ganz kurz hintereinander 3 RC Versionen? Davor wurde ein RC Kandidat erst kurz vor dem offiziellen Release veröffentlicht und es waren deutlich weniger RC im Umlauf.

Also kann mir jemand erzählen was er möchte, dies war eine bewusste Entscheidung von Unifi.....nur das warum?

Alles anzeigen

war eigentlich jemals etwas anderes als ein RC unterwegs? Wenn ich mir ansehe auf welchem Stand eine Version 7.0.23 ist (müsste ja besser sein alles alles zuvor), wie schlecht das Fehlerhandling in der Programmierung ist (das sieht man wenn man sich die wenigen Logs ansieht die es so gibt), wie fehlerhaft das alte GUI immer noch ist (oder immer mehr wird), auf welchem Level das neue GUI unterwegs ist, seit Jahren viele nach eine vollständigen IGMP Proxy usw Implementation schreien und nur vertröstet werden usw dann stellt man sich schon diverse Fragen zur Qualitätskontrolle und der Einstellungskriterien beim Hersteller. Von aussen betrachtet fehlt es an wesentlichen Standards was die Softwareentwicklung anbelangt.

bin gerade dabei auf 7.0.23 EA zu updaten in der Hoffnung dass es nicht schlechter wird sondern eher Bugs gefixt sind

Zitat von lycra

Hab grad nur am Handy mal geschaut, aber da ist seit dem 11.11.2021 keine logs in der. Log Datei.

du musst auf Download klicken. Im Fenster selbst wird nichts angezeigt bzw es dauert extrem lange bis mal was dort "live" gezeigt wird. Einfach mal oben rechts auf Download klicken

Habt ihr mal dier Serverlog Datei heruntergeladen und euch die mal angesehen? Bei sieht die grausam aus. Viel zu viele Fehlermeldungen. Wahnsinn was da im Hintergrund im System alles so schief läuft.

In der "legacy GUI" links auf "Insights" klicken, dann oben links Network logs auswählen und dann rechts oben auf Download logs klicken. Ihr erhaltet eine frei lesbare

Datei in welcher ihr den Zeitpunkt der letzten Neustarts suchen und von da an mal alles durchlesen könnt.

Ich habe da sehr viele Fehler.

Zitat von lycra

Nicht schlecht, dass die soetwas anbieten!

Bin beim Level2 Support, angefangen hat's mit dem IPTV/IGMP Thema und der Diskussion warum das immer noch nicht integriert ist. Nun sind wir halt an dem Punkt gelandet wo ich darauf hingewiesen habe dass meine Serverlog laufend Fehlermessages rausschreibt dass die Default FW Rules nicht gerendert werden konnten wegen einer IP Adresse die ich nie vergeben habe. Da ich überall den letzten Softwarestand habe, teilweise ReleaseCandidate, denke ich dass da bei UI auch jemand wissen möchte was genau auf meiner UDM-SE vor sich geht. Vielleicht trägt's ja zu einer Bugerkennung und dann Behebung bei - dann haben alle etwas davon

Werde heute Abend eine Teamviewer Sitzung mit dem Support haben wegen der Default FW Rules welche im Serverlog laufend Fehlermeldungen erzeugen. Bin mal gespannt ob es sich lohnt, denn durch die Zeitverschiebung wird die Sitzung erst spät heute Abend sein

Nun nach über 1 Woche hat der Support sich endlich dazu hingerissen mir zu schreiben dass mein Problem dadurch zu erklären ist dass kein IGMP Proxy auf der UDM unterstützt wird, aber dass dieses Feature für eine spätere Release vorgesehen seih, aber man habe noch kein ETA.

WAS?!? Das Thema geistert seit Jahren im Netz herum, man findet immer die gleichen alten Beiträge. Und nach mindestens 3 Jahren denkt man bei UI immer noch drüber nach wann man das wohl fixen soll? Und für die Antwort habe ich auf Level2 Support warten müssen, eine Supportdatei hochladen müssen usw... es macht mich einfach wütend.

Das meine Logdatei voller Fehlermeldungen steht hat niemanden interessiert, werde wohl noch ein Ticket aufmachen müssen.
Guter Support geht anders. Bei QNAP hat's nicht mal 1 Tag gedauert bis ich eine Antwort hatte die auch noch weitergeholfen hat.

Sieht dann wohl so aus dass ich auch den leidigen Weg gehen muss und mir Fremdsoftware auf der UDM-SE installieren muss nur damit sowas wie

TV schauen wieder normal funktionniert. Und das in 2022. Trübt den ganzen Spass schon etwas...

Hallo,

Habt ihr euch mal die Servlog runtergeladen und angesehen? Erschreckend was da alles an Fehlern auftaucht, am laufenden Band.
Über "Insights" dann Network Log oben links einstellen und dann rechts auf "Download" klicken. Man erhält eine lesbare Datei.
Man findet nach etwas herumscrollen dann den Startzeitpunkt und kann ab da mal nachlesen was alles an Fehlern auftritt. Wenn ich meine Datei durchlese, auch noch unter 6.5.55 dann ist die Software mit "Beta" lieb umschrieben. Grausam.

Meinem WAN wird aus irgend einem Grund eine 10.0.0.45 "interne" Adresse zugewiesen die dann anschliessend aber laufend zu Problemen führt
und immer wieder tauchen Meldungen auf dass default firewall rules nicht generiert wurden wegen fehlerhafter WAN IP 10.0.0.45 usw....