X86 Server als Freifunk Knoten mit Atheros AR9271

lsmod · November 24, 2024, 10:39am

Hallo zusammen,

eventuell wurde eine passende Beschreibung übersehen, aber bislang kommt nur dieser aktuellere Thread dem Thema Nahe.

Es geht darum als Hardware für den Betrieb eines Freifunk-Knotens einen vorhandenen Webserver zu nutzen mit

AMD A10-6700T APU (with Radeon™ HD Graphics)
Debian GNU/Linux 11 (bullseye)
Atheros AR9271 WLAN-Stick mit externer Antenne
Optionale Virtualisierung mit Virtualbox 6.1.3 (neuere Versionen haben Probleme mit der alten Hardware)

Es ist bereits gelungen ein x86-Image vom lokalen DiVoNet.de als Knoten in Virtualbox ans Netz zu bekommen, allerdings ohne WLAN und ohne parallelen SSH-Zugang.

Die Konfiguration des x86-Image (für den WLAN-Stick und das SSH) hat sich als extrem harte Nuß erwiesen, da die Kenntnisse im Bereich Netzwerk und Virtualbox leider an ihre Grenzen stoßen.
Daher wäre jeder Tip sehr hilfreich.

Im Grunde genommen erscheint eine virtuelle Maschine sogar als übertriebene Lösung, da hier gluon mit einem Linux-Kernel in GNU/Linux läuft.
Sollte das nicht viel einfacher gehen?
Eine Abschottung der notwendigen Prozesse kann elegant über AppArmor realisiert werden und würde den Zugriff auf den WLAN-Stick deutlich vereinfachen, da dieser nativ im Debian GNU/Linux problemlos eingebunden wird.

[ 8207.181681] usb 4-2: new high-speed USB device number 2 using xhci_hcd
[ 8207.420638] usb 4-2: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08
[ 8207.420646] usb 4-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 8207.420651] usb 4-2: Product: UB93
[ 8207.420654] usb 4-2: Manufacturer: ATHEROS
[ 8207.420657] usb 4-2: SerialNumber: 12345
[ 8207.551011] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 8207.551323] cfg80211: Loaded X.509 cert 'benh@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
[ 8207.551606] cfg80211: Loaded X.509 cert 'romain.perier@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[ 8207.551871] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 8207.552135] cfg80211: Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[ 8207.552445] platform regulatory.0: firmware: direct-loading firmware regulatory.db
[ 8207.553987] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s
[ 8207.699369] usb 4-2: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[ 8207.699560] usbcore: registered new interface driver ath9k_htc
[ 8207.700013] usb 4-2: firmware: direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw
[ 8207.991096] usb 4-2: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
[ 8208.241530] ath9k_htc 4-2:1.0: ath9k_htc: HTC initialized with 33 credits
[ 8208.507235] ath9k_htc 4-2:1.0: ath9k_htc: FW Version: 1.4
[ 8208.507242] ath9k_htc 4-2:1.0: FW RMW support: On
[ 8208.507246] ath: EEPROM regdomain: 0x60
[ 8208.507248] ath: EEPROM indicates we should expect a direct regpair map
[ 8208.507253] ath: Country alpha2 being used: 00
[ 8208.507256] ath: Regpair used: 0x60
[ 8208.518026] ieee80211 phy0: Atheros AR9271 Rev:1
[ 8208.527433] ath9k_htc 4-2:1.0 wlxc01c300da4cc: renamed from wlan0
[ 8208.802285] usb 4-2: USB disconnect, device number 2
[ 8209.841657] ath: phy0: Failed to wakeup in 500us
[ 8209.855591] ath: phy0: Failed to wakeup in 500us
[ 8209.865622] ath: phy0: Failed to wakeup in 500us
[ 8209.875618] ath: phy0: Failed to wakeup in 500us
[ 8210.145816] usb 4-2: ath9k_htc: USB layer deinitialized
[ 8210.485962] usb 4-2: new high-speed USB device number 3 using xhci_hcd
[ 8216.254168] usb 4-2: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08
[ 8216.254177] usb 4-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[ 8216.254181] usb 4-2: Product: UB93
[ 8216.254185] usb 4-2: Manufacturer: ATHEROS
[ 8216.254188] usb 4-2: SerialNumber: 12345
[ 8216.268986] usb 4-2: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[ 8216.269179] usb 4-2: firmware: direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw
[ 8216.553899] usb 4-2: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
[ 8216.806343] ath9k_htc 4-2:1.0: ath9k_htc: HTC initialized with 33 credits
[ 8217.065406] ath9k_htc 4-2:1.0: ath9k_htc: FW Version: 1.4
[ 8217.065414] ath9k_htc 4-2:1.0: FW RMW support: On
[ 8217.065418] ath: EEPROM regdomain: 0x60
[ 8217.065420] ath: EEPROM indicates we should expect a direct regpair map
[ 8217.065425] ath: Country alpha2 being used: 00
[ 8217.065427] ath: Regpair used: 0x60
[ 8217.069610] ieee80211 phy1: Atheros AR9271 Rev:1
[ 8217.079646] ath9k_htc 4-2:1.0 wlxc01c300da4cc: renamed from wlan0

