Bug in gluon-0.7.2-x86-vmware?

Hallo liebe Community,

obwohl ich den Freifunk schon länger kenne und mich seit 2006 schon aktiv mit OpenWRT beschäftige und die ein oder andere Appliance auf der Basis erstellt habe, bin ich jetzt erst aktiv zur Community dazu gekommen. Mein erstes Projekt soll sein auf verschiedenen Veranstaltungen Freifunk anzubieten. Da ich vor Ort immer eine größere Menge an dummen Accesspoints (dienen nur als Schnittstellen Wandler Kupfer->Luft ;)) ausrolle, wollte ich auf dieser Basis nun Freifunk anbieten. Natürlich entfällt damit in jedem Fall die Meshing Funktionalität, aber in dem Projekt geht es erstmal nur darum den Besuchern freies Internet zu bieten :slight_smile: . Als Basis sollte dazu ein VMWare ESXi 4.1 Server dienen, der die entsprechende Firmware (hier:https://github.com/freifunktrier/firmware_store/blob/master/firmware/stable/factory/gluon-fftr-0.7.2-x86-vmware.vmdk) hostet und damit als großer, virtueller Freifunk Router dient.

Die Einstellungen sind relativer Standard:
VMWare Appliance als „Linux Other 32 Bit“, 2x E1000 bzw Flexibel (beides geht) Ethernet Interface. Eth0 ist das Client Netz, Eth1 ist der WAN Uplink, LSI Logic Controller für die Platte und das entsprechende Image habe ich oben verlinkt. Nach dem Boot kommt auch korrekt auf eth0 das Client Interface hoch, ich kann mit einem externen Laptop auf 192.168.1.1 gehen, den Router einrichten und rebooten. Soweit alles ok. (Standard Einstellungen, Mesh VPN aktivieren, Key ans Team nach Trier schicken, die habens eingetragen → Alles gut).
Nach dem nächsten Boot (nun nicht mehr im Config Mode) kommt dann das Problem: Das System kriegt über eth1 einfach keine DHCP Adresse: br-wan kriegt nichts, das System kommt aufs hauen nicht ins Netz - und damit funktioniert nichts. Das Problem tauchte bei Version 0.7.2 auf, sowohl bei Trier als auch beim Freifunk ggrz auf (die habe ich nur als Beispiel zum Vergleich genommen, um zu sehen ob es vielleicht ein Problem ist was Versionsspezifisch auftritt).

Das Problem ist in ESXi 4.1 sowie in der Workstation 11 Variante von VMWare nachvollziehbar.

Mit der exakt gleichen Konfiguration auf dem VMWare Server und der gluon-0.3.3 von IT-KL.eu (https://www.it-kl.eu/2015/08/gluon-x86-unter-vmware/ ) tritt das Problem NICHT auf: Nach dem Reboot kriegt die Kiste erfolgreich eine WAN IP. Weiter gehts von dem Punkt nicht, weil ich den VPN Key nicht weitergegeben habe (wollte die Leute wegen diesem Test nicht belästigen :/!)

Habt ihr eine Idee woran dieses Problem liegen könnte?
Kann jemand anderes den Fehler reproduzieren?
Stell ich mich eventuell nur etwas ungeschickt an, oder ist das wirklich ein Bug im Image (Ideale Antwort: Wo und wie kann mans reparieren?)

Vielen Dank,

Nico

Ich habe zwischenzeitlich ein Issue in Gluon geöffnet: Gluon on VMWare does not get DHCP on WAN interface · Issue #496 · freifunk-gluon/gluon · GitHub
Es stellte sich heraus dass der Bug wirklich existiert.
Ein Workaround ist das aktivieren des promiscuous Modes des ESXi Switches.
Bitte vorher informieren, promiscuous Mode ist etwas unschön…

…ohne Promisc kann man aber keine Bridge machen - da wird man nicht drum herum kommen. Am WAN könnte man sie mit größerem Aufwand eventuell wegbasteln (was aber Mesh-on-WAN unmöglich machen würde), am LAN ist es nahezu unmöglich darauf zu verzichten. Freifunk arbeitet meist auf Layer 2, der Router muss also auf alle Adressen reagieren können.

Ich gehe davon aus, dass MoW/MoL nur im promiscous Mode sinnvoll nutzbar ist.
Auch da kann man sicher wieder was für bauen, dass Meshing auf dem Interface dann halt nicht geht. Macht den Code dann aber auch nicht schlanker.

Man kann promisc auch auf „Interface only“ Basis aktivieren, nicht nur auf dem ganzen Switch. Das macht das ganze schon besser. Allerdings ist in der Zwischenzeit ein weiteres Problem aufgetreten, was dafür sorgt dass das alleinige anschalten der VM schon dafür sorgte, dass ein Supernode per Kernel Fault / Reboot abgestürzt ist (Duplicate MAC die nicht sein dürfte…). Daher - es gibt noch weitere Bugs in 0.7.2 x86 vm und der Einsatz kann von meiner Seite im Moment nicht empfohlen werden.