Freifunk in Duderstadt

Hallo

möchte kurz unseren Freifunk-Knoten vorstellen : ffdud_St-Martini_Krankenhaus

über die Initiative Duderstadt2020 sind wir auf die Möglichkeit des Freifunk und den „Freifunk-Göttingen“ gekommen, um unseren Patienten und Mitarbeitern ein Internet-Zugang bereit stellen zu können …

Derzeit sind wir dabei unser WLAN-Netz in den Gebäuden auszubauen, eine SSID wird dabei auch für Freifunk bereit gestellt. Es sind 28 APs eingerichtet, wird in den nächsten Wochen bis auf ca. 60 und mehr noch erweitert.

Das Mesh-Netz wird derzeit nicht weiter gereicht, soll aber nach dem Ausbau an den Ecken der Grundstückes/ Gebäude als SSID zu Verfügung gestellt werden.

6 „Gefällt mir“

Hallo,

durch unseren WLan Ausbau derzeit 37 APs kommen wir langsam an die Grenzen unseres „Freifunk“-Router „TP-Link TL-WR1043N/ND v2“, in der Spitze bis zu 120 Freifunk-Verbindungen … welche Möglichkeit besteht mehr Durchsatz zu bekommen ?

Des-weiteren würde ich auch gerne die Mesh SSID an die vier Eckpunkte von unseren Gebäuden auf Haus eigenen APs bringen. Denn nur so macht das vernetzen zu anderen Nodes Sinn …

Das Freifunk-Netz habe ich per LAN / VLAN an unsere APs geführt und dann über die SSID „Freifunk“ veröffentlicht, mit dem Mesh sollte es ja auch ähnlich funktionieren …

Moin,

ich denke da macht ein Offloader Sinn… Einfach mal nach googeln, da findet man eigentlich viel zu. Entweder ein Fujitsu Futro s550, ein alter Rechner oder eine VM aus vorhandenem Blech.

An die 4 Ecken ecken würde ich jeweils eine Ubiquiti Nanostation hängen, die kann dann auch mit an den Offloader.
Die müssen aber zwingend die Freifunk-Firmware haben. Mesh funktioniert mit der Hersteller-eigenen Firmware nicht.

Ich würde aber auf alle Fälle mal mit den Göttingern sprechen. Bei so einer Großinstallation ist es wünschenswert, wenn sowas mit Absprache passiert. Soweit ich weiß, sind die Göttinger hier selten im Forum aktiv.

Was schafft ihr denn noch für einen Druchsatz, wenn dort so viele Clients aktiv sind? Ich denke da ist der WR1043 mit Fastd gut beschäftigt.

Viele Grüße aus Einbeck
Martin

Besten Dank erst mal für die Info …

würde dann zwei Futro s550 redundant aufbauen oder kann man die auch zugleich im gleichen LAN(VLAN) Freifunk laufen lassen … ?

Eine Frage zu den Ubiquiti Nano, werden die auch dann an das LAN(Freifunk) angeschlossen,
dann muss bei denen aber eingestellt werden, das ein Offloader vorhanden ist …

Redundant wird das im Parallelbetrieb.
Loadbalancing wirst Du jedoch fast nicht bekommen. Sprich: Der Traffic wird sich im Stundenmittel zwar gleichmäßig verteilen, aber schlicht weil er in Wellen hin- und her-schwappt…
Das Wechseln kann man per HopPenalty (in einem der beiden Router) weitestgehend unterbinden. Aber dann hast Du nur das Failover-Szenario.
Und nein, man kann Batman dahingehend nicht „tweaken“.

1 „Gefällt mir“

Du brauchst quasi ein 2. Vlan.
Aktuell verteilst du das Client-Netz an die vorhandenen APs.

In dem 2. Vlan wird dann das Mesh-Netz transportiert.
Den Nanostations sagst du dann, dass die Mesh on Lan machen sollen. Die Knoten tauchen dann mit der Friefunk-Firmware auch auf der Karte auf.

1 „Gefällt mir“

Redundant wird das im Parallelbetrieb. Loadbalancing wirst Du jedoch fast nicht bekommen.

Eine einfache Redundanz würde mir reichen, so das ich nicht am WE raus muss, nur weil die Patienten kein Internet (Freifunk) haben, weil eventuell der gebrauchte Futro s550 oder dessen Netzteil abgeraucht ist …

Hatte nur bedenken, da ja an beiden Offloadern die Freifunk-LAN Seite jeweils auf dem selben LAN/VLAN liegt.

Habe mir schon zwei gebrauchte Futro s550 mit 1GB CF und 12Monate Garantie für je 15 Euro bestellt,
auch die benötigte RISERCARD habe ich für 7 Euro gefunden.
In unserer Grabbelkiste haben wir noch einige RTL8169SC(PCI) liegen, mal sehen ob die dann auch erkannt werden …

In dem 2. Vlan wird dann das Mesh-Netz transportiert.

Mit dem Mesh muss ich dann sehen, derzeit ist auch nichts in der Nähe mit dem ich unser Freifunk-Node verbinden könnte …

Musst Du nicht.
Du solltest sie nur auf Mesh-Ebene (also dem Switch auf dem MoL liegt) zusammenlegen.