iwconfig zeigt:

wlxc01c300da4cc  IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

Zur Zeit müßte Hardware für einen Freifunk-Knoten gezielt angeschafft werden und würde erheblich mehr zusätzliche Energie konsumieren. Darüber hinaus soll der Knoten in der Nacht deaktiviert werden können, um die Strahlenbelastung zu senken.
Daher kam es zu dieser Idee als Hardware für einen Freifunk-Knoten.
(Es gibt hier weit und breit keinen einzigen Freifunk-Knoten mehr.)

wusel · November 24, 2024, 1:25pm

Feel free; im Grunde ist ein Knoten nur ein Gateway mit WLAN aber ohne DHCP. Er macht prinzipiell nicht mehr, als das WLAN in Batman zu bridgen und über den Tunnel der Community zum Gateway zu transportieren.

Kann man mit den Infos aus einem Knoten-Image prinzipiell alles nachbauen, und wer seine Lösung inkl. Weg dorthin verbloggt oder in einem Wiki versenkt, könnte zukünftigen Nachfragern einen Dienst erweisen.

Wem das zu (zeit-) aufwändig ist, nimmt eine Gluon-VM als Offloader und einen 25€-Reiserouter als Knoten mit WiFi. (Ob jener relevant für mehr Energieverbrauch der X86-Box sorgt oder das im Grundrauschen untergeht, würde mich tatsächlich interessieren. Bauchgefühl: it depends.)

BTW: dies sollte eher nach Technik/Gluon.

lsmod · November 24, 2024, 1:30pm

Danke für Deine Gedanken.
Das klingt so schön einfach das es nur noch umgesetzt werden muß …

Für einen ersten Versuch werden nun die Binaries aus dem x86-Image extrahiert und die Idee wäre, Mal einen Startversuch über ein chroot zu wagen.
Es wird darüber weiter berichtet …

lsmod · November 24, 2024, 2:07pm

Hat jemand bitte noch ein paar Tips zu dem SSH-Problem bei dem Zugriff auf ein x86-Image in Virtualbox?

Das x86-Image hat zunächst einmal die IP 192.168.1.1 - korrekt?
Das paßt mit Virtualbox nicht zusammen, um auf Port 80 zugreifen zu können.
Daher mußte die IP mit ifconfig auf 192.168.56.3 geändert werden und danach konnte über den „Host-Only Adapter“ über diese IP das Konfigurationsmenü auf Port 80 aufgerufen werden.
Parallel dazu kann über ssh root@192.168.56.3 auf die virtuelle Maschine zugegriffen werden.

Nach der Konfiguration und dem Reboot der VM wurde über den DHCP von Virtualbox die IP 192.168.56.101 vergeben.

Es ist so allerdings nicht möglich, den Knoten in das Community Netzwerk einzuhängen!
Die VM bekommt so kein Gateway ins Internet.
Dies funktioniert erst, nachdem in Virtualbox ein NAT-Interface für die VM eingestellt wird.
Dann funktioniert jedoch der SSH-Zugang nicht mehr, selbst dann, wenn als zweiten Netzwerk-Adapter ein Host-Only Adapter konfiguriert ist!

Das NAT-Interface läuft bei Virtualbox eindeutig auf der IP 10.0.2.0.
Wie kann der SSH-Zugang mit dropbear in dem x86-Image nun parallel auf 192.168.56.101 gelegt werden?

wusel · November 24, 2024, 2:34pm

Bei den meisten Communities.

Wieso? Bridge auf 192.168.1.254/24 konfigurieren und der Zugriff sollte tun. Aber ich nutzte straight KVM per virt-manager, kann zu VirtualBox nicht wirklich was sagen; too much hassle aus meiner Sicht.

Logisch. WAN steht für Wide-Area-Network, also muß das Interface in der VM ins Internet kommen.

Routing? Firewalling? Ferndiagnose hier schwierig.

Ah, Standard-Gluon nutzt LAN für den Config-Zugang, d. h. für den Config-Mode mußt Du (bei >1 Interface) über das 2. Interface den Config-Mode nutzen, dort muß dann die 192.168.1.0/24 hingehen. Oder so, ist jedenfalls jedesmal extrem nervig — wir nutzen in unserer FW daher für den Config-Mode immer das WAN-IF (1. Interface); den Port, an dem das Gerät i. d. R. mit dem Router verbunden ist.

lsmod · November 24, 2024, 2:36pm

Die Dateien sind aus dem Image gluon-DiVoNet-v2023.1.1-wireguard-139-x86-64.vdi extrahiert. Dafür wurde das Image einfach als „Festplatte“ in Virtualbox verwendet und über ein CD-Image von Knoppix gebootet und die „Festplatte“ ausgelesen.

Nun stellt sich jedoch die Frage was tatsächlich gestartet werden muß, um den Batman zum fliegen zu bringen?

