Dumme WLAN-APs am Offloader - wie am cleversten?

Community Dresden
1

Moin zusammen,

ich habe in meinem Netz seit mehrere Aruba-RAP155 laufen, die mein internes Netz sehr zuverlässig gemacht haben. Dann hat vor ein paar Tagen ein Nachbar gefragt, ob er mein WLAN für nen 10er mitbenutzen kann - und meine Antwort war ein „weißte was, ich wollte schon lange mal Freifunk aufstellen, spende das was wenn du Geld ausgeben magst an Freifunk Dresden, und ich spann mal Netz auf.“

24h später sind dann Knoten 1713 und 1715 im Netz gelandet, und machen ordentlich Traffic. Aber ich bin aus betreibersicht nicht ganz zufrieden. Meine eigentliche Idee war, Indoor über meine Aruba-APs eine SSID aufzuspannen und über den Offloader(1713) ans Freifunk-Netz anzubinden. Dann kam die Überlegung, dass ich eigentlich auch gerne meshable wäre, was ja mit der Lösung nicht geht. Also den guten alten TPLink TL-WDR4300 v1(1715) neu geflasht und festgestellt dass der Traffic darüber doch ganzschön Last auf der alten Hardware verursacht. Darauf hin ist dann 1713 zum Offloader geworden, und 1713<->1715 machen jetzt mesh-on-LAN.

Damit ist jetzt mein Nachbar erstmal relativ zufrieden und 1715 meshable, aber ich bin mir sicher, dass noch mehr rauszuholen geht.

Damit mal ein paar konkrete Fragen:

  1. Kann ich am Offloader mit drei Interfaces arbeiten, damit WAN, Mesh und Clients sauber getrennt bleiben? Wenn ja, bekomme ich das sauber (auto-update-tauglich) mit der offiziellen QEMU-Firmware hin?
  2. Ist das Bereitstellen über meine Aruba-APs im Indoor-Bereich ohne Mesh tolerabel?
  3. Gibt es einen Weg, dass 1715 100% des Traffics an 1715 weitergibt, ohne dass 1715 die WAN-Leitung gezogen bekommt? Als Redundanz wäre mir das wesentlich lieber. Momentan ist das eher ein 60 Teile an Offloader und 40 Teile direkt per WAN raus.

Wenn das so klappt, kann 1715 im Outdoor-Bereich landen, und vllt den Dr-Külz-Ring ausleuchten (aber das wird dann ein separater Thread).

Als Grundsatz sollte ich vielleicht noch dazu sagen, dass ich ungern Mesh-on-WAN machen möchte, ich neide dazu lieber mehr zu trennen, als das zu vermischen. Ansonsten ist in meinem Netz alles direkt an HPE Switches, und ich hab noch einige VLANs frei, bis die Hardware die Mücke macht, also keine Beschränkungen in Sachen VLANs oder Ports.

Achja, um dem vorzugreifen: mich interessieren nur Lösungen, die im Freifunk Dresden Netz funktionieren und nicht unbedingt den Selbstbau des Images benötigen.

Viele Grüße,
klaernie

2

Hallo klaernie,

schön das du dabei bist. Du hast ja ein tollen Standort, an dem mal viel bauen könnte. :grinning:

Zu deinen Fragen.

  1. In der aktuellen Testfirmware (7.1.>3), soviel sei schon mal verraten, wird Meshonlan VLAN unterstützen, so das man sich den einen oder anderen Port sparen kann. Inwieweit das auf QEMU zutrifft kann ich nichts sagen.* Unter den Router läuft es schon ganz gut. Wenn die dann in die Freiheit entlassen wird, ist es auch updatefest.

  2. Das ist so ein bisschen eine Gewissenfrage. Schön ist es nicht, aber verhindern können wir es auch nicht. Das es gemacht wird, sieht man unteranderem an der Diskrepanz zwischen Exit VPN Traffic und Wireless AP Traffic, ganz unten hier: https://grafana.freifunk-dresden.de/

  3. Verstehe die Frage nicht, kommt mir zuviel 1715 vor.

*)Würde dich gern zur wöchentlichen Sprechstunde einladen, da kann man von Angesicht zu Angesicht Fragen, wenn auch die Tage nur virtuell, häufig schneller klären: Freifunk-Sprechstunde – Freifunk Dresden - Anwender-Wiki

VG

3

Moin Emploi,

ja, wenn ich was mache, versuche ich es richtig zu machen :wink: Also wird sehr bald auf dem Balkon noch was landen. Meine grobe Idee ist, den Platz und den Spielplatz auszuleuchten, aber ich hab nur die Südwand - also direkt nach Westen wird nichts. Sonst noch Ideen für den Standort?

  1. Gibt es die 7.1.* schon als QEMU-Kompilat (CI-Artifakt oder so), oder sollte ich mich doch mal daran versuchen, es aus git heraus zu bauen? Was wird denn tendenziell bei Auto-Updates zerstört? Meine Erfahrungen unter OpenWRT gingen in die Richtung, dass die Updates den Großteil der uci-config beibehalten, wenn ich also da das ein drittes Interface in die richtige Bridge werfe, sollte das reichen, oder?

  2. Mein Ansatz wäre halt, Indoor mit den Arubas rock-solid zu laufen, und dafür die existierende Hardware meshable außerhalb zu befestigen, denn wenn jemand mesh hier im Haus machen möchte, lege ich liebend gern ein Kabel für Mesh-on-LAN. Die Alternative wäre ja, dass ich hier

  3. Whoopsie, das kommt von bis 23:00 an einer Frage bauen…
    Die Frage sollte lauten:

    Gibt es einen Weg, dass 1715 100% des Traffics an 1713den Offloader weitergibt, ohne dass 1715 die WAN-Leitung gezogen bekommt? Als Redundanz wäre mir das wesentlich lieber. Momentan ist das eher ein 60 Teile an Offloader und 40 Teile direkt per WAN raus.

    Was ich bereits schon gemacht hatte (wohl auch gestern vergessen zu erwähnen), ist 1713 als bevorzugtes Gateway für 1715 einzustellen.

Sprechstunde steht schon seit ein paar Tagen im Kalender, aber meine Erfahrung ist, dass ich komplexe Gedanken in Text meist besser formen kann.

Grüße,
klaernie

1 „Gefällt mir“
4

Hi,

ich habe deinen Aufbau noch nicht ganz überblickt, was du alles wie verbinden möchtest.
Aber um dir paar ergänzende Infos zur firmware zugeben:

aktuell wird einen neue firmware getestet, die auf openwrt 21 basiert.

Hier kommt eine gravierende Änderung rein. Da openwrt die Netzwerkkonfiguration und Switchkonfiguration (DSA) überarbeitet hat und auch die Art der konfiguration, wird es extrem
kompliziert. Viele Router nutzen noch „alte“ konfiguration, andere schon die „neue“ Art und Weise.
Die einzige Möglichkeit hier für ist, die Netzwerkconfiguration (/etc/config/network) bei Konfigurationsänderungen via GUI in der Freifunk Firmware Dresden, komplett neu zu generieren.
Das bedeutet, dass manuelle Anpassungen verloren gehen, sobald in der GUI Einstellungen vorgenommen werden (auch bei netzwerkfremden).

Du sprichst davon, ein 3 Netzwerkinterface hinzuzufügen. ich verstehe hier noch nicht die Aufgabe,
da du via WAN, LAN und (neu) VLAN eigentlich alle meisten Netzwerksetups abbilden kannst.
Wenn du eigene Interfaces in der Firmware hinzufügst und diese in irgend eine bridge gibtst,
so ist fliegen diese wieder raus. Wird das interface direkt hinzugefügt, so muss das in firewall,routing rules/tabellen und auch im routing protokoll beachtet werden.
Das wäre ein tiefer Eingriff in die Firmware, wo unser support aufhört.