Wenn Du einen solchen noch nicht hast, dann brauchst Du einen solchen. Das kann ggf. der 1043er machen, den dann als „puren“ Batman-Switch auslegen, der an seinem WAN-Port beide Futros sieht (ja, brauchste dann noch einen kleinen weiteren Switch).
Und dann vom Lan des 1043ers weiter wie bislang.

SinglePointOfFailure wirdst Du dann auch in der Konstellation haben. Hat man immer.
Kannst halt ggf. einen 1043er (oder einen 841er, reicht auch) vor jeden AP hängen und das MoL über die strukturierte Hausverkabelung verteilen (ggf. auch in einem Vlan.)

1 „Gefällt mir“

Würde dann also, so aussehen:

müssen sich die beiden Offloader denn über das Mesh(VLAN) sehen,
damit ein Parallel-Betrieb funktioniert ?

Du kannst in der Tat nicht die beiden ff-client-netze bridgen.
Zusammenschalten darfst Du nur das Meshnetz.

Und Du brauchst dann eben einen übergang von der br-mesh auf die br-client. Das kann der 1043er machen… oder mehrere 1043/841er für Kleingruppen von APs, wenn du die Redundanz erhöhen willst.

1 „Gefällt mir“

Also so in der Richtung …

a) der 1043 hängt nur mir einem Kabel an ff-mesh, und zwar am Haupt-Switch (also Deiner Switch-Infrastruktur, samt Vlan)
b) die Futros hängen an Deinem Haupt-Switch (vlan…) an ff-mesh (und nicht am 1043er)

c) alle Freifunkrouter sollten an ungetagten Switchports hängen, also der jeweilige Port das Tagging übernehmen.

1 „Gefällt mir“

Hallo adorfer

ich glaube jetzt habe ich es verstanden … nicht wundern, habe mir einen privaten Account angelegt …

die beiden Futros werden mit je einem Internet-Router über das VLAN(WAN) angebunden

im 1043er wird der VPN-Client deaktiviert und die WAN-Seite (LAN) mit dem MoL verbunden
der LAN-Port liefert dann das FF-Client-Netz_Lan(3)

FF-Client-Netz_Lan(1) und FF-Client-Netz_Lan(1) ist dann das FF-Client_Lan der beiden Futros,
könnt auch getrennt isoliert verwendetet werden, die beiden Futros sind ja über das Mesh verbunden und
somit brauch ja nur einer der beiden ein funktionierenden Internet Zugang …

Die beiden Futros haben kein ff-cl-Netz.
Brauchen sie auch nicht. Es wäre auch nicht sinnvoll, weil Du dann Clients dahinter hättest, die nicht redundant angebunden wären.

Außerdem solltest Du auch den Futros das „untagged“ geben, d.h. keine Vlan-Konfig im Gluon/Futro. Sondern „lassen“
(Wenn Du doch vlan fahren willst im Futro, dann kannst Du natürlichdie zweite Netzwerkkarte einsparen, dann kommst Du mit der Onboard aus. Ist nur eben ein zumindest geringfügiges Risiko, dass bei einem Sysupgrade da mal was schief geht. Plus Bastelarbeit, wenn man es mal neu Aufsetzen muss, weil sich erfahrungsmäß dann doch die syntax von /etc/config/network ändert spätestens bei dem was nach LEDE kommt oder so… und das 1,5 Jahre alte Configbackup nimmer passt. )

1 „Gefällt mir“

Hallo adorfer

macht Sinn, hier die angepasste Planungs-Grundlage

1 „Gefällt mir“

Sehr schöne Grafik!
Magst Du noch einen Urhebervermerk drauf setzen, dann würde ich die gern hier und da zukünftig nutzen, wenn’s Recht ist.

Hallo adorfer,

meine Zeichnungen sind CC, also kein Problem … ist jetzt auch nichts besonderes,
nur eine Zeichnung, die eine Diskussion erheblich erleichtert … Zeichnungen sagen häufig mehr aus als tausend Worte.

Ich muss mich erst mal recht herzlich bedanken, das mir so schnell und kompetent geholfen wurde :handshake:

1 „Gefällt mir“

Update …

hier noch mal ein Systematische Zeichnung

1 „Gefällt mir“

Habe da noch mal eine Frage zum FF_MoL,

bei den beiden Futro, wie muss da die LAN-Seite eingerichtet werden ?
ist das FF_MoL IP basierend, wenn ja , benötigen die ja dann ein feste IP und der 1043er kann ja dann nur mit einem Futro verbunden werden … oder läuft das FF_Mol mit einem eigenen Protokoll …

Der Switch darf nicht auf „Port-security“ (oder ähnlichen Dingen) stehen, da der Futro durchaus die MAC-Adresse wechseln kann. (Falls man es in eine VM sperrt, was ja hier nicht der Fall sein wird, dann muss dem Gluon auch Promiscous-Mode erlaubt sein.)

Ja. IP, UDP, nicht IPv4, nicht TCP.

Jein,
Die IP wird aus der Hauptmac des Nodes (Futro) abgeleitet, da der Futro -wie angesprochen- eben meist NICHT die Mac des HW-Interfaces nutzt, sondern für die LinkLocal etwas, was aus der Mainmac des Nodes abgeleitet wird.
(die Logik ist relativ komplex. Sinnvollerweise bitte einfach den Portsecurity-Kram abschalten, dann sucht sich der Futro die richtigen LinkLocal-Adressen nicht nur selbst, sondern darf sie dann auch nutzen.)

1 „Gefällt mir“