Beiträge von gr00ve

Zitat von hommes

Hast du einen Netzwerktester da, dann am besten testen, es kann durchaus zu Kabelbrüchen führen, wenn es zu enge Biegeradien sind.

Habe ich getestet, alle 8 Adern plus Ground zeigen grün an.

Grüße,

gr00ve

UP 🔼

Nach mehr als 24h Betrieb war der ACP wieder offline und ließ sich nicht mehr zum Leben erwecken. Erst nach einem kompletten Reset und Neuadoption direkt am Switch ging er wieder online. Draußen in der Garage jedoch scheint er isoliert zu sein, also keine Datenverbindung zum Switch zu haben. Das wundert mich insofern, als das die Verbindung von diesem Testgerät als ok angezeigt werden.

Allerdings habe ich das Cat7 Kabel in einem Kabelkanal in der Garage in Schleifen gelegt, um für spätere Erweiterungen etwas Kabellänge übrig zu haben.

Könnten zu enge Schleifen / Knicke die Ursache sein oder hat der ACP ein Problem? Kann mir da jemand was dazu sagen?

Grüße,

gr00ve

Servus und ein Gutes Neues nachträglich!

Da mein Netzwerk eigentlich perfekt funktioniert, war ich schon länger nicht mehr hier, aber gestern gab's ein kleines Problemchen.

Ich weiß auch, daß es bereits einen Thread über RSTP Discarding gibt, aber da geht es um andere Hardware als bei mir.

Ich habe hier am Laufen:

• USG Pro 4
• USW-24-PoE
• US-8-60W
• 2x USW-Flex-Mini
• 3x UAP-AC-Pro

Das System lief die längste Zeit stabil, bis ich mir vor Kurzem einen gebrauchten UAP-AC-M angeschafft habe. Dieser soll in der Garage das ebenfalls neue E-Auto mit WLAN versorgen. Natürlich habe ich beim neuen Accesspoint einen Factory reset durchgeführt und das Verlegekabel vom Switch im Keller hinaus in die Garage ist getestet und für gut befunden.

Trotzdem ging mir der UAP-AC-M immer wieder offline und der betreffende Port am Switch zeigte das RSTP discarding Symbol. Gestern blockierte der Switch dann auch einen der AC-Pros, worauf dieser sich über Meshing an einen der anderen dranhängte.

Meine Vermutung bis jetzt ist, daß die Accesspoints, die ja alle verkabelt sind, sich untereinander einen Loop gebaut haben, was der Switch unterbinden wollte. Daher habe ich gestern Abend in den globalen ACP Einstellungen Meshing ausgeschaltet; ich brauche es ja sowieso nicht.

Soweit funktioniert alles wieder wie gehabt, aber ich wollte fragen, ob es noch einen anderen Grund für diese Verhalten geben könnte?

Grüße,

gr00ve

maxim.webster

Ich habe das Router Advertisement im Bereich IPv6 im Kinder Netzwerk disabled, und, siehe da, die USG ist wieder voll da.

Allerherzlichsten Dank!

Grüße,

gr00ve

Danke, das werde ich versuchen. Im schlimmsten Fall muss ich wahrscheinlich das Kinder Netz ganz löschen und wieder neu einrichten, was ich aber gerne vermeiden möchte, denn dann müsste ich wahrscheinlich auch im Pi-hole die Regeln neu definieren etc.pp.

Grüße,

gr00ve

maxim.webster

OK, vielen Dank, ich werde mal suchen.

Grüße,

gr00ve

Ich habe das Netz "Kinder" pausiert und die USG neu gestartet, was aber leider keine Lösung war. Mir fiel gerade ein, daß ich das schon mal über die Android App gemacht hatte, als sich die Bande mal wieder daneben benommen hatte. Kann es sein, daß der Zugriff über die App in der radvd.conf was verbogen hat? Ich habe eben versucht, dass Netz aus der App zu pausieren und wieder zu reaktivieren, aber er Loop besteht noch immer.

Grüße,

gr00ve

Schon gefunden:

interface eth0.10 {
#   This section was automatically generated by the Vyatta
#   configuration sub-system.  Do not edit it.
#
#   Generated by root on Thu Jun 23 09:58:17 2022
#
    IgnoreIfMissing on;
    AdvSendAdvert on;
    AdvOtherConfigFlag off;
    AdvDefaultLifetime 1800;
    AdvLinkMTU 0;
    AdvCurHopLimit 64;
    AdvReachableTime 0;
    MaxRtrAdvInterval 600;
    MinRtrAdvInterval 198;
    AdvDefaultPreference high;
    AdvRetransTimer 0;
    AdvManagedFlag off;
    prefix ::/64 {
        AdvPreferredLifetime ;
        AdvAutonomous on;
        AdvOnLink on;
        AdvValidLifetime ;
    };
    DNSSL Kinder {};
};
interface eth0.20 {
#   This section was automatically generated by the Vyatta
#   configuration sub-system.  Do not edit it.
#
#   Generated by root on Wed Jun 22 21:57:18 2022
#
    IgnoreIfMissing on;
    AdvSendAdvert on;
    AdvOtherConfigFlag off;
    AdvDefaultLifetime 1800;
    AdvLinkMTU 0;
    AdvCurHopLimit 64;
    AdvReachableTime 0;
    MaxRtrAdvInterval 600;
    MinRtrAdvInterval 198;
    AdvDefaultPreference high;
    AdvRetransTimer 0;
    AdvManagedFlag off;
    prefix ::/64 {
        AdvPreferredLifetime 14400;
        AdvAutonomous on;
        AdvOnLink on;
        AdvValidLifetime 86400;
    };
};
interface eth0.30 {
#   This section was automatically generated by the Vyatta
#   configuration sub-system.  Do not edit it.
#
#   Generated by root on Wed Jun 22 21:57:20 2022
#
    IgnoreIfMissing on;
    AdvSendAdvert on;
    AdvOtherConfigFlag off;
    AdvDefaultLifetime 1800;
    AdvLinkMTU 0;
    AdvCurHopLimit 64;
    AdvReachableTime 0;
    MaxRtrAdvInterval 600;
    MinRtrAdvInterval 198;
    AdvDefaultPreference high;
    AdvRetransTimer 0;
    AdvManagedFlag off;
    prefix ::/64 {
        AdvPreferredLifetime 14400;
        AdvAutonomous on;
        AdvOnLink on;
        AdvValidLifetime 86400;
    };
};
interface eth0.40 {
#   This section was automatically generated by the Vyatta
#   configuration sub-system.  Do not edit it.
#
#   Generated by root on Wed Jun 22 21:57:19 2022
#
    IgnoreIfMissing on;
    AdvSendAdvert on;
    AdvOtherConfigFlag off;
    AdvDefaultLifetime 1800;
    AdvLinkMTU 0;
    AdvCurHopLimit 64;
    AdvReachableTime 0;
    MaxRtrAdvInterval 600;
    MinRtrAdvInterval 198;
    AdvDefaultPreference high;
    AdvRetransTimer 0;
    AdvManagedFlag off;
    prefix ::/64 {
        AdvPreferredLifetime 14400;
        AdvAutonomous on;
        AdvOnLink on;
        AdvValidLifetime 86400;
    };
};

Zitat von BlackSpy

Ist der Loop einfach gekommen? oder nach der Bearbeitung der Json Datei?

Ist Punkt 2 zutreffend gibt es einen Fehler in der config.gateway.json (Syntax oder so, meist nur ein Schreibfehler).

Ansonsten mal komplett runter und hochgefahren?

Nein, die config.gateway.jsaon ist seit der Einrichtung unbearbeitet und die habe ich auch von der genannten Website kopiert, um eben genau diese Schreibfehler zu vermeiden. Runterfahren lässt er mich im Controller nicht, ich musste die harte Tour (Stecker ziehen) gehen. Hab ich gestern gemacht und brachte nichts.

maxim.webster : Moment, muss die Datei erst finden.

Grüße,

gr00ve

Servus,

ich habe seit einigen Tagen ein Problem, bei dem ich Eure Hilfe benötige: meine USG Pro 4 hängt in einem provisioning loop fest und wird im Controller permanent als "getting ready" angezeigt.

