ich habe hier ziemlich viele Access Points, einerseits weil es viel auszleuchten gibt, andererseits weil ich neben meinen privaten SSIDs (Achtung Plural) eben auch Freifunk ausstrahlen möchte. Alles in einem geht ja nicht.
Die VPN Verbindung lasse ich einen Offloader herstellen. Mit mesh-on lan gehe ich dann zu weiteren Access Points.
Jetzt würde ich statt dessen lieber das Gastnetz aus dem Offloader rausbridgen und über ein separates VLAN zu meinen eigenen Access Points bringen, um sie über eine eigene SSID ausszustrahlen. Ich weiß, die Funktion mit der _offline SSID geht dann kaputt, aber bei mir ist nix Offline, außerdem ist hier auch keine Pontstraßenfrequentierung, also alles OK.
Leider funktioniert das aber nicht. Clients die sich mit meiner Freifunk SSID verbinden schicken einen DHCP request, erhalten aber nie eine Antwort. Den DHCP Request sehe ich bis zum offloader kommen aber nur bis auf das eth0 Interface. Wenn ich schon an br-client sniffe, ist das Paket dort nicht mehr zu sehen, geschweige denn auf dem VPN Interface. Wird d irgendwas gefiltert?
Welche Community ?
Tritt das konstant immer auf, oder evtl ist das bei Neustart des Knotens weg ?
Ich habe den Effekt, dass Clients zwar Adressen bekommen, aber dann irgendwann v6 nicht mehr geht - v4 schon. Wenn ich parallel das knotenlokale Wifi nehme, geht alles stabil. Ich bin jetzt selber noch nicht dazu gekommen bei Auftreten das Testsetup so zu minimieren, um lokale Probleme auszuschliessen, halte sie aber nicht für wahrscheinlich. Fragte mich aber auch, wieso das nicht schon andere gemerkt haben sollten, aber sie trauen sich evtl auch noch nicht damit aus dem Gebüsch.
Also wired client geht nicht. Wireless client lan geht. Bei Dir womöglich immer. Bei mir nur partiell.
Teste es also am besten noch mal alles direkt am Knoten - wireless und wired.
Hi, das ist Community Aachen.
Ein Client erhält bei mir weder IPv6 noch IPv4 Adresse. Habe gerade auch mal ein Endgerät per Kabel direkt mit dem Switch verbunden in dem VLAN, wo die Gäste drauf laufen.
Da ist natürlich auch der Batman-Traffic mit drin, weil eben mesh-on-lan aktiviert ist.
Welches „Gastnetz“ willst Du aus dem Offloader – der doch nur WAN & Freifunk hat – „rausbridgen“ (was ist das)?
Die Offline-SSID setzt der Knoten, wenn er vom Freifunknetz getrennt ist — es kann also auch jenseits Deiner Infra Probleme geben, die den Knoten die Freifunk-SSID abschalten ließen.
Kann man schon machen.
Das sind die Knoten (wenn es jemand schafft, cli und mesh zusammenzubridgen, egal ob via Kabel oder im Gluon), bei denen ich hoffe, dass eine E-Mailadresse hinterlegt ist. Denn die werden zur Schadensbegrenzug auf den Supernodes geblockt… notfalls eben auch die ganze lokale Wolke dort.
Gäste sind die Freifunk Nutzer. Dachte das wäre übliche Terminologie, zumindest heißt das Interface in gluon auch „br-guests“.
Ich denke es jetzt hinbekommen zu haben. Beim Einrichten des offloaders lasse ich mesh-on-lan deaktiviert, dann kann man die Gäste an eth0 anschließen und diese erhalten dann auch eine IP.
Damit ich aber weiterhin noch meshen kann, hat mein offloader ein drittes Interface eth2. Darauf muss ich dann nur das hier laufen lassen:
ip link set up dev eth2
batctl if add eth2
Edit:
Anscheinend br_client, nicht br-guests, danke @adorfer
Um es rebootfest zu machen kann man auch das hier in /etc/config/network schreiben:
config interface ‚eth2‘
option proto ‚gluon_mesh‘
option ifname ‚eth2‘
Ich denke, dass hier (in Gluon-Terminologie) „br_client“ gemeint ist.
Als das Client-Netzwerk, was man direkt auf APs (und deren „Freifunk“-SSID) bridgen könnte.
(Und nein, „Freifunk-SSID“ ist hier exemplarisch gemeint.)
Oh, hat sich das in Gluon 2020 geändert? Bis einschließlich Gluon 2018 heißt die Bridge „br-clients“.
Äh, ja, wie gesagt, der Offloader legt normalerweise das Freifunk-Netz auf „lan“, das ist das (V)LAN, in welchem die Standard-APs hängen sollten und die lokale Freifunk-SSID über eine vorhandene AP-Infrastruktur ausstrahlen. Mesh-on-*AN heißt, daß Du da batman-Frames auslieferst, damit kann aber ein Nicht-Gluon-AP nix anfangen.
Viele Konfigurationen werden bei Gluon bei einem sysupgrade überschrieben; es mag so zwar rebootfest sein, Dir – sofern es eine Gluon-VM ist – aber beim nächsten Firmwareupdate aber dennoch überschrieben werden. Just FTR.
Bei Gluon hat es sich bewährt, Netzwerkkarten (egal ob physisch oder virtuell) vor dem „firstboot“ an die Maschine zu schrauben. (Oder nach dem Hinzuklicken genau dieses aufzurufen, sofern man nicht versehentlich ext als fs gewählt hat.)
Dann erkennt auch Gluon die und man kann sie -nach meiner Erfahrung- gefahrlos als mesh, client oder meinetwegen auch als zusätzliches wan einrichten.
Das überdauert auch dann ein sysupgrade, weil sicher ist, dass der enumerator auch dann die Zählreihenfolge der eth[0-9] gleich lässt.
(Ist aber jetzt eher was für die Gluon-Ecke als für „Technik“)