IPV6 router advertisement

[asmcc]

Hallo cuma,
ich experimentiere bei mir gerade mit einer ziemlich wilden Netzwerkumgebung (OPNsense als Firewall mit mehreren Netzwerken + 7590 als DSL-Router + eine zweite 7590 die dann im LAN angeschlossen ist und WLAN mit den AVM-Repeatern in MESH macht). Dabei will ich mein "AVM-Universum" nicht ganz aufgeben und kämpfe gerade mit dem GAST-WLAN bzw. GAST-LAN. In der "alten" IPV4-Welt ist alles wunderbar, bei IPV6 habe ich gerade ein folgendes Problem festgestellt: dnsmasq reagiert leider gar nicht auf die so genannten "Router Advertisment (RA)"-Anfragen, sondern der multid "überstimmt" hier den dnsmasq und antwortet mit den IPV6-Einstellungen aus dem AVM-WebIF. Interessanterweise startet dnsmasq dabei ohne Fehler und behauptet, dass er die RAs auch in dem ihm bekannten IPV6-Bereich verteilt. Tut er aber in der Realität nicht.
Ich weiß, dass du kräftig an dem "wrapper" mitgewerkelt hast, der sich zwischen dem multid und dem dnsmasq platziert. Aus diesem Grund frage ich auch hier. Die "normalen" UDP- und TCP-Ports sieht man ja auch mit "netstat -tulpn" alle schön dem dnsmasq zugeordnet (z.B. Port 53 usw.), bei diesem "Router Advertisment" erfolgt die Kommunikation allerdings über ICMPv6-Protokoll, wenn man es überhaupt als Protokoll bezeichnen darf. Also, es ist weder UDP noch TCP und soweit ich es verstanden habe, gibt es dazu keine "Ports" in dem Sinne, wie man es von UDP oder TCP kennt. "netstat -wlpn" (für raw-sockets) liefert folgende Ausgabe bei mir:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
raw 0 0 0.0.0.0:2 0.0.0.0:* 2 12082/multid
raw 0 0 0.0.0.0:2 0.0.0.0:* 2 12082/multid
raw 0 0 0.0.0.0:2 0.0.0.0:* 2 12082/multid
raw 0 0 0.0.0.0:2 0.0.0.0:* 2 12082/multid
raw 0 0 :::58 :::* 58 2075/dnsmasq
raw 0 0 :::58 :::* 58 12082/multid

Ich vermute mal, dass die letzten zwei Sockets (58) für RA zuständig sind und vermutlich da beide "parallel" laufen. Ich nehme mal an, dass es im Unterschied zu UDP/TCP mit ihren festen Ports sowas möglich ist.
Fragen:

1. Klingt meine Beobachtung und Erklärung plausibel, oder stehe ich irgendwo anders auf dem Schlauch?
2. Kann man dem multid irgendwie abgewöhnen, RA-Anfragen zu beantworten und da überhaupt als eine RA-Instanz zu lauschen? Die Einstellungen im AVM-WebIF helfen da leider nicht weiter. Der RA von dnsmasq wird immer durch RA von multid überstimmt, selbst wenn man in AVM WebIF alles "abstellt".

Danke!

[aus-sua]

Ich denke, es wäre (wie ja immer...) hilfreich, Deine benutzte FOS- und die freetz-NG-Version mit anzugeben.

[asmcc]

