Es ist soweit, es gibt die erste experimentelle Firmware Version unserer Firmware mit der Nummer 0.5. Diese basiert dabei auf dem aktuellen Gluon Master Branch. Da es dort einen Fix für den TL-WR841N v10 gibt, wird dieser mit der experimental Version 0.5 ab jetzt experimentell unterstützt. Außerdem gibt es einige Neuerungen und Verbesserungen, wer wissen will was genau passiert ist, kann sich hier den Milestone für Gluon 2015.2 angucken.
Die größte Änderung ist die neue Statusseite, die jetzt deutlich hübscher und leichter zu verstehen ist.
BTW: Der ARCHER C7 den die Darmstädter schon länger haben und sogar empfehlen ist in dem GLUON 2014.2 leider doch nicht drin ? Ist die Anpassung daran ein Eigengebräu von denen ?
Danke fürs das schnelle bereitstellen der Firmware. Hab meinen TL-WR841N v10 direkt damit geflasht und einen Knoten eingerichtet, komme aber damit noch nicht ins Internet.
Dauert es eine Weile, bis die Verbindung steht und Internet für das Freifunk-WLAN nutzbar ist?
Danke für die schnelle Antwort @leah . Ich war natürlich im Gast-Modul auf dem LAN-Port der Fritzbox und habe die Ports nicht konfiguriert. Danke.
Werde jetzt mal prüfen ob alles funktioniert.
Super, dann könnte ich mein C7 endlich sinnvoll einsetzen :-)
noch was: Die Darmstädter haben auch X86 images. Wenn ich es richtig verstehe wären das dann reine Offloader ohne eigenes WLAN? stimmt das? könnten man das bei uns auch mit bauen lassen ?
bzw. wie könnte ich sonst „einfach“ offloader bauen ?
Ja es gibt die Möglichkeit ein x86 Image zu bauen. Leider ist es damit noch immer nicht einfach aus einem Rechner mal schnell und einfach einen Offloader zu machen. Dafür musst du immer noch Interfaces konfigurieren, die Virtualisierung einrichten und einiges mehr.
Ich glaube es ist allen mehr geholfen wenn man es manuell oder per Ansible automatisiert auf der Kiste einrichtet, da man da die Dinge einfach präziser steuern kann. Ansonsten bekommst du da relativ schnell Probleme. Außerdem macht es, wenn es wirklich einen Offloader braucht, eh sind das etwas anders zu bauen als so nen Standard gluon Knoten.
Was hast du denn mit einem Offloader vor? Ich kann dann beim nächsten mal auch gerne das x86 Image mitbauen, wenn du damit experimentieren willst.
Hauptsächlich erst mal lernen damit umzugehen. Ich würde gern verstehen wie gut man damit dann auch größere Netze vernünftig anbinden kann. Wenn das VPN komplett in einem oder mehreren Offloadern liegt sollte ja selbst die schwache Hardware von einem 841 ziemlich flott sein und auch viele Clients bedienen können. Aber wieviel Leistung kostet das Mesh-en dann z.B.
Würde gern mal selbst sehen wie gut das klappt und was man dafür alles machen muss.
Wäre super :-) wie gesagt ist erst mal eine „Lernwiese“
Wenn man mehrere Knoten im LAN hat, hat man aktuell die Wahl zwischen 2 Übeln: Mehrfaches Grundrauschen (wenn man allen Knoten Uplinks gibt) oder wenig Performance (da ein Knoten sehr wenig VPN-Performance hat).
Mit einem Offloader hätte man beide Probleme auf einmal erledigt. Dass man beim Konfigurieren der Interfaces und der VLANs etwas aufpassen muss, ist klar.
Ein reiner fastd-tunnel ist ja auf jedem Debian-Rechner in Minuten aufgesetzt, aber würde das schon als Offloader reichen? Oder muss zwangsläufig auch BATMAN auf dem Rechner laufen?
Ja, in allen Fällen in denen jemand nur nen kleinen Offloader für < 50 - 80 Leute braucht, braucht es neben dem fastd Tunnel auch batman-adv im Client Modus. Aber keine Sorge, das Modul ist in der aktuellen Debian Stable Version schon im Kernel enthalten. Es muss nur geladen werden.
Für größere Installationen muss es aber vom Netzwerk/Backbone Team umgesetzt werden. Da wir dort dann mit BGP, GRE Tunneln und lokalen DHCP Servern, etc. arbeiten und das anders in unser Netz einbinden.