Wenn du dein Netz also trennen willst, so musst du das ausserhalb des Routers/Offloaders durch switche/routerGeräte machen.
Die Freifunk-Firmware basiert zwar auf Openwrt, aber jede Funktion ist mit Firewall, Netzwerk, routing
genau abgestimmt, damit weder das Netz noch die Sicherheit des eigenen Netzes gestört wird.

Ich kann dir hier nur empfehlen, nicht in der Firmware Änderungen vorzunehmen, das es extrem komplex ist, alle Abhängikeiten zu überblicken.
Ebenso können wir nur vom aktuellen Stand der Firmware weiter entwicklen und können keine Rücksicht auf anpassungen nehmen, die wir nicht selber vorgenommen haben.

Die neue firmware enthält erhebliche Änderungen und auch verbesserungen, und wird daher aktuell nur intern getestet. Wenn die firmware und auch die Interaktioon mit den Servern soweit funktioniert, wird diese ins nightly gegeben. wenn dann diese durch unsere Freifunker soweit das ok bekommt, gibt es eine offizielle Test version, die jeder nutzen kann. Die sollte dann kaum noch fehler haben.
Und wenn die dann ok ist, wird sie offizell :slight_smile:

Wie Mirko schon sagt, komme einfach zur sprechstunde (online) und was auch hilft, wäre ein
Bildchen, mit deiner Wunsch-Verkablung. Dann können wir dir sicherlich einfacher helfen und
eine lösung für dein Setup-wunsch finden, der nicht die Änderung der fireware beinhaltet.
VG Stephan

5

Servus ddmesh,

danke erstmal für die Erklärungen was alles kaputt gehen kann und wie komplex es wird. Auf der Oberfläche sah es (wie bei vielem anderen) relativ einfach aus.

Meine Plan war, dass die Offloader-VM bei mir im Netz keine direkte WLAN-Hardware hat, ich aber via ein Interface gerne meine Indoor-APs benutzen würde, um WLAN-Zugang ins Freifunk-Netz bereitzustellen. Diese APs stehen alle so, dass außerhalb der Wohnung möglichst wenig ankommt - 2.4Ghz ist hier arg dicht - und auch wenig Störungen zurück kommen.

Dann braucht der Offloader natürlich ein WAN und Mesh für meinen Freifunk-AP. Damit komme ich dann auf drei Interfaces.

Nach meiner Erfahrung ist es jetzt so, wenn ich einen Hardware-AP wie den TL-WDR4300 nehme, habe ich mit dem integrierten Switch die Möglichkeit aus dem einen CPU-LAN-Port für jeden dieser drei Zwecke VLANs zu machen, die der interne Switch dann auf separate Ports führt. In einer VM habe ich aber keinen integrierten Switch, aber dafür die Möglichkeit beliebig viele Netzwerkkarten hinzuzufügen. Aber wenn ich dich richtig verstehe, ist die Einrichtung im Next-Gen-Image nicht via GUI machbar, und wird damit früher oder später kaputt gehen.

Die Wunschverkablung wäre:

  • Offloader und Hardware-AP haben eine direkte Verbindung zum WAN
  • Offloader und Hardware-AP haben eine verkabelte Mesh-Verbindung, die nicht über WAN geht
  • Offloader hat eine Verbindung, die das Client-Netz an die „dummen“ Aruba-APs durchreicht

Was darin nicht erwähnt ist, ist die Möglichkeit außerhalb via WLAN zu meshen, was ich die Freifunk-AP(s, seien wir ernsthaft, das bleibt nicht bei einem) machen lassen möchte. Damit kann ich Outdoor-APs mit Mesh auf die Außenseiten der Fenster hängen, und innerhalb der Wohnung mit meinem Aruba-Cluster Freifunk anbieten.

Ich weiß jetzt nicht, wieviel Sinn es macht, das noch in Bildern zu verdeutlichen, mein Netzwerk ist auf der etwas exzessiven Seite, und ich wöllte ungern zuviel der physischen Komplexität in ein Diagram einbauen müssen. Kurz gesagt, mein pre-Freifunk-Netz allein besteht aus drei Switches (zwei HP 48port, ein 24port), vier VLANs (Kabel-WAN, VDSL-WAN, trusted-Netz, semi-trusted-Netz) und über 100 IPs. Router ist eine pfsense-VM, die dank Proxmox sich frei zwischen meinen Maschinen bewegen kann und das MultiWAN managed, und momentan hängen Offloader und Freifunk-AP direkt am VDSL-WAN, aber können deswegen auch nicht vom Gigabit-Kabel profitieren.

Grüße,
Andre

6

HI, ich denke ich verstehe dein Setup-Wunsch.
die Firmware (router oder offloader - x86-64) sind identisch und können normal so konfiguriert werden,
dass alles was an geräten am LAN durch das freifunk gehen.
Das würde ein Setup mit den arubar-aps erfüllen.
der Wan anschluss der VM würde dann an deinen internet router gehen, der halt das wan bereit stellt.
Mit der aktuellen Firmware (die freigegeben ist, oder auch im nightly verfübar wäre), ist sonst nichts weiter möglich. Dir fehlt da das mesh-on-lan zu deinem freifunk AP.
Mit der aktuell noch in testung befindlichen firmware, kommt jedoch VLAN dazu. dieses ist
per default auf VLAN id 9 gelegt und wird (wenn aktiviert) über LAN und WAN interfaces zusätzlich ausgeben.
der freifunk router muss dann ebenfalls diese neue firmware haben und vlan aktiviert haben.
Dann kann dieser FF router mit seinem WAN an dein internet geschlossen werden und sein lan
an den lan vom offloader (wo auch deine arubar AP hängen).
das vlan ist dann für das meshen zwischen offloader und FF AP verfügbar.

Was du dann nur noch beachten musst, ist dass das VLAN auch auf WAN rauskommt, und in deinen switchen es nicht zu irgend welchen loops kommt. Evt lässt sich zukünftig noch was einbauen, dass das vlan gezielt auf wan, lan oder beides einzeln aktiviert wird. ist aber noch nicht in planung, da wir erstmal die aktuellen massiven inernen änderungen testen müssen und bisher noch keiner vlan nutzt.
Für die einfache nutzung ist daher VLAN auf WAN und LAN gleichzeitig aktiv.

Wenn du dann mit dieser neuen Software dein setup aufgebaut hast (was dann möglich ist), muss du
nur beachten, dass du für deinen offloader und AP (mit WAN) unterschiedlichen Backboneverbindungen nutzen musst. Beispiel: der offloader hat backbone zu vpn12 und der AP nutzt als bevorzugtes GW vpn12, darf aber selber keine direkte verbindung zu vpn12 haben. Da der AP sonst seinen traffik direkt raus gibt und nicht über den offloader (der ja die last tragen soll).
der AP würde nur als „backup“ dienen, falls offloader ausfällt. dann würde zwar weiterhin vpn12 als GW genutzt, aber die verbindung würde erst über einen anderen server zu vpn12 gelangen (anzahl der hops zum GW wird durch routing protokoll bmxd mit beachtet).

Ich kann dir leider aber die neue software noch nicht geben, da wir erst die anpassungen auf serverseite gut testen müssen. anpassungen wurden in firmware und auf serverseite gemacht, und server muss weiterhin kompatibel zur alten firmware sein.
Falls du noch nicht in der freifunk-signal gruppe bist, kannst du gerne dazu stossen, um näher an infos zu sein, oder keybase. auf den anderen kanälen bin ich eher weniger unterwegs.

