Offloader-Installation, virtualisiert (Proxmox, VLANs etc)

root@Si-Si-AlterWassergang02:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bat0 state UP qlen 1000
link/ether e6:58:ea:24:3f:2c brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan state UP qlen 1000
link/ether 7a:55:70:2f:6b:79 brd ff:ff:ff:ff:ff:ff
4: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 7a:d2:28:43:a9:b2 brd ff:ff:ff:ff:ff:ff
5: teql0: mtu 1500 qdisc noop state DOWN qlen 100
link/void
7: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether e6:58:ea:24:3f:28 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.37/24 brd 192.168.10.255 scope global br-wan
valid_lft forever preferred_lft forever
inet6 2001:16b8:4b7:5000:e458:eaff:fe24:3f28/64 scope global dynamic
valid_lft 7099sec preferred_lft 3499sec
inet6 fe80::e458:eaff:fe24:3f28/64 scope link
valid_lft forever preferred_lft forever
8: local-port@local-node: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP qlen 1000
link/ether fe:a2:56:bf:41:e7 brd ff:ff:ff:ff:ff:ff
9: local-node@local-port: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 04:5c:85:12:ef:e0 brd ff:ff:ff:ff:ff:ff
inet 172.18.254.254/16 brd 172.18.255.255 scope global local-node
valid_lft forever preferred_lft forever
inet6 2a03:2260:100c:300::cafe/128 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::65c:85ff:fe12:efe0/64 scope link
valid_lft forever preferred_lft forever
10: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether fe:a2:56:bf:41:e7 brd ff:ff:ff:ff:ff:ff
inet6 2a03:2260:100c:300:fca2:56ff:febf:41e7/64 scope global dynamic
valid_lft 86198sec preferred_lft 14198sec
inet6 fe80::fca2:56ff:febf:41e7/64 scope link
valid_lft forever preferred_lft forever
11: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UNKNOWN qlen 1000
link/ether e6:58:ea:24:3f:2b brd ff:ff:ff:ff:ff:ff
inet6 fe80::e458:eaff:fe24:3f2b/64 scope link
valid_lft forever preferred_lft forever
12: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UNKNOWN qlen 1000
link/ether fe:a2:56:bf:41:e7 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fca2:56ff:febf:41e7/64 scope link
valid_lft forever preferred_lft forever
13: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc fq_codel master bat0 state UNKNOWN qlen 1000
link/ether e6:58:ea:24:3f:2f brd ff:ff:ff:ff:ff:ff
inet6 fe80::e458:eaff:fe24:3f2f/64 scope link
valid_lft forever preferred_lft forever

root@Si-Si-AlterWassergang02:~# brctl show
bridge name bridge id STP enabled interfaces
br-wan 7fff.e658ea243f28 no eth1
br-client 7fff.fea256bf41e7 no local-port
bat0

wenn das virtuelle WAN Kabel gezogen wird, sagt logread -f