Ich glaube zwar nicht, dass dies wirklich der Klärung der Sache beiträgt, denn die Änderungen am Wrapper wurden schon vor einer Weile gemacht, wenn ich es richtig mitbekommen habe. Ich poste es aber dennoch:
7590_07.57.all-rev107893_MOVE21NL1
freetz-ng-22530
Gebaut am 17.09.2023
Eine "alte" 7590, noch ohne AX.
Meine weitere Beobachtungen bzgl. IPv6 (zumindest im Gast-WLAN und mit meiner jetzigen Konfiguration): Ich kann mit dem "laufenden" dnsmasq keine IPV6-Verbindung nach draußen aufbauen: Weder DNS, noch "ping -6" von einem Gast-client geht. Von daher vermute ich, dass da noch mehr dahinter steckt, als nur die fehlende RA-Vergabe. Ich muss es aber noch tiefer untersuchen, um eine detailliertere Information dazu zu bekommen, was z.B. mit/ohne dnsmasq (und dann entsprechend mit/ohne multid als DNS/DHCP/RA) da alles geht und was nicht geht. Auch mit traceroute und ähnlichen Werkzeugen. Denn bei IPV6 bekommt man unter anderem "externe" IPV6-Adressen zugewiesen (2axx-Bereich), was in dem Falle nicht passiert. Die lokalen fexx oder die ULA mit z.b. fdxx helfen da meiner Beobachtung nicht wirklich weiter, weil sie zum Teil vom Router geblockt werden. Und leider weiß ich nicht in Detail, wie AVM es in ihrer "Firewall" realisiert.
Ich kämpfe an der Front solange weiter, bis ich etwas rauskrige, was mich ggf. weiter bringt, werde aber auch nach alternativen Wegen suchen und ggf. einen Umweg über meine OPNsense machen, wie ich es bereits im normalen LAN/WLAN mache.

[aus-sua]

nicht OT:

Ich glaube zwar nicht, dass dies wirklich der Klärung der Sache beiträgt...

