Beiträge von petra92

Zitat von gierig

Protokoll auf anderen Ports, oder über Ipv6, oder andere Ports und IPv6.

Sollt einen Reinen router nicht interessieren, also kommt das von einem Dienst

der sich den Traffic ankommt. Da das IPS über Suricata läuft dieses nur lauscht (

und im Automode ggf. Filter regeln auf die Firewall schmeißt) Kann es eigentlich

im Unifi Universum nur die Traffic Erkennung aka DPI sein. Das ist bei Unfi

eine Kernel Basierte Lösung höchst wahrscheinlich von TrendMirco dazu gekauft wurde.

Schaut wir nen Bug aus.

Geht denn alles ? Dann Bugreport und Ignorieren.

Einschränkungen ? Ticket + Bug Report + Nerven + nerven +nerven.

Alles anzeigen

ich schau mal auf welchen Ports Instagramm Quic verwendet. Und ggf. den Block nachschärfen.

Ich denke die Meldung kommt vom DPI der UDM. Evt. kommt der Inspector mit der Modifikation von QUIC, die Meta - wie oben beschrieben -vorgenommen hat, nicht zurecht (not supported payload length).

Naja. es geht nicht alles ich habe verschiedene Probleme die ich auch mit dem Support nicht lösen konnte (zB. "received packet on eth10 with own address as source address" und eigenartige Dinge mit einerm UAP U6 Pro). Deshalb schaue ich mir die logfiles gerade genauer an. Ich bin mir jetzt ziemlich sicher, dass die Probleme nichts mit der hier behandelten Fehlermeldung zu tun haben. Ich werde das Phänomen trotzdem mal als bug report an Ubiquiti schicken.

Facebook/Instagramm/meta schreibt 2020 hier

How Facebook is bringing QUIC to billions

We are replacing the de facto protocol the internet has used for decades with QUIC, the latest and most radical step we’ve taken to optimize our network…

engineering.fb.com

"Broadly speaking, QUIC is a replacement for the Transmission Control Protocol (TCP), one of the main protocols for internet communication. QUIC was originally developed internally by Google as Google QUIC, or gQUIC, and was presented to the IETF in 2015.""We developed our own implementation of QUIC, called mvfst, in order to rapidly test and deploy QUIC on our own systems."

"We deployed QUIC to the Instagram apps as well, using the same strategies as our Facebook deployment — testing it on a small percentage of Instagram’s traffic and then scaling up. Today, QUIC is deployed on Instagram for iOS and Instagram for Android."

Das Blockieren hat nicht dazu geführt, dass die Fehlermeldungen in das log geschrieben werden.

Ich habe aber mittlerweile herausgefunden, dass die Nutzung von Instagramm auf einem Iphone dazu führt, dass die Fehlermeldungen protokolliert werden. der Aufruf eines neuen reels sorgt dafür dass eine Zeile dazukommt. Solbald ich Instagramm beende, werden diese Fehlermeldungen nicht mehr geloggt.

Ich frage mich jetzt natürlich, warum das Blockieren von QUIC nichts gebracht hat.

Habe jetzt QUIC blockiert nach dieser Anleitung:

Mal sehen ob es hilft.

Wahrscheinlich bezieht sich die Meldung auf ein Netzwerkprotokoll namens QUIC, das die IETF standardisiert hat.

