Gluon on VMWare does not get DHCP on WAN interface

[nmaas87]

As written here (https://forum.freifunk.net/t/bug-in-gluon-0-7-2-x86-vmware/7801), I got an 0.7.2. version of the Freifunk Trier VMWare Image (https://github.com/freifunktrier/firmware_store/blob/master/firmware/stable/factory/gluon-fftr-0.7.2-x86-vmware.vmdk) - which does, after inital setup - not get an dhcp lease on the wan (eth1) interface. I left everything in the configuration on the website on default, activated mesh_via_vpn and checked in the vpn key - which was done successfully. however, my appliance can't get an ip on the wan interface and does not connect to the internet. same thing with the image from ggrz. Any ideas?
Can reproduce the error on Workstation 11 as well as on VMWare ESXi 4.1 - with multiple gluon 0.7.2 Versions. Wan Interface, as descibred in the core config of gluon is correctly configured to be eth1, udhcpc eht1 does not give back an ip. Using the UNOFFICAL gluon 0.3.3 image from IT-KL.eu (https://www.it-kl.eu/2015/08/gluon-x86-unter-vmware/ ) does work correctly in the same configuration and enviroment.

[jplitza]

Could you verify the layer 2 connectivity of that interface, i.e. use something like ping6 -I eth1 ff02::1 and see if your host responds? Also, more details about the network setup of your VMWare setup would probably be needed.
Also, what Gluon versions do those community version numbers correspond to?

[nmaas87]

Hi there,

ping6 -I eth1 ff02::1does only give me an ping6: sendto: Operation not permitted.
Same for eth0. However, an ping6 on br-client, br-wan and bat0 give me back an answer.
The system also gives out IPv6 addresses on eth0, the client network - but none ipv4, due to the fact that it is not online.

Network:
Freifunk VM, eth0 (E1000) for client port to vlan 5
Freifunk VM, eth1 (E1000) for wan port to vlan 1
Internal pfSense, which gives LAN and dhcp on vlan 1
Internal pfSense, which takes WAN on vlan 2
VMWare ESXi 4.1, attached with trunk port to switch
Switch with trunk port to VMWare
Switch with vlan 2, WAN access is attached here
Switch with vlan 1, LAN port, Freifunk is attached here with Uplink
Switch with vlan 5, Client port of Freifunk

I can plug my notebook into vlan 1, and it gets an IP Adress succesfully - so trunking, vlan and all is working. I can plug it into vlan 5, and it gets an autogenerated IPv6 address from Freifunk Client Port.
However, the freifunk vm does not get an WAN IP...

In easy, Freifunk is attached in that way:
WAN with dhcpdv4 ----- eth1 (Freifunk) eth0 ------ Client Laptop

The Image is based on Gluon 2015.1.2.

[neocturne]

I've confirmed this issue. It is caused by Gluon explicitly setting the MAC address of br-wan (to avoid address conflicts in the case mesh-on-WAN is used). VMware blocks unknown MAC addresses though...

This is a regression introduced in v2015.1.2.

[adlerweb]

For ESXi: Did you try to allow promisc mode in VMWares network security settings [1]? Gluon uses a network bridge (br-wan) for WAN causing the interface to enter promic mode - this however is forbidden in VMWares default configuration. This also affects static configuration and is not related to DHCP.

[1] http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004099

[Little-Ben]

nmaas87, this is Freifunk Westpfalz.

Our official repositories lives only under:
https://github.com/freifunk-westpfalz/

Official Downloads solely via:
http://westpfalz.freifunk.net/firmware/
or
http://download.westpfalz.freifunk.net/

Please do not announce other locations as official references!

[nmaas87]

@adlerweb That was the right hint. I got it working by enabling promiscuous mode on the ESXi Software Switch. However, it would be better if there could be a software-fix in the Freifunk Firmware, as promiscuous mode is more of an work-around and not secure, if I recall correctly.

@Little-Ben Sorry, I rewrote the issue and stated unofficial, as well as removing the reference to Freifunk Westpfalz.

[nmaas87]

Ok, promiscuous mode does not solve the problem completly. After enabling it, br-wan got an ip address and vpn and everything worked (eth1). On eth0 (client net), I also got an client ip from the net and got access to the internet. However, it turned out to be VERY slow ( In terms of loading www.google.de in about one minute... - or even dropping the connection while accessing other sites like www.web.de ).
On my console, I found the message
br-wan: recveived packet on eth1 with own address as source address
repeated in milisecond steps, spamming the console.
And sometimes something like net_ratelimit: 77 callbacks supressed.
I don't know wheter that is because of the promiscuous mode, however, it seems like a) the VPN network already got an host with the same mac address, or b) I'm somehow shorting the Freifunk net at my end?
I can however guarantee, that I only got eth1 on my WAN end online and eth0 on a own switchport and they never connect at any point... And that the wan interface br-wan is seeing its own source address on the wan port (eth1) is somehow funny.

Anyhow, something is still broken and I'll let the appliance switched off until further advice.

[neocturne]

@nmaas87, could you post the complete outputs of ip a, brctl show and batctl if?

[nmaas87]

@neoraider Will do. Is there any easy way to access that box from wan/lan interface? Can I enable ssh login via console? (Would make things easier) ( I think I will have time to get the outputs this evening :))

[dracoTrier]

sure, during config-mode, you can enable ssh and set password or ssh key for login.

[nmaas87]

@neoraider Okay, now comes the entertaining stuff: I installed the VM again from scratch, and this time, I did got errors on duplicate MAC addr on the client site (eth0). Turns out the VM fryed on of the FFTR Supernodes due to MAC addr collision. So I shut it down for good. Somehow the VM got the same MAC as the supernode - however, the ones randomly generated by VMWare on eth0 and eth1 are not identical to the Supernode Addresses and should not generated this problem...

[dracoTrier]

my conclusion: current gluon x86vm ist buggy. Needs more testing.