Ernsthaft?! :-(
Wie kommt man nur immer zu solchen "Ansagen"?
Du kannst gerne glauben was Du möchtest, aber denke wenigsten einmal vorher nach!
Es gibt freetz-ng für xx Stück verschiedene FOS-Versionen, wie soll z.B. jemend Dein Problem
nachvollziehen, wenn Du schon diese "verheimlichen" möchtest?

Aber danke für's dann doch "liefern", ohne weitere Diskussion. ;-)

freetz-ng-22530

Stand ist z.Z. 23247M - ca 720 Änderungen weiter...
bau NEU!

Ja,
auch das wird Dein Problem wohl noch nicht lösen...
Aber keiner wird für alte freetz-NG-Versionen irgend etwas testen/nachvollziehen, wenn es
damit nicht gerade die Fehlerrückverfolgung erleichtert!

[aus-sua]

Ich glaube, Du "zäumst das Pferd von der falschen Seite" auf.

Teste Deine spezielle Konfiguration und Netzwerkumgebung doch erst einmal mit der
Original-FOS-Version + IPv6, um wenigstens Grundlegendes zu überprüfen/testen/auszuschließen.

Gastnetz-LAN und Gastnetz-WLAN unterscheiden sich ja auch technisch,
kennst Du die Unterschiede/Einzelheiten?
Kennst Du die AVM-Zugangsprofile und deren Beschränkungen/Arbeitsweisen
für die Gastnetze?

[asmcc]

Nee, deswegen jetzt "auf Verdacht" neu zu bauen, mache ich sicherlich nicht. Ich gehöre nicht zu der Sorte der Leute, die einfach darauf hoffen, dass es mit einer neueren Software "alles besser wird". Tut es meiner Erfahrung nach in den 99% der Fälle nicht. Aber ja, ich habe es noch nicht gründlich untersucht und analysiert.
Meines Erachtens habe ich das Problem allerdings im ersten Posting ausreichend beschrieben: dnsmasq wird durch multid bei der RA-Kommunikation "überstimmt". Per RA werden die Werte aus AVM-WebIF verteilt und nicht das, was man unter dnsmasq einstellt. Vielmehr: dnsmasq meldet sogar im Log und meint, dass er seine Werte per RA verteilen würde, tut es aber in der Realität nicht. Aber gut, wenn es nicht ausreichend genug deifiert und beschrieben ist, "lege ich mich wieder schlafen", wie es schön heißt. Bzw. untersuche es weiter in meinem "stillen Kämmerchen". Die Allgemeinheit hier braucht es anscheinend nicht.
Bzgl. Unterschiede zwischen dem Gastnetz und Gastnetz-WLAN würde ich es nicht so pauschal behaupten, dass sie völlig unterschiedlich sind. Zumindest besteht meine Hoffnung daran, dass sie halbwegs "bridged" sind, sobald man im AVM-WebIF die Kommunikation unter den Geräten erlaubt. Aber ja, sicher wissen tun wir es nicht und es bedarf weiterer Untersuchungen, was ich wohl demnächst tun werde.
Danke für die nette Unterhaltung hier!

[aus-sua]

darauf hoffen, dass es mit einer neueren Software "alles besser wird".

Das hat doch nichts mit "hoffen" zu tun!
Der Grund ist oben genannt...
"Waffengleichheit", oder anders gesagt: es spart mindestens Zeit in der Problemlösung!

meine Hoffnung daran, dass sie halbwegs "bridged"

Glauben/Hoffen >=< wissen...

Als Tipp:
Das FOS ist kein "normales" Linux, AVM hat viele Sachen anders gelöst, machmal regelrecht "gebastelt".
Mit Linux-Kenntnissen ist man da durchaus ggf. erst einmal "auf dem Holzweg"...
Viele der "Andersheiten" sind über Jahre im ip-ph-f beschrieben und "erkämpft", ggf. erst einmal dort quer lesen.
z.B. zur Gastnetz-IP-Vergabe:
ar7.cfg beachten

[asmcc]

Diese IPPF-Anleitung kenne ich schon längst. Und genau so ist es bei mir auch realisiert. Bloß, dort in IPPF hat man sich mit IPV4 befasst. Ich gehe aber deutlich weiter und treibe dnsmasq schon an seine Grenzen mit vielen Sonderoptionen unter "extras". Und ja, die sind jetzt für diese Experimente bis auf die zu testende Optionen auskommentiert.
Bzgl. Glauben, Hoffen und Wissen: Nach meinem jetzigen Überfliegen in den Quellen hier fühle ich mich in meinem vorherigen Glauben nur bestätigt: An dem besagten Wrapper wurde anscheinend seit August 2023 nichts mehr geändert. Somit dürfte meine FREETZ-NG-Version von September 2023 diesbezüglich aktuell sein.
Aber lass uns mal diese Diskussion hier beenden. So kommen wir hier nicht weiter. Ich habe es schon verstanden, dass ich MEIN PROBLEM mit MEINEN EIGENEN Mitteln lösen muss. Botschaft angekommen.

[aus-sua]

Ach komm,
nichts von dem, was Du jetzt auf einmal "rausgerückst", kann ich als gegeben bei Dir ansehen!
Wenn Du es kennst, warum schreibst Du es nicht schon in Deiner Eingangs-Frage?
Es war Dir ja wohl schon zuviel, wenigsten DEINE dnsmasq-config mit anzuhängen
bzw. überhaupt nur die FOS-Version zu nennen...
DAS hätte uns 4h Zeit gespart!
Ich habe hier nur die allg. basics abgefragt, die Du bisher eben alle nicht geliefert hattest!
Und jetzt bist Du beleidigt, weil DU selbst diese Infos nicht mit lieferst...

Ich habe es schon verstanden, dass ich MEIN PROBLEM mit MEINEN EIGENEN Mitteln lösen muss. Botschaft angekommen.

Selbstgefälliger Blödsinn.
Keiner hat so etwas behauptet!

[fda77]

58/raw sollte icmp-ipv6 sein, bin aber nicht sicher ... einfach mal selbst googeln. In /etc/protocols steh kein udo/tcp/raw dabei.
Bei ipv6 gibts ja verschieden Mechanismen für dhcp6 wird jedenfalls 546/udp + 547/udp genutzt.
Braucht RA überhaupt ein Listen-Port? Sendet das die Advertisements nicht einfach ungefragt in einem bestimmten Intervall ins Netz?

Und ganz wichtig bei ipv6: Nutzt du (tagged) Vlan (unwahrscheinlich als avm nutzer) und Windows PCs?

Auf meinem betagten avm-Gerät hört der multid dort aber nicht. Das Gerät ist aber auch nicht im "normale" Routing-Modus. Und IPv6 gibt hier nur als ULA

netstat -anp |grep -E "multi|dnsm"
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1218/dnsmasq
tcp        0      0 :::53                   :::*                    LISTEN      1218/dnsmasq
tcp        0      0 :::50053                :::*                    LISTEN      1301/multid
udp        0      0 0.0.0.0:53              0.0.0.0:*                           1218/dnsmasq
udp        0      0 0.0.0.0:50067           0.0.0.0:*                           1301/multid
udp        0      0 :::51939                :::*                                1301/multid
udp        0      0 :::59364                :::*                                1301/multid
udp        0      0 :::34032                :::*                                1301/multid
udp        0      0 :::42257                :::*                                1301/multid
udp        0      0 :::43028                :::*                                1301/multid
udp        0      0 :::43029                :::*                                1301/multid
udp        0      0 :::59440                :::*                                1301/multid
udp        0      0 :::53                   :::*                                1218/dnsmasq
udp        0      0 :::55353                :::*                                1301/multid
udp        0      0 :::55353                :::*                                1301/multid
udp        0      0 :::55355                :::*                                1301/multid
udp        0      0 :::55355                :::*                                1301/multid
udp        0      0 :::48199                :::*                                1301/multid
udp        0      0 :::51303                :::*                                1301/multid
udp        0      0 :::50034                :::*                                1301/multid
udp        0      0 :::42612                :::*                                1301/multid
udp        0      0 :::42621                :::*                                1301/multid
udp        0      0 :::50053                :::*                                1301/multid
udp        0      0 :::40596                :::*                                1301/multid
udp        0      0 :::56982                :::*                                1301/multid
udp        0      0 :::38059                :::*                                1301/multid
udp        0      0 :::60357                :::*                                1301/multid
udp        0      0 :::54469                :::*                                1301/multid
unix  2      [ ]         DGRAM                      5655 1301/multid         /var/tmp/me_neighbour.ctl
unix  2      [ ]         DGRAM                      6262 1301/multid         /var/tmp/me_multid-pcp-1301.ctl
unix  2      [ ]         DGRAM                      6614 1301/multid         /var/tmp/me_lldp_avmipc.ctl
unix  2      [ ACC ]     STREAM     LISTENING       6887 1301/multid         /var/tmp/avmnexus_NetworkDevices.ctl
unix  2      [ ]         DGRAM                      5618 1301/multid         /var/tmp/me_multid.ctl
unix  3      [ ]         STREAM     CONNECTED       6886 1301/multid
unix  2      [ ]         DGRAM                      5476 1218/dnsmasq

[asmcc]

Ich habe es mittlerweile anders gelöst, cuma. Und zwar, ich bespeise in jetzt die Fritz!Box von OPNsense über GastLAN (LAN4) quasi rückwärts (auf Deutsch gesagt in den Arsch reingeschoben) und habe in der Fritz!Box alles im GastLAN deaktiviert, was es nur geht (DNS/DHCP/RA). Nur der dnsmasq läuft da auf IPV4, damit er per DHCP-Option quasi die IP von OPNsense als "Router", "DNS" usw. da verteilt. Die GastIP habe ich in ar7.cfg als 192.168.189.31 eingestellt und der OPNsense hat dann 192.168.189.1. Das blöde am GastLAN in der Fritz!Box ist es, dass du es im Unterschied zum normalen LAN da über ar7.cfg oder sonstige Einstellungen nicht sagen kannst: Die Box ist nicht der Router/DNS/DHCP und da separat eine IP für den Router/DNS/DHCP einstellen, wie es beim HauptLAN möglich ist. Aber sei es rum. Ich habe es erst gestern so mit OPNsense umgesetzt. Muss erst testen und da genau mir die dumps/traffic anschauen, ob das alles da wirklich so geroutet wird und funktioniert, wie ich es will. Grob gesagt: Ich nutze AVM in diesem Fall nur für Telefonie, WLAN mit vielen Repatern, die dann per Mesh mit der Hauptbox verbunden sind und zusätzlich noch GastWLAN aufspannen, DECT-Repeater mit 2x Fritz!Fonen. Das wars dann. Netzwerk (LAN) läuft vollständig über OPNsense also an dieser Fritz!Box vorbei, sozusagen. Ja, ist seltsam, zugegebener massen und wahrscheinlich wäre die bessere Lösung, endlich diesen kompletten AVM-Quatsch weg zu werfen. Ich bin aber ein Gewohnheitstier.
Zurück zu RA. Ich bin da leider auch kein IPV6-Experte, cuma. Daher kann sein, dass ich mich da irre. Mit dem RA hatte ich es aber so verstanden, dass der Client die Anfrage anstoßt und dann die verfügbaren Server es als Antwort verteilen. Es mag aber sein, dass du Recht hast. So oder so, hat aber der dnsmasq seine Daten per RA nicht verteilt, der multid aber dagegen schon. Und ja, das ist kein richtiger Port, weil ja RAW und weder TCP noch UDP. Darum weiß ich nicht, wofür da 58 überhaupt steht. Aber ich google danach. Hast du Recht.
Meine Aussage oder Frage ging aber in die Richtung: Wird denn im multid-Wrapper dieses RAW/58 bzw icmp-ipv6 überhaupt irgendwie "verarzt"? (übrigens, genau so heißt es im OPNsense-Universum "icmp-ipv6" und dort wird es dringends empfohlen genau das in allen Firewalls freizugeben, damit IPV6 überhaupt möglich ist!) Meines Erachtens wird nämlich im multid-Wrapper derzeit nichts dagegen getan. Nur übliche Verdächtigten: Port 53 für DNS und 546/547 für DHCP, aber keine Umleitung/Umlenkung für dieses "icmp-ipv6" RAW/58. Ob die denn notwendig ist, weiß ich nicht.
Und jetzt kommen wir zu DHCPv6 versus RA. In den meisten Anleitungen wird empfohlen, BEIDES auf dem Server einzurichten, weil es heutzutage wohl noch vereinzelt Geräte geben sollte (Android, Apple, M$ usw.), die wohl entweder das eine oder das andere beherrschen aber nicht beides. Beim DHCPv6 hast du Recht: Das läuft über UDP 546/547, RA aber nicht. Und DHCPv6 ist eigentlich keine native Lösung für IPV6. Eher Fallback oder nenne es, wie du es willst. Primär ist unter IPV6 eigentlich RA angesagt. Daher hatte ich ja hier den Schwerpunkt auf RA gelegt.
Nun zu tagged/untagged. Ja, nutze ich natürlich hinter der OPNsense mit entsprechenden Switches. Ich wusste aber nicht, dass die Fritz!Box auch tagged und vlans unterstützt. Daher sind die Strippen, die vom Switch zu Fritz!Box gehen dann an der Stelle untagged und dem jeweiligen vlan (wenn es denn welche an der Stelle gibts) bereits im Switch zugeordnet. So mache ich es z.B. mit dem GastLan auf LAN4, wie oben erklärt. Aber die Fritz!Box sieht keine vlans dann.
Bzgl. deines netstats und dass weder dnsmasq noch multid auf diesem RAW/58 bei dir lauschen: Wenn du es im AVM-WebIF so eingestellt hast, dass da z.B. "keine DHCP-Server im Netz" oder "RA deaktiviert" ist, kannst du schon den multid auf diesem RAW/58 zum Schweigen bringen. Hatte ich auch geschafft. Welche Kombination von all den IPV6-Häckchen da im AVM-WebIF genau ist, kann ich es jetzt nicht sagen. Muss es nachstellen. Aber ja, es ist möglich. Beim dnsmasq ist es vermutlich auch möglich, wenn in deinen dnsmasq-Pareametern da nirgendswo was mit IPV6 steht. Bei mir habe ich z.B. DHCP-Bereich da als IPV6 definiert. Daher denke ich, dass dnsmasq in einem solchen Fall auf den IPV6-Interfaces lauscht. Aber ist auch nur ins Unreine gesprochen. Muss man nachstellen, wann es wirklich der Fall ist und wann nicht.
Wie gesagt, ich habe es hier in den "Diskussionen" und nicht unter "Issues" gepostet und erwarte jetzt nicht, dass es gelöst wird. Bitte nur als "Beobachtung" betrachten. Das echte Problem hat man mit RA nur beim Gast-LAN/WLAN. Beim normalen LAN/WLAN kriegst du es über AVM-WebIF "umgebogen" eingerichtet und kannst mit so einer Kombi-Lösung vermutlich leben, wo der dnsmasq dann DHCP macht und multid von AVM gleichzeitig RA tätigt. Du musst nur die beiden "synchron halten". Bei "Gast" hast du diese Möglichkeiten bei AVM leider nicht. Der dichtet sich da all ULAs, RAs usw. selbst zusammen. Kannst du nirgendswo umstellen. Und die passen nicht immer in die Wunschvorstellungen mancher Benutzer, wie ich, z.B. Kommt also sehr selten vor.

[fda77]

Ich nutze AVM Software auch nicht mehr zum routen da mir das FOS einfach zu schlecht ist. Bei mir fing es damit an dass AVM mit einem "Sicherheitsupdate" die komplette Telefonie über Hybrid lahmgelegt hat. Da hatte ich die Wahl zwischen Telefon, Sicherheit oder gleich was richtigem. Jetzt nutze ich Asterisk seit langem! Die AVM Hardware die ich noch nutze hat Openwrt und damit Vlan, multi SSID, iptables usw. Laut AVM wird sowas nicht gebraucht, ich bin aber der Überzeugung dass AVM sich mit dem ganzen Gemurkse dieser Linux-Imitat-Daemons wie multid, rextd, dsld, ctlmgr usw sich einfach in einer Sackgasse befindet. Um den allen Vlan zu ermöglichen müsste sehr viel Aufwand erforderlich sein.
Daher nutze ich nun private einen Router der nur 30% von AVM Hardware gekostet hat und viel mehr kann. Mit Fos nutze ich nur noch das Modem und Smarthome. Sogar das Dect Telefon ist mittlerweile im Müll.
So brauche ich mir wegen "Sicherheitsupdates" keine Sorgen mehr zu machen ^^ Für die gammelige Telekomleitung hier reicht als Router sogar ein alter Raspberry (Wlan machen andere Geräte dort wo es gebraucht wird)
Daher hab ich IPv6 für alles mit Fos (auch Testgeräte) abgeschaltet. AVM hat da eh eigenwillige Implementierungen oder mal ne Zeit lang fehlende Funktionen. Das Dual-Stack stellen andere Geräte (besser) bereit.
Und wie gesagt bin ich zu ULA only übergegen, mit denen ich Nat6 nutze. Bekanntlich kann die Telekom ja kein gutes Internet (bis zu 100 mbit - real unter 50!) und ist dazu noch überteuert für den 0 Service. Und statt diese Scheisse mal zu reparieren wird täglich ständig das rein-raus-Spiel gemacht und mit "normalem" ipv6 bekommenn dann alle Geräte viele (bis zum Timeout) IPv6s von denen bis auf 1 alle ungültig und unbenutzbar sind.
Die Provider sollten statische IPv6 Präfixe (auf Wunsch) anbieten, aber das wäre wohl zu einfach!
DHCPv6 nutze ich für statische ipv6 und slaac für die die dhcpv6 nicht können, also alles mit Android wie Handy, Tablet, Firetv usw
Der libmultid verbiegt LISTEN Ports, und ein RA empfängt nicht sondern sendet, das ganz hilft also nicht. Der source dazu ist direkt in Freetz in src/ drin, einfach durchlesen. Das icmpv6 müsste hier egal sein.
Tagged Vlan darf man mit Windows nicht verwenden da dann RA aus ALLEN Vlans ausgewertet werden (ausser mit speziellen Server-Treibern der Netzwerkkarte). Ich hab lange gesucht um das problem zu finden
Issues gibt es hier eh nicht, da dann oft die Erwartung besteht dass es jemanden gäbe der einem die Probleme löst - diesen gibt es hier nicht

[asmcc]

ok, danke! Ich sehe schon, wir laufen in eine ähnliche Richtung. Bloß bei mir wird es noch ein wenig dauern, bis ich AVM-Krempel wirklich komplett weg werfe. Und so betreibe ich es ähnlich wie bei dir "hybrid", wobei bei mir der Anteil der AVM-Geräte noch recht hoch ist. In meinem spezielen Fall mit einem recht großen Netzwerk zuhause und vielen Geräten hatte ich mir irgendwann mal zu tiefsten Corona-Zeiten so ein X86-basiertes Gerätchen, was speziell für OPNsense "getunt" und emfohlen ist zugelegt. Allerdings erst jetzt (zwei Jahre später) dazu gekommen, es umzusetzen. Hauptmotivation war bei vielen Geräten mit unterschiedlichen Netzen zu arbeiten. So habe ich neben LAN noch OUTDOOR, AUTOMATION und KNX Netze. Jetzt noch zwei GastLANs, die ich noch da zusätzlich eingerichtet hatte. Die Kiste mit OPNsense hat physikalisch 4 Ports, was schon an sich nicht schlecht ist. Rest geht über tagged vlans dann. Ich hatte seinerzeit mir mehrere managed DLINK-24-Kanal Switches zugelegt. Ja jeder Profi lacht mich aus, die waren aber damals noch günstig und gibt es jetzt quasi zum Nulltarif in der Bucht, weil die Wenigsten sich damit rumärgern wollen. Deren Software (WebIF) ist so buggy, dass du da zum Teil 2-3 Stunden damit verbringst, um nur ein 24-channel Switch komplett einzurichten. Aber das machst du nicht täglich und wenn es eingerichtet ist, dann läuft es zunächst. Die viele Netze sind wirklich sinnvoll, weil z.B. die China-Devices (WebCAMs, Türklingel, etc.) gerne "nach Hause telefonieren", was du denen somit sauber abgewöhnen kannst. KNX-Geräte kommunizieren gerne über irgendwelche Broadcasts. Als ich es im HauptLAN hatte, waren alle Switches dadurch nur am Blinken. Jetzt ist es deutlich ruhiger. Außerdem das, was man im KNX oder AUTOMATION Netzwen hat, ist oft kaum per HTTPS und Co abgesichert und läuft zum Teil noch wie in den 80-er Jahren im Klartext. Daher ist es sinnvoll diese Netze zu separieren.
Aber das alles ist nicht ohne. Sitze hier schon seit mehreren Wochen dran, um es von ONE-NET-Konzept auf diese getrennten Netze umzustellen. Macht auch nicht jeder. Man muss es schon wollen.
Bzgl. deiner Erfahrung mit Windows und "tagged" vlan hatte ich neulich auch gehabt. Hatte mir hier komplette Strippe mit einem untagged Haupt-LAN und einem tagged AUTOMATION zu Testzwecken bis zum PC hingelegt. Daneben lag ein Raspberry, an dem man es natürlich sauber separieren konnte. Am Windows-Rechner, der dann am gleichen unmanaged switch hing, kamen dann alle IPV6 zum Erscheinen. Ja, so ist das Default-Verhalten von M$. Vermutlich sogar für einen 0815-Bloduser so gewollt. Ich hatte es aber am Ende doch hinbekommen, ihm das abzugewöhnen. Frag mich aber nicht wo. Vermutlich irgendwo in den Treiber-Einstellungen, wie du schon sagst. Google danach. Da gibt es bestimmt eine Lösung. Er kann dann natürlich nicht tagged, filtert den aber zumindest aus und agiert nur als untagged, wie man es sonst erwarten würde.
Aber diese ganze Geschichte mit tagged und vlans ist leider nichts für die heutige Generation. Das ist für die zu kompliziert alles. Daher kriegst du die managed Geräte auch günstig in der Bucht angeboten, weil sich keine Sau Mühe gibt, sich damit zu beschäftigen.

[fda77]

Also bei mir fing das ganze damit an dass ich beim unfähigsten Internetprovider in Deutschland gelandet bin, der Telekom. Es heisst ja immer wenn man dort wäre würde man besseren Support bekommen wenn die Leitungen mal wieder nicht funktionieren - einen Scheissdreck bekommt man da!
Sondern: Die Leitungen sind die letze Kacke, der Support unfähig und labert einem nur das Ohr voll ("Spezialteam"-Bullshit etc) und das ganze zu heillos überzogenen Preisen! (Dann lieber zu Vodafon und nur 30% für den selben Mist bezahlen...)
Da hier weder das LTE noch das DSL von "Hybrid" richtig geht hatte ich ständig neue Adressen, was extrem nervig ist
Davon abgesehen kann Hybrid auch keine Prefix-Delegation (Neuland) oder eingehendes IPv6-Ports (auch Neuland), geplant ist das sowieso nicht

Diese Rotze bekommt man hier wenn man DSL-bis-zu-100 bei der Telekom bestellt und bezahlt:

Und ja, ich hatte schon über Jahre 1000e Störungen gemeldet, scheinbar ist die Telekom aber schlicht unfähige! Wie man sieht ist aktuell sogar die Leitungskapazität unter DSL 50 Niveau gesunken! Vor der aktuellen 64/27 Assia-Drossel hatte ich lange eine 80/32 Drossel :)
Hätte ich die ganzen Besuche der Telekom "(Spezial-)Techniker" hier nicht gehabt wäre die Verbindung genau so müllig, ich hätte aber viel verschwendete Zeit gespart.

