Konnte es noch ausprobieren. Das deaktivieren von „Block LAN to WLAN multicast“ hat leider nichts gebracht.
Beiträge von smart-1987
-
-
Ja das stimmt leider.
Danke für den Screenshot. Ja genau das sind auch die default Werte bei mir…
Ich werde morgen mal versuchen Block LAN to WLAN multicast auszumachen. Bei mir hat das die Kommunikation meiner WLAN Geräte (vor allem den HomePods) deutlich verbessert und auch die Anzahl der verlorenen Pakete ist dadurch gesunken, deshalb habe ich es aktiviert. Wenn das die Ursache wäre, könnte ich das immerhin an Ubiquiti weitergeben, da diese Pakete vom USG ja sicher nicht blockiert werden sollten. Zumal das USG ja auch in der Ausnahmenliste ist.
Ich werde hier auf jeden Fall nochmal berichten. Wenn jemand trotzdem noch eine Idee hat, dann immer gerne her damit
-
Ich habe herausgefunden, dass mein Problem wahrscheinlich mit folgendem zusammenhängt: https://community.ui.com/quest…bd-4eb9-9692-4bb4a5c44bb5
Hier ist die Paketaufnahme von eth0 meines U6-LR (es gibt die RS-Nachricht und die RA-Nachricht):
Code10:46:10.210148 IP6 fe80::18d8:fc5e:db99:22a3 > ff02::2: ICMP6, router solicitation, length 8 10:46:10.213013 IP6 fe80::265a:4cff:fe7b:1e1b > ff02::1: ICMP6, router advertisement, length 144 10:46:10.398948 IP6 fe80::265a:4cff:fe7b:1e1b > ff02::1:ffab:f96d: ICMP6, neighbor solicitation, who has
Und hier ist die Paketaufnahme von meinem MacBook WiFi (en0). Es sendet nur die RS-Nachricht, empfängt aber irgendwie die RA-Nachricht nicht und erhält daher keine IPv6-Adresse bis zur nächsten unaufgeforderten RA (die standardmäßig zwischen 198 und 600 Sekunden laut radvd.conf erfolgt).
Code10:46:11.944435 IP6 fe80::18d8:fc5e:db99:22a3 > ff02::2: ICMP6, router solicitation, length 8 10:46:12.163315 IP6 fe80::1031:3b40:6a77:981f > ff02::1:ff99:22a3: ICMP6, neighbor solicitation, who has fe80::18d8:fc5e:db99:22a3, length 32 10:46:12.163317 IP6 fe80::4b0:29b0:3b4:9297 > ff02::1:ff99:22a3: ICMP6, neighbor solicitation, who has fe80::18d8:fc5e:db99:22a3, length 32 10:46:12.163382 IP6 fe80::18d8:fc5e:db99:22a3 > fe80::1031:3b40:6a77:981f: ICMP6, neighbor advertisement, tgt is fe80::18d8:fc5e:db99:22a3, length 32 10:46:12.163420 IP6 fe80::18d8:fc5e:db99:22a3 > fe80::4b0:29b0:3b4:9297: ICMP6, neighbor advertisement, tgt is fe80::18d8:fc5e:db99:22a3, length 32
Eine weitere Beobachtung: Das passiert nicht jedes Mal. Ich musste das MacBook 7 Mal neu verbinden, bis ich den Fall erfassen konnte. Bei meinen mobilen Clients wie dem iPhone 11 Pro passiert das aber fast immer. Es dauert wie beschrieben ca. 4-6 Minuten, bis es nach dem erneuten Verbinden mit dem WiFi-Netzwerk seine IPv6-Adresse erhält.
Wenn ich mein MacBook über LAN anschließe, bekommt es seine IPv6-Adresse sofort nach dem Einstecken des Kabels. IPv6 scheint also korrekt eingerichtet zu sein.
Ich habe "LAN zu WLAN Multicast blockieren" für mein WiFi-Netzwerk aktiviert. USG (der Router) ist natürlich ausgeschlossen (standardmäßig), so dass die Pakete nicht blockiert werden sollten. Aber vielleicht könnte das eine erste Eingrenzung der Ursache für den Fehler sein?
Die Firmware meines U6-LR ist 5.60.23.13051 (letzte stabile Version).
Vielleicht hat ja jemand das gleiche Problem mit seinen U6-LR und möchte hier einmal berichten?
-
Hat es denn eigentlich einen Nachteil, wenn ich das max-Intervall der RAs auf 10 Sekunden verkürze?
Das hier verunsichert mich halt etwas:
RFC 7772 - Reducing Energy Consumption of Router Advertisements
Wie ist das Intervall denn bei deiner pfSense?
-
Ganz sicher. Ich hab alles 5-fach überprüft und zig Anleitungen im UI Forum angeschaut. Und nach einigen Minuten bekomme ich ja dann die IPv6, und kann auch Webseiten wie ipv6.google.com aufrufen.
Die fd Adressen vergebe ich, damit ich einen statische Adresse für meinen Raspberry Pi habe, auf dem Pi-hole läuft. Diese fd-Adresse kann ich dann als DNS Server verwenden.
Wieso muss das eigentlich alles so experimentell sein, ich fühle mich als wäre das alles noch Beta. Bei meiner Fritzbox davor hat es einwandfrei funktioniert mit den IPv6.
-
Ja die Idee hatte ich auch schon. Das hat leider nichts geändert. Auch ohne das fd Zeug bekomme ich erst nach Minuten eine IP zugewiesen.
Allerdings bekomme ich ohne die öffentliche IP direkt eine meiner ULAs zugewiesen, was ja auch nicht der Fall ist, sobald ich die öffentliche wieder aktiviere.
Ok, ja so sollte es ja auch eigentlich sein…
-
Ja die advertisements sind ja immer mit lokalen fe Adressen. Und die fd ist die ULA, die alle Clients bekommen sollen.
Sobald das iPhone eine IPv6 bekommt, ist es eine öffentliche 2a…..
-
Hi Wolke68,
ja genau so bin ich auch vorgegangen. Das funktioniert soweit ja auch einwandfrei alles. Lediglich das Problem, dass es lange dauert, bis ich eine IPv6 bekomme nach einem Reconnect ist halt da.
Das ist aber doch sicher nicht der Normalfall oder?
-
Hallo liebe Community,
ich habe kürzlich IPv6 auf meinem USG-3P eingerichtet. Zusätzlich verwende ich 2 U6-LR mit der neuesten Firmware. Ich schaffe es leider nicht, IPv6 nicht richtig zum Laufen bringen. Wenn ich ein Gerät, wie mein iPhone, von meinem Wifi-Netzwerk trenne und es dann wieder anschließe, dauert es mehrere Minuten, bis es eine IPv6-Adresse erhält. In dieser Zeit ist IPv6 auf meinem iPhone nicht nutzbar.
Ich habe viel recherchiert und sehr vieles ausprobiert. Hier sind einige Packet Sniffs auf dem U6 AP, mit dem das iPhone verbunden ist:
Code20:09:21.946179 IP6 fe80::54:9704:9ac3:1740 > ff02::2: ICMP6, router solicitation, length 8 20:09:21.948962 IP6 fe80::265a:4cff:fe7b:1e1b > ff02::1: ICMP6, router advertisement, length 144
Sobald sich das iPhone verbindet, sendet es eine Router Solicitation (RS) Nachricht und USG antwortet mit einer Router Advertisement Nachricht (RA), aber das iPhone bekommt kein IPv6. Vielleicht wird die RS zu früh gesendet?
Dann, nach etwa 4 Minuten, sendet das iPhone? eine weitere RS und erhält eine RA-Antwort von USG:
Code20:13:13.075434 IP6 fe80::815:bb91:a4f0:bbbd > ff02::2: ICMP6, router solicitation, length 8 20:13:13.077662 IP6 fe80::265a:4cff:fe7b:1e1b > ff02::1: ICMP6, router advertisement, length 144
Das war genau der Zeitpunkt, an dem mein iPhone eine IPv6 erhalten hat.
Ich konnte dieses Problem nur beheben, indem ich das Max-Intervall des Router Advertisements auf 10 (maxrtradvinterval) und das Min-Intervall auf 3 (minrtradvinterval) setze. Mit dieser Einstellung sendet mein USG sehr häufig RAs und das iPhone erhält seine IPv6 einige Sekunden nach dem Verbindungsaufbau.
Was kann ich noch versuchen, um das Problem zu lösen, und hat jemand von dem gleichen Problem schon einmal gehört oder es sogar selber gehabt?
Stimmt es auch, dass es nicht empfehlenswert ist, die Häufigkeit der RAs auf ein so kurzes Intervall einzustellen, da dies die Batterie meiner Clients entleert und mein Netzwerk mit ICMP6-Paketen vollspammt?
Vielleicht ist noch ein anderes Detail wichtig: Ich verwende 6 HomePod minis, die ein Thread-Netzwerk aufbauen, und diese HomePods spammen mein Netzwerk buchstäblich mit RAs zu, wie der Sniff zeigt. Macht es dann überhaupt noch was aus, weitere ICMP6-Pakete von USG zu erhalten?
Code
Alles anzeigen20:12:40.860978 IP6 fe80::188c:dcc4:dd76:3626 > ff02::1: ICMP6, router advertisement, length 72 20:12:40.982279 IP6 fe80::4d8:9c1a:d226:e4bc > ff02::1: ICMP6, router advertisement, length 72 20:12:45.142145 IP6 fe80::1095:eb74:ab78:f211 > ff02::1: ICMP6, router advertisement, length 72 20:12:45.380924 IP6 fe80::188c:dcc4:dd76:3626 > ff02::1: ICMP6, router advertisement, length 72 20:12:46.008439 IP6 fe80::c25:82cb:7bad:62be > ff02::1: ICMP6, router advertisement, length 72 20:12:46.020723 IP6 fe80::4b0:29b0:3b4:9297 > ff02::1: ICMP6, router advertisement, length 72 20:12:46.286019 IP6 fe80::102f:e118:e54a:6242 > ff02::1: ICMP6, router advertisement, length 72 20:12:46.412939 IP6 fe80::4d8:9c1a:d226:e4bc > ff02::1: ICMP6, router advertisement, length 72 20:12:50.685280 IP6 fe80::1095:eb74:ab78:f211 > ff02::1: ICMP6, router advertisement, length 72 20:12:51.208018 IP6 fe80::4b0:29b0:3b4:9297 > ff02::1: ICMP6, router advertisement, length 72 20:12:51.443159 IP6 fe80::4d8:9c1a:d226:e4bc > ff02::1: ICMP6, router advertisement, length 72 20:12:51.477243 IP6 fe80::c25:82cb:7bad:62be > ff02::1: ICMP6, router advertisement, length 72 20:12:51.673059 IP6 fe80::102f:e118:e54a:6242 > ff02::1: ICMP6, router advertisement, length 72 20:12:51.717200 IP6 fe80::188c:dcc4:dd76:3626 > ff02::1: ICMP6, router advertisement, length 72 20:12:55.936900 IP6 fe80::188c:dcc4:dd76:3626 > ff02::1: ICMP6, router advertisement, length 72 20:12:55.939302 IP6 fe80::4b0:29b0:3b4:9297 > ff02::1: ICMP6, router advertisement, length 72 20:12:55.997299 IP6 fe80::1095:eb74:ab78:f211 > ff02::1: ICMP6, router advertisement, length 72
Weitere Details zu meinem aktuellen Setup
Ich habe ein /56-Präfix von meinem ISP bekommen und es mit DHCPv6 eingerichtet. In meinem Heim-LAN habe ich IPv6-Präfix-Delegation und RA-Ankündigung auf hoch eingestellt.
Ich habe auch einen benutzerdefinierten DNS-Server eingerichtet (meinen Pi-hole). Also nichts Besonderes.
Über die config.gateway.json habe ich ULA für alle meine Clients eingestellt:
Code
Alles anzeigen{ "interfaces": { "ethernet": { "eth0": { "dhcpv6-pd": { "rapid-commit": "disable" } }, "eth1": { "Adresse": [ "192.168.18.1/24", "fd12:3456:789a:bcde::1/64" ], "ipv6": { "router-advert": { "cur-hop-limit": "64", "link-mtu": "0", "managed-flag": "true", "max-interval": "600", "other-config-flag": "wahr", "prefix": { "fd12:3456:789a:bcde::/64": { "autonomous-flag": "true", "on-link-flag": "true", "bevorzugte-Lebensdauer": "14400", "Gültige-Lebensdauer": "86400" } }, "Erreichbar-Zeit": "0", "retrans-timer": "0", "send-advert": "true" } } } } } }
So sieht meine radvd.conf auf USG aus:
Code
Alles anzeigeninterface eth1 { # Dieser Abschnitt wurde automatisch vom Vyatta # Konfigurations-Subsystem generiert. Bearbeiten Sie ihn nicht. # # Generated by root on Sat Feb 12 18:43:28 2022 # IgnoreIfMissing ein; AdvSendAdvert ein; AdvOtherConfigFlag ein; AdvDefaultLifetime 1800; AdvLinkMTU 0; AdvCurHopLimit 64; AdvReachableTime 0; MaxRtrAdvInterval 600; MinRtrAdvInterval 198; AdvDefaultPreference hoch; AdvRetransTimer 0; AdvManagedFlag ein; Präfix ::/64 { AdvPreferredLifetime 14400; AdvAutonomous ein; AdvOnLink ein; AdvValidLifetime 86400; }; Präfix fd12:3456:789a:bcde::/64 { AdvPreferredLifetime 14400; AdvAutonomous ein; AdvOnLink ein; AdvValidLifetime 86400; }; RDNSS fd12:3456:789a:bcde::40 { }; };
Ich bin sehr froh über jede Idee und jeden Vorschlag.
Danke euch!