In meinem Netz hängt eine Fritz.Box vor der USG und das NAT der USG ist per config.gatway.json laut dieser Anleitung deaktiviert. Was mir dabei auffällt ist, dass die USG nicht im Unifi Netz (xxx.xxx.1.xxx), sondern im Netz der Fritz.Box (xxx.xxx.178.xxx) angezeigt wird. Ich habe schon mit Troubleshooting begonnen, in dem ich aus /var/log das File messages ausgelesen habe:

Jun 23 09:18:23 USGPro4 radvd[3328]: exiting, failed to read config file
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] [ interfaces ethernet eth0 vif 10 ipv6 router-advert ]
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] Re-generating radvd config file for interface eth0.10...
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] Starting radvd...
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] Starting radvd: /etc/radvd.conf:20 error: syntax error, unexpected ';', expecting NUMBER or INFINITY
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] [Jun 23 09:18:23] radvd (3328): exiting, failed to read config file
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] failed.
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] 0
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit error] Commit failed
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [delete] failure: 0 success: 1
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [set] failure: 0 success: 1
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: mca-edgemax._edgemax_parse_set_commit_save_results(): [commit] failure: 1 success: 1
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: ace_reporter.reporter_handle_response(): edgemax apply config failed (error code: 4)
Jun 23 09:18:26 USGPro4 mcad: mcad[4507]: ace_reporter.reporter_handle_response(): commit errors, {"COMMIT": {"error": "[ interfaces ethernet eth0 vif 10 ipv6 router-advert ]\nRe-generating radvd config file for interface eth0.10...\nStarting radvd...\nStarting radvd: /etc/radvd.conf:20 error: syntax error, unexpected ';', expecting NUMBER or INFINITY\n[Jun 23 09:18:23] radvd (3328): exiting, failed to read config file\nfailed.\n\n0\nCommit failed\n", "failure": "1", "success": "1"}, "DELETE": {"failure": "0", "success": "1"}, "SESSION_ID": "8045b776c919fde9567e564294", "SET": {"failure": "0", "success": "1"}}#012

Leider reichen meine Kenntnisse nicht aus, das richtig zu interpretieren und dafür brauche ich Eure Hilfe. Das Problem besteht seit einigen Tagen, nachdem es seit anderthalb Jahren klaglos funktioniert hat. Kann das möglicherweise an einem Softwareupdate des Controllers liegen?

Grüße,

gr00ve

Hi,

ich häng mich mal dran, wenn ich darf.

Seit dem ich heute Nachmittag die Updates gemacht habe, die mir im Controller für meine USG - Pro - 4 (4.4.55.5377109) uns USW -24-PoE (5.43.35.12698) angeboten wurden, bekomme ich auf allen meinen drei AC-Pros permanent kurze Aussetzer und es wird "Heartbeat missed" im Controller angezeigt. Außerdem tut sich der Laptop schwer, sich mit den betreffenden ACPs zu verbinden, obwohl die SSIDs richtig angezeigt werden.

Ich versuch's jetzt mal mit einem Restart aller Access Points.

Falls das nicht helfen sollte, kann ich den Switch (ich vermute, an dem liegt es, weil alle ACPs da direkt dranhängen) wieder downgraden?

Gruß,

gr00ve

Edit: die Restarts der ACPs scheinen geholfen zu haben, bis jetzt heute morgen keine Aussetzer.

matijaF

Das stimmt schon so, wie Du es da eingetragen hast. Das Gateway für das Netz hinter der UDM ist ja die UDM selbst mit der IP 10.1.1.1, das Subnetz ist 10.1.1.0/24. Bei läuft es nach dem gleichen Schema.

Gruß,

gr00ve

Ich habe das mit Pi-Hole und einem eigenen VLAN / WLAN für die Kinder gelöst.

Im Pi-Hole habe ich eine Gruppe "Kinder", für die restriktivere Regeln gelten als für den Rest des Netzes und mittels MAC Adress Filter stelle ich sicher, daß sie sich nur in das Kinder WLAN einloggen können. Die Nutzungszeiten werden auf den Android Geräten über Family Link festgelegt und auf der Linux Maschine läuft Timekpr-nExt. Damit habe ich auch nicht das Problem, daß sie einen anderen DNS verwenden, da sie unter Linux nicht an diese Einstellungen rankommen. Bis jetzt bin ich sehr zufrieden mit diesem Setup.