Wenn man in die Prozeßliste der funktionierenden VM schaut, sieht man ziemlich viele Prozesse und es ist nicht klar was davon wirklich benötigt wird?

  PID USER       VSZ STAT COMMAND
    1 root      1276 S    /sbin/procd
    2 root         0 SW   [kthreadd]
    3 root         0 IW<  [rcu_gp]
    4 root         0 IW<  [rcu_par_gp]
    5 root         0 IW   [kworker/0:0-eve]
    6 root         0 IW<  [kworker/0:0H-ev]
    7 root         0 IW   [kworker/u2:0-ev]
    8 root         0 IW<  [mm_percpu_wq]
    9 root         0 SW   [rcu_tasks_trace]
   10 root         0 SW   [ksoftirqd/0]
   11 root         0 IW   [rcu_sched]
   12 root         0 SW   [migration/0]
   13 root         0 SW   [cpuhp/0]
   14 root         0 IW<  [netns]
   15 root         0 IW   [kworker/u2:1-ev]
   16 root         0 SW   [oom_reaper]
  232 root         0 IW   [kworker/u2:2-ev]
  233 root         0 IW   [kworker/0:1-wg-]
  362 root         0 IW<  [writeback]
  364 root         0 SW   [kcompactd0]
  369 root         0 IW<  [pencrypt_serial]
  371 root         0 IW<  [pdecrypt_serial]
  373 root         0 IW<  [cryptd]
  379 root         0 IW<  [kintegrityd]
  381 root         0 IW<  [kblockd]
  453 root         0 IW<  [ata_sff]
  479 root         0 SW   [watchdogd]
  567 root         0 IW<  [kworker/0:1H-kb]
  586 root         0 SW   [kswapd0]
  612 root         0 IW<  [acpi_thermal_pm]
  706 root         0 IW<  [iscsi_eh]
  708 root         0 IW<  [iscsi_conn_clea]
  721 root         0 IW<  [nvme-wq]
  723 root         0 IW<  [nvme-reset-wq]
  725 root         0 IW<  [nvme-delete-wq]
  739 root         0 SW   [scsi_eh_0]
  740 root         0 IW<  [scsi_tmf_0]
  743 root         0 SW   [scsi_eh_1]
  746 root         0 IW<  [scsi_tmf_1]
  750 root         0 IW   [kworker/u2:3-ev]
  767 root         0 IW   [kworker/u2:4-ev]
  820 root         0 IW<  [ipv6_addrconf]
  926 root         0 IW   [kworker/0:2-wg-]
  944 root         0 SW<  [loop0]
  947 root         0 SW   [jbd2/loop0-8]
  948 root         0 IW<  [ext4-rsv-conver]
  977 root         0 IW<  [ext4-rsv-conver]
 1170 ubus       940 S    /sbin/ubusd
 1172 root      1128 S    /bin/ash --login
 1203 root       816 S    /sbin/urngd
 1248 root      1532 S    /usr/sbin/haveged -F -w 1024 -d 32 -i 32 -v 1
 1322 root         0 IW<  [ena]
 1362 root         0 IW<  [ixgbe]
 1605 root         0 IW<  [cfg80211]
 1694 root         0 IW<  [bat_events]
 1925 logd       992 S    /sbin/logd -S 64
 2044 root      2144 S    {dnsmasq} /sbin/ujail -t 5 -n dnsmasq -u -l -r /bin/ubus -r /etc/TZ -r /etc/dnsmasq.conf -r /etc/ethers -
 2080 dnsmasq   2172 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
 2109 root       936 S    /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300 -T 3
 2358 root      2144 S    {hostapd} /sbin/ujail -t 5 -n hostapd -U network -G network -C /etc/capabilities/wpad.json -c -- /usr/sbi
 2372 network   4328 S    /usr/sbin/hostapd -s -g /var/run/hostapd/global
 2404 root       752 S    /usr/sbin/gluon-arp-limiter
 2480 root      1384 S    /sbin/netifd
 2705 root       832 S    odhcp6c -s /lib/netifd/dhcpv6.script -t120 br-wan
 2719 root      1120 S    udhcpc -p /var/run/udhcpc-br-wan.pid -s /lib/netifd/dhcp.script -f -t 0 -i br-wan -x hostname:Eitorf-Berg
 2741 root       832 S    odhcp6c -s /lib/netifd/dhcpv6.script -L -m30 -t120 br-client
 2896 root       772 S    /usr/sbin/micrond /usr/lib/micron.d
 2960 root       748 S    /usr/sbin/sse-multiplexd
 3154 root       972 S    /usr/sbin/uhttpd -f -h /lib/gluon/status-page/www -r Eitorf-Berg -x /cgi-bin -t 60 -T 30 -k 20 -A 1 -n 32
 3302 root      2112 S    /usr/sbin/dnsmasq -u root -i lo -p 54 -h -k -c 0 -r /var/gluon/wan-dnsmasq/resolv.conf
 3485 root      2144 S    {ntpd} /sbin/ujail -t 5 -n ntpd -U ntp -G ntp -C /etc/capabilities/ntpd.json -c -u -r /bin/ubus -r /usr/b
 3510 ntp       1124 S    /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p fd89:dea2:3c0b:1330::4 -p fd89:dea2:3c0b:1331::4 -p fd8
 3643 root       896 S    /usr/sbin/vnstatd --nodaemon
 4149 root         0 IW<  [wg-crypt-mesh-v]
 4652 root      1280 S    /usr/bin/respondd -d /usr/lib/respondd -p 1001 -g ff02::2:1001 -i mesh-vpn -g ff05::2:1001 -i br-client -