Aber egal wie grottig die Leitung ist, abkassieren scheint das einzige zu sein auf das man sich bei der Telekom verlasen kann.
Auf das Minderungsrecht wie es seit der Novelle von 2021 des Telekommunikationsgesetzes existiert wird gepflegt und konsequent geschissen

Daher lieber zu Vodafon und nur 30% für die selbe Mistleitung bezahlen
In diesem Sinne wünsche ich jedem den ich nicht leiden kann einen Internetanschluss der Deutschen Telekom :)

So bin ich dann zu Nat6 gekommen

[fda77]

Es gibt viele Wege sowas zu lösen... Die Battery gleich ans normal Netz würde den Aufwand bei allen anderen Geräten ersparen. Nur lohnt sich das aktuell noch nicht so richtig. Daher warte ich noch etwas, die nächsten Jahre sollte es da ein paar Neuerungen geben

[fda77]

24 Port gibts bei dem auch, immer noch unter für 100. Aber so viele Ports brauch ich nicht (mehr) :)

[fda77]

Und um Geld ohne viel Aufwand zu sparen empfehle ich nach wie vor die Telekom zu vermeiden und lieber zu Vodafone zu gehen

dazu haben 50-Vodafone-Mbit einen 63-Mbit sync - statt grottige 58-Mbit Sync bei 100-Telekom-Mbit