Gruß,

gr00ve

@EJHome

Ich glaube, ihr sprecht von zwei verschiedenen Dingen. Du meinst Site-to-Site in Bezug auf zwei Unifi "Sites", während razor den Begriff allgemeiner versteht, als Kopplung von zwei beliebigen LANs über VPN (Engl. site to site).

Gruß,

gr00ve

Zitat von matijaF

Niemand hat eine Lösung für mein Problem?

Ich weiß jetzt auch nicht mehr weiter, sorry.

Versuche, den Thread noch einmal von Anfang an durchzugehen und überprüfe folgende Punkte einzeln:

• config file Box A
• config file Box B
• static routes Box B
• UDM NAT ein oder aus
• WAN in rules UDM mit group (z. Bsp. LAN2LAN Address 192.168.10.0/24)

Mit dem Punkt 3 in der Anleitung von AVM ist der letzte Punkt der oben stehenden Liste gemeint: Dein Router hinter der FB B ist die UDM und die muss den Traffic aus Netz 192.168.10.0 durchlassen.

Wenn Du es dann noch immer nicht hin bekommst, musst Du vielleicht doch in den sauren Apfel beißen und einen Netzwerktechniker bezahlen, der vor Ort alles überprüft.

Gruß,

gr00ve

Zitat von EJHome

...

Bis vor ca. sechs Monaten, konnte man im UniFi-Controller noch Site-to-Site VPN aufbauen, mit FQDN, also auch DynDns!

Das geht zurzeit nicht.

...

OK, das wusste ich nicht. Again what learned.

Wenn es schon mal ging, besteht ja Hoffnung, daß es irgendwann wieder funktioniert. Wäre ja nicht das erste Mal, daß Unifi ein Feature "weg updated" und später zurück bringt.

Gruß,

gr00ve

matijaF

Das sieht so aus, als ob der Tunnel nur nach einer Richtung funktioniert. Kannst Du Dich von zu Hause aus auf die Fritz Box B einloggen?

Gruß,

gr00ve

Zitat von matijaF

gr00ve

Haben Sie eine Idee, wie ich einen IP-Client in einem 192.168.10.0-Netzwerk manuell einrichte und 192.168.178.1 als Gateway verwende können?

Ich interpretiere das so, daß Du einen Deiner Rechner zu Hause von DHCP auf manuelle IP Adresse umstellen und dabei als Gateway Box B [192.168.178.1] eintragen sollst. Unter Win10 gehst Du dazu in die PC Einstellungen, Netzwerk und Internet, {DEIN_NETZ} Eigenschaften, IP Einstellungen bearbeiten. Dort kannst Du manuell eine IP Adresse vergeben und Box B als Gateway eintragen.

Gruß,

gr00ve

matijaF

Nein, nicht für jeden Client, aber für jedes Subnetz. Wenn Du nur das Management LAN 10.1.1.0/24 hast, reicht die erste Route. Hast Du aber mehrere VLANs 10.1.xx.0/24, braucht jedes seine eigene Route. Das ist damit gemeint.

Gruß,

gr00ve

matijaF

Das habe ich noch nie gemacht, da ich ein USG Pro4 und keine UDM besitze. Ich hatte Dir nur den Thread im offiziellen Unifi Forum verlinkt, weil ich mal drüber gestolpert war. Vielleicht fragst Du mal in da mal nach? Routen in der UDM braucht es nicht, das stimmt, aber in der Fritz Box muß für jedes Subnetz eine static Route vorhanden sein, wenn die UDM kein NAT macht.

Gruß,

gr00ve

matijaF

Wenn das NAT der UDM deaktiviert ist, brauchst Du in der Fritzbox statische Routen für jedes Subnetz hinter der UDM. Hast Du die? Passen die Firewallregeln noch? in Post Nr 21 hattest Du sie, hast Du daran was geändert? Hast Du getestet, ob das NAT tatsächlich deaktiviert ist? Dazu deaktivierst Du die statische Route in der FB und versuchst danach, aus dem 10.1.1.0 Netz ins Internet zu kommen. Wenn das nicht mehr geht, ist das NAT deaktiviert.

Gruß,

gr00ve