Hallo Freifunker,
ich möchte das Clientnetz aus einem Offloader heraus nutzen. Das funktioniert nicht: die Rechner, die ich mit dem Client-LAN des Offloaders verbinde, bekommen zwar eine v6 IP, aber keine v4 IP, keinen DNS und kein Gateway. Pingen im Client-Netz geht: ich erreiche das Gateway und andere Router in demselben Netz.
3 WR841-Router über Mesh on LAN verbunden, dort Mesh-VPN deaktiviert
Freifunknetz funktioniert im WLAN auf allen Funk-Nodes über Mesh-on-Lan mit diesem Offloader
Es ist eine Neuinstallation, es ist also nicht so, dass es schon mal gegangen ist.
Ich würde gerne Freifunk-Client-Netz auch auf ausgewählte Netzwerkdosen bringen. Leider funktionieren aber die Teilnehmer im Client-LAN am Offloader nicht. Sie bekommen keinen DNS und kein Gateway. ping auf Gateway und meine anderen Router im Client-Netz geht.
Auf dem Client im LAN sieht es so aus:
root@remus:~# ifconfig eno1
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fd83:e002:c8a1:0:724:c6a6:beb2:a437 prefixlen 64 scopeid 0x0<global>
inet6 fd83:e002:c8a1:0:587e:cf92:c6df:d3e7 prefixlen 64 scopeid 0x0<global>
inet6 fe80::25e0:bce6:c1f7:253e prefixlen 64 scopeid 0x20<link>
ether 20:47:47:bd:11:9a txqueuelen 1000 (Ethernet)
RX packets 20160 bytes 1988227 (1.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2255 bytes 326583 (326.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 2
device interrupt 20 memory 0xf7200000-f7220000
root@remus:~# ping ffuegw7.ffue
PING ffuegw7.ffue(ffuegw7.ffue (fd83:e002:c8a1::7)) 56 data bytes
64 bytes from ffuegw7.ffue (fd83:e002:c8a1::7): icmp_seq=1 ttl=64 time=39.4 ms
^C
--- ffuegw7.ffue ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 39.448/39.448/39.448/0.000 ms
root@remus:~# systemd-resolve --status
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
[....]
Link 2 (eno1)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: fd83:e002:c8a1::1
fd83:e002:c8a1::3
fd83:e002:c8a1::6
fd83:e002:c8a1::2
fd83:e002:c8a1::5
fd83:e002:c8a1::4
fd83:e002:c8a1::7
Was weiter auffällig ist, dass auf der Statusseite des Offloaders keine Namen der Nachbarknoten angezeigt werden: http://[fd83:e002:c8a1:0:5054:ff:fe58:77b1]/
im Vergleich z.B. zu http://[fd83:e002:c8a1:0:fa1a:67ff:fe31:6a74]/
Ich bin leider ziemlicher Freifunk-Newbie und etwas ratlos. Ein paar Hinweise, was ich mal an meinem Offloader prüfen könnte, wären super-nett.
Edit: Ich habe auf dem Host mittels „brctl addif br-ff-client eth1“ einmal das Clientnetz auch auf auf das zweite Ethernet des Servers gelegt, um mögliche VLAN-Probleme auszuschließen. Ergebnis ist das gleiche, und der Traffic sieht mit tcpdump betrachtet gefühlt gleich aus wie auf dem Client-VLAN…
Hi Matthias, danke, du hast recht: Die Aussage selbst war falsch . Trotzdem müsste aber sonst alles passen:
Node-Client-Netz ist auf der Bridge br-client
Dieser Bridge ist Node-eth2 mit MAC 52:54:00:f8:37:c0 zugehörig
Node-eth2 entspricht wiederum vnet2 auf dem Hypervisor (mit gleicher MAC)
Und vnet2 ist wiederum Teil der Bridge br-ff-client auf dem Hypervisor, an dessen Interfaces ich den Möchtegern-Freifunkclient anstecke.
echo "Node:";echo; ssh root@ff-0 brctl show\; ip a show eth2\; ip a show eth0\; ip a show eth1;echo;echo Host:;echo; ip a show vnet2; ip a show vnet0; ip a show vnet1; brctl show
Node:
bridge name bridge id STP enabled interfaces
br-client 7fff.5254005877b1 no eth2
bat0
br-mesh_lan 7fff.6eee58d4c4fc no eth0
br-wan 7fff.6eee58d4c4f8 no eth1
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client state UP qlen 1000
link/ether 52:54:00:f8:37:c0 brd ff:ff:ff:ff:ff:ff
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-mesh_lan state UP qlen 1000
link/ether 52:54:00:e6:72:c5 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 52:54:00:59:77:b1 brd ff:ff:ff:ff:ff:ff
Host:
13: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br-ff-client state UNKNOWN group default qlen 1000
link/ether fe:54:00:f8:37:c0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fef8:37c0/64 scope link
valid_lft forever preferred_lft forever
11: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br-ff-mesh state UNKNOWN group default qlen 1000
link/ether fe:54:00:e6:72:c5 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fee6:72c5/64 scope link
valid_lft forever preferred_lft forever
12: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:59:77:b1 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe59:77b1/64 scope link
valid_lft forever preferred_lft forever
bridge name bridge id STP enabled interfaces
br-ff-client 8000.0cc47a92872e no eth0.11
eth1
vnet2
br-ff-mesh 8000.0cc47a92872e no eth0.10
vnet0
br0 8000.0022aabbccdd no eth0.1
netdev-apps
netdev-daten
netdev-extern
vnet1
vnet3
Edit:
Dass das vnet2 des Nodes tatsächlich der Host-Bridge br-ff-client richtig zugeordnet ist, sieht man - nicht wie ich oben geschrieben an der MAC-Adresse, die ist zwar ähnlich, aber nicht gleich - sondern an der Ausgabe von virsh dumpxml:
Hallo Matthias, danke nochmal für das genaue Nachfragen, das einen selber nochmal zum besseren Nachdenken bringt.
Es funktioniert jetzt.
Ursache für den Fehler war keine fehlerhafte Bridge-, VLAN- oder Gluon-Konfiguration sondern das Folgende:
Auf dem Host waren iptables-Regeln wirksam, die vollständiges Verbinden mit dem Client-Netz (insbesondere DHCP und DNS) verboten haben. ICMP jedoch funktionierte, weil ich echo request/reply immer durchlasse, daher die etwas merkwürdigen Symptome. Nachdem ich auf dem Client-Netz die FW aufgemacht habe, läuft es jetzt.