[asmcc]

Bzgl. Aufwand ersparen und Batterie ans 230V-Netz bringen: Ja, schon, es ist einfacher für den normalen Nutzer. Wirkungsgradtechnisch ist es aber eine Katastrophe. Genau so, wie allgemein Batterien zur Speicherung zu verwenden, wenn man eben diesen schlechten Wirkungsgrad hat und immer die volle Wandlungskette durchfährt. Ich erspahre mir aber wenigstens den Weg der Rückspeisung über das 230V-Netz, bzw. gestallte ihn effizienter. Zugegebenrmaßen ist es aber nicht die Lösung für jedermann. Ist vergleichbar mit den VLANs oder deinen OpenWRT-Routern. Man muss sie ja auch nicht haben und so ein 0815-User kommt mit dem AVM-Krempel auch klar.
Zu den 24-channel-Switches: Ja, die DLINKs lagen damals so um 2014 auch so um 100EUR herum. Ich hatte mir aber neulich einen gebrauchten für 1EUR plus 5EUR Versand ersteigert. Man muss natürlich Glück haben. Sonst gehen die gebrauchten 24Channel-DLINKs für so um 20EUR herum. Weil eben sehr viele möchte-gern-Admins sie für semiprofessionelle Lösungen anschaffen (z.B. so ein Freund eines Arztes einer Arztpraxis oder einer für sich privat, ohne zu wissen, was "managed" wirklich heißt). Danach kommt so eine Profi-Firma (die sich so stolz nennt, außer stolz aber nichts mehr vorweisen kann) und schmeißt diese "unprofessionellen" Switches raus, um eben diesem Arzt was gaanz tolles für >300EUR anzudrehen. Die ausgemusterten Switches landen dann in der Bucht. Ist genau die Vorgeschichte meines 1EUR-Switches. Man muss sie nur dort zum passenden Zeitpunkt am passenden Ort erwischen.

[fda77]

An den AVM "Gästen" fehlen aber ein paar wichtig Funktionen, wie Portfreigabe und/oder Zugriff vom normalen ins Gäste Netzwerk. Das eine für IOT Geräte die man gerne erreichen würde, aber mit AVM ins normale LAN hängen muss, und das lokale Routing zum zb Dateiaustausch oder "Server"-Zugriff. Aber die AVM Zielgruppe sind wohl Otto-User die das nicht vermissen.

Trotz Umwandlungsverlusten würde ich mir so ein Nieder/Mittelspannungs Gebastel nicht zutrauen. :) Ich warte auf gutes P/L-Verhältnis der Batterien
Mit Arztpraxen kann man alles machen, siehe Zertifikate der Connectoren