Thu Aug 15 22:36:29 2019 daemon.notice netifd: Network device ‚eth1‘ link is down
Thu Aug 15 22:36:29 2019 kern.info kernel: [ 1453.340503] br-wan: port 1(eth1) entered disabled state
Thu Aug 15 22:36:30 2019 daemon.notice netifd: bridge ‚br-wan‘ link is down
Thu Aug 15 22:36:30 2019 daemon.notice netifd: Interface ‚wan6‘ has link connectivity loss
Thu Aug 15 22:36:30 2019 daemon.notice netifd: Interface ‚wan‘ has link connectivity loss
Thu Aug 15 22:36:30 2019 daemon.notice netifd: wan (2239): udhcpc: received SIGTERM
Thu Aug 15 22:36:30 2019 daemon.notice netifd: wan6 (2240): Command failed: Permission denied
Thu Aug 15 22:36:30 2019 daemon.warn dnsmasq[2797]: no servers found in /var/gluon/wan-dnsmasq/resolv.conf, will retry
Thu Aug 15 22:36:37 2019 kern.info kernel: [ 1461.405563] br-wan: port 1(eth1) entered blocking state
Thu Aug 15 22:36:37 2019 kern.info kernel: [ 1461.406595] br-wan: port 1(eth1) entered forwarding state
Thu Aug 15 22:36:37 2019 daemon.notice netifd: Network device ‚eth1‘ link is up
Thu Aug 15 22:36:37 2019 daemon.notice netifd: bridge ‚br-wan‘ link is up
Thu Aug 15 22:36:37 2019 daemon.notice netifd: Interface ‚wan6‘ has link connectivity
Thu Aug 15 22:36:37 2019 daemon.notice netifd: Interface ‚wan6‘ is setting up now
Thu Aug 15 22:36:37 2019 daemon.notice netifd: Interface ‚wan‘ has link connectivity
Thu Aug 15 22:36:37 2019 daemon.notice netifd: Interface ‚wan‘ is setting up now
Thu Aug 15 22:36:37 2019 daemon.notice netifd: wan (7622): udhcpc: started, v1.28.4
Thu Aug 15 22:36:37 2019 daemon.notice netifd: wan (7622): udhcpc: sending discover
Thu Aug 15 22:36:37 2019 daemon.notice netifd: wan (7622): udhcpc: sending select for 192.168.10.37
Thu Aug 15 22:36:37 2019 daemon.notice netifd: wan (7622): udhcpc: lease of 192.168.10.37 obtained, lease time 864000
Thu Aug 15 22:36:37 2019 daemon.notice netifd: Interface ‚wan‘ is now up
Thu Aug 15 22:36:37 2019 user.notice firewall: Reloading firewall due to ifup of wan (br-wan)
Thu Aug 15 22:36:37 2019 daemon.info dnsmasq[2797]: reading /var/gluon/wan-dnsmasq/resolv.conf
Thu Aug 15 22:36:37 2019 daemon.info dnsmasq[2797]: using nameserver 192.168.10.1#53
Thu Aug 15 22:36:42 2019 daemon.notice netifd: Interface ‚wan6‘ is now up
Thu Aug 15 22:36:42 2019 user.notice firewall: Reloading firewall due to ifup of wan6 (br-wan)
Thu Aug 15 22:36:42 2019 daemon.info dnsmasq[2797]: reading /var/gluon/wan-dnsmasq/resolv.conf
Thu Aug 15 22:36:42 2019 daemon.info dnsmasq[2797]: using nameserver fd00::e228:6dff:fe76:41b5#53
Thu Aug 15 22:36:42 2019 daemon.info dnsmasq[2797]: using nameserver 192.168.10.1#53
Thu Aug 15 22:36:51 2019 daemon.info fastd[2871]: sending handshake to <mesh_vpn_backbone_1_peer_siegen1>[91.134.144.230:10000]…
Thu Aug 15 22:36:51 2019 daemon.info fastd[2871]: received handshake response from <mesh_vpn_backbone_1_peer_siegen1>[91.134.144.230:10000] using fastd v17
Thu Aug 15 22:36:51 2019 daemon.info fastd[2871]: 91.134.144.230:10000 authorized as <mesh_vpn_backbone_1_peer_siegen1>
Thu Aug 15 22:36:51 2019 daemon.info fastd[2871]: new session with <mesh_vpn_backbone_1_peer_siegen1> established using method `salsa2012+umac’.

dann sollte batctl-gwl aber mindestens einen Gateway auflisten!

batctl gwl sagt

[B.A.T.M.A.N. adv openwrt-2018.1-8, MainIF/MAC: primary0/e6:58:ea:24:3f:2b (bat0/fe:a2:56:bf:41:e7 BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth

  • 04:ee:ef:ca:fe:3a (255) 04:ee:ef:ca:fe:3a [ mesh-vpn]: 48.0/48.0 MBit

jetzt ist er auch online gekommen, also seit gestern 20h. (davor hatte er kein MeshVPN)

https://map.eulenfunk.de/stats/d/000000004/node-byid?orgId=1&var-nodeid=fea256bf41e7
dann kannst Du von dort aus weiterforschen, evtl. auch anhand von
https://wiki.freifunk.net/Mein_Freifunk_funktioniert_nicht_mehr

Hab „Mein Freifunk funktioniert nicht mehr – wiki.freifunk.net“ durchgearbeitet.
HW Installation prüfen fällt bei einer VM weg. Die VM läuft, hat WAN, hat VPN, Gateway ist vorhanden, Next Node kann gepingt werden.
Die andere NIC (für die Clients?) liegt auf einer anderen vmbr. Ein virtueller Client mit Bein ebenfalls auf dieser vmbr bekommt aber keine IP.
Zum Verständnis: Bei etablierten VPN sollten doch die DHCP Requests auf dem Client Interface vom nexthop beantwortet werden, oder?

Nein, die DHCP-Requests werden vom Gateway (oder beser: vom Backend) beantwortet…
d.h. der FF-Router bridged die dhcp-req nur von CLI über’s VPN nach draußen.
Die Antworten (offer…) kommen dann aus der Richtung des Supernode.

Du könntest also a) einen virtuellen Client auf das Interface/den switch „br-client“ hängen über eine vmbr
b) könntest Du mal br-bat (aka br-mesh) nach draußen legen und dort einen HW-Knoten (aka: Plasterouter) mit MoW (oder MoL, je nachdem auf welchem Port Du es dort aktiviert hast) dranhängen.

Ja, das meinte ich. Ich dachte next-node = gateway

Aber das konnte nicht sein:

local-node Link encap:Ethernet HWaddr 04:5C:85:12:EF:E0
inet addr:172.18.254.254 Bcast:172.18.255.255 Mask:255.255.0.0
inet6 addr: fe80::65c:85ff:fe12:efe0/64 Scope:Link
inet6 addr: 2a03:2260:100c:300::cafe/128 Scope:Global

„next_node“:{„mac“:„04:5c:85:12:ef:e0“,„ip6“:„2a03:2260:100c:300::cafe“,„name“:[„nextnode“,„nn“],„ip4“:„172.18.254.254“}

Hm, ist also Next_node = local-node?

Ich hab also das Problem dass die Clients keine IP bekommen. Kann man das Problem irgendwie eingrenzen?

Nextnode ist (in Gluon-basierten Netzen derzeit) immer der Knoten, der das (W)LAN liefert. Nextnode antwortet auch, wenn nur 1 Client an 1 Knoten in einem Keller der NSA waterboarded werden.

Auf dem Knoten batctl gwl ausführen:

root@33332-R6120-Test-5829:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: primary0/0a:c4:d1:23:54:db (bat0)]
=> de:ad:be:ef:67:01 (247) 02:00:25:f3:7f:25 [  mesh-vpn]: 215 - 96MBit/96MBit
   72:fc:e9:5b:2c:85 (191) 02:00:25:f3:7f:25 [  mesh-vpn]:  94 - 128MBit/112MBit

Kein Gateway => keine Verbindung zum Mesh. Dann also weiterdebuggen, warum keine Verbindung zum Mesh (logread?) …

batctl gwl sagt

[B.A.T.M.A.N. adv openwrt-2018.1-8, MainIF/MAC: primary0/e6:58:ea:24:3f:2b (bat0/fe:a2:56:bf:41:e7 BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth

  • 04:ee:ef:ca:fe:3a (251) 04:ee:ef:ca:fe:3a [ mesh-vpn]: 48.0/48.0 MBit

Dann ist die Mesh Verbindung da, oder?

Ja, ist sie.

Zwischenzeitlich hab ich mal ein anderes Image verwendet (aus Lippe), mit dem funktioniert es auf Anhieb. Es scheint also etwas mit dem Siegener Image nicht zu stimmen. Ich ja auch ne Beta. Ein Stable VDI Image für FF Siegen gibts noch nicht.

Nein, das Problem sitzt irgendwo bei Dir vor der Tastatur. Es liegt definitiv NICHT am Siegener Image.

Ich habe es mit unter Proxmox mit dem Siegener Image von http://images.ff-si.ovh/siegen/beta/factory/gluon-sisi-2019081120-bet-x86-64.vmdk probiert.




1 „Gefällt mir“

Oh, sieht nach einem ähnlichen Fehler wie im Nachbarhread aus: Du führst das von Dir gewünschte Netz (die Bridge) auf keinen „physikalisches“ eth-interface der VM.
Also kommt da auch nichts heraus.

„/etc/config/network“ solltest Du Dir auf dem offloader dringend anschauen, wie da die ports assigned sind, Kontrolle mit „brctl show“.

Danke für Deine Unterstützung, Andreas! Gut zu Wissen das es ein Layer8 Problem ist. :slight_smile: Ich fang nochmal von vorne an und berichte!

Schaue bitte, dass Du im Web-Configmode unter „Erweiterte Einstellungen“/„Netzwerk“ die Funktion „Mesh On Lan“ abschaltest. (lies: kein Haken)

Dann sollte -wenn der Knoten regulär läuft- die Ausgabe von „brctl show“ und „ip a“ einen sinnvollen Zusammenhang zwischen dem „client“-Network und dem Interface (MAC des eth) herzustellen sein, was dann irgendwie zu den clients transportiert wird.

1 „Gefällt mir“

Heureka!
Kaum macht man es richtig, schon funktioniert es.
Hab Deine Nachricht zu spät gesehen und MoL nachträglich deaktiviert per

uci set network.mesh_lan.disabled=1
for ifname in $(cat /lib/gluon/core/sysconfig/lan_ifname); do
uci add_list network.client.ifname=$ifname
done
uci commit network

Danke für Deine Unterstützung !

1 „Gefällt mir“