QUIC (ursprünglich ein Akronym für Quick UDP Internet Connections) ist ein auf dem User Datagram Protocol (UDP) aufbauendes zuverlässiges, verbindungsorientiertes und verschlüsseltes Netzwerkprotokoll auf Transportschicht. Es kann Transport Layer Security (TLS) zur kryptographischen Absicherung der Kommunikation nutzen und verfolgt das Ziel, eine höhere Performanz als das Transmission Control Protocol (TCP) zu bieten. QUIC wird von Protokollen wie HTTP/3 oder DNS over QUIC (DoQ). QUIC wurde ursprünglich von der Firma Google Inc. entwickelt und am 20. Juli 2016 zur Standardisierung eingebracht. Im Februar 2017 gründete die Internet Engineering Task Force (IETF) eine entsprechende Arbeitsgruppe.[7][8] Der Standard wurde im Mai 2021 als RFC 8999,[1] RFC 9000,[2] RFC 9001,[3] und RFC 9002[4] veröffentlicht.[9] verwendet. (Quelle https://de.wikipedia.org/wiki/QUIC)

Hallo,

ich habe eine

Model: UniFi Dream Machine PRO

Version: 3.2.12.14768

Network 8.0.28

In var/log/messages finden sich hunderte Fehlermeldungen folgenden Typs:

2024-03-17T13:07:32+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-17T13:07:32+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-17T13:07:32+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-17T13:07:34+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-17T13:08:16+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-17T13:08:16+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-17T13:08:16+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

Hat jemand eine Idee was das bedeudet und wie man den Fehler behebt?

LG

Petra

Hallo,

in /var/log liegen ein paar komprimierte ältere messages-logfiles mit der Dateiendung zst.

Sie sind komprimiert mit zstd (https://facebook.github.io/zstd/#references). Um sie zu dekomprimieren gibt man den befehl zstd -d dateinamen ein.

LG

Petra

Hallo,

unter

AP's vergeben 169. IP Adresse (169.254. - Adressvergabe)

und

Fehler auf Port (Spanning tree)

werden Fehlerbilder beschrieben, die heute auch in meinem Netz aufgetreten sind und zwar:

Bei einem U6 Pro AP, 6.6.65 haben clients (Windows PCs und Iphones) alle paar Sekunden abwechslend Adressen aus dem Bereich 169.254.x.x und dem eigentlich vorgesehenen Adressbereich 172.16.20.x zugewiesen bekommen. Gelegentlich ist der Port 1 der USW mit der Fehlermeldung "Blocked by Spanning Tree Protocol to prevent a network loop. This port will be automatically re-enabled when the loop is no longer detected." "udm pro" blockiert worden. (Bei der oben angegebenem 1. link handelte es sich auch um eine U6 Pro. background zu 169.254 hier unter https://www.computerweekly.com…tic-Private-IP-Addressing nachzulesen)

Der AP hing an einer Ethernet-Dose im Büro, die über ein Patch-Feld mit Port 1 einer USW-24POE-Pro verbunden war.

U6 Pro ----Dose----Patchfeld----USW-24POE Pro---UDM Pro

Ein Austausch des Kabels von der Dose zum AP hat das Fehlerbild nicht behoben.

Beim Anschluss des AP direkt an den Port 1 der USW trat das Fehlerbild nicht auf.

U6 Pro ---USW-24POE Pro--UDM Pro

Beim Anschluss des AP an einen US-8-150W tart das Fehlerbild ebenfalls nicht auf.

U6 Pro ----DUS-8-150W---Patchfeld----USW-24POE Pro---UDM Pro

Ich habe also darauf getippt, dass das Kabel zwischen Patchfeld und Dose einen Defekt aufweist. Es handelt sich um ein KAT7-Kabel, das bislang keine Probleme gemacht hat, solange an der DOSE eine ältere UAP-FlexHD hing - dachte ich jedenfalls. Also habe ich die ausgemusterte UAP-Flex-HD wieder an die Dose gehängt. Und siehe das gleiche Fehlerbiild zeigte sich auch mit der FlexHD.

Neue These: Das Kabel macht Probleme, wenn ein POE-Device daran hängt.

Also habe ich zunächst ein Raspi an die Dose gehängt - was unproblematisch war.

Dann habe ich einen POE-Injektor (UPOE) zwischen den UAP und die Dose geschaltet, um den UAP nicht vom entfernten Switch sondern von dem UPOE mit Strom zu versorgen (und die POE-Versorgung über den Switch deaktiviert).

U6 Pro ---UPOE---Dose----Patchfeld----USW-24POE Pro---UDM Pro

Das Fehlerbild trat dann nicht mehr auf. Weder bekamen clienten des UAP Adressen aus dem Bereich 169.254.x.x mehr zugewiesen, noch trat die STP-Fehlermeldung mehr auf. Die Ursache schien damit eingegrenzt.

Dann habe ich mir über den ssh-Zugang /var/log/messages angesehen und folgende "verdächtige" Zeilen entdeckt:

2024-03-15T20:53:22+01:00 UDMPRO kernel: br120: received packet on eth10.120 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br30: received packet on eth10.30 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br120: received packet on eth10.120 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br30: received packet on eth10.30 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br2: received packet on eth10.2 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br2: received packet on eth10.2 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br40: received packet on eth10.40 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br200: received packet on eth10.200 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br110: received packet on eth10.110 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

2024-03-15T20:53:22+01:00 UDMPRO kernel: br100: received packet on eth10.100 with own address as source address (addr:43:ab:b9:5f:c3:bb, vlan:0)

An eth10 (Port 11 der USW-24POE Pro) hängt der management Port eines vigor166 modems (um das modem zu konfigurieren- was auch funktioniert hat). Das Modem hängt mit seinem 2. Port an WAN2 der UDM Pro. Die angegebene MAC-Adresse wird von einem MAC-finder UBIQUITI zugeordnet. Möglicherweise ist sie die Mac-Adresse von eth10. (ich habe noch keine Stelle in der unifi-Gui gefunden, wo man sich die Mac-Adressen der eth-Schnittstellen ansehen kann.)

Für mein laienhaftes Verständnis könnte die Fehlermeldungen bedeuten, dass es ein Problem ist, das Modem 2mal mit meinem Netzwerk zu verbinden. Evt. war also diese zweifache Verbdindung des Modems die Ursache für das STP-Problem an Port 1???.

Ich habe dann zunächst Port 11 (eth10) der USW-24POE Pro deaktiviert. Und danach wieder den UPOE entfernt.

U6 Pro ----Dose----Patchfeld----USW-24POE Pro---UDM Pro.

Und oh Wunder: das Fehlerbild ist nicht mehr aufgetreten. Weder bekamen clienten des UAP Adressen aus dem Bereich 169.254.x.x mehr zugewiesen, noch trat die STP-Fehlermeldung mehr auf. Die Ursache schien damit eingegrenzt.

Ich neige daher dazu, dass Ursache für das Fehlerbild die wahrscheinlich der von mir fehlerhaft vorgenommene zweifache Anschluss des Modems war.

Um das zu checken, habe ich den Port 11 ( an dem der Management port des Modems hängt) wieder aktiviert. Meine Erwartung war, dass dann das Fehlerbild wieder auftritt.

Zu meiner Überraschung war das nicht der Fall. Die clieneten blieben in ihrem zugewiesenen Adressbereich und auch der STP-Fehler trat nicht mehr auf.

Um die Maschine zu provozieren, habe ich mich dann noch auf der GUI des Modems eingeloggt und über WAN2 einen Speedcheck laufen lassen. Das hat das Fehlerbild nicht mehr auftreten lassen und in /var/log/messages wurde auch die Fehlermeldung "received packet on eth10.110 with own address as source address" nicht mehr protokolliert.

Jedenfalls bislang nicht. Ich neige trotzdem noch dazu, dass der doppelte Anschluss des Modems das Fehlerbild verursacht hat. Möglicherweise tritt es nicht sofort zu Tage, sondern nur wenn eine weitere Ursache hinzutritt. Ich lasse jetzt Maschine mal über Nacht laufen und werte /var/log/messages morgen aus und/oder schaue, ob sich das Fehlerbild wieder zeigt.

Hat jemand eine Idee, wie am das Modem richtig an zweimal anschliesst (WAN und Management-Port), ohne dass diese Fehlermeldung "received packet on eth10.110 with own address as source address" auftritt?

Liebe Grüße

Petra

Hallo,

bekomme die Meldung auch in /var/log/messages geschrieben

2024-03-14T18:12:09+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-14T18:12:09+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-14T18:12:09+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-14T18:12:15+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-14T18:15:30+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

2024-03-14T19:11:04+01:00 UDMPRO kernel: [quic_sm_ietf_long_hdr_func#598]: not supported payload length.

Hier wird auch darüber berichtet: https://community.ui.com/quest…15-4a8a-8dad-13aa4f19c2df

UniFi OS 3.2.12

Network 8.0.28

Ursache und Wirkung unbekannt.

LG

Petra

Zitat von VerTex

IVielleicht ist meine 2020er UDMp einfach zu alt, um zu den aktuellen Updates und dem Internet-Update-Mechanismus kompatibel zu sein? Aber eine deutlich billigere Consumer-Fritzbox wird doch auch mehr als zwei Jahre supportet, warum sollte das Ubiquiti also nicht auch machen?

Meine UDM Pro ist auch aus 2020. Denke nicht, dass es daran liegt.

Update (UDM Pro) auf 2.4.27 verlief unproblematisch. <15 Minuten, davon ca. 5 min keine Internetverbindung.

Eigenartig bei mir fehlt der Eintrag

Hallo,

seit ich eine UAP Nano und eine UAP-Flex-HD durch eine U6-Pro und eine U6-Mesh habe ich den Eindruck, dass Clients öfters die Verbindung abreißt. Deshalb wollte ich heute mal schauen, ob ich eine Grund dafür finde. Dabei ist mir aufgefallen, dass der Menüpunkt AP Group auf dem Karteireiter Overview bei U6-Pro und U6-Mesh fehlt. Ist der entfallen oder an eine andere Stelle gerutscht oder aber habe ich beim Einrichten der neuen APs vergessen irgendo etwas einzustellen, damit der Menüpunkt erscheint?

LG

Petra

Zitat von opensec

Hi Petra,

danke Dir für das ausführliche Feedback in der Sache.

Eine OPNsense und pfSense will ich sicherlich auch nicht. Das ist mir zu "viel".

Ja - so eine UDM macht schon Vieles gut und kann z.T. natürlich auch mehr als eine fritz.box

Keine leichte Entscheidung - denn im Grunde kann so ne fritz.box schon viel bei sehr wenig Stromverbrauch. Die Access Points sind halt nicht so schön/elegant und nicht so leicht umzusetzen - aber irgendwie gehen tut es ja schon.

Hast Du denn IPv6 auch am Laufen?

Alles anzeigen

naja, das ist Geschmackssache. Zu FB-Zeiten hate ich diese hässlichen Repeater im Haus verteilt (die zudem im Vergleich zu der hervorragenden Abdeckung der Unifi APs auch von der Funktion her zu wünschen übrig liesen). Die APs von UNifi gefallen mir besser. Im Wohnbereich machen UAP-FlexHD und U6-Mesh eine gute Figur. Beim Kaffekränzchen wurde ich schon gefragt, wo man diese formschöne Feng Shui-Lampe bekommt. Dass das ein AP und kein Kunstobjekt ist merken die meisten Besucher nicht. Auf dem Hof und im Büro reichen die nüchtern Ufos. Ich habe im Grunde nichts gegen FB, aber vom Design her hat UNifi mehr zu bieten. Selbst die Switches haben eine Apple-ähnliche Anmutung. Wenn ich an unsere alten HP-Switches denke wird mir heute noch übel, die konnte man nur im Keller verstecken - mal davon abgesehen, dass das Management von diesen Kisten extrem öde war. Bei UNifi macht das Switch-management genau soviel Spass wie die schicke Gui der FB. Was mir bei UNifi gefällt ist die gefällige Formensprache und die einheitliche Linie aller Devices sowie das einheitliche Management . Nach 2,5 Jahren bin ich froh, umgestiegen zu sein.

Stromverbrauch ist natürlich ein Thema. Habe mir ein paar Sheely-Plugs besorgt und will demnächst mal messen was der ganze UNifi Komfort und Design so für Stromkosten verursacht.

Zitat von opensec

Hi Zusammen,

ich überlege die ganze Zeit, ob die UDM Se überhaupt so die richtige Lösung ist für alles (unabhängig von den aktuellen Problemen die sie doch hat).

Ich selbst habe aktuell einen Dual Stack Kabel Anschluss der Vodafone und bald Telekom Glasfaser.

Also beides Anschlüsse welche auch IPv6 haben.

Die Frage, die ich mir stelle ist ob eine fritz.box o.ä. nicht evtl. doch eine bessere Lösung darstellen, als die UDM Se? Gerade IPv6 kann so eine fritz.box doch schon um einiges Besser, oder liege ich da falsch?

Irgendwie wird von Ubiquiti das Thema IPv6 sehr "bescheiden" behandelt...

Ich überlege mir, wie es am meisten Sinn macht, jetzt sein Netzwerk zu Hause (Familie und Co) mit den ganzen Devices (aber auch zwei Gastfamilien, die ein WIFI bekommen) aufzubauen.

Immer wieder stoße ich halt auf "Einschränkungen" bei dem UniFi System, die z.B. eine fritz.box nicht so hat. Eine OPNsense im Vergleich schon gar nicht - aber das ist mir glaube ich einfach zu viel Aufwand.

Wie seht Ihr das so und wie würdet Ihr entscheiden bzw. entscheidet Ihr?

Alles anzeigen

bin mit der Fritzbox aufgewachsen und war begeistert. Bin auf Unifi umgestiegen und habe den Schritt nicht bereut. Betrieb die FB nur noch als Telefonanlage hinter der UDM.

Gute Kritik an der UDM von Lawrence Systems

APs und Switches sind meiner Meinung nach super. Die Protect-Linie gefällt mir auch. Alles unter einer Oberfläche zu managen will ich nicht mehr missen. Die UDM mag shortcommings haben, aber für Home small business völlig ok. Es sei denn man legt auf die fehlenden Feature wert, die Lawrence herausstellt.

LG

Petra

Zitat von hondaracer

ok funzt das denn auch wenn man statt einer FB zum beispiel es an eine Gigaset DX800A weiterleiten will. Weil das habe ich noch nicht hinbekommen.

Weil kann dann nicht telefonieren bzw kommen keine Anrufe durch wenn welche reinkommen.

Deswegen habe ich das Gigaset Telefonanlage direkt an die FB angeschlossen und opfere daher einen Netzwerkanschluss in den Keller

Gruß Swen

Ich habe keine Erfahrung mit dem Gerät. Ist es denn überhaupt eine Telefonanlage?

Gigaset DX800A Schnurgebundenes All-In-One DECT-Telefon mit großem Farbdisplay???

Was ich hier sehe (https://gse.gigaset.com/filead…20in%20one_Web_de_AUT.pdf) erinnert mich an das Gigaset N670 IP, was ich vorübergehend zum Testen hatte. Nach meiner Erinnerung war dieses Gerät keine Telefonanlage und musste mit der Fritzbox verbunden werden, so wie DU das mit deiner DX800A gemacht hast.

Zitat von tisp

Hallo zusammen,

ich wenden mich mal mit dem leidigen Thema FritzBox (Kabel), BridgeMode, Exposed Host usw an Euch. Dieses Thema wurde zwar schon einige mal hier im Forum besprochen, aber ich glaube inzwischen, dass sich hier ein paar Voraussetzungen geändert haben.

habe hier im Forum beschrieben, wie ich eine FB hinter der UDM als Telefonanlage 2021 eingerichtet habe. Nicht ganz Dein Ansatz. Fuktioniert aber seit 2 Jahren zufriedenstellend.

Zitat von gierig

um mal frech zu sein was hindert sich daran das einfach zu testen und auszuprobieren ?

Ist ja nicht so das danach gleich das halbe Netzwerk in die Luft Fliegt oder irgendwas doof ist...

und nein immer einen ganzen domain Namen, der dann wahlfrei da einfach stumpf ein

host-record Eintrag gemacht wird in DnsMasq der dann Präsenz über einen ggf realen domain

Namen hat (weil der lokale halt drauf antwortet)

Alles anzeigen

Ich habe da schon viel rumprobiert und Ergebinsse erzielt, auf die ich mir keinen Reim machen kann. Ich habe keine Dokumenation zur Funktionalität der DNS-Einträge auf den Gerätekarteikarten und zu dem bei der Definition der Netzwerke und freue mich immer über den anregenden Gedankenaustausch hier im Forum.

Zitat von bic

Du verwendest eine Firewall, die das letzte Mal vor 8 Jahren aktuallisiert wurde? Na dann!

Sorry war ein Versehen. Hatte IP Cop vor langer Zeit einmal im Einsatz und schon lange nicht mehr. Ich meinte PI Hole. Sorry.

ok und bei dem local dns Eintrag ist nur der Gerätename oder auch subdomain und domain einzugeben?

Dass ich domains/ (evt. auch subdomains) einen Namen geben kann habe ich bei der Network-Definition gesehen. Dann wäre es doch logisch wenn ich bei der Geräte-Karteikarte nur den Namen des Geäts eingebe???