Eine andere frage: die aruba APs können die nicht auch freifunk knoten werden? falls es da ne firmware gibt. ich kenn das gerät nicht. aber wenn es openwrt dafür gäbe, könne es auch für freifunk möglich sein. kommt auch auf flash und ram an.
Ich frage deswegen, weil bei so vielen routern, evt die airtime vom 2,4ghz einfach nur zu ist und dann kaum noch durchsatz ist.

Andre idee. wenn du feifunk router hast, die gleichzeitig 5ghz indoor haben, so können die auch über 5ghz meshen. zum offloader hätten die aber aktuell trotzdem keine verbindung :wink:

Bye
Stephan

7

Hallo Andre,

zu erst mal herzlich willkommen bei Freifunk Dresden, und ich freue mich über Zuwachs in der Community Oberlausitz. (Was verwechselt, man sollte Nachts nicht mehr schreiben…)

Zu deinem Aufbau:
Wenn es leistungstechnisch kein Problem ist, dann kannst du es mit der aktuellen Firmware auch mit 2 VM’s machen. Ich skizziere das hier einfach mal.

Internet <-> [WAN] VM_1 [Mesh-LAN] <-> [Mesh-WAN] VM_2 [LAN] <-> APs
                                    |
                                    v
                              [Mesh-WAN/LAN]
                              Freifunk Router

Aus meiner Sicht ist es konfigurations-technisch die einfachste Lösung mit der aktuellen Firmware, mit der neuen Firmware ist es dann natürlich einfacher, vor allem wäre die Lösung Update fest.

Viele Grüße
Niklas

1 „Gefällt mir“
8

so schön einfach! ist interessant, wie sehr man in einer Denkrille hängen bleibt. ich muss total lachen. gefällt mir sehr!

9

Jap, @hibo98 hat den Vogel abgeschossen, so ist definitiv genial. Nicht nur update-sicher und sauber, sondern auch unkompliziert.

Und wenn ich das noch etwas erweitere, gibt es sogar redundante Anbindung vom Mesh ans Internet:

          +-> [WAN] VM_1 [Mesh-LAN] <+> [Mesh-WAN] VM_2 [LAN] <-> APs
          |                          |
Internet <+                          v
          |                      [Mesh-LAN]
          +-----------> [WAN] Freifunk Router

Hab das jetzt mal so umgesetzt, und schon ist die VM als 1719 am Netz. Und sobald ich mir ein paar Outdoor-APs angeschafft hab, müssen dir nur in vlan200 gepatcht werden, und schon läuft alles.

All good, it’s done when it’s done. :wink:

Ich versuche ehrlich gesagt immernoch zu verstehen, was du meinst. Sollte das bevorzugte Gateway per Design ein Node der nur durch VPN erreichbar ist sein, oder ist es auch richtig, wenn ich direkt meinen Offloader als Gateway angebe? Bei ersterem Fall macht es für mich Sinn, das es keine direkte Verbindung zu dem als Gateway angegebenen Knoten geben darf, aber in zweiterem Fall wäre das ja irrelevant, oder?

Es gibt für nur wenige Aruba-APs Firmware, aber meine RAP-155 sind da nicht dabei. Aber das ist auf für mich nicht so wichtig, da ich deren Stock-Firmware tatsächlich mag. Mal abgesehen von dem Sammelsorium an Diagnostik-Daten was die rauswerfen, haben die ein Killer-Feature für mich: die APs bilden einen Cluster, und stellen eine virtuelle IP bereit, über die der Cluster verwaltet werden kann. Statt also die Konfiguration jeweils pro AP zu machen, pflege ich es nur einmal, und alle APs wenden die Änderung an. Dazu kommt noch, dass Handover zwischen den APs sauber funktionieren und keine Protokoll-Kenntnisse zur Konfiguration erfordern (daran bin ich bei OpenWRT gescheitert). Generell sind bei uns hier die Anforderungen an Verfügbarkeit und Robustheit des WLANs abnormal: geht was kaputt, hab ich binnen Sekunden zwei Stakeholder neben mir stehen, die Fragen wann das WLAN wieder geht. :fearful:

Viele Grüße,
Andre

10

Gateway:

also das mit dem gateway (gw) ist so. wenn du einen knoten (router oder server oder vm) hast, der sein eigenes Internet freigibt, dann sendet dieser knoten diese Info an alle anderen knoten. diese „anderen“ knoten können dann dein GW auswählen.
Da ich vermute, dass deine VM zwar ein Offloader ist (also die last für die backbone verbindung zu einem server trägt) aber kein gw in diesem sinne ist, macht es keinen sinn dein offloader als GW irgendwo einzutragen. die IP des offloaders wird niemals als gw bekannt gegeben.
Wenn du allerdings auf deiner VM einen eigenen vpn tunnel (wie airvpn.org, nordvpn…) hättest, kann dieser als gateway (exit) arbeiten. dann kannst du in deinen freifunk routern, dein gw eintragen. der internet traffik geht dann direkt zu deiner vm (die offloader und gw ist) und leitet dann den traffik durch deinen tunnel-anbieter (airvpn,…).

Allerdings können auch andere freifunk knoten im gesamten netz, dann deine VM als GW nutzen.

VG
Stephan

11

Okay, also Gateway ist nur „das ist der Exit-Node aus dem Freifunk-Netz heraus“, hat aber ansonsten nichts zu bedeuten.

Wie überzeuge ich denn einen Knoten, der sowohl VPN über WAN als auch Mesh hat, das Mesh dem VPN zu bevorzugen? Ist der Entzug vom WAN (bzw allen VPN Connections) die einzige Möglichkeit? Wie bekomme ich eine Redundanz hin, dass ein solcher Knoten mit Mesh und WAN das WAN benutzt, sobald das Mesh unbenutzbar wird (z.B. Wegfall des Offloader-Knoten).

Ich hab schon das Wiki bemüht, aber leider hab ich nichts gefunden, was mir das erklären würde, und auch bmx selbst zu verstehen ist wahrscheinlich an wissen-wo-es-steht gebunden.

Apropos Exit: gibt es VPN-Anbieter, die bei Netflix nicht geblockt sind? Nachbar meinte, dass Netflix ihm über Freifunk nur die Eigenproduktionen anbietet. Wenn es da was gibt, würde ich wahrscheinlich selbst ein VPN-Exit hinstellen (sofern ich rausfinde wie das geht :wink: ).

Viele Grüße,
Andre

12

Bist du noch wach und Lust kurz drüber zu quatschten im Jitsi? Kann eh nicht schlafen :wink:

13

Leider nur noch Matsch-Brain und in ein paar min im Bett. Aber Danke für das Angebot!

14

Gut dann mach ich denn pc wieder aus;)
Können uns gern morgen treffen. Habe hier auch die ein oder andere freifunk vm laufen. Und betreibe ein paar der gateways.
Dann eine gute Nacht :wink:

15

Falls die Frage noch offen ist, wie man an einer Gluon-VM WAN, Mesh und Clientnetz auf drei virtuelle Netzwerkschnittstellen bringt, hier meine Doku - ich hoffe sie stimmt noch:

  1. VM mit drei Netzwerkschnittstellen ausstatten.
  2. Mesh on LAN auf eth0 einschalten:
    uci set network.mesh_lan.disabled=0
    uci set network.mesh_lan.ifname=eth0
  3. WAN auf eth1 legen:
    uci set network.wan.ifname=eth1
  4. Client-Netzwerk auf eth2 legen:
    uci add_list network.client.ifname=eth2

Welchen Namen welche Netzwerkschnittstelle erhalten hat, kann man anhand der MAC-Adressen herausfinden.

Ich hab’s vor etwa 2 Jahren so eingerichtet, funktioniert seitdem updatesicher.

16

Servus @citronalco,

ne, die Frage ist nur für die Dresdner Firmware - also ist gluon nicht anwendbar.

Grüße,
Andre

1 „Gefällt mir“