Freifunk VMWare


#1

Hallo zusammen,

ich versuche schon seit geraumer Zeit eine virtuelle Freifunk-Maschine in unserer vSphere zu betreiben. Leider scheitere ich nun an dem VPN-Tunnel.

Die virtuelle Maschine mesht sich wunderbar mit anderen TP-Link Routern im LAN, allerdings baut sie keinen eigenen Tunnel auf.

Muss ich auf weitere Einstellungen außer network.mesh_wan.auto=1 achten?

Ein Hinweis, der für euch nützlich sein könnte:
Die VM gibt mir auf der Commandline foldenden Text aus: br-wan: received packet on eth1 with own address as source address.

Habt ihr einen Tipp, wie ich das troubleshooten kann?

Vielen Dank für die Hilfe,
Frank


#2

2 interfaces beim ersten boot aktiv?
Mac spoofing aktiv?


#3

Das ist die falsche Einstellung für den VPN-Tunnel. Die sollte auf ‘0’ stehen in deiner Konfiguration. (Damit leitest du lokales Mesch auf das WAN-Interface und somit in dein privates Netz. Das willst du nicht.

Je nach Community musst du Fastd oder den Tunneldigger aktivieren.

uci show|grep enabled

wird die Option anzeigen.

Wichtig ist auch bei VMware den promisken Modus (promiscous mode) oder wie er dort heißt zu aktivieren, weil die MAC der WAN-Schnittstelle bei Gluon wechselt. Wie es genau geht, kann ich nicht sagen. Bin KVM-Nutzer.

Viele Grüße
Matthias


#4

siehe auch


#5

Ich habe jetzt erstmal die Option geändert - vielen Dank für den Hinweis.

uci Show|grep enabled zeigt folgende Informationen:

autoupdater.settings.enabled=‘1’
fastd.sample_config.enabled=‘0’
fastd.sample_peer.enabled=‘0’
fastd.sample_group.enabled=‘0’
fastd.mesh_vpn.enabled=‘1’
fastd.mesh_vpn_backbone.enabled=‘1’
fastd.mesh_vpn_backbone_peer__10002.enabled=‘1’
gluon-setup-mode.@setup_mode[0].enabled=‘0’
hoodselector.hoodselector.enabled=‘1’
simple-tc.example.enabled=‘0’
simple-tc.mesh_vpn.enabled=‘0’
system.ntp.enabled=‘1’

Den ‘Promiscous mode’ hatte ich bereits aktiviert. Die MAC-Adressänderungen waren noch nicht erlaubt. Das habe ich nun nachgezogen und offenbar baut er nun den Tunnel auf.

Gruß
Frank


#6

DAs ist übrigens nicht nur bei VMware-Hosts ein “beliebtes” Thema, sondern auch bei irgendwelchen Orten an denen Switche mit strikter Port-Security gefahren werden. Wo z.B. selbst an einem eigentlich “offenen” Port trotzdem zeitgleich nur eine MAC-Adresse zulässig ist… da failed das Gluon auch, weil er während des Bootens noch mit einer anderen MAC unterwegs ist als zu dem Zeitpunkt an dem er dann das MeshVPN-auf dem WAN-Interface hochbringt.


#7

Das sieht soweit gut aus. Schau dir jetzt mal

ip a s br-wan
ip r s
ping 1.1.1.1
logread

an.


#8

ip a s br-wan

19: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master bat0 state UP qlen 1000
link/ether 12:73:c2:2b:40:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.26/24 brd 192.168.178.255 scope global br-wan
valid_lft forever preferred_lft forever
inet6 fe80::1073:c2ff:fe2b:4000/64 scope link tentative flags 08
valid_lft forever preferred_lft forever

ip r s

default via 192.168.178.1 dev br-wan src 192.168.178.26
192.168.178.0/24 dev br-wan src 192.168.178.26
192.168.178.1 dev br-wan src 192.168.178.26

ping 1.1.1.1

1.1.1.1 ist erreichbar

logread

Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.399787] net_ratelimit: 2302 callbacks suppressed
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.400871] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.402385] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.403762] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.405403] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.406823] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.408555] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.410101] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.411506] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.412923] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.414331] br-wan: received packet on eth1 with own address as source address
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available
Mon Jan 28 09:08:55 2019 daemon.err respondd[6148]: sendto failed: Address not available

Das sieht noch nicht so aus, als müsste das so…


#9

hast Du noch mal den output von

brctl show
batctl if
batctl gwl

und vielleicht

batctl o | wc -l

#10

brctl show

bridge name bridge id STP enabled interfaces
br-wan 7fff.1273c22b4000 no eth1
br-lan 7fff.000000000000 no
br-mesh_lan 7fff.000000000000 no
br-client 7fff.00505637c2de no bat0
eth0
local-port

batctl if

br-wan: active
primary0: active
mesh-vpn: active

batctl gwl

[B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/12:73:c2:2b:40:03 (bat0/00:50:56:37:c2:de BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth

  • 86:85:ca:b4:91:fb (255) 86:85:ca:b4:91:fb [ mesh-vpn]: 1000.0/1000.0 MBit

batctl o | wc l

hier bekomme ich keine Ausgabe


#11

versuch mal
batctl o | wc -l


#12

sorry, tippfehler. “|wc -l” bitte.

zu den Meldungen im logread/syslog: Schaut so aus als ob schlicht bei Dir die Freifunk-Domain defekt wäre.
Irgendwer hat an einem Router einen Loop zwischen batman und clientnetz gebaut und an den Supernodes wird es nicht gefiltert.
siehe auch


#13

Das könnte hiermit zusammen hängen. Dreh das WAN-Mesch mal wieder ab (auf 0 setzen):

Bzgl. dem Rest könnte @adorfer recht haben. Evtl. mal temporär eine andere Freifunk-Firmware testen.

Kann man das inzwischen effizient filtern oder meinst du den betreffenden Knoten aussperren?