Danke für den Link.
Aber wo ist da recht viel Text aus dem man lernen kann?
Wie der Titel „InterCityVPN meta information“ besagt, geht es hier um Konfigurationsdaten …
Danke für Deine Zusammenfassung in zwei Sätzen!
Die bringen es für die Übersicht auf den Punkt, so daß dann nach den Details weiter recherchiert werden kann.
Irgendwie doch, weil Du siehst doch, auf was für Gedanken Leute kommen können.
Darüber waren wir uns bereits einig.
Genau da sind wir wieder beim Thema Hexenwerk.
OpenWrt trägt in sich bereits die Komplexität einer eigenen Distribution.
Basierend auf diesem Projekt wurde mit vielen Tricks und Schlichen dann gluon gebaut, welches vom Prinzip her einem ganz anderen Zweck dient, nämlich ein WAN-Netzwerk mit verteilten WLAN Hot-Spots zu realisieren.
Kann man das so ausdrücken?
Dies war bereits geschehen, aber die Zielsetzungen der ursprünglichen Idee eines „Freifunks“ (im Sinne vom Mesh-Netzwerk) haben sich ehrlich gesagt zu sehr gewandelt.
Das liegt selbstverständlich an der mangelnden Beteiligung von Leuten die mitmachen und nicht an der Community an sich.
Somit ist dies wiederum ein ganz anderes Thema.
Genau so ist es. Hier werden ganz unterschiedliche „Motivationen“ bedient.
Wer sein LAN durch Inkompetenz offen legt, ist halt selber daran Schuld.
Wer anderen unvorhergesehen extra Arbeit bereitet hat definitiv einen Schaden angerichtet, was selbstverständlich zu vermeiden ist.
Darum wurde selber dieser Thread gestartet, um im Vorfeld eine eigene Idee abzuklopfen, für die offenbar (noch) nicht genügend Kenntnisse vorhanden sind.
Dies kann man wiederum von zwei Seiten aus betrachten.
Das x-86 Image steht für eine bestimmte Hardware.
Deine Sicht aus der erforderlichen Konfiguration eines OpenWrt (für die Lösung) ist letzten Endes ein Software-Problem.
Danke für den nächsten Tip zur Lösung!
Bis vor ein paar von Deinen Posts war einfach nicht klar / bewußt, das hier der Blick auf OpenWrt gerichtet werden muß. Das liegt vor allem daran, daß OpenWrt selber als ein Projekt für Router-Hardware betrachtet wird und daher keine Treiber für WLAN-Sticks erwartet werden.
Daher war die einzige einfache Lösung die vorschwebte, wie man den bereits eingebundenen WLAN-Stick (AR9271) aus dem Host heraus in die VM / gluon durchgereicht bekommt.
Das funktioniert wie gesagt in Virtualbox sehr einfach und problemlos.
Dafür muß dann aber der WLAN-Stick vom Kernel in gluon eingebunden werden, was bislang nicht der Fall ist. Hier hast Du den entscheidenden Tip mit den OpenWrt-Paketen gegeben.
Das ebenfalls, weil auf der Hardware vom Server in einer Virtualbox 7.x das USB nicht mehr funktioniert, während es auf dem Arbeits-PC klappt. Darum Virtualbox 6.1.3 auf dem Server.
Es macht offensichtlich Sinn wirklich auf KVM umzuschwenken …
OpenWrt muß man imho im historischen Kontext sehen. Es ist ›optimiert‹ für sehr kleine Systeme und mit starkem Netzwerk-Fokus.
Gluon nutzt diesen Unterbau geschickt, um eine noch spezialisiertere Lösung zu bieten, die es Menschen erleichtert, ›ein großes WLAN aus vielen verteilten Accesspoints‹ betreiben zu können.
Rein technisch ist Gluon ›nur‹ aktuelles OpenWrt plus aktuellem batman-adv.ko plus z. Zt. drei (davon nur noch zwei vom Projekt direkt unterstützten) Tunnelmethoden: fastd (›neuerdings‹ – seit zwei? Jahren – auch mit L2TP-Transport), Tunneldigger (L2TP-Transport) sowie VXLAN-over-Wireguard (Tunnel über Wireguard, für L2-Nutzung darin VXLAN). [Es wird wohl auch an einem gerouteten Netzwerklayout gearbeitet, aber das ist IIRC noch nicht ›Primetime-ready‹ (und widerspricht zumindest meinem Verständnis eines BSS — ganz anderes Thema).]
Das Gluon-Framework macht es für die Freifunker einfach(er), Netzparameter zu definieren und damit eine funktionierende Firmware zu bauen. Außer, man ist bei einigen ›design decisions‹ unterschiedlicher Ansicht und muß seine Änderungen bei jeder Version nachziehen, kann man eigentlich damit recht schnell auf aktuellen OpenWrt-Unterbau mit aktuellen, häufig verbesserten, Treibern kommen. (Außer, die eigene Knotenflotte ist von Breaking Changes betroffen, dann dauert’s auch mal länger.) Nice: selbst größere Änderungen (Wechsel der Tunneltechnik) sind oft mit nur einem Firmwareupdate umsetzbar. Das erleichtert den ((zu) wenigen) Admins ihr Tagesgeschäft.
Hexenwerk? Wenn man das erste Mal gesehen hat, wie ein ›make‹ Gluon-Code patcht, der dann OpenWrt-Code patcht, der dann wiederum Linux-Code patcht … und nach Stunden dann zig Firmwareimages vorfindet — yepp, sieht so aus Aber eigentlich nicht wirklich, nur ein sehr hoch spezialisierter Haufen von ›Anweisungen‹.
Und ja: Gluon-Netze sind i. d. R. zentralistisch gebaute Netze. Muß man nicht mögen, hat aber den Vorteil, daß es meistens gut für alle Seiten funktioniert.
Vielen Dank für die erneute geniale Zusammenfassung.
Ja - bereits erfolgreich durchgeführt.
Aber ein Build-System „rattern“ zu lassen ist etwas vollkommen anderes als gezielte Änderungen daran vorzunehmen.
Dank Eurer Detailinformationen wird das noch einmal versucht, aber später, da im Moment schlichtweg die Ruhe und Zeit dafür fehlt.
Du willst noch immer 'nen USB-Stick in die Gluon-x86-VM packen? IIRC wird ›wireless‹ bei x86 nicht mitgebaut, zumindest habe ich sowas dunkel in Erinnerung. Ja, zumindest ›iw‹ fehlt im x86-Image, meine ich mich zu erinnern, mußte ich was faken. Ich denke, ›ath0‹ auf dem Host laufen zu lassen (WiFi-Gedöns macht der Host) und das Interface in die VM und dort in ›client0‹ zu bridgen dürfte einfacher sein?
Aber eigentlich nicht wirklich, nur ein sehr hoch spezialisierter Haufen von ›Anweisungen‹.