In der /etc/init.d gibt es ebenfalls eine Menge Startskripte, von denen direkt keines dem Batman zuzuordnen ist. Es sind immerhin 6 Skripte die für gluon stehen.

-rwxr-xr-x  1 root root 1,4K  2. Okt 2023  boot
-rwxr-xr-x  1 root root  846  2. Okt 2023  cron
-rwxr-xr-x  1 root root  33K  2. Okt 2023  dnsmasq
-rwxr-xr-x  1 root root  263  2. Okt 2023  done
-rwxr-xr-x  1 root root 5,8K  2. Okt 2023  dropbear
-rwxr-xr-x  1 root root  997  2. Okt 2023  firewall
-rwxr-xr-x  1 root root  226  2. Okt 2023  fstab
-rwxr-xr-x  1 root root  293  2. Okt 2023  gluon-arp-limiter
-rwxr-xr-x  1 root root  200  2. Okt 2023  gluon-core-reconfigure
-rwxr-xr-x  1 root root 1,7K  2. Okt 2023  gluon-ebtables
-rwxr-xr-x  1 root root  351  2. Okt 2023  gluon-radvd
-rwxr-xr-x  1 root root 1008  2. Okt 2023  gluon-respondd
-rwxr-xr-x  1 root root  435  2. Okt 2023  gluon-wan-dnsmasq
-rwxr-xr-x  1 root root 1,4K  2. Okt 2023  gpio_switch
-rwxr-xr-x  1 root root  362  2. Okt 2023  haveged
-rwxr-xr-x  1 root root 3,5K  2. Okt 2023  led
-rwxr-xr-x  1 root root 2,7K  2. Okt 2023  log
-rwxr-xr-x  1 root root  269  2. Okt 2023  micrond
-rwxr-xr-x  1 root root 2,7K  2. Okt 2023  network
-rwxr-xr-x  1 root root 1,1K  2. Okt 2023  socat
-rwxr-xr-x  1 root root  181  2. Okt 2023  sse-multiplexd
-rwxr-xr-x  1 root root 1,2K  2. Okt 2023  sysctl
-rwxr-xr-x  1 root root  662  2. Okt 2023  sysfixtime
-rwxr-xr-x  1 root root 3,2K  2. Okt 2023  sysntpd
-rwxr-xr-x  1 root root 1007  2. Okt 2023  system
-rwxr-xr-x  1 root root 5,9K  2. Okt 2023  uhttpd
-rwxr-xr-x  1 root root  125  2. Okt 2023  umount
-rwxr-xr-x  1 root root 1,4K  2. Okt 2023  uradvd
-rwxr-xr-x  1 root root  239  2. Okt 2023  urandom_seed
-rwxr-xr-x  1 root root  220  2. Okt 2023  urngd
-rwxr-xr-x  1 root root 1,8K  2. Okt 2023  vnstat
-rwxr-xr-x  1 root root 1,2K  2. Okt 2023  wpad

lsmod · November 24, 2024, 2:45pm

Es ist kein Problem KVM zu benutzen, wenn dafür eine nachvollziehbare Anleitung / Tutorial für diesen Anwendungsfall gegeben ist.
Wäre es in KVM einfacher die Netzwerkprobleme zu lösen?
Wie ist es mit dem Zugriff auf den WLAN USB-Stick?

Eigentlich nicht, denn das x86-Image arbeitet hier nur auf einer IP 10.0.2.0, die aber bei NAT mit Virtualbox irgendwie nicht mehr in das LAN kommt, sondern nur noch extern auf das Gateway nach draußen geht.

Es ist nicht ganz einfach Deinen Gedankengängen hier zu folgen.
Auf jeden Fall wäre es kein Problem einfach Euer x86-64 Image zu nutzen, um erst einmal zu einer funktionsfähigen Lösung zu kommen.
Hast Du bitte einen Link für einen Download?
(Freifunk Rheinland wäre hier im Prinzip immer noch regional zutreffend.)

Wofür steht hier übrigens der Begriff Offloader?
Wie gesagt ist das Wissen im Bereich Netzwerktechnik begrenzt.

https://wiki.bremen.freifunk.net/Anleitungen/Offloader/Was-ist-ein-Offloader

Das ist ein Mini-PC, Rasberry, Thin-Client Futro/Igel, der mit der Freifunksoftware primär nur eine Aufgaben hat. Er baut einen leistungsstarken VPN Tunnel zu einem Freifunkgateway auf. Ein Offloader kommt zum Einsatz, wenn mehr Bandbreite an einem DSL-Anschluss benötigt wird.

Batman ist für die Bridge des WLAN in das Gateway notwendig.
Der Offloader ist der Anteil der das VPN beim Transport der Daten erledigt?

lsmod · November 24, 2024, 3:16pm

Zur Zeit verliert sich der Thread in Detailproblemen einer alternativen Umsetzung ohne virtuelle Maschine …

Das primäre Problem ist wie man den WLAN-Stick an die virtuelle Maschine anbindet, so daß der Knoten arbeiten kann?

In Virtualbox kann der USB-Stick für die virtuelle Maschine freigegeben werden und dieser wird dann im Kernel-Log und mit lsusb in der virtuellen Maschine gesehen.
Gibt es eine bekannte Möglichkeit das gluon Image so zu erweitern, daß es mit dem USB-Stick arbeiten kann?

[ 3710.973081] usb 1-1: new high-speed USB device number 2 using ehci-pci

Bus 002 Device 001: ID 1d6b:0001 Linux 5.10.197 ohci_hcd OHCI PCI host controller
Bus 001 Device 002: ID 0cf3:9271 ATHEROS UB93
Bus 001 Device 001: ID 1d6b:0002 Linux 5.10.197 ehci_hcd EHCI Host Controller

lsmod · November 24, 2024, 4:01pm

Es ist möglich auf einem PC das Verzeichnis mit den Dateien aus dem x86-Image zu chrooten.
Allerdings scheitert alles bereits an dem Konzept mit dem ubus daemon von OpenWrt, der sich auf einem PC zwar starten läßt, aber danach dennoch nicht ohne weiteres zu funktionierenden daemons führt.
https://openwrt.org/docs/techref/ubus

wusel · November 24, 2024, 4:03pm

Wie gesagt, nimm Image im Config-Mode, brctl show, und nach Config-Mode nochmal brctl show. (Console ist ja jeweils ohne PW zugänglich.)

Über das Interface in br-setup mußt Du per 192.168.1.1 drauf, auf das Interface in br-wan muß Dein NAT konfiguriert sein.

lsmod · November 24, 2024, 4:15pm

Im Betrieb zeigt brctl show

bridge name	bridge id		STP enabled	interfaces
br-wan		7fff.080027d1e259	no		eth0
br-client		7fff.0800277f6029	no		bat0
							local-port

und ifconfig

bat0      Link encap:Ethernet  HWaddr 08:00:27:7F:60:29  
          inet6 addr: fe80::a00:27ff:fe7f:6029/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:15 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:600 (600.0 B)  TX bytes:152 (152.0 B)

br-client Link encap:Ethernet  HWaddr 08:00:27:7F:60:29  
          inet6 addr: fe80::a00:27ff:fe7f:6029/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:864 (864.0 B)  TX bytes:3920 (3.8 KiB)

br-wan    Link encap:Ethernet  HWaddr 08:00:27:D1:E2:59  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fed1:e259/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:167 errors:0 dropped:0 overruns:0 frame:0
          TX packets:117 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:34748 (33.9 KiB)  TX bytes:19805 (19.3 KiB)

eth0      Link encap:Ethernet  HWaddr 08:00:27:D1:E2:59  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:167 errors:0 dropped:0 overruns:0 frame:0
          TX packets:117 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:37086 (36.2 KiB)  TX bytes:19805 (19.3 KiB)
          Interrupt:9 Base address:0xd020 

gre       Link encap:Ethernet  HWaddr D6:07:58:36:4F:8E  
          inet6 addr: fe80::d407:58ff:fe36:4f8e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1382  Metric:1
          RX packets:118 errors:0 dropped:15 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12086 (11.8 KiB)  TX bytes:5166 (5.0 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:324 (324.0 B)  TX bytes:324 (324.0 B)

local-node Link encap:Ethernet  HWaddr 16:42:CA:FE:BE:EF  
          inet addr:10.81.32.32  Bcast:10.81.47.255  Mask:255.255.240.0
          inet6 addr: fdd3:5d20:b5dd:fe00::1/128 Scope:Global
          inet6 addr: fe80::1442:caff:fefe:beef/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:36 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2812 (2.7 KiB)  TX bytes:2290 (2.2 KiB)

local-port Link encap:Ethernet  HWaddr 08:00:27:7F:60:29  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2290 (2.2 KiB)  TX bytes:2812 (2.7 KiB)

mesh-vpn  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.3.1.57  P-t-P:10.3.1.57  Mask:255.255.0.0
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:136 errors:0 dropped:0 overruns:0 frame:0
          TX packets:72 errors:1 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:21916 (21.4 KiB)  TX bytes:11796 (11.5 KiB)

primary0  Link encap:Ethernet  HWaddr 42:77:26:E3:5F:73  
          inet6 addr: fe80::4077:26ff:fee3:5f73/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1532  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:4940 (4.8 KiB)

Davon läßt sich jedoch nur br-wan klar zuordnen und der Rest verliert sich in den Geheimnissen von gluon / OpenWrt.
Wohin die IP-Adressen des local-node zeigen ist ebenso schleierhaft. Diese lassen sich vom host aus nicht erreichen.

Beide Netzwerkadapter in Virtualbox sind auf jeden Fall konfiguriert.

Die Reihenfolge der beiden Netzwerkadapter ist nun jedoch anders herum!
Der 1. Adapter ist NAT und der 2. Adapter die Host-Bridge

wusel · November 24, 2024, 6:56pm

Woher kommt diese IP, ist das vboxnet0? Das Netz der Community nutzt …

›next-node‹-Adressen, darüber kann ein Client im Freifunk-Netz auf die Statusseite des Knotens, mit dem er verbunden ist, zugreifen ⇒ Gluon-Essentials … Ein Gluon-Knoten hat prinzipiell kein IPv4 im Freifunk-Netz, nur IPv6; diese ›next-node‹-Adressen sind identisch auf jedem Knoten mit der gleichen Firmware und gegen Leaking ins Freifunk-Netz per *tables abgeschottet. Wie gesagt, Gluon-Essentials …

… ohne grundlegende Kenntnisse, wie ein Gluon-Netz (und insbesondere eine OpenWrt-Gluon-Firmware) funktioniert, ist das weder einfach verständlich noch einfach ›zu Fuß‹ nachzubauen. Wobei in batman-Netzen die ›next-node‹-Adressen AFAICS auch verzichtbar für die Funktion sind (in gerouteten Netzen könnten dies die Default-Gateway-Adressen sein).

Yepp, wie gesagt, Sonderbarkeiten des (unmodifizierten) Gluon-Config-Modes.

… aber nicht zielführend, wie Du ja selbst schreibst.

Vermutlich gar nicht; die FW wird keine Treiber für den USB-Stick mitbringen, zudem nutzt Gluon nur ›fest verbaute‹, beim allerersten Start vorhandene, WLAN-Geräte — und wie stabil ein reingereichter USB-Port ist, dunno. Vor ~10 Jahren kam ein in VBox emuliertes Windows 8 jedenfalls nicht mit USB-Kamera und -Headset in Lync nutzbar klar.

Nein. Du kannst die Community-Config nutzen und Dir ein entsprechendes Image bauen, aber USB-WLAN-Adapter werden von den Gluon-Setup-Skripten prinzipiell ignoriert. Auch das kannst Du – mit Kenntnissen in Lua, sh und C++ – vermutlich ändern.

Für mich (lies: auch remote) ja, da ich weiß, wie KVM out of the box funktioniert. Andere Hypervisoren nutze ich nicht.

Dann fehlen Dir (Gluon-) Hintergründe, die ich voraussetze, sorry.

Sure; aber Du mußt halt nur die Gluon-Configmode-Eigenheiten in Deinem Virtualisierungssetup abbilden, dann tut’s auch mit Standard-Gluon:

Das hast Du ja mittlerweile auch erkannt, daß das Interface-Setup, welches Du für den Config-Mode genutzt hast, nicht das ist, was im Freifunk-Mode genutzt wird. ›Oder so‹, beim Hardware-Knoten muß man das WAN-Kabel (also das ins lokale Netz zum Internet-Router) vom WAN- in einen LAN-Port umstecken für den Config-Mode und nach dem Reboot wieder zurück. Analog mußt Du wohl die Zuordnung in Deiner Virtualisierungslösung (host-only <> NAT) ändern.

Gateway:

root@ngw-ber01 ~ # brctl show br01
bridge name	bridge id		STP enabled	interfaces
br01		8000.02caffee0170	no		l2tp127-127
							l2tp179-179
							l2tp18-18
							l2tp425-425
    						l2tp489-489
	    					l2tp513-513
		    				l2tp573-573
			    			l2tp79-79
				    		l2tp82-82
					    	l2tp832-832
							l2tp896-896
    						l2tp899-899
    						l2tp919-919
	    					l2tp92-92
		    				l2tp93-93
root@ngw-ber01 ~ # batctl bat01 if
br01: active
t01-ng-ber02: active
t01-ng-fra01: active
t01-ng-fra02: active
t01-map03: active

Gluon-Knoten:

root@33332-Schalueckstr-107-8e8b:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-client		7fff.744401748e8b	no		eth0
							bat0
							client1
							owe1
							client0
							owe0
							local-port
br-wan		7fff.5692c93e8760	no		eth1
root@33332-Schalueckstr-107-8e8b:~# batctl bat0 if
primary0: active
mesh0: active
mesh1: active
mesh-vpn: active

Sprich: Du brauchst auf dem simulierten Knoten eine Brücke, die das batman- und das WLAN-Interface bridged. Dem batman-Interface muß dann das VPN-Interface hinzugefügt werden. Das »mesh-vpn«-Interface wird durch »tunneldigger«, »fastd« oder »Wireguard-over-VXLAN« erzeugt, je nach Firmware, und der Tunnel muß zu den Gateways der Community aufgebaut werden, alle Daten dazu stehen bei einem konfigurierten(!) Knoten unter /etc/config. Wenn alles klappt, bekommt ein Client am WLAN eine IPv4-Adresse vom Gateway der Community.

Das zu Fuß zusammenzubauen ist, wie gesagt, kein Hexenwerk, und für jemanden, der tief in die Materie einsteigen will, eine tolle Methode, sich die Hände schmutzig zu machen und dabei auch den einen oder anderen Finger zu brechen

Alternativ versucht man, daß WLAN-Interface auf dem Host in eine Bridge zu packen, diese Bridge in die VM durchzureichen und in der Gluon-VM dieses Interface in br-client zu haben — könnte funktionieren, siehe br-client oben (da ist ja LAN (eth0) und WLAN (client0, client1 für 2,4 bzw. 5 GHz) auch einfach nur gebridged).

Wer das ansonste nur möglichst problemlos nutzen möchte, nimmt einen 25€-Mobilrouter, klatscht da die Firmware drauf und ist glücklich. IMHO, YMMV.

Viel Spaß noch am Gerät jedenfalls

adorfer · November 25, 2024, 2:36am

Ich habe Schwierigkeiten nachzuvollziehen, was hier überhaupt das Problem ist.
Die normalen Gluon-x64 images laufen problemlos in Virtual Box. Und auch das Durchreichnen von USB Wifisticks in die VM plus ggf Nachladen von passenden Kernel Modulen aus dem jeweilig dazugehörigen Opkg-Tree bei Openwrt. org funktioniert, notfalls per manueller Anlieferung der Dateien, falls der opkg-feed falsch eingetragen ist.
So Setups habe ich jahrelang zu Debug/Vergleich, aus unterschiedlichen Communities auf meinem daily driver Laptop gehabt, bis ich das dann doch mal ins Promox im Homelab verschoben habe.
Was ich aber hier im Threadzu sehen glaube, wenn schon das Verständnis für den guon Setup Modus, lokales ssh und wie man das sinnvoll zu einem Browser, und sei es eine „Browser live CD“-VM bridged, dann sehe ich ziemlich schwarz dafür, diese Dinge irgendwie wie vorgeschlagen direkt auf dem Host-OS nachzubauen.
Ein wichtiger Aspekt von gluron und darauf basierende Netzwerken ist, dass der Autoupdater funktioniert.
Als, dass bei Änderungen in der Backend-struktur per Auto Update oder akuten Sicherheitsproblemen neue Firmware vollautomatisch den ganzen Netz ausgerollt werden kann.
Denn gerade diese handgebriegelten Setups bleiben mit zu sehr großen Risiko dann zurück.
Vom Risiko durch fehlende oder falsche ebitable rules auf dem Client-L2 Netz mal ganz zu schweigen. Dort können mehrere Communitys mit mundgklöppelten Raspi setups ein Lied singen, wo sich selbst langjährig Freifunkenden Anmins sich und alles anderen ein Bein gestellt und das noch nichtmal binnen Monaten bemerkt haben. zB durch ungewolltes Routing wegen vergessener HopPenalty.

adorfer · November 25, 2024, 7:05am

Wenn der Kntoen auch einen VPN-Tunnel aufbauen sollte, dann sollte man auch mit Routing-Tabellen und (spätenstens wenn auch IPv6) funktionieren soll, FW-marking funktionieren. Wenn auf dem Client-Netz mehr als nur ein (ewig fixes) /64 von den Supernodes per Radvd announced wird, dann vereinfacht man sich mE das Leben mit Network-Namespaces erheblich.

https://www.howtogeek.com/devops/what-are-linux-namespaces-and-what-are-they-used-for/

lsmod · November 25, 2024, 1:24pm

wusel:

lsmod:
br-wan    Link encap:Ethernet  HWaddr 08:00:27:D1:E2:59  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
Woher kommt diese IP, ist das vboxnet0? Das Netz der Community nutzt …

Nein - das ist offenbar die Gateway-Adresse, so wie diese für die virtuelle Maschine abgebildet wird.

Ist dies bei einer KVM Virtualisierung einfacher und somit besser gelöst?

Gibt es eine schönes Bildchen wie das oben für die Netzwerk-Dummies, um eine Chance zu haben das Konstrukt der „Essentials“ zu verstehen?

Darauf läuft es hinaus, wenn sich sogar Experten wie Du damit schwer tun, einen grundlegenden Nachbau der Funktionalität von gluon in einer Standard GNU/Linux Distribution anzugehen.

Hinzu kommt die fehlende Einbindung eines WLAN in dem x86 Image.
Dies scheint weder vorgesehen zu sein, noch hat dies bislang jemand erfolgreich gemeistert.
Inzwischen stellt sich die Frage wozu dieses Image überhaupt gut ist …

Danke für Deinen Support und Deine Bestätigung.

Aber nur wenn das Gesamtkonzept von gluon erst einmal hinreichend nachvollzogen worden ist.

Darum die Anfrage hier in diesem Forum.

Ist es damit schon getan?
Eher nicht, denn der WLAN-Stick muß ja dafür erst einmal richtig konfiguriert sein.
Standardmäßig wird ein WLAN-Stick immer als Client und nicht als AP verwendet.

Es ist an der Zeit die eigenen Grenzen zu erkennen.
Das Gesamtkonstrukt entspricht derzeit leider immer noch einem Hexenwerk, insbesondere wenn noch die Nettigkeiten von Virtualbox hinzu kommen.
Der Lerneffekt wäre allerdings wirklich gigantisch!

Dein Hinweis doch besser einen kompatiblen Router zu verwenden wird daher überdacht und dankend angenommen.

Damit hast Du bereits ein schönes Schlußwort gefunden. Danke!

lsmod · November 25, 2024, 1:33pm

Nenne es doch einfach Inkompetenz.

Das war die Antwort die erhofft worden ist.
Vor allem mit einer nachvollziehbaren Beschreibung dazu, wie man dies bewerkstelligt?

Damit erklärt sich nun doch noch der Sinn des x86 Image.

Danke für die offene Einschätzung!
Somit werden für solche Experimente, wie sie in diesem Thread erfragt werden, deutlich mehr Wissen und Erfahrung vorausgesetzt.

Das Argument ist ebenfalls nachvollziehbar.

adorfer · November 25, 2024, 1:49pm

Einen Linuxhost einer standard-distro „zu Fuß“ ins Freifunk zu bringen, samt Wifimesh: Kann man tun. wie Wusel schreibt: eine tolle Übung auf Layer 2+3.

(Den Thread jetzt abdrehen zu lassen: „Wie installiere ich ein Gluon in Virtualbox“: Das doch nicht das, was initial gefragt war. Denn dazu gibt es ja neben mehreren Parallehtreads auch einen Haufen Wiki-Seiten.)

Vom Zeitaufwand oder der erhofften Resourceneinsparung her lohnt es sich nicht. Von der potentiellen Betriebsgefahr für die betroffene FF-Community/L2-Domain mal ganz abgesehen (als Supernode-Admin würde ich mir solche Experimente in produktiven Domains verbieten, aber YMMV):

Lerneffekt und anschließende Wertschätzung/Respekt für den Gluon-Stack (und seine für selbstverständlich gehaltenen Features) sind jedoch sicher.

wusel · November 25, 2024, 6:10pm

Nope, recht viel Text, was aber auch Grundlagen wie ›was ist B.A.T.M.A.N. Advanced und warum baut man überhaupt landesweite Layer-2-Netze?‹ voraussetzt.

Gluon ist im Prinzip ›nur‹ ein Satz von OpenWrt-Paketen — allerdings zusammengeschnürt als OpenWrt patchendes System, um OpenWrt für den Einsatz in (Gluon-basierten) Freifunk-Netzen zu optimieren. Aus 10 km Flughöhe geht es nur darum, WLAN-Interfaces mittels batman-adv.ko und Tunneln ortsübergreifend zu einem Layer-2-Netz, und damit einer BSS, zusammenzukleben. (Ja, es gibt auch Ansätze für L3-Freifunk-Netze auf Gluon-Basis; Mainstream ist weiterhin L2.)

Genau.

Nö, die stellt sich allgemein nicht. Stichwort »Offloader«, z. B. um das Freifunk-Clientnetz in gemanagten Umgebungen als (weitere) SSID auszustrahlen.

Einerseits wurde Gluon deshalb entwickelt, so flasht man einen (Gluon-kompatiblen) OpenWrt-Router auf Gluon um und hat einen Freifunk-Knoten. Virtualbox hat damit wohl eher weniger zu tun, eher Unkenntnis des Gluon-Setup-Procederes bzw. Adaption dessen auf VB (›Umstecken‹ des ›Kabels‹ von LAN nach WAN).

Wie @adorfer ja schrieb, geht das mit dem Durchreichen wohl (auch) in Virtualbox. Aber auch da brauchst Du gewisse Grundkenntnisse im Umgang mit OpenWrt (Pakete nachinstallieren; sind die benötigten für Deinen FW-Build bei der Community überhaupt verfügbar?) und Wissen, wie Gluon (in der jeweiligen Version, vgl. readthedocs-Link oben) die Netzkonfiguration zusammenbaut. Wenn Du soweit bist, solltest Du IMHO Kontakt mit der Community aufnehmen und Deine Mitarbeit anbieten — typischerweise gibt’s lokal fast immer Nachwuchsbedarf

Naja, Freifunk ist auch ein experimentelles Medium; aber es stimmt natürlich, macht man da Unsinn, hat man schnell sein heimisches LAN ins Freifunk-Netz gebridged oder bereitet den Admins extra Arbeit durch sonsige Fehlfunktionen. Kontakt zur lokalen Freifunk-Gruppe sollte vor solchen Experimenten bestehen …

lsmod · November 27, 2024, 7:59am

Doch - im Prinzip schon.
Wie am Anfang beschrieben wurde, läuft das x86-Image von DiVoNet in einer virtuelen Maschine und ist bereits als Knoten sichtbar, allerdings ohne WLAN.
Es geht als primär darum, wie ein WLAN-Stick an diese virtuelle Maschine angebunden werden kann, damit das gewünschte Ziel erreicht wird.

Dies ist die nachvollziehbare Sichtweise von einer anderen Seite her.

Dies stellt die dritte Art und Weise dar dieses Thema zu betrachten.

adorfer · November 27, 2024, 8:16am

Das ist zumindes für mich ein Software-Problem, keines der Hardware.
Also entweder Gluon, weil Du das richtige Kernelmodul zu Deinem Kernel nicht findest.
Oder nicht weißt, wie man Kernelmodule läd. (was ich mal auf Grundlage Deines Nicks ausschließen möchte)
Oder weil Du das Durchreichen von USB-Resourcen in Virtualbox von VM-Guest auf HostOS nicht hinbekommst.
Oder weil Oracle (mal wieder) irgendwas in dem USB-Stack von Virtualbox kaputtgemacht hat in der von Dir verwendeten Kombination aus Guest- und Host-OS.