Freifunk VMWare

[FG]

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

[windoof]

2 interfaces beim ersten boot aktiv?
Mac spoofing aktiv?

[MPW]

@FG

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

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

[adorfer]

siehe auch

Virtuelles Gluon unter VMWare - Keine Netzwerk-Verbindung

Hallo zusammen, ich versuche aktuell einen Knoten in VMWare zum laufen zu bringen. Scheinbar filtert der Hypervisor aber an einer Stelle die Pakete. Bei Hyper-V ist die Option schnell gefunden: [image] Bei VMWare scheint es nicht ganz so einfach zu sein. Hat einer von euch Erfahrung mit Gluon unter VMWare? Wo finde ich die Option um MAC-Spoofing zu erlauben. Oder könnte es noch etwas anderes sein? Bei wem funktioniert ein Gluon-Knoten unter VMWare? Bisher versucht: VMware Knowledge Base …

[FG]

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

[adorfer]

@FG

Die MAC-Adressänderungen waren noch nicht erlaubt. Das habe ich nun nachgezogen und offenbar baut er nun den Tunnel auf

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.

[MPW]

@FG

uci Show|grep enabled zeigt folgende Informationen:

Das sieht soweit gut aus. Schau dir jetzt mal

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

an.

[FG]

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…

[adorfer]

hast Du noch mal den output von

brctl show
batctl if
batctl gwl

und vielleicht

batctl o | wc -l

[FG]

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

[efbeff]

@FG

batctl o | wc l

hier bekomme ich keine Ausgabe

versuch mal
batctl o | wc -l

[adorfer]

@FG

batctl o | wc l

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

Br-client_br-client-Kurzschluss? Und wenn ja, wie lokalisieren?

Auf meinen Knoten bekomme ich neben diversen Pings mit „DUP!“ auch noch im Log haufenweise, selbst an „Meshvpn-Hotspots“, also nicht nur auf den Gateways. @RubenKelevra meinte, man könnte evtl dazu wiresharken, um die Schuldigen zu finden. Ich brauche da etwas Hilfe, gibt vermutlich ein Tutorial, das ich nur nicht erfolgreich ergoogle… Wed May 11 02:50:07 2016 kern.warn kernel: [ 1134.400000] br-client: received packet on bat0 with own address as source address Wed May 11 02:50:07 2016 kern.w…

Received packet on bat0 with own address as source address

Kann jemand von euch was mit der Fehlermeldung anfangen? received packet on bat0 with own address as source address Viele Grüße Patrik

Br-client: received packet on bat0 with own address as source address ?

meshender Knoten , gleich zu beginn vielfach diesen Fehler … vielleicht steh ich gerade auf dem Schlauch, aber das heisst doch nix gutes … wie debug ich das am gezieltesten # dmesg [510616.610000] br-client: received packet on bat0 with own address as source address [510933.920000] br-client: received packet on bat0 with own address as source address [511027.010000] br-client: received packet on bat0 with own address as source address [511208.180000] br-client: received packet on bat0 with own …

[MPW]

@FG

Mon Jan 28 09:08:53 2019 kern.warn kernel: [431615.406823] br-wan: received packet on eth1 with own address as source address

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

@FG

network.mesh_wan.auto=1

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

@adorfer

Irgendwer hat an einem Router einen Loop zwischen batman und clientnetz gebaut und an den Supernodes wird es nicht gefiltert.

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