Gesucht: Howto für Grundinstallation gluon-vmware-x64

und den einen oder anderen Nachbarn im 10.190er Freifunk Netz sehe ich ja auch …

root@sogo:~# arp -a
ipizza (10.0.0.120) at 00:0c:29:b0:0a:6b [ether] on ens192
? (10.190.0.81) at 02:00:39:01:08:01 [ether] on ens224
? (10.190.0.11) at 02:00:39:01:01:01 [ether] on ens224
? (10.190.0.8) at 02:00:39:01:08:00 [ether] on ens224
root@sogo:~#

Das 10.0.0.0/24 Netz ist mein privates Intranet.

und meine Interfaces sehen auch sinnvoll aus.

root@sogo:~# ifconfig
ens192 Link encap:Ethernet HWaddr 00:0c:29:a5:4c:28
inet addr:10.0.0.124 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fea5:4c28/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:35159 errors:0 dropped:0 overruns:0 frame:0
TX packets:34866 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24215757 (24.2 MB) TX bytes:5239184 (5.2 MB)

ens224 Link encap:Ethernet HWaddr 00:0c:29:a5:4c:32
inet addr:10.190.54.29 Bcast:10.190.63.255 Mask:255.255.192.0
inet6 addr: fd21:b4dc:4b01:0:20c:29ff:fea5:4c32/64 Scope:Global
inet6 addr: fd21:711::20c:29ff:fea5:4c32/64 Scope:Global
inet6 addr: fe80::20c:29ff:fea5:4c32/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8236 errors:0 dropped:0 overruns:0 frame:0
TX packets:261 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:575204 (575.2 KB) TX bytes:24252 (24.2 KB)

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:5644 errors:0 dropped:0 overruns:0 frame:0
TX packets:5644 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:781061 (781.0 KB) TX bytes:781061 (781.0 KB)

root@sogo:~#

Man kann übrigens Beiträge editieren und ergänzen ;).

Kannst du denn das Gateway pingen? Ist die IP per DHCP vergeben?

Das hatte ich schon erwähnt:

  • Das Default GW antwortet nicht auf ping
  • Die Adressen auf dem Interface ens224 sind per DHCP bezogen.

Ich bekomme, wie gesagt, noch nicht einmal eine Antwort vom DHCP Server. Wobei … hier sind DHCP Server und Default GW identisch. Das ist recht ungewöhnlich. Selbst in paranoiden Sicherheitsumgebungen gibt mindestens der DHCP eine Antwort ;- )

Kannst du per V6 den Knoten oder das Gateway pingen? Ich fürchte, sonst ist das ein Fall für die Stuttgarter Admins. Du könntest sonst mal ein Image einer anderen Community testen, um zu schauen, ob das Problem in deiner Konfiguration liegt, oder wirklich an dem Gateway.

Da musst Du mir ein wenig auf die Sprünge helfen. Hier die IPv6 Routing Tabelle

root@sogo:~# netstat -anr6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
fd21:711::/64                  ::                         UAe  256 0     0 ens224
fd21:b4dc:4b01::/64            ::                         UAe  256 0     0 ens224
fe80::/64                      ::                         U    256 0     0 ens192
fe80::/64                      ::                         U    256 0     0 ens224
::/0                           ::                         !n   -1  1     1 lo
::1/128                        ::                         Un   0   2    11 lo
fd21:711::20c:29ff:fea5:4c32/128 ::                         Un   0   1     0 lo
fd21:b4dc:4b01:0:20c:29ff:fea5:4c32/128 ::                         Un   0   1     0 lo
fe80::20c:29ff:fea5:4c28/128   ::                         Un   0   1     0 lo
fe80::20c:29ff:fea5:4c32/128   ::                         Un   0   1     0 lo
ff00::/8                       ::                         U    256 0     0 ens192
ff00::/8                       ::                         U    256 1  2176 ens224
::/0                           ::                         !n   -1  1     1 lo
root@sogo:~#

Versuche einmal die adresse zu pingen, welche der knoten auf dem local-node Interface hat, die 254 am ende.
Dann wissen wir zumindest, ob es an der Verbindung zum knoten liegt oder an der Anbindung zum gateway bzw dem gateway

1 Like

254 am Ende?
Die IP Adresse 172.21.24.254 ?
Die gibt auch keine Antwort.

