-
Notifications
You must be signed in to change notification settings - Fork 325
Gluon on VMWare does not get DHCP on WAN interface #496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Could you verify the layer 2 connectivity of that interface, i.e. use something like |
Hi there, ping6 -I eth1 ff02::1does only give me an ping6: sendto: Operation not permitted. Network: 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. In easy, Freifunk is attached in that way: The Image is based on Gluon 2015.1.2. |
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. |
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. |
nmaas87, this is Freifunk Westpfalz. Our official repositories lives only under: Official Downloads solely via: Please do not announce other locations as official references! |
@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. |
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 ). Anyhow, something is still broken and I'll let the appliance switched off until further advice. |
@nmaas87, could you post the complete outputs of |
@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 :)) |
sure, during config-mode, you can enable ssh and set password or ssh key for login. |
@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... |
my conclusion: current gluon x86vm ist buggy. Needs more testing. |
@nmaas87 as already said on the forum: I don't think this would help much. It could be possible to get rid of the bridge on the WAN interface (but this would make switching mesh-on-wan a nightmare), but since we are using L2-Routing it is not really possible to avoid promisc on the LAN interface |
@adlerweb That is ok, I found out that you can enable promisc mode on an "per interface" base instead of the whole switch. Which is ok by me :). |
Is it possible that your image was not clean when you experienced the MAC collisions? Gluon derives all MAC addresses from the address of the LAN interface (eth0) on first boot. If the image has already been booted once, it should not be migrated to another host, as the MAC addresses won't be regenerated. |
It is possible for the MAC collisions on WAN, 2015-09-23 2:12 GMT+02:00 Matthias Schiffer notifications@github.com:
|
I currently see three options to setup the WAN MAC address:
My current plan is keeping the current solution 1 for Gluon 2015.2, and switching to 2 as soon as #284 is solved. |
I think the plan is reasonable. |
On VMware ESXi you need an additional setting when using promiscuous mode, if vSwitch has more than one phys. NIC connected: "Net.ReversePathFwdCheckPromisc" must be set to 1. You will find it on Configuration - Software - Advanced Settings. |
@FFS-Roland Perfect Answer. I tried this now with 0.8.4 Gluon (from Freifunk Trier) - worked like a charm 👍 |
I documented the whole thing on https://www.nico-maas.de/?p=1320 :). Maybe the helps someone in the future. |
Trier 0.8.4 is gluon 2016.1.6-3-g9300421, it's just 2016.1.6 + ee597c6 + Webinterface-color-patches |
830440d nodogsplash: Backport Version 4.0.1. (freifunk-gluon#494) a93e684 alfred: Merge bugfixes from 2019.3 6ea9e9b batctl: Upgrade hardif settings patches to upstream version d65d6f1 batctl: Merge bugfixes from 2019.3 9d559fd batman-adv: Merge bugfixes from 2019.3 784ae0e Merge pull request freifunk-gluon#496 from ecsv/batadv-for-19.07
As a partial fix to #496, do not touch the MAC address of the WAN interface when using VXLANs (as only the MAC address of the VXLAN interface matters to batman-adv).
A partial fix for this issue now exists in #2015. |
As a partial fix to #496, do not touch the MAC address of the WAN interface when using VXLANs (as only the MAC address of the VXLAN interface matters to batman-adv).
FWIW, this also has some unfortunate side-effects: now the MAC can change when switching between a legacy non-vxlan domain and a modern vxlan domain. It would be better if the MAC would be consistent in all our domains, even if that MAC might not be the one printed on the box. |
That is unfortunate, but at some point the migration needs to happen if we want to fix this at all. Support for non-VXLAN domains will be dropped from Gluon eventually, at which point things will be consistent again. |
Oh, that's interesting news. We don't really have plans currently for changing our legacy domain (and our numbering scheme would make it hard to do so...).
It would have helped if we could configure this in the site.conf, then the migration can be independent of whether a domain is using vxlan or not. But I guess that's water under the bridge at this point. |
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.
The text was updated successfully, but these errors were encountered: