Ich habe ein „ThinkCentre tiny“ vor der Entsorgung gerettet und mir daraus ein Unraid System gebastelt. Somit habe ich jetzt Docker und KVM-VM zur Verfügung und das Erste was ich dachte war „Freifunk“ - das System läuft sowieso 24/7, also warum nicht.
Ich dachte das ich damit vielleicht einen Offloader bauen oder gar meinen Knoten ersetzen könnte. (Ich habe einen Spielplatz in der Nähe und Rentner ohne internet und abstrusen Mobilverträgen in der Nachbarschaft, da wäre ein Offloader nicht schlecht)
Die Recherche hierzu war allerdings mit meinem ambitioniertem Eisteigerwissen eher verhalten, man landet zu schnell auf den Futuro none VM Lösungen oder VMDK vs. KVM Problematik.
Und im IRC-Channel war man sich uneinig in meiner Community, daher der Post.
Ist es möglich mit einem Unraid System sowas zu realisieren, ohne eine VM in einer VM laufen zu lassen?
Weil bisher sagte man mir das Docker kein BATMAN realisieren könnte, weil Docker mit dem Host Kernel gekoppelt wäre und ich quasi eine Ubuntu VM bräuchte, in der ich ein QEMU image virtualisiere. Somit aus meiner Sicht eine doppelte Virtualisierung und irgendwie überhaupt ein wenig seltsam, weil ich dann doch gleich auch GLUON virtualisieren könnte - ich verstehe den Umweg nicht.
Sofern das nun wirklich nicht via Docker realisierbar ist, müsste das doch auf jeden Fall auch via KVM direkt gehen oder nicht?
Könntet ihr mich ein wenig erleuchten was das angeht?
Oder konkret: Wie kann ich mein Unraid System für Freifunk nutzen?
Und klappt das mit nur einer NIC via VLAN etc.? (muss sonst noch eine bestellen)
Wenn Du KVM hast, bootest Du darin ein ausgepacktes gluon-*-x86-64.img.gz-Image, 1. Ethernet wird IIRC LAN, 2. WAN, done.
Ich kenne Unraid nicht (lizenztechnisch eher eine grenzwertige Unternehmung, IIRC), aber KVM ist nicht »VM in VM« (»nested VM« geht wohl in KVM auch, never tried; Docker in 'ner VM ist schon abstrus genug ;-)).
Das ist korrekt, Kram in Containern läuft auf dem Host-Kernel, Kram in einer VM hat einen eigenen Kernel. Wobei, wenn Du nur 1 Batman-Interface benötigst, könnte das ggf. auch auf dem Host-Kernel laufen und in Docker genutzt werden — keine Ahnung, ob das schon mal wer gebaut hat. Wir haben $früher die fastd-Prozesse auf dem Blech laufen lassen und in die VM reingebridged, weil das deutlich performanter war.
Hä? Wenn Du ein virtuelles Ubuntu starten kannst, dann kannst Du genauso ein virtuelles Gluon starten.
Yepp, this just works.
Das hängt davon ab, ob Du VLAN-fähige Switche hast. Auf einem Linux-Host kann man die VLANs auf eigene virtuelle Netzwerkkarten der VM legen, damit kommt Gluon-x86 klar.
Zum Lernen ist das beschriebene Szenario bestimmt nicht schlecht.
Selbst wenn es wie im dargestellten Fall technisch vermutlich kein real existierendes Problem löst, einfach weil kein Offloader nötig ist.
vlan, q-in-q, vxlan sind Techniken, die - wenn man sie einmal verinnerlicht hat - auch anderweitig sehr nützlich sind.
Nein, KVM ist VM. Mir wurde aber gesagt das ich Ubuntu in KVM machen soll und in diesem Ubuntu ein QEMU image (damit BATMAN laufen kann) laufen lassen soll, was wieder eine VM wäre. Also eine VM (QEMU) in einer VM (Ubuntu). Ich sage ja abstrus.
So habe ich mir das auch gedacht, aber das scheint ja zu einfach zu sein.
Bzw. ist das dann doch „eine Firmware“ also als ein Knoten anzusehen. Ist das so intelligent, dass die 4040 daneben checkt das mein Heimserver das dann tunnelt und nicht selber anfängt? Oder brauche ich am Heimserver dann ein WLAN Stick, trenne die 4040 komplett vom Netz und hoffe auf den Mesh?
Ich habe halt nur dieses Tut, das eigentlich für Futuro ist: Link-Tutorial
und x86-64 unter den Firmwares
keine weiteren Anhaltspunkte zum reinen x86 Offloarder oder images die nicht unter Firmware laufen.
Bzw. keine Informationen wie ich unsere FF-Sachen in ein reines GLUON bekomme (es für meinen FF-Bereich einrichte).
Da fehlt mir auch schon das Haaki zu ohne Tutorial.
Dieses Wissen fehlt mir. Und diese Vergangenheit ist „hier“ Gegenwart.
richtig, aber das wurde mir nicht als Lösung von „unseren Leuten“ gennant. → Ubuntu und darin QEMU war die „könnte klappen“ Lösung.
Ich habe den Server und Knoten an einem VLAN fähigen Switch.
Will den Server aber nicht dafür in ein VLAN zwingen, wenn ich das auch unter Linux über eine NIC laufen lassen kann und das nicht hardwaretechnisch trennen muss.
Dann spar ich ne 2. NIC und deren Strom (in dem ThinkCentre ist das nicht soo günstig Hardware zu besorgen (FRU 50€+ oder NIC mittels PCIe-Adapter oder USB-Variante)) und kann meinen Heimserver wie gewohnt nutzen (Freifunk soll zusätzlich laufen (Zugewinn), nicht hauptsächlich (Möglichkeitenverlust), dafür ist das Thinkcentre zu schade - ich bin eine Insel, keiner mesht mit mir ,dass man sich das schön reden könnte).
Dachte an den unteren Teil der Futuro-Anleitung, mit einer NIC via soft-VLAN
Das sehe ich anders, hier arbeitet man noch mit fastd, das bedeutet das meine ach so tolle 4040 real nicht viel mehr macht, als der billigere Bruder 1043n (30 zu 25 MBit) und nun sein wir mal ehrlich, wenn sich 5 Leute 15-25 MBit teilen ist das vom Feeling her „Ausreichend“, also Schulnote 4.
Und nun habe ich eben 2m daneben einen i3-8100T, der daraus locker 100MBit machen könnte und immernoch gelangweilt wäre.
Und ich habe 4-8 Dauerkunden (Nachbarn und deren frequenter Besuch - Rentnerclique) und einen Spielplatz in der Nähe, wo die Muttis das auch schon spitz bekommen haben und teilweise nutzen.
Da denke ich, kann man schon mal eben ein wenig boosten, was einen Offloader bzw. direkten x86-Knoten doch rechtfertigt.
Wie gesagt, kein L2TP. Das gibt es bei uns nicht, dann müsste ich eine eurer Gemeinschaften anzapfen, was ich unfair fände euch gegenüber, dann wäre ich ja bei meinen 160-200 MBit, wie man im Nachbarchannel lesen durfte. Da wären wir uns einig. Bei fastd könnte man eigentlich eher argumentieren nichts ohne Offloader zu machen
–
Gut, also halten wir fest.
-x86-64 Gluon img.gz in KVM
-VLAN Anpassung in GLUON/VM → eine NIC ohne Hardware-VLAN
4040 bleibt ?
4040 leite ich im Konfiguarationsmodus auf die IP des GLUON um? Lasse die einfach im gleichen Switch ohne hard-VLAN.
4040 kommt weg?
dafür einen WLAN Stick mit Realtek, wenn ich recht entsinne.
4040 vom Netz und woanders beim Nachbarn verbauen und meshen /dem Verein spenden
Gibt es da irgendwo Tutorials für, die unspezifisch(er) sind (nicht Siemens Futro*), wo auch mal was zu ner intel NIC steht, man mit SSD/NVME statt CF arbeitet?
Ich nehm auch was von Youtube.
Oder kann ich jetzt echt mein Thinkcentre unter den Arm klemmen und zum nächsten Treffen gehen? Sprengt sowas nicht den Rahmen? Ich meine ich wäre mitmenschlich „so doof“ und würde das für andere machen, wenn da einer käme, aber ich bin auch echt sozial und möchte da keinen überstrapazieren.
*mal im Ernst: Die bekommt man doch gar nicht mehr (da steht noch Siemens dran), das ist doch deutschlandweit obsolet, dafür gehen die 50€ Kisten bei Mydealz (Dell, Fujitsu, Lenovo) doch viel zu oft über den Tisch und verbrauchen den gleichen Strom bei 5-20x Leistung). Die Anleitungen kann man doch eigentlich viel besser allgemeiner halten und damit mehr Leute erreichen.
Oder eben Sachen die die Leute auch nutzen oder nebenbei haben: Plex, Unraid, Synology (eben NAS/VM-Systeme).
Im Leben haben deutschlandweit keine 10 Leute noch die Futro Anleitungen auf der Hardware umgesetzt in 2022-23. Aber bestimmt schon mehr Leute mit Synology-System nach einer Lösung gesucht bzw. würden diese nebenbei betreiben - kostet doch nichts und je mehr der „Server“ macht desto besser das Gefül den laufen zu lassen → sollte man ausnutzen.
Ich meine ja, die Anleitungen waren gut, die Hardware ein guter Tip. Aber die Zeit lief weiter und keiner bekommt noch sowas ins Haus.
Jetzt haben wir SmartHomes mit Servern und gleich VPN und VMs dazu (Multisysteme). Da muss doch umgedacht werden bei den Tutorials.
Warum das so kompliziert belassen?
Ja, 30MBit/s wegen fastd sind schon ärgerlich. Aber wenn’s „nach draußen geht“ (wenn es noch weitere Nachbarn gibt, also nicht nicht auf dem Einsiedlerhof oder dem Naturfreundehaus im Wald), dann wirst Du wegen Airtime-Problemen sowieso nie mehr als 25MBit/s im Stundenmittel rausbekommen, selbst bei mehreren Clients mit Downloadmanagern.
Will sagen: Zum Lernen von Netzwerkstack des Unraid ist das alles eine gute Übungsaufgabe. Bei einer 4040er für Outdoor-Versorgung (und nicht mehreren APs im Lan-Mesh) wird ein neuzeitliches Gerät ausreichen, die 25MBit/s wird sich mit RealLife-Clients auch mit einem performanten Offloader nicht knacken lassen.
Ich wohne nicht im Wald, aber hier hat Sido auch nicht „Mein Block“ gedreht.
Soll heißen wenn hier einer den Luftraum verfunkt, bin ich das mit meiner 4040 am Fenster.
Unterm Strich ist das kein Problem → wenn ich mein Handy nehme und nach WLANs scannend die Straße runter gehe, dann habe ich alle 5m was Neues und das Alte ist weg (außer mein FF-Knoten natürlich).
Die Häuser hier sind so vom Funkschluck, das mein eigenes WLAN vor verschlossener Haustür nicht erreichbar ist und nur 10m in den Garten reicht. Bauartbedingt reicht jedes 2. Haus bis vor die Haustür 5-10m und die anderen landen im Garten.
Ich habe keinen Funk auf der einen Seite und nur 2 weitere Netze auf der anderen Seite, die verbleibenden 2 Seiten sind nahezu frei. Und das sind alles Menschen die einfach nur ihre Fritze in die Dose gesteckt haben, die Kanäle kann ich mir hier noch frei wählen und deren Boxen verdrängen.
Wenn ich ne Nanostation aus dem Fenster halte sieht das anders aus, ich will aber die Kinder nicht mit Richtfunk beschallen, das ist topologisch unnötig.
Wenn das zu viel ist, macht das alles hier keinen Sinn mehr.
–
Aber ich habe gerade mal nach „KVM Gluon“ in mehreren Varianten (add, xml etc.) geschaut und das dazugehörige XML und lande nur hier im Forum in 2 Channels, wo die das schon aufgesetzt haben.
Da fehlt mir jetzt einfach das Haaki zu, der Server steht hier die 2. Woche und bisher hat mich Docker alleine schon genug erheitert, das wäre jetzt meine erste VM und ich habe ja sowas von keinen Plan … Stößchen (sagte er ohne alkoholischen Einfluss, mit einem Erfrischungsgetränk light)
Doch doch, dafür habe ich hier schon zu viel vom Futro gelesen.
Ich meine zu wissen das das Problem war das nur ein Kern genutzt wird (daher ja auch die Sinnlosigkeit der 4040 hier bei mir), wenn ich jetzt aber den Futro Kern gegen den 8100T Kern rechne ist das eine ein Messer und das andere Kaliber 50.
Wenn der Futro also 50-90 Mbit und mehr schafft, dann macht der i3 locker meine Leitung dicht.
x86-Knoten wird auf Mesh-on-LAN konfiguriert, die 4040 auf Mesh-on-WAN, und ihr WAN an den „LAN-Port“ der VM angeschlossen. (Wie Du das auf Deiner Infrastruktur löst, kann ich Dir nicht sagen.)
gluon-ffhb-2019.1.3+bremen8-x86-64.img.gz auspacken, das .img ist die virtuelle Disk. VM mit dem .img-File als Disk erzeugen, die VM braucht 2x Ethernet. VM booten, das Gluon darin konfigurieren (Config-Mode), Hinweise oben beachten.
Dann mußt Du Dich wohl entscheiden, ob Du Theoretikern oder Praktikern folgen willst.
Für mich ergibt der Satz keinen Sinn. Wie dem auch sei: die Gluon-VM braucht 2x Ethernet, 1x WAN („Internet“) und 1x LAN. An das LAN muß das WAN der 4040, jeweils mit „Mesh-on-?AN“-Einstellung in Gluon. Wie Du das löst, ist Deine Sache — VLANs scheinen mir da das Einfachste, aber wenn Dich batman-Pakete im LAN nicht stören, geht’s vermutlich auch ohne VLANs und mit nur 1 Netzwerkkarte.
… daß es nichts bringt, auf Deiner Seite eine 10-GHz-CPU für „fastd-Klassik“ einzusetzen, wenn das Gateway der Community in einer VM auf Low-Power-CPUn aus der letzten Dekade läuft. Wie Du schon feststelltest, fastd ist single-threaded und in der klassichen Einsatzweise (ohne L2TP) geht auch auf dem Gateway jedes Paket mehrfach durch die CPU und wechselt dabei auch zwischen Kernel- und Userspace-Kontext. So Xeon ist zwar flotter als eine MIPS- oder ARM-CPU in einem WLAN-Router — aber dafür muß der fastd-Prozeß auf jedem Gateway die Pakete von 10?, 20?, 100? Knoten verarbeiten. Und Virtualisirung macht das ja nicht schneller
Du willst nichts in Gluon ändern, weil Du das bei jedem Firmwareupgrade nachziehen müßtet. Du willst 2x Ethernet in der VM, damit kann Gluon umgehen.
Ich sehe kein Hardwareproblem in Deiner Beschreibung, was willst Du also mit der Hardware auf 'nem Treffen?
Willst Du Dein Thinkcentre zum Offloader machen? Dann bau eine 2. Netzwerkarte ein und nutze Gluon2Futro. — mit deaktiviertem Sicherheitscheck (Zeile 107 löschen) habe ich damit einen fetten Office-PC zum Offloader gemacht, als es ein 1043 nicht mehr packte …
Es geht im Grunde mit jeder x86-64-Hardware, solange es nur 2 Netzwerkkarten sind. Ab Futro 900 geht das auch schon als kleiner Hypervisor durch, 920 gibt’s mit mehr vCores und RAM:
root@gw-gut01:~# dmidecode | grep -i Futro
Product Name: FUTRO S900
root@gw-gut01:~# free -h
total used free shared buff/cache available
Mem: 1.5G 270M 238M 416K 1.0G 1.1G
Swap: 979M 143M 836M
root@gw-gut01:~# virsh list
Id Name State
----------------------------------------------------
1 offloader running
Bitte nur 1, 5, 9, 13 nehmen und nein, Du verdrängst nichts, Aussendungen auf anderen Kanälen ist nur störendes Rauschen.
Naja, wenn Du schneller sendest als der fastd im Gateway Dir zuhören kann … sicher.
Vielen Dank für die ausführliche Antwort. Die hat mich die Woche ein wenig beflügelt.
Image:
Ich habe es probiert das entpackte image zu virtualisieren, allerdings ohne Efolg. In dem Zuge habe ich mir aus dem Bereich „factory“ ein vmdk-Image gezogen und versucht. Das lief/läuft mit Erfolg.
Geplantes Setup:
Router <----onbaord----> Unraid/vm-FF-Offloarder <------dongle -----> 4040 (Mesh on WAN)
Also ich habe die VM mit 256 RAM, einem CPU-Kern und dem vmdk als vDisk realisiert.
Konnte auch via der Onboard Nic auf die Konfigurationsseite zugreifen und den „Knoten“ einstellen.
Bei der 4040 habe ich das so verstanden, dass die Änderung zu „mesh on WAN“ reicht und habe das vorgenommen. Und die 4040 von WAN zum dongle angeschlossen.
2. NIC
Ich habe mir nochmal Gedanken zu der ein NIC Problematik gemacht.
Dazu noch der Gedanke, dass ich ohne LAN Kabel meshen könnte, um so die Ausleuchtung zu verbessern, ohne Kabel legen zu müssen.
Diesen Ansatz musste ich leider verwerfen, da Unraid keine WLAN-Hardware unterstützen soll.
Ich habe jedoch nochmal einen Netzwerkdongle angeschafft, um das Duo Nic Szenario fahren zu können. (Chipsatz: AX88179 - Unraid soll sich gut mit dem vertragen)
Der wird von Unraid auch erkannt und kann konfiguriert werden.
In meinem Fall habe ich daraus nun eine 2. Bridge gemacht br1 (br0 ist die onboard NIC) und diese als 2. NIC in der FreiFunk VM hinzugefügt.
Problem
Die 4040 bekommt kein Internet.
Als ich auf der Konfigurationsseite der VM war, hatte ich keine Möglichkeit „Mesh on LAN“ zu aktivieren. Daraus habe ich geschlossen, ob der VM-Knoten wirklich 2 verschiedene NICs zur Verfügung hat (und weiss nicht wie ich das so richtig nachsehen kann - gibt es was besseres als ifconfig?).
Zuerst habe ich vermutet, dass der Dongle nicht richtig umgesetzt wird und ich nur die onboard NIC habe (über die konnte ich den Knoten konfigurieren). Oder das nun die Anschlüsse vertauscht sind (der dongle WAN ist und die onboard LAN)
ifconfig
ifconfig hatte ich im Nachbarchannel gefunden und da habe ich eben nur eth0 und keine zusätzliche eth1 (die ich jetzt erwartet hätte).
Lustiger Weise ist jedoch eth0 die MAC von dem dongle und nicht die von der onboard NIC. Was mich in sofern beruhigt, als das der Dongle auch in der VM wohl funktioniert.
Doch wo ist denn dann die onbaord hin? Der Treiber wird auf jeden Fall geladen und die MAC Adresse finde ich unter „bat0“ und „br-client“.
Unter „br-wan“ habe ich eine MAC die ich nicht zuordnen kann, weder real noch virtuell.
Wenn ich also beide MACs von den NICs sehe, gehe ich davon aus das es ein Konfigurationsproblem ist, das nicht via Konfigurationsseite zu lösen ist (der Punkt „mesh on LAN“ wird mir nicht angeboten).
Und da habe ich momentan keine Quelle zu gefunden, die auf mich zutrifft, bei denen sind immer beide NICs unter ifconfig zu sehen. Bei mir halt nicht.
Aber bisher finde ich das schonmal gut und das geht in die richtige Richtung.
ip a
„ip a“ hingegen zeigt mir an das eth0 mein dongle ist und eth1 die onboard nic.
–
onboard ist eth1 und eingetragen bei „bat0 und br-client“
dongle ist eth0 und sonst nirgends eingetragen
br-wan ist auf einer MAC die ich nicht zuordnen kann
müsste ich jetzt nicht eigentlich nur eth1 auf WAN legen und eth0 auf br-client/mesh ?
Deinen »Dongle« (die USB-Netzwerkkarte) sieht nur das Hostsysstem (bei Dir Unraid) — also sollte jedenfalls nur… Was Du der VM reinreichen mußt ist ein Bridgeinterface (bzw. derer zwei), in welchem schon hostseitig das physische Interface konfiguriert ist und in welches der VM-Layer dann ein virtuelles Ethernet-Interface packt. Dessen Typ konfigurierst Du auf dem VM-Layer (bei mir libvirt, dunno, was Unraid nimmt — vmdk ist IIRC VMWares Format?), und für diese vorgegaukelte Hardware muß die VM Treiber besitzen.
Wenn Du »eth1« erst nach dem ersten Booten der VM hinzugefügt hast, wird das allerdings IIRC nicht mehr erkannt. Ob »firstboot« reicht, dunno (ja auf anderer Hardware, aber OpenWrt-x86 ist ja nicht Flash-basiert).
Solltest Du also Config-Mode aufgerufen, dann die 2. NIC Deinem Unraid-System hinzugefügt, dann Deiner VM ein zweites Interface spendiert und dann nochmals den Config-Mode aufgerufen haben und dann »auf der Konfigurationsseite der VM […] keine Möglichkeit „Mesh on LAN“ zu aktivieren« gehabt haben, liegt jenes vermutlich daran.
Bei Standard-Gluon ist das Config-Mode-Interface jenes, was Gluon als »LAN« ansieht, bei >1 Interface IIRC das zweite, bei nur einem jenes, es wird aber als »WAN« angenommen IIRC; Interfaces sammelt Gluon beim ersten Boot.
Die MAC-Adressen der Ethernet-Interfaces (wie auch der WiFi-Interfaces) werden von Gluon verändert. »ip addr show« in Gluon zeigt die genutzten.
habe ich:
in Unraid: onboard ist br0 (in der VM eth1)
dongle br1 (in der VM eth0)
unter ip a sind beide NICs und unter ifconfig ist nur eth0 eingetragen (der Dongle) und eth1 via br_client und bat0
Nein, das ist die onboard NIC (die war schon immer dabei). Die VM wurde mit beiden NICs angefeuert, es kam nichts nachträglich dazu.
Das bestätigt meine Befürchtung das die NICs vertauscht sind. Bzw. die Konfiguration nicht stimmt. Demnach ist meine Onboard NIC LAN und mein Dongle nichts. Das muss ich drehen.
Aus meiner Sicht müsste ich jetzt z.B. mittels uci die Zuweisungen ändern. Aber ich weiß trotz der letzten 3h und 12 Themen nicht exakt wie.
Ich müsste die Console jetzt screenen, weil ich nichts kopieren kann.
ip a
onboard eth1
dongle eth0
ifconfig
dongle eth0
onboard taucht nicht als eth1 auf, ist aber als mesh (bat0) und br-Client eingetragen
aus meiner Sicht muss ich jetzt über eth1 das Internet laufen lassen statt client/mesh und auf eben eth0 den mesh/client …
Aber wie drehe ich das jetzt? bzw. konfiguriere ich das jetzt richtig.
Ich kenne einfach die Befehle nichtbzw. bin mir da unsicher.
Natürlich schließe ich auch die Umsetzung in Unraid jetzt nicht als fehlerfrei aus oder in der VM.
Aber momentan läuft das, er hat eigentlich alles, aber es ist nicht richtig verschlatet.
Weil momentan kann de 4040 auch kein Inet bekommen, weil der ganze Server via Onboard angebunden ist, was in der VM aber jetzt ja „Client“ ist.
Dann verstehe ich »[a]ls ich auf der Konfigurationsseite der VM war, hatte ich keine Möglichkeit „Mesh on LAN“ zu aktivieren« nicht.
Nix einfacher als das, einfach brctl delif brX ethY (IIRC) und in anderer Reihenfolge wieder hinzufügen?
So funktioniert Gluon eher nicht.
?
Was sagen …
root@525400596884:~# brctl show
bridge name bridge id STP enabled interfaces
br-client 7fff.525400596884 no eth0
local-port
bat0
br-wan 7fff.be7b5d01aa58 no eth1
… und …
root@525400596884:~# for i in /lib/gluon/core/sysconfig/*ifname ; do echo "$i: $
(cat $i)" ; done
/lib/gluon/core/sysconfig/lan_ifname: eth0
/lib/gluon/core/sysconfig/setup_ifname: eth0
/lib/gluon/core/sysconfig/wan_ifname: eth1
… in der VM (vorzugsweise nicht im Config-Mode)? (EDIT: Du weißt, daß Du da einfach per SSH draufkommen kannst, wenn Du das im Config-Mode konfigurierst?)
Ich habe mir deine Einwände zu Herzen genommen und nochmal das Setup gelöscht.
Neues Image, alles frisch.
Ich habe jetzt das Sysupgrade img nochmal probiert und das läuft, habe die NICs somit neu gesetzt.
Jetzt musste ich zur Konfiguration die andere NIC (den dongle nehmen) und habe zumindest auf dem VM System einen Ping auf google. Sieht somit schonmal richtig aus.
Diemsal hatte ich auch mesh on LAN zur Auswahl.
Die SSID von der 4040 ist von offline zu online gewechselt. Wenn man sich jedoch verbindet erhält man kein Internet. man bekommt eine IPv6 aber Router ist 0.0.0.0 eingetragen.
Muss ich an der noch was anderes einstellen als
Ich bekomme auf die 4040 einfach kein Netz.
Im Heimrouter ist der VM-Knoten im IP-Bereich, die 4040 sehe ich gar nicht. Die SSID ist „online“ man bekommt aber kein Netz und auf der karte ist die 4040 offline.
Ich wüsste jetzt auch nicht wie ich die anpinge, weil ich nicht weiß welche IP die hat bzw. wie das jetzt am VM-LAN-mesh funktioniert, ob die VM der 4040 ne IP gibt oder ich das statisch setzen muss.
Auf der VM ist mesh-VPN und mesh-on-LAN aktiviert.
Auf der 4040 ist mesh-on-WAN aktiviert und mesh-VPN deaktiviert. Und die Verkabelung geht vom Dongle in den WAN der 4040.
br1 benötigt kein IP, darüber wird ja nur Batman gesprochen (bei Standard-Gluon brauchst Du da aber temporär 192.168.1.0/24 drauf wg. Config-Mode); die 169er-Adressen sind da vollkommen fehl am Platze.
Damit gibt’s kein IP auf LAN der VM/WAN der 4040 — da läuft Batman.
batctl gw sagen jeweils was auf VM und 4040?
Ausgabe von ip addr show jeweils von VM und 4040?
Und auch brctl show jeweils posten.
Der Beschreibung nach sollte das funktionieren, zumal wenn Du eine öffentliche v6-Adresse ‚hinter der 4040‘ bekommst.
Was mir gerade aufgefallen ist:
via ifconfig sieht man ja den Traffic auf den einzelnen Posten.
Ich habe 1,1 GiB auf eth1 und WAN.
Der Knoten ist ja „nicht angebunden“ und auf der VM hat auch keiner was gemacht. Das finde ich dafür ein wenig viel.
eth0 300 MiB RX und 600 TX.
Ich hab’ das mal spaßeshalber eben gemacht … (In der Annahme, es ginge um FFHB, mit Images von dort; das tut aber tentenziell mit jeder Gluon-basierten FW so.)
KVM-Hypervisor (Laptop):
root@lap:~# brctl addbr batlnk
root@lap:~# brctl addif batlnk enxa0cec85b4714
root@lap:~# ip link set up dev batlnk
root@lap:~# ip addr add 192.168.1.205/24 dev batlnk # Nur für Config-Mode bei Standard-Gluon notwendig
root@lap:~# ls -la /var/lib/libvirt/images/*ffhb*
-rw-r--r-- 1 libvirt-qemu kvm 285736960 Jul 23 12:56 /var/lib/libvirt/images/gluon-ffhb-2019.1.3+bremen8-x86-64.img
root@test-node:~# brctl show
bridge name bridge id STP enabled interfaces
br-wan 7fff.3ad140f7d2d0 no eth0.2
br-client 7fff.e4956e46470e no eth0.1
local-port
bat0
client0
root@test-node:~# batctl if
primary0: active
vx_mesh_wan: active
mesh0: active
root@test-node:~# batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-13, MainIF/MAC: primary0/3a:d1:40:f7:d2:d3 (bat0/e4:95:6e:46:47:0e BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth
46:bc:50:0e:02:c2 ( 68) 96:92:b9:c3:85:d4 [vx_mesh_wan]: 100.0/100.0 MBit
* 4e:b1:8a:d9:80:36 (111) 96:92:b9:c3:85:d4 [vx_mesh_wan]: 100.0/100.0 MBit
9e:9b:0e:b0:b7:fd ( 68) 96:92:b9:c3:85:d4 [vx_mesh_wan]: 100.0/100.0 MBit
c2:be:cd:f0:8c:8f ( 69) 96:92:b9:c3:85:d4 [vx_mesh_wan]: 100.0/100.0 MBit
Ergebnis eines Clients hinter der „logischen 4040“:
root@ff-client:~# traceroute -I -6 google.com
traceroute to google.com (2a00:1450:4001:811::200e), 30 hops max, 80 byte packets
1 2a06:8782:ffbb:42::7 (2a06:8782:ffbb:42::7) 39.462 ms 55.559 ms 55.531 ms
2 bgp-plutex01.bremen.freifunk.net (2a06:8782::2) 55.504 ms 61.460 ms 61.441 ms
3 * * *
4 2a00:c380:1337:10::4 (2a00:c380:1337:10::4) 65.095 ms 65.074 ms 65.055 ms
[…]
14 fra16s51-in-x0e.1e100.net (2a00:1450:4001:811::200e) 60.925 ms 61.174 ms 61.144 ms
root@ff-client:~# traceroute -I 1.0.0.1
traceroute to 1.0.0.1 (1.0.0.1), 30 hops max, 60 byte packets
1 10.196.0.8 (10.196.0.8) 36.957 ms 41.825 ms 47.688 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 one.one.one.one (1.0.0.1) 54.418 ms 37.583 ms 40.313 ms
(Die fehlenden Zwischenantworten bei IPv4 liegen daran, daß ich nur 1.0.0.1 über den FFHB-Zugang route. Würde die Default-Route über FFHB gehen, gebe es eine Schleife: Die VM geht ja über den Laptop ins Intermet, also würde dann die VM über das (gelbe, s. u.) Kabel zum Freifunk-Knoten gehen, der über das andere (blaue) Kabel zur VM, die das dann über die Laptop-Defaultroute zum FFHB-Gateway senden würde — also via gelbem Kabel … ;-))
(Bild via FFHB per Mail verschickt; auch das tut also.)
Blau ist das Mango-WAN. welches im USB-Ethernet-Dongle steckt, welches als enxa0cec85b4714 in br-batlnk steckt. Das Gluon auf dem Mango ist auf Mesh-on-WAN konfiguriert. Gelb geht vom LAN-Port des Mango in den Adapter für das onboard-Ethernet enp0s31f6, über den ich auf’s Freifunk-Bremen-Netz durch den Mango und die VM zugreifen kann. (Der Laptop hat Internet via WLAN, die VM bekommt genattetes IPv4 über virbr0 (libvirt-Standardsetup).) Nicht im Bild: mobiler Client, der per WLAN bremen.freifunk.net verbunden ist. Auf dem Hypervisor habe ich faktisch nur br-batlnk mit enxa0cec85b4714 als »Port« hinzugefügt, die Bridge aktiviert und die VM hinzugefügt (1. Ethernet Gluon-LAN, 2. Ethernet Gluon-WAN).
root@lap:~# brctl show
bridge name bridge id STP enabled interfaces
batlnk 8000.a0cec85b4714 no enxa0cec85b4714
vnet0
virbr0 8000.525400d86533 yes virbr0-nic
vnet1
Kurzum: das funktioniert mit libvirt/qemu-kvm prinzipiell. Warum das bei Dir nicht tut, ist ferndiagnöslich eher nicht zu ermitteln. (Und das Aufsetzen dauerte nicht halb so lange wie die Dokumentation ;-))
Also ich habe auf der 4040 mal meinen ssh key hinterlassen aber komme an die 4040 nicht ran. Also nicht über den Namen und die IP weiß ich nicht (ist ja nicht erreichbar (und ja ich war am LAN Port der 4040 direkt dran, bekomme ipv6 und sogar v4 aber keinen Anhaltspunkt was die knoten IP ist)
Habe in dem Zuge die Einstellungen überprüft und es ist alles richtig (mesh VPN aus, mesh on WAN an ))
die VM bekomme ich nicht in den konfig mode also setz ich das einfachhaltshalber neu auf und spiel mal an dem Dongle rum. Ich konfiguriere das mal ohne mesh on lan und schau mal, ob ich als Client an dem Dongle was bekomme.
Nachtrag:
Ich habe die VM ohne mesh on LAN konfiguriert und bekomme via Dongle als Client tatsächlich Zugriff
uci set gluon-setup-mode.@setup_mode\[0\].enabled='1'
uci commit
reboot
Auch auf der VM kannst Du im Config-Mode Deinen SSH-Key hinterlegen und dann per ssh auf die WAN-IP draufgehen; falls die Community das in der Firmware geblockt haben sollte, müßte es jedenfalls von außen über IPv6 gehen (außer sie blocken Port 22 inbound — das sind so Details, die jede Freifunk-Gruppe selbst entscheidet …).
Wir reden über FFHB? Anyway, einfach der verlinkten Firmware folgen (im Falle FFHB landet man dann hier). Worked for me (allerdings nur IPv4 — kann aber am zusammengehackten Setup liegen).
Die »next node«-IP[s], so konfiguriert in der Gluon-basierten Firmware, greifen nur über Zugang per Client-Netz – br-client –, also normalerweise (sprich wenn FW-Default für »LAN« nicht »Mesh-on-LAN« ist) LAN & WLAN.
,dass man sich das schön reden könnte).
/dem Verein spenden
… Stößchen (sagte er ohne alkoholischen Einfluss, mit einem Erfrischungsgetränk light)