Mhh, hätte ich mir denken können, ist ja anderes subnetz… Zur sicherheit, gehe mal aus deinem lokalen netz raus und verbinde dich nochmal neu mit freifunk. Wenn das dann nichts bringt, müssen wohl die leute ran deren netz du nutzt :wink:

äh, sorry?

Dafür gibt es vermutlich ein Kommando. Gell? :- ) Oder soll ich die VM neu starten? Geht natürlich auch.

… [quote=„Brother_Lal, post:43, topic:14082“]
die leute ran deren netz du nutzt
[/quote]
Wenn ich von denen einen Hauch von Unterstützung erwarten könnte, wäre ich nicht hier. Ich teste liebend gerne vorher alle anderen bundesrepublikanischen Freifunk Images durch.

:smile:
Das ist ja doof^^
Meine aussagen oben haben sich auf den client bezogen, den du nutzt. Der soll nur mit der gluon-vm verbunden sein, nicht mit einem anderen Netz. Und neu verbinden heisst stecker raus und stecker rein, am client, damit neue dhcpanfragen rausgehen und routen neu usw.
Wenn dhcp klappt, ist naemlich das layer 2 wohl in ordnung(und das gateway erreichbar), nur das Routing will wohl noch nicht, nehme ich an.
Ob dort jetzt der Client ein problem hat oder der router unbekannte subnetze nicht weiterleitet, weiss ich aber auch nicht.

Ok. Ich habe alle anderen Interfaces ausgehängt und nur das „Client Netzwerk“ aktiviert. Die LAN Karte bekommt per DHCP eine Adresse. Routing scheitert trotzdem. Ich kann ja gerne mal jemand auf die Shell des Gluon VPN Gateway drauf lassen. Ein Putty Public Key genügt :- )
Oder ich versuche ein anderes Image. Ich bin da für jeden Vorschlag offen.

Wenn das wirklich die Knoten-IP ist - was ich gerade nicht überprüfen kann - dann liegt das Problem in deiner VM-Ware-Konfiguration.

Zur Info:

Jeder Freifunkrouter bzw. Knoten hat eine IPV6, über die er im ganzen Netz erreichbar ist und in manchen Communities auch von außen. Danach sieht das hier aber nicht aus. Zusätzlich gibt es eine lokale IPV4, die für alle Router gleich ist. Über diese ist er von allen Rechnern erreichbar, die an diesem Knoten hängen.

Wenn die schon nicht geht, liegt es definitiv an deiner VMware-Konfiguration. Ich hab bisher nur mit KVM gearbeitet, daher kann ich da nicht im Detail sagen, wo es hängt.

Die Verbindung im virtuellen Netzwerk sollte eigentlich überhaupt kein Problem sein, weil man da meines Wissens nach nichts beachten muss.

Mhh, da aber der DHCP klappt, glaube ich eher an ein Routingproblem auf seiten des Knotens
Die localnodeadresse sollte ja stimmen, aber die DHCP-Adressen sind aus einem völlig adneren Bereich.
Vll stimmt die IPtables-Einstellung des Knotens nicht mit dem Subnetz der stuttgarter überein?

Sollte man vll mit IPv6 noch durchprobieren.

Da der Client per DHCP eine Adresse bekommt, ist das Bridging mitsamt Tunnel ins Freifunk Netz erstmal ok. Und MTU Größenprobleme können es bei einem 60 Byte Päckchen auch nicht sein.

Also ob das VMWare, KVM oder Metall ist, spielt in dem Stadium mit Sicherheit keine Rolle mehr. Da tendiere ich eher zu der Einschätzung von Brother_Lal.

Das Log beim Starten des Tunnels sieht so aus. Vielleicht erkennt der erfahrene Freifunker daran den Fehler.

