Virtuelle Maschine statt Router

Hallo!

Ich würde gerne meinen FF-Router, da er bald deprecated ist, gegen eine VM tauschen.
Ich hatte daran gedacht, eine VM mit Libvirt laufen zu lassen und dann ein USB Wifi Gerät anzuschliessen.

Nun habe ich einen recht günstigen Wifi Stick, der seit Kernel 4.4 oder so supported wird.

Ich habe ganz naiv probiert, ein x86_64 Image zu importieren und dann noch im Config Mode das entsprechende Modul nachzu installieren um dann hoffentlich spaetestens nach einem Reboot die Wifi Optionen im Browser zu sehen. Das funktionierte allerdings nicht.

Ist das der falsche Weg? Liegt es zb. an der Hardware (USB Wifi)?

Ich hoffe, hier antwort zu finden.

1 Like

Das funktioniert eher nicht bzw. ist schlicht nicht vorgesehen. Diese manuelle Einbindung müßte zudem nach jedem Firmwareupdate wieder händisch erfolgen, das macht auf Dauer keinen Spaß.

Meine Glaskugel ist leider kaputt — lies: welches Modell ist es denn :wink:

Ohne nachgeschaut zu haben könnte ich mir allerdings auch vorstellen, daß das gesamte WiFi-Subsystem bei x86-Builds im Image weggelassen wird — dann hilft der USB-Treiber allein leider nicht. Hintergrund: generell nimmt man x86-Images eher für Offloader, d. h. an deren »LAN-Ports« ist dann das Freifunk-Netz drauf, was dann von normalen Accesspoints ausgestrahlt wird.

Nächste Frage ist, ob denn der USB-Port des Rechners korrekt zur VM weitergegeben wird — hab’ ich mit libvirt noch nie gemacht, soll aber wohl gehen.
Ich würde wohl einfach auf dem Rechner eine Bridge br-ff anlegeen, das LAN-Interface (eth1, IIRC eth0) der VM da reinpacken und außerdem das Interface des USB-Sticks auf dem Rechner; vorher noch Master-/AP-Modus und SSID setzen und fertig. Dürfte auch deutlich performanter sein mit realem statt emuliertem US-Bus …

Edit: LAN liegt auf eth0.

Im Prinzip frage ich tatsächlich, ob ausgeschlossen werden kann, dass Wifi weggelassen wird.

Dann habe ich aber den ganzen geilen Mesh Kram nicht… :frowning:

Ich bin nicht sicher, wie ich ein Image für 4830 baue. Finde weder Anleitung noch werde ich aus dem Github repo wirklich schlau. Für FF Uelzen ging das scheinbar mehr nach den offiziellen docs von Gluon?

Es gibt nur sehr wenige USB WLAN Stick Modelle welche 802.11s unterstützen und das dann noch parallel zum normalen AP Mode. Das ein random Stick dies kann ist unwahrscheinlich.

Auch hast du mit den Sticks in der Regel nicht die Möglichkeit zeitgleich 2,4 und 5 GHz zu nutzen.

Und so richtig stabil und toll habe ich solche Adapter auch nie erlebt.

Ich denke USB WLAN Sticks als AP sind einfach der falsche Weg. Es haben schon einige probiert und du kannst es mit den richtigen Sticks hinpfuschen, aber da kam nie etwas raus was du dauerhaft nutzen willst :sweat_smile:


Ein paar Optionen aus meiner Sicht sind:

  • beim dedizierten FF-Router bleiben (aber halt erneuert)
  • VM und irgendwelche Multi SSID fähige APs die sowohl die private als auch die ff client ssid aussenden (ff-mesh geht damit aber halt nicht)
  • VM und OpenWrt APs welche private, ff-client und ff-mesh konfiguriert haben
2 Likes

FTR, AFAICS wird bei x86 nur in-, nicht excluded.

Vielleicht beantwortest vor neuen Fragen ersteinmal Dir gestellte, z. B. nach der geheimnisvollen USB-WiFi-HW? :wink:

Wie @TomH schon schrieb, USB-Sticks, die AP-Modus und 802.11s-Mesh gleichzeitig und auch noch stabil können, sind rar. Das dann noch durch USB-Virtualisierung zu de-simplifizieren … kann man machen, ist aber vermutlich hochgradige Zeitverschwendung. (Die, wenn man ehrlich zu sich ist und nicht mehr Schüler (d/m/w), der/die eigene Lebenszeit nicht monetarisieren kann, selbst einen 100-EUR-High-End-AP sehr schnell als günstigere Investition entlarvt.) Erfahrung dazu liegt $hier jedenfalls nicht vor, und damt kann auch keine Hilfe bei spezifischen Problemen gegeben werden.

Erfahrung besteht wie folgt: USB-Sick als weiteres Interface (WiFi-Client) für WAN-Zuführung — kann funktionieren (HW-, sprich: modellabhängig, und abhängig von Stick-FW und Linux-Treiber) . AP-Modus: in klassischer Stickfirmware typischereise drin, aber oft nicht dauerhaft stabil. Mehrere Modi parallel: doubly so. USB-Durchreichung von zeitsensitiver HW (Audio-/Video-Geräten): hoher CPU-Verbrauch, choppy experience.

Ab Gluon v2022 (derzeit experimental): site-4830 auschecken, dann README.md dort lesen.

Davor: ReleseNotes zum Build holen (firmware.­4830.org/$branch/factory), entsprechenden commit des FFGT-Gluons auf github.­com/ffgtso/gluon-4830.git auschecken, entsprechenden site-commit von github.­com/ffgtso/site-ffgt-v2021.1.git unter site im Gluon-Verzeichnis packen, in modules unter PACKAGES_FFGT_COMMIT den entsprechende commit packen, dann sollte ein Bau klappen.

Beispiel:

Further Build Information:
==========================
Release: 1.4.0~159
PACKAGES_FFGT_PACKAGES_COMMIT=8d7e61183947b3aa485fc8a290dcb4bc1ce6a026
FFGT_SITE_COMMIT=d96cd824fc3f564e353fac395d7b3f0d3f10f8ea
GLUON_BASE_COMMIT=ce7cf3de24357415b46f1cca675f67f1d89b689a
Buildslave: kaos
Buildjob: 3628454
Buildtime: 56 minutes @ 24 core(s)

Ich bin mir relativ sicher, daß Du für ein funktionierendes Gluon die Treiber für Deine HW vor dem ersten Boot im Image haben mußt. Wenn’s Mainline-Kram ist, sollte das entsprechene Package von OpenWrt ja mitgebaut werden, dann müßte ein Eintrag in der site.mk zum Inkludieren ins Image reichen.

Vielen dank für die Rückmeldungen.

Ich sehe die Probleme mit USB Wifi. Ich hatte gehofft, das es »privat reicht«.

Leider ist eine Erweiterung, ausser via USB, nicht möglich. Ich hatte gehofft, etwas Strom und Nerven zukünftig zu sparen, indem ich keinen Hardwarerouter verwende.

Freifunk ist auch Bastelfunk, Du kannst es ja gerne ausprobieren und berichten — ›ältere Hasen‹ erwarten allerdings, daß gerade der Punkt »Nerven sparen« eher ins Gegenteil gehen wird :wink: