Beiträge von petra92

Zitat von somm

Wer weiß fileicht kommt ja noch eine UDM Pro max SE

Oder eine UDM Pro Ultra

Hier wird für Fehlerbild

https://community.ui.com/questions/Cannot-adopt-USW-Ultra-60W/74f54651-1d76-417d-9506-23892cc0a321

als Lösung angegeben, im Legacy Modus Adoption durchzuführen.

Im neuen Modus habe ich zunächst das Device "vergessen". die Adoptionsversuche hören dann auf. UNter click learn more steht:"

To adopt this device, hold the reset button until its LED state changes. After 1-2 minutes, it will appear for adoption."

Ich habe dann in den Legacy Modus umgeschaltet.

Im Legacy Modus wird zunächst "managed by other" angezeigt.

Dann habe ich ein Reset bei der USW-Ultra vorgenommen. Danach liess sich das Gerät adoptieren.

Sehr seltsam.

LG

Petra

Hier wird selbes Fehlerbild bescrieben

From the Ubiquiti community on Reddit

Explore this post and more from the Ubiquiti community

www.reddit.com

Hallo eine neue USW-Ultra läßt sich nicht von meiner UDM Pro adoptieren. Sie bekommt Strom per POE++ und hängt an einem Port dem das default VLAN zugewiesen ist. Sie erhält für kurze Zeit eine IP aus dem DEfault-Netz (172.16.1.x). Dann bekommt sie eine IP aus dem Bereich 192.168.1.x, dabei wird abwechselnd angezeigt "adopting" und "click to resolve". Port-Wechsel, stromlosmachen und Reset haben nichts gebracht. Network ist auf 8.1.113. Sieht für mich nach einem Hardwaredefekt aus? Hat noch jemand eine andere Idee.

LG,

Petra

Ah gefunden: https://xxx.xxx.xxx.xxx/networ…s/security/firewall-rules

und dann advanced aktivieren und schon sieht man conntrack options und timeout settings

Zitat von sebcodes

Aus Neugier, welche Option ist das aus dem Screenshot?

Ich finde das nur im legacy gui hier:

Der Screenshot oben sieht anders aus. also müßte das auch in der neuen GUI zu finden sein - nur ich finde es nicht.

Zitat von BlackSpy

In der neuen Beta Network App gab es eine Hinweis auf Unifi OS 4.

Nach suchen im Unifi Forum wurde dies auch bestätigt, nur keine Aussage wann sie kommt und was neu wird.

Was würdet ihr euch wünschen?

Integration einer internen certificate authority zB. von https://smallstep.com

Zitat von flo222

Klar, genau dafür ist die GO-Box 100 ja gedacht. Du hinterlegst Deine ganzen Telefonnummern je Provider (gehen auch unterschiedliche) und ordnest diese dann den an der Box angemeldeten Telefonen zu. Ne FritzBox ist damit obsolet. Die Box hat eine eigene GUI auf die man sich aufschalten und alles einstellen kann. Ist quasi ne kleine DECT-Telefonanlage.

Das klingt interessant ich habe noch eine Gigaset N670. Ginge das auch damit?

Zitat von benni0707

Tja, übrig bleiben würde nur die Telefonie. Das übernimmt natürlich auch die FritzBox über VoiP. Dazu habe ich die Fritz Telefone. Festnetz nutze ich zwa kaum noch, aber ganz abschaffen möchte ich es nicht. Auch wenn es hier vermutlich von Ubi keine Lösung gibt, vielleicht hat jemand ein ähnliches Szenario und wüsste hier auch eine kleine Lösung. Natürlich wäre es auch denkbar die FritzBox die Telefonie weiterhin zu übernehmen, aber ne 7590 nur für Telefonie wahrscheinlich überbewertet.

Genauso würde ich natürlich die AVM Hardware weiterverkaufen um die Neueinrichtung ein bisschen auszugleichen.

So, viel Text. Vielen Dank im Voraus für Antworten.

Hallo,

Ich nutze 2 Fritzboxen als Telefonanlagen hinter einer UDM PRO.

DIe Fritzboxen sind in den IP-Client-Mode versetzt.

DIe Fritzboxen verwalten jeweils die die Festnetznummern, die meine ISPs zur Verfügung stellen.

Portweiterleitung aktiv halten aktivieren.

Bei der UDM noch folgende Schritte:

1. Conntrack SIP deaktivieren

2. 2 VLAN jeweils für die Fritzboxen anlegen (bei den Fritzboxen eine feste IP aus dem Adressbereich der VLANs vergeben)

3. Routing der Fritzboxen-VLANs an den jeweiligen WAN-Port

LG

Petra

Update:

Das Fehlerbild ist in den letzten Tagen nicht mehr aufgetreten. Es verbleibt ein ungutes Gefühl.

Update zur MAC-Adresse:

Mit dem Befehl

ifconfig | grep -i "eth"

bekommt man eine Liste der Mac-Adressen der eth-Ports der UDM-Pro.

ich gehe jetzt davon aus, dass die Mac-Adresse in den Meldungen wie

"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)" sich auf die Schnittstelle eth9 also Port 10 der UDM bezieht und eth10 ist dann Port 11 der UDM pro ist.

Also haben die Meldungen wahrscheinlich nichts mit dem vigor166 an Port 11 der USW Pro 24 POE zu tun. An Port 11 meiner UDM Pro hängt die USW Pro24 POE per SFP+-Modul. Port 10 der UDM Pro ist z.Zt nicht belegt (dort hatte ich einmal WAN2 über einen SFP-Adapter angeschlossen - jetzt ist WAN2 aber auf Port 8 konfiguriert und dort das vigor 166 angeschlossen.

Ich kann mir dann keinen Reim mehr auf die Meldungen machen.

Und es sieht so aus dass das vigor 166 an port 11 der USW dann auch nicht die Ursache für das in der ersten Nachricht beschriebene Fehlerbild ist.

Ich bin jetzt komplett verwirrt

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