Sat Dec 31 15:01:42 2016 daemon.notice fastd[17538]: fastd v17 starting
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Network device 'mesh-vpn' link is up
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Sat Dec 31 15:01:42 2016 daemon.notice fastd[17538]: changed to UID 0, GID 800
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw04>
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw05>
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw10>
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw08>
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw01>
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw09>
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw06>
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw02>
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.823566] batman_adv: bat0: Adding interface: mesh-vpn
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.824978] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1406) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.830985] batman_adv: bat0: Interface activated: mesh-vpn
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.834275] 8021q: adding VLAN 0 to HW filter on device bat0
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Interface 'bat0' is enabled
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Network device 'bat0' link is up
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.836398] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.839560] device bat0 entered promiscuous mode
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.840790] br-client: port 2(bat0) entered forwarding state
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.842177] br-client: port 2(bat0) entered forwarding state
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Interface 'bat0' has link connectivity
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Interface 'bat0' is setting up now
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw07>
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Interface 'bat0' is now up
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: adding peer <mesh_vpn_backbone_peer_gw03>
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw03.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw03>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw07.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw07>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw02.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw02>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw06.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw06>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw09.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw09>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw01>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw08.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw08>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw10.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw10>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw05.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw05>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw04.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw04>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw07.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw02.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw10.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolved host `gw09.freifunk-stuttgart.de' successfully
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw06.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw08.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolved host `gw05.freifunk-stuttgart.de' successfully
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw03.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw04.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:42 2016 daemon.notice netifd: Interface 'mesh_vpn' is now up
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolved host `gw01.freifunk-stuttgart.de' successfully
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.980902] batman_adv: bat0: Changing gw mode from: off to: client
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.985391] batman_adv: bat0: hop_penalty: Changing from: 30 to: 15
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.987094] batman_adv: bat0: multicast_mode: Changing from: enabled to: disabled
Sat Dec 31 15:01:42 2016 kern.info kernel: [ 2040.989505] batman_adv: bat0: orig_interval: Changing from: 1000 to: 5000
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: sending handshake to <mesh_vpn_backbone_peer_gw09>[[2a01:4f8:130:6373::3]:10037]...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw07s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw07>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw07s01.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw03s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw03>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw02s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw02>...
Sat Dec 31 15:01:42 2016 daemon.info fastd[17538]: resolving host `gw02s01.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:43 2016 daemon.info fastd[17538]: resolving host `gw03s01.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:43 2016 daemon.info fastd[17538]: resolving host `gw04s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw04>...
Sat Dec 31 15:01:43 2016 daemon.info fastd[17538]: resolving host `gw04s01.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:43 2016 daemon.info fastd[17538]: resolving host `gw10s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw10>...
Sat Dec 31 15:01:43 2016 daemon.info fastd[17538]: resolving host `gw10s01.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:43 2016 daemon.info fastd[17538]: sending handshake to <mesh_vpn_backbone_peer_gw01>[[2001:4ba0:fff1:f8::10]:10037]...
Sat Dec 31 15:01:43 2016 daemon.info fastd[17538]: resolving host `gw06s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw06>...
Sat Dec 31 15:01:43 2016 daemon.info fastd[17538]: resolving host `gw06s01.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:01:44 2016 kern.info kernel: [ 2042.835776] br-client: port 2(bat0) entered forwarding state
Sat Dec 31 15:01:44 2016 daemon.info fastd[17538]: sending handshake to <mesh_vpn_backbone_peer_gw05>[91.226.89.224:10037]...
Sat Dec 31 15:01:44 2016 daemon.info fastd[17538]: resolving host `gw05s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw05>...
Sat Dec 31 15:01:44 2016 daemon.info fastd[17538]: resolved host `gw05s01.freifunk-stuttgart.de' successfully
Sat Dec 31 15:01:44 2016 daemon.info fastd[17538]: resolving host `gw08s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw08>...
Sat Dec 31 15:01:44 2016 daemon.info fastd[17538]: resolved host `gw08s01.freifunk-stuttgart.de' successfully
Sat Dec 31 15:02:03 2016 daemon.info fastd[17538]: resolving host `gw10s02.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw10>...
Sat Dec 31 15:02:03 2016 daemon.info fastd[17538]: resolving host `gw10s02.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:02:03 2016 daemon.info fastd[17538]: resolving host `gw04s02.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw04>...
Sat Dec 31 15:02:03 2016 daemon.info fastd[17538]: resolving host `gw04s02.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:02:03 2016 daemon.info fastd[17538]: resolving host `gw02s02.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw02>...
Sat Dec 31 15:02:03 2016 daemon.info fastd[17538]: resolving host `gw02s02.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: resolving host `gw03s02.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw03>...
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: resolving host `gw03s02.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: sending handshake to <mesh_vpn_backbone_peer_gw05>[[2001:4ba0:ffec:83::1]:10041]...
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: sending handshake to <mesh_vpn_backbone_peer_gw09>[88.198.134.226:10037]...
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: resolving host `gw09s01.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw09>...
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: resolving host `gw07s02.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw07>...
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: resolving host `gw09s01.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: resolving host `gw07s02.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: resolving host `gw06s02.freifunk-stuttgart.de' for peer <mesh_vpn_backbone_peer_gw06>...
Sat Dec 31 15:02:04 2016 daemon.info fastd[17538]: resolving host `gw06s02.freifunk-stuttgart.de' failed: Name or service not known
Sat Dec 31 15:02:05 2016 daemon.info fastd[17538]: sending handshake to <mesh_vpn_backbone_peer_gw08>[81.7.8.106:10041]...
Sat Dec 31 15:02:05 2016 daemon.info fastd[17538]: received handshake response from <mesh_vpn_backbone_peer_gw08>[81.7.8.106:10041] using fastd v17
Sat Dec 31 15:02:05 2016 daemon.info fastd[17538]: 81.7.8.106:10041 authorized as <mesh_vpn_backbone_peer_gw08>
Sat Dec 31 15:02:05 2016 daemon.notice fastd[17538]: connection with <mesh_vpn_backbone_peer_gw08> established.
Sat Dec 31 15:02:05 2016 daemon.info fastd[17538]: new session with <mesh_vpn_backbone_peer_gw08> established using method `salsa2012+umac'.

Kann es sein, dass VMware einen DHCP-Server in das virtuelle Netz schmeißt? KVM und VirtualBox tun das standardmäßig und man muss das explizit deaktivieren.

Also, ich nehme an, dass du eine Firmware auf Basis dieser site.conf hast: site-ffs/site.conf at v1.7 · freifunk-stuttgart/site-ffs · GitHub

next_node = {
      ip4 = '172.21.24.254',
      ip6 = 'fd21:711::1',
      mac = '02:00:0a:25:00:01',
},

Wenn die 172.21.24.254 nicht pingbar ist, stimmt was mit dem Image nicht (ist durchaus schon vorgekommen) oder mit deiner virtuellen Netztopologie.

Kannst du denn die IPV6 des Clients vom Knoten aus oder andersherum pingen? Der Knoten müsste die IP fd21:711::1 haben, diese müsste vom Client aus erreichbar sein.

Um ein defektes Image auszuschließen, kannst du das ggfs. mal ausschalten und parallel ein anderes von einer anderen Community testen. Du kannst ja jederzeit wieder zurück zu dem anderen.

VMware „schmeißt“ nichts ohne ausdrücklichen Wunsch des Administrators :- ) Und in diesem konkreten Fall: nein. Da ist kein DHCP Server im VMware Netz im Umkreis von 10 GBit/s.

Ich bekomme zwar IPv6 Adressen per DHCP, der Knoten und der Client können sich aber in der Tat nicht gegenseitig anpingen. Obwohl sie im selben Subnet sind. Da ist wohl der Hund begraben.

Ich sehe mir den virtuellen Switch nochmal an, der das Client Netz in VMware definiert. Ich tippe ganz stark auf eine Besonderheit, die der Gluon haben will. Stay tuned …

ich schaffe es gerade nicht, alle 51 Postings des Threads aufzurollen, daher sei nochmal die Frage gestattet:
Promiscous-Mode hast Du der Gluon-VM auf ihren Interfaces erlaubt?

Die Lösung ist: man braucht den Promiscous Modus auf einer(!) der beiden Seiten: im (Freifunksprech-)Client Netz. Dort aktivierte ich es auf der Port-Gruppe, nicht global im Switch.

In VMware ESXi kann man keinen Promiscous Mode auf VM Interfaces definieren. Das ist eine Eigenschaft des vSwitches oder der Portgruppe.
Auf WAN Seite genügt es, die macaddr Option zu kicken.

/etc/config/network:

.
.
config interface ‚wan‘
`` option igmp_snooping ‚0‘
`` option ifname ‚eth1‘
`` option auto ‚1‘
`` option peerdns ‚0‘
`` option type ‚bridge‘
`` option proto ‚dhcp‘
`` # option macaddr ‚02:0d:29:47:ff:bb‘
.
.

Wer immer sich das ausgedacht hat. Aber ich darf nicht schimpfen, schließlich wurde ich hier geholfen :- )

Vielen Dank ringsrum!

1 Like

Siehe auch dieser Thread zu VMware, und zu HyperV.

Es gibt seit September 2015 auch einen Gluon-Bugreport und wird seitdem auch als „KnownIssue“ mitgeschleppt, z.B. siehe
http://gluon.readthedocs.io/en/v2016.2.2/releases/v2016.2.2.html

1 Like