FB 4020 Packet loss / DNS Stress

yanbec · 12. April 2019 um 15:07

(TL;DR: WLAN-Verbindung instabil, langsam. Verbindung Router <-> Gateway <-> Internet funktioniert aber grundsätzlich)

Moin moin zusammen!
Nachdem ich gestern das Freifunk-Treffen voll Freude mit einer frisch geflashten FritzBox 4020 verlassen habe, funktioniert leider doch nicht ganz alles wie gehofft/erwartet.

Folgende Konfiguration:
Buchse <-> Telekom Speedport “Smart” 3 <-> TP-Link Archer C7 <-> FritzBox.

Am Archer hängt außerdem noch ein Pi 3 mit PiHole, dessen Adresse der Archer verteilt. Funktioniert seit Januar in der Form einwandfrei, leicht abgewandelt (andere Wohnung) schon quasi ewig. Wlan am Speedport ist aus, Archer hat auf der Seite des Speedports ne statische IP. Am Archer steckt noch ein USB-Stick für PXE-Boot, sonst aus meiner Sicht nichts weiter besonderes.

Nun zur Problematik:
Ich bekomme im FF-Wlan, wenn die Verbindung funktioniert, einen Durchsatz von 2-3mbit/s pro Richtung. Abbrüche sind häufig, am Rechner häufiger als am Handy.

Was habe ich versucht?
Die FB hat zwischenzeitlich eine feste IP eingestellt bekommen, einmal mit und einmal ohne statische DNS-Server (Pi + 8.8.8.8). Zur Minute hängt das Ding direkt am Speedport statt am Archer.

Mit dem Laptop komme ich gerade garnicht mehr ins WLAN rein, wenn es ging, hatte ich einen Packet loss von ca. 75%.
Handy kommt noch rein (?!), ist aber wie oben erwähnt äußerst langsam.
Pings direkt vom Router aus (ssh) gehen über direkte IPv4 wunderbar, IPv6 scheint nicht zu gehen (wie könnte ich das am besten testen? Ich bin hier noch steinzeitlich und hab keinen Plan). Domains pingen geht nicht und ich vermute irgendwo in der Gegend liegt der Hund begraben - daher habe ich eben auch mit den DNS-Servern getestet.

root@ffka-graf-rhena-strasse:~# ping google.com
ping: bad address 'google.com'
root@ffka-graf-rhena-strasse:~# ping ipv6.google.com
ping: bad address 'ipv6.google.com
root@ffka-graf-rhena-strasse:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=124 time=10.994 ms

(Nachtrag bzgl. IPv6-Ping, 192.168.2.1 ist der Speedport:)

root@ffka-graf-rhena-strasse:~# nslookup google.com 192.168.2.1
Server:		192.168.2.1
Address:	192.168.2.1#53

Name:      google.com
Address 1: 172.217.16.174
Address 2: 2a00:1450:4001:806::200e
root@ffka-graf-rhena-strasse:~# ping 2a00:1450:4001:806::200e
PING 2a00:1450:4001:806::200e (2a00:1450:4001:806::200e): 56 data bytes
^C
--- 2a00:1450:4001:806::200e ping statistics ---
17 packets transmitted, 0 packets received, 100% packet loss

Evtl. ein weiterer Hinweis auf den DNS-Stress, wobei ich nicht weiß, wie ihr das normalerweise handhabt:

root@ffka-graf-rhena-strasse:~# cat /tmp/resolv.conf.auto 
# Interface client
# Interface wan
# Interface wan6

Sollten hier nicht die Server des Freifunk enthalten sein?

Auf der Karte ist der Knoten als Online gelistet, die Verbindungsquali bricht allerdings gelegentlich auch hier ein.

Ich vermute, das irgendwo eine Kleinigkeit verkehrt ist, vielleicht bringt ihr ja Licht ins dunkel bzw. habt Tipps zur weiteren Analayse. Falls irgendwo etwas zu wirr wurde, bitte nachfragen, dann stelle ich klar

Viele Grüße
Yannick

rgr · 12. April 2019 um 18:30

Bin auf dem Sprung, daher nur in Kürze meine Config zum Vergleich:

root@ffka-wiesental-lusshardstr44-garten:~# cat /var/etc/dnsmasq.conf.cfg02411c
# auto-generated config file from /etc/config/dhcp
conf-file=/etc/dnsmasq.conf
dhcp-authoritative
domain-needed
localise-queries
read-ethers
expand-hosts
domain=lan
server=/lan/
server=2001:678:6e3:40d::1
server=2001:678:6e3:40d::2
dhcp-leasefile=/tmp/dhcp.leases
resolv-file=/tmp/resolv.conf.auto
dhcp-broadcast=tag:needs-broadcast
addn-hosts=/tmp/hosts
conf-dir=/tmp/dnsmasq.d
user=dnsmasq
group=dnsmasq
no-dhcp-interface=br-wan
no-dhcp-interface=local-node

root@ffka-wiesental-lusshardstr44-garten:~# ping6 www.google.de
PING www.google.de (2a00:1450:4001:81c::2003): 56 data bytes
64 bytes from 2a00:1450:4001:81c::2003: seq=0 ttl=58 time=53.207 ms

Tests immer per Kabel machen, damit sicher gestellt ist, dass nicht der Nachbar quer funkt.

yanbec · 12. April 2019 um 18:57

Danke dir. Meine /var/etc/dnsmasq.conf.cfg02411c ist exakt identisch, außer ein paar Leerzeilen zwischendrin, sollte wohl nichts machen.
Interessant wäre noch, bei Gelegenheit, der Inhalt der resolv.conf.auto, die ja bei mir leer ist.
Ansonsten hier mal noch die /etc/config/dhcp:

config dnsmasq //die Optionen hier sind schon richtig eingetabbt - sieht nur falsch aus.
option domainneeded '1'
option filterwin2k '0'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option boguspriv '0'
option rebind_protection '0'
option localservice '0'
option localise_queries '1'
list server '2001:678:6e3:40d::1'
list server '2001:678:6e3:40d::2'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config dhcp 'local_client'
	option ignore '1'
	option interface 'client'

config dhcp 'local_node'
	option ignore '1'
	option interface 'local_node'

config domain 'nextnode4_1'
	option name 'nextnode.ffka.space'
	option ip '10.214.55.254'

config domain 'nextnode6_1'
	option name 'nextnode.ffka.space'
	option ip '2001:678:6e3:1050::1:1'

config domain 'nextnode4_2'
	option name 'nextnode'
	option ip '10.214.55.254'

config domain 'nextnode6_2'
	option name 'nextnode'
	option ip '2001:678:6e3:1050::1:1'

Außerdem hab ich noch folgendes im Log entdeckt:
(Ausschnitt, wiederholt sich aber in der Art, keine Ahnung ob das gesund ist.)

Fri Apr 12 20:26:11 2019 kern.warn kernel: [15030.266037] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:26:11 2019 kern.info kernel: [15030.625983] batman_adv: bat0: IGMP Querier disappeared - multicast optimizations disabled
Fri Apr 12 20:26:16 2019 kern.info kernel: [15035.625967] batman_adv: bat0: IGMP Querier appeared
Fri Apr 12 20:26:22 2019 kern.warn kernel: [15041.146073] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:26:22 2019 kern.warn kernel: [15041.266261] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:26:22 2019 kern.info kernel: [15041.625933] batman_adv: bat0: MLD Querier disappeared - multicast optimizations disabled
Fri Apr 12 20:26:25 2019 kern.warn kernel: [15044.836243] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:26:26 2019 kern.warn kernel: [15045.336215] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:26:27 2019 kern.info kernel: [15046.625931] batman_adv: bat0: MLD Querier appeared
Fri Apr 12 20:26:56 2019 kern.warn kernel: [15074.920563] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:27:45 2019 kern.warn kernel: [15124.666176] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:27:45 2019 kern.info kernel: [15124.674090] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Fri Apr 12 20:27:45 2019 kern.warn kernel: [15124.684112] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:27:46 2019 kern.warn kernel: [15124.946344] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:27:46 2019 kern.warn kernel: [15125.106180] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:28:22 2019 kern.warn kernel: [15161.386223] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:28:23 2019 kern.warn kernel: [15162.226139] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:28:23 2019 kern.info kernel: [15162.234049] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Fri Apr 12 20:28:23 2019 kern.warn kernel: [15162.246234] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:28:30 2019 kern.warn kernel: [15169.145106] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:28:36 2019 kern.warn kernel: [15174.970488] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:29:14 2019 kern.warn kernel: [15213.306017] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:29:14 2019 kern.info kernel: [15213.625926] batman_adv: bat0: IGMP Querier disappeared - multicast optimizations disabled
Fri Apr 12 20:29:19 2019 kern.info kernel: [15218.626081] batman_adv: bat0: IGMP Querier appeared
Fri Apr 12 20:29:25 2019 kern.warn kernel: [15224.186051] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:29:25 2019 kern.warn kernel: [15224.366252] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:29:25 2019 kern.info kernel: [15224.625927] batman_adv: bat0: MLD Querier disappeared - multicast optimizations disabled
Fri Apr 12 20:29:26 2019 kern.warn kernel: [15224.926232] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:29:26 2019 kern.warn kernel: [15224.996476] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:29:26 2019 kern.warn kernel: [15225.726331] br-client: received packet on eth1 with own address as source address
Fri Apr 12 20:29:30 2019 kern.warn kernel: [15229.126257] br-client: received packet on eth1 with own address as source address

Schönes Wochenende!

rgr · 12. April 2019 um 19:00

Die .auto ist leer, aber unwichtig. Wichtig:
root@ffka-wiesental-lusshardstr44-garten:~# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1

Zusammen mit den IP-Adressen in der config vom dnsmasq funktioniert die Auflösung.

Hast ping6 getestet?

yanbec · 13. April 2019 um 12:22

Moin! Leider kein Erfolg in Sicht:

root@ffka-graf-rhena-strasse:~# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
root@ffka-graf-rhena-strasse:~# ping6 www.google.de
ping6: bad address 'www.google.de'

rgr · 15. April 2019 um 18:04

ping6 2001:678:6e3:40d::1 und
ping6 2001:678:6e3:40d::2 ?

yanbec · 15. April 2019 um 19:02

Da wäre wieder das packet loss Phänomen:

root@ffka-graf-rhena-strasse:~# ping6 2001:678:6e3:40d::1
PING 2001:678:6e3:40d::1 (2001:678:6e3:40d::1): 56 data bytes
64 bytes from 2001:678:6e3:40d::1: seq=5 ttl=57 time=15.344 ms
64 bytes from 2001:678:6e3:40d::1: seq=34 ttl=57 time=139.152 ms
^C
--- 2001:678:6e3:40d::1 ping statistics ---
48 packets transmitted, 2 packets received, 95% packet loss
round-trip min/avg/max = 15.344/77.248/139.152 ms
root@ffka-graf-rhena-strasse:~# ping6 2001:678:6e3:40d::2
PING 2001:678:6e3:40d::2 (2001:678:6e3:40d::2): 56 data bytes
64 bytes from 2001:678:6e3:40d::2: seq=5 ttl=57 time=15.338 ms
64 bytes from 2001:678:6e3:40d::2: seq=11 ttl=57 time=47.291 ms
64 bytes from 2001:678:6e3:40d::2: seq=17 ttl=57 time=340.380 ms
64 bytes from 2001:678:6e3:40d::2: seq=23 ttl=57 time=15.056 ms
64 bytes from 2001:678:6e3:40d::2: seq=24 ttl=57 time=15.378 ms
64 bytes from 2001:678:6e3:40d::2: seq=25 ttl=57 time=15.338 ms
64 bytes from 2001:678:6e3:40d::2: seq=26 ttl=57 time=52.811 ms
64 bytes from 2001:678:6e3:40d::2: seq=32 ttl=57 time=15.007 ms
64 bytes from 2001:678:6e3:40d::2: seq=39 ttl=57 time=15.041 ms
64 bytes from 2001:678:6e3:40d::2: seq=44 ttl=57 time=45.624 ms
64 bytes from 2001:678:6e3:40d::2: seq=51 ttl=57 time=672.488 ms
64 bytes from 2001:678:6e3:40d::2: seq=63 ttl=57 time=15.564 ms
64 bytes from 2001:678:6e3:40d::2: seq=76 ttl=57 time=49.218 ms
64 bytes from 2001:678:6e3:40d::2: seq=78 ttl=57 time=15.001 ms
64 bytes from 2001:678:6e3:40d::2: seq=97 ttl=57 time=441.358 ms
64 bytes from 2001:678:6e3:40d::2: seq=104 ttl=57 time=15.485 ms
64 bytes from 2001:678:6e3:40d::2: seq=109 ttl=57 time=44.997 ms
64 bytes from 2001:678:6e3:40d::2: seq=121 ttl=57 time=15.831 ms
^C
--- 2001:678:6e3:40d::2 ping statistics ---
142 packets transmitted, 18 packets received, 87% packet loss
round-trip min/avg/max = 15.001/102.622/672.488 ms

Welche Interfaces sollten eine IPv6 Adressierung haben? br-wan hat eine zu meinem Anschluss passende globale, ansonsten nur local-node@local-port.

Pings über das br-wan Interface laufen problemlos. Ich blicke leider zu wenig in die Interna, vor allem das “es geht ein bisschen” ist für mich nicht ganz nachvollziehbar
In der Zwischenzeit hab ich mich um anständige Unterstützung von IPv6 in meinem Lan gekümmert, das läuft jetzt problemlos, auch wenn es mit dem Problem sowieso nichts zu tun haben sollte.

Das hier:
Fri Apr 12 18:10:42 2019 kern.info kernel: [ 6901.944326] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!

Gibt keinen Hinweis auf Ursache?

Grüßle

rgr · 16. April 2019 um 21:24

Die duplicate address habe ich schon mal gesehen, bekomme sie aber nicht zugeordnet.

Was sagt den ping6 2001:678:6e3:1050::2 ?

Und eigentlich sollte jedes Interface eine v6-Adresse haben.

yanbec · 16. April 2019 um 23:27

root@ffka-graf-rhena-strasse:~# ping6 2001:678:6e3:1050::2
PING 2001:678:6e3:1050::2 (2001:678:6e3:1050::2): 56 data bytes
64 bytes from 2001:678:6e3:1050::2: seq=0 ttl=57 time=1677.359 ms
64 bytes from 2001:678:6e3:1050::2: seq=1 ttl=57 time=669.137 ms
64 bytes from 2001:678:6e3:1050::2: seq=2 ttl=57 time=42.836 ms
64 bytes from 2001:678:6e3:1050::2: seq=3 ttl=57 time=17.293 ms
64 bytes from 2001:678:6e3:1050::2: seq=4 ttl=57 time=14.553 ms
64 bytes from 2001:678:6e3:1050::2: seq=5 ttl=57 time=14.914 ms
64 bytes from 2001:678:6e3:1050::2: seq=6 ttl=57 time=14.187 ms
64 bytes from 2001:678:6e3:1050::2: seq=7 ttl=57 time=15.043 ms
64 bytes from 2001:678:6e3:1050::2: seq=8 ttl=57 time=15.271 ms
64 bytes from 2001:678:6e3:1050::2: seq=9 ttl=57 time=14.632 ms
64 bytes from 2001:678:6e3:1050::2: seq=10 ttl=57 time=15.792 ms
64 bytes from 2001:678:6e3:1050::2: seq=11 ttl=57 time=15.158 ms
64 bytes from 2001:678:6e3:1050::2: seq=12 ttl=57 time=15.054 ms
64 bytes from 2001:678:6e3:1050::2: seq=13 ttl=57 time=14.617 ms
64 bytes from 2001:678:6e3:1050::2: seq=14 ttl=57 time=21.631 ms
64 bytes from 2001:678:6e3:1050::2: seq=15 ttl=57 time=14.714 ms
64 bytes from 2001:678:6e3:1050::2: seq=16 ttl=57 time=14.525 ms
64 bytes from 2001:678:6e3:1050::2: seq=17 ttl=57 time=14.680 ms
64 bytes from 2001:678:6e3:1050::2: seq=18 ttl=57 time=14.602 ms
64 bytes from 2001:678:6e3:1050::2: seq=19 ttl=57 time=14.789 ms
64 bytes from 2001:678:6e3:1050::2: seq=20 ttl=57 time=15.779 ms
64 bytes from 2001:678:6e3:1050::2: seq=21 ttl=57 time=17.451 ms
64 bytes from 2001:678:6e3:1050::2: seq=50 ttl=57 time=39.099 ms
64 bytes from 2001:678:6e3:1050::2: seq=51 ttl=57 time=15.359 ms
64 bytes from 2001:678:6e3:1050::2: seq=52 ttl=57 time=21.031 ms
64 bytes from 2001:678:6e3:1050::2: seq=53 ttl=57 time=16.021 ms
64 bytes from 2001:678:6e3:1050::2: seq=56 ttl=57 time=15.905 ms
64 bytes from 2001:678:6e3:1050::2: seq=95 ttl=57 time=35.122 ms
64 bytes from 2001:678:6e3:1050::2: seq=96 ttl=57 time=14.954 ms
64 bytes from 2001:678:6e3:1050::2: seq=97 ttl=57 time=14.759 ms
64 bytes from 2001:678:6e3:1050::2: seq=98 ttl=57 time=14.429 ms
64 bytes from 2001:678:6e3:1050::2: seq=99 ttl=57 time=14.684 ms
64 bytes from 2001:678:6e3:1050::2: seq=100 ttl=57 time=15.050 ms
64 bytes from 2001:678:6e3:1050::2: seq=101 ttl=57 time=14.812 ms
64 bytes from 2001:678:6e3:1050::2: seq=102 ttl=57 time=14.595 ms
64 bytes from 2001:678:6e3:1050::2: seq=103 ttl=57 time=16.159 ms
64 bytes from 2001:678:6e3:1050::2: seq=104 ttl=57 time=16.780 ms
64 bytes from 2001:678:6e3:1050::2: seq=148 ttl=57 time=38.834 ms
64 bytes from 2001:678:6e3:1050::2: seq=149 ttl=57 time=15.024 ms
64 bytes from 2001:678:6e3:1050::2: seq=150 ttl=57 time=17.908 ms
64 bytes from 2001:678:6e3:1050::2: seq=154 ttl=57 time=15.089 ms
64 bytes from 2001:678:6e3:1050::2: seq=199 ttl=57 time=589.395 ms
64 bytes from 2001:678:6e3:1050::2: seq=200 ttl=57 time=23.300 ms
64 bytes from 2001:678:6e3:1050::2: seq=201 ttl=57 time=14.551 ms
64 bytes from 2001:678:6e3:1050::2: seq=202 ttl=57 time=19.554 ms
64 bytes from 2001:678:6e3:1050::2: seq=203 ttl=57 time=15.730 ms
64 bytes from 2001:678:6e3:1050::2: seq=204 ttl=57 time=15.764 ms
64 bytes from 2001:678:6e3:1050::2: seq=205 ttl=57 time=14.585 ms
64 bytes from 2001:678:6e3:1050::2: seq=206 ttl=57 time=14.874 ms
64 bytes from 2001:678:6e3:1050::2: seq=208 ttl=57 time=23.921 ms
64 bytes from 2001:678:6e3:1050::2: seq=209 ttl=57 time=14.958 ms
64 bytes from 2001:678:6e3:1050::2: seq=250 ttl=57 time=37.066 ms
64 bytes from 2001:678:6e3:1050::2: seq=251 ttl=57 time=14.556 ms
64 bytes from 2001:678:6e3:1050::2: seq=252 ttl=57 time=14.410 ms
64 bytes from 2001:678:6e3:1050::2: seq=253 ttl=57 time=15.867 ms
64 bytes from 2001:678:6e3:1050::2: seq=254 ttl=57 time=14.858 ms
64 bytes from 2001:678:6e3:1050::2: seq=256 ttl=57 time=15.389 ms
64 bytes from 2001:678:6e3:1050::2: seq=257 ttl=57 time=14.949 ms
64 bytes from 2001:678:6e3:1050::2: seq=258 ttl=57 time=14.808 ms
64 bytes from 2001:678:6e3:1050::2: seq=259 ttl=57 time=277.169 ms
64 bytes from 2001:678:6e3:1050::2: seq=260 ttl=57 time=15.766 ms
64 bytes from 2001:678:6e3:1050::2: seq=261 ttl=57 time=14.549 ms
64 bytes from 2001:678:6e3:1050::2: seq=262 ttl=57 time=21.185 ms
64 bytes from 2001:678:6e3:1050::2: seq=263 ttl=57 time=17.868 ms
64 bytes from 2001:678:6e3:1050::2: seq=264 ttl=57 time=14.615 ms
^C
--- 2001:678:6e3:1050::2 ping statistics ---
295 packets transmitted, 65 packets received, 77% packet loss
round-trip min/avg/max = 14.187/66.143/1677.359 ms

Die nicht verlorenen Pakete kommen scheinbar selten allein. Hatte bei den ersten 22 schon kurzzeitige Freude, bis es dann wieder versagt hat.

Mit den Adressen hab ich mich wohl etwas ungeschickt ausgedrückt - nur diese beiden Interfaces haben globale v6-Adressen. Falls da doch was nich stimmt hier mal der Auszug:

root@ffka-graf-rhena-strasse:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether da:58:14:d9:4b:c6 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan state UP qlen 1000
    link/ether 34:31:c4:9d:bb:34 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client state UP qlen 1000
    link/ether 34:31:c4:9d:bb:33 brd ff:ff:ff:ff:ff:ff
7: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 9e:1b:0d:8b:3f:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.162/24 brd 192.168.1.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 2003:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic 
       valid_lft 604788sec preferred_lft 86388sec
    inet6 2003:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global deprecated dynamic 
       valid_lft 517569sec preferred_lft 0sec
    inet6 fe80::9c1b:dff:fe8b:3fc8/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 34:31:c4:9d:bb:35 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 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
    inet 10.214.55.254/21 brd 10.214.55.255 scope global local-node
       valid_lft forever preferred_lft forever
    inet6 2001:678:6e3:1050::1:1/128 scope global deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fe80::1441:95ff:fe40:f7dc/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 34:31:c4:9d:bb:35 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::3631:c4ff:fe9d:bb35/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 9e:1b:0d:8b:3f:cb brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9c1b:dff:fe8b:3fcb/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 34:31:c4:9d:bb:35 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::3631:c4ff:fe9d:bb35/64 scope link 
       valid_lft forever preferred_lft forever
13: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UP qlen 1000
    link/ether 9e:1b:0d:8b:3f:c9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9c1b:dff:fe8b:3fc9/64 scope link 
       valid_lft forever preferred_lft forever
14: client0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP qlen 1000
    link/ether 9e:1b:0d:8b:3f:c8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9c1b:dff:fe8b:3fc8/64 scope link 
       valid_lft forever preferred_lft forever
15: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc fq_codel master bat0 state UNKNOWN qlen 1000
    link/ether 9e:1b:0d:8b:3f:cf brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9c1b:dff:fe8b:3fcf/64 scope link 
       valid_lft forever preferred_lft forever

rgr · 17. April 2019 um 15:29

Der Ping war direkt zu dem Gateway an dem Du hängst.
Es sieht daher so aus, als hättest Du Probleme mit der Vebindung zum Gateway. Die anderen Probleme (niedriger Durchsatz usw) kommen daher.

fastd basiert auf udp-Paketen. Hast Du am Speedport irgend einen Filter, oder Gastnetz oder sowas eingestellt?

Für die duplicate address: Wie ist die Verkabelung, hast Du die Standardsettings verändert?

br-client sieht bei Dir merkwürdig aus, das sollte eigentlich v6-Adressen haben.

Wir können ja mal direkt auf batman-Ebene noch schauen.
root@ffka-wiesental-lusshardstr44-garten:~# batctl n
[B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: primary0/9e:ca:3c:13:b7:43 (bat0/64:66:b3:8a:4a:6a BATMAN_IV)]
IF Neighbor last-seen
mesh-vpn aa:ff:ab:03:fe:04 8.690s

root@ffka-wiesental-lusshardstr44-garten:~# batctl ping aa:ff:ab:03:fe:04
PING aa:ff:ab:03:fe:04 (aa:ff:ab:03:fe:04) 20(48) bytes of data
20 bytes from aa:ff:ab:03:fe:04 icmp_seq=1 ttl=50 time=16.31 ms

Aber ich denke, es liegt bei Dir irgendwo rund um den uplink.

herrbett · 17. April 2019 um 15:54

Zum Ausfall Gestern Abend gegen 22 Uhr. Da sind auf unserer Seite Routing Sessions zu einem unserer Transit Provider immer wieder kurz ausgefallen, so das es aus machen Netzen teilweise 60-90 sekündige Erreichbarkeitsprobleme gegeben hat. Wir untersuchen das Problem grade und bis dahin verwenden wir diesen Transit Provider nicht.

An Sonaten sieht es so aus als hätte dein Router Probleme eines unserer Gateways zu erreichen. Das kann viele Gründe habe.
Insbesondere kann es sein das eine Vorgeschaltete Firewall den Traffic falsch erkennt, drosselt oder anders manipuliert. Wichtig ist das der Portbereich 10000 bis 11000 UDP Freigeschaltet ist, den verwenden wir für das VPN.

Auch taucht dein Knoten ohne v6 auf der Karte auf, was mich etwas stutzig macht.
https://map.karlsruhe.freifunk.net/#/de/map#!/de/map/3431c49dbb35

Grüße,
Simon

yanbec · 17. April 2019 um 20:05

Danke euch zwei für die Antworten, ich hab nochmal einiges an Zeit reingesteckt, komme ich aber nicht wirklich weiter.
Der Speedport ist jetzt insofern aus dem Bild, als dass er nurnoch als DSL-Modem agiert, der Archer baut die Verbindung über PPPoE auf, nach ein bisschen frickeln funktioniert das jetzt mit dem Rest meiner Geräte wieder einwandfrei.

Da ich zuvor schon die Freifunk-FB sowohl hinter dem Speedport als auch hinter dem Archer hatte und der Sp jetzt raus ist, kann ich mir kaum vorstellen, dass es am Archer liegt, aber wer weiß. Also hab ich mal ein paar Firewall-Regeln in Luci auf dem Archer zusammengeklaubt, hier liegt aber auch kein Fachwissen meinerseits vor. Dabei kam folgendes raus:

config rule              
        option target 'ACCEPT'
        option src 'wan'      
        option proto 'udp'     
        option src_port '10000-11000'
        option dest_port '10000-11000'
        option name 'Allow-Freifunk-Batman-Forward'
        option dest 'lan'
                             
config rule                   
        option target 'ACCEPT' 
        option src 'wan'
        option proto 'udp'
        option dest_port '10000-11000'     
        option name 'Allow-Freifunk-Batman-Input'
        option enabled '0'
                                      
config rule             
        option target 'ACCEPT'
        option src 'wan'     
        option name 'Allow-Freifunk-Batman-Vxlan'
        option family 'ipv6'
        option proto 'udp'
        option dest 'lan'       
        option dest_port '4789'

Die zweite ist bewusst deaktiviert, hab da mal ein bisschen rumgespielt…

Ping über batman funktioniert wunderbar - ist der hier ausgegebene Neighbor eins der FF-Gateways?

root@ffka-graf-rhena-strasse:~# batctl n
[B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: primary0/9e:1b:0d:8b:3f:cb (bat0/34:31:c4:9d:bb:35 BATMAN_IV)]
IF             Neighbor              last-seen
     mesh-vpn	  fc:fa:51:04:02:00    0.370s
root@ffka-graf-rhena-strasse:~# batctl ping fc:fa:51:04:02:00
PING fc:fa:51:04:02:00 (fc:fa:51:04:02:00) 20(48) bytes of data
20 bytes from fc:fa:51:04:02:00 icmp_seq=1 ttl=50 time=12.19 ms
20 bytes from fc:fa:51:04:02:00 icmp_seq=2 ttl=50 time=12.39 ms
20 bytes from fc:fa:51:04:02:00 icmp_seq=3 ttl=50 time=12.57 ms
[gekürzt]
20 bytes from fc:fa:51:04:02:00 icmp_seq=416 ttl=50 time=12.79 ms
20 bytes from fc:fa:51:04:02:00 icmp_seq=417 ttl=50 time=39.51 ms
20 bytes from fc:fa:51:04:02:00 icmp_seq=418 ttl=50 time=12.86 ms
^C--- fc:fa:51:04:02:00 ping statistics ---
418 packets transmitted, 418 received, 0% packet loss
rtt min/avg/max/mdev = 6.919/13.148/44.250/3.329 ms

Am Wochenende werd ich das Ding mal an nen anderen Uplink hängen können, dann sollte sich ja schließen lassen an welchem Gerät irgendwas falsch läuft. Verbindung von der FB innerhalb meines LANs funktioniert soweit auch, ein dig @192.168.1.2 google.com funzt auch, das wäre mein DNS hier intern.

Bin wirklich sehr gespannt, was hier des Rätsels Lösung sein wird. Bei weiteren Ideen, bitte Bescheid sagen

Achja: Verkabelung aktuell: Wand <-> Speedport als Modem <-> Archer <-> FritzBox

rgr · 17. April 2019 um 21:42

Und was tut nach dem Umbau? Irgendeine Änderung?

yanbec · 17. April 2019 um 23:17

Letzter Post war schon der aktuelle Nach-Umbau-Zustand. Also leider gar keine Änderung soweit ich sehen kann. Aber auch nochmal rumgepingt, das Verhalten bleibt das gleiche wie vorher.

Wie sieht das aus, kann ich die Config irgendwie völlig resetten? Oder erledigt neu flashen das? Wäre zwar schade, wenn dadurch die Ursache unbekannt bleiben würde, vielleicht wäre es ja aber eine Lösung. Aus meiner Sicht sollte der Kram zwar in Ordnung sein, aber ich hab schon echt viel rumgefrickelt in den letzten Tagen und garantiere daher mal lieber für nichts

Nachtrag: Ich hab mal ein bisschen gewiresharked. Die DNS Queries gehen in Richtung der Freifunk-DNS raus, sowohl meine Pings/Digs/Nslookups als auch an den NTP-Server. Als Quell-IP finde ich in den Paketen allerdings die IPv6 des br-wan, die Pakete gehen aber über vpn-mesh (schätze, das ist korrekt?) raus. Die IP hat entsprechend meinen persönlichen Präfix - damit ist auch klar, warum die Responses nicht zurück kommen. Frage nach dem konkreten Fehler bleibt bestehen, aber ich denke es wird langsam warm.

Nachtrag zwei: die Pings an den DNS die verloren gehen, gehen weder über br-wan noch über mesh-vpn überhaupt raus. Wenn dann doch mal einer rausgeht, geht er über das mesh-vpn Interface raus und kommt über br-wan zurück. Ich häng mal nen Screenshot an, sollte die Situation dann ganz gut darlegen.

rgr · 18. April 2019 um 08:22

Schau mal nach Meldungen von fastd im logread.

Neu flashen mit zurücksetzen der Konfiguration (ist eine getrennte Option) ist auf jeden Fall ein Versuch wert.

yanbec · 18. April 2019 um 09:22

Im aktuellen Log findet sich folgendes:

Sat Apr 13 04:44:07 2019 daemon.info fastd[2052]: refreshing session with <mesh_vpn_backbone_peer_alb1>
Sat Apr 13 04:44:07 2019 daemon.info fastd[2052]: sending handshake to <mesh_vpn_backbone_peer_alb1>[185.65.241.22:10140]...
Sat Apr 13 04:44:07 2019 daemon.info fastd[2052]: received handshake response from <mesh_vpn_backbone_peer_alb1>[185.65.241.22:10140] using fastd v18
Sat Apr 13 04:44:07 2019 daemon.info fastd[2052]: 185.65.241.22:10140 authorized as <mesh_vpn_backbone_peer_alb1>
Sat Apr 13 04:44:07 2019 daemon.info fastd[2052]: new session with <mesh_vpn_backbone_peer_alb1> established using method `salsa2012+umac'.

Fastd Restart bringt:

Sat Apr 13 05:19:34 2019 daemon.notice fastd[32765]: fastd v18 starting
Sat Apr 13 05:19:34 2019 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Sat Apr 13 05:19:34 2019 daemon.notice netifd: Network device 'mesh-vpn' link is up
Sat Apr 13 05:19:34 2019 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity 
Sat Apr 13 05:19:34 2019 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Sat Apr 13 05:19:34 2019 daemon.notice fastd[32765]: changed to UID 0, GID 800
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: adding peer <mesh_vpn_backbone_peer_alb3>
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: adding peer <mesh_vpn_backbone_peer_alb1>
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: adding peer <mesh_vpn_backbone_peer_alb2>
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: adding peer <mesh_vpn_backbone_peer_alb0>
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolving host `gwbat01.ffka.vzffnrmo.de' for peer <mesh_vpn_backbone_peer_alb0>...
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolving host `gwbat03.ffka.vzffnrmo.de' for peer <mesh_vpn_backbone_peer_alb2>...
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolving host `gwbat02.ffka.vzffnrmo.de' for peer <mesh_vpn_backbone_peer_alb1>...
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolving host `gwbat04.ffka.vzffnrmo.de' for peer <mesh_vpn_backbone_peer_alb3>...
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolving host `gwbat01.ffka.vzffnrmo.de' failed: Name does not resolve
Sat Apr 13 05:19:35 2019 daemon.notice netifd: Interface 'mesh_vpn' is now up
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolved host `gwbat02.ffka.vzffnrmo.de' successfully
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolving host `gwbat04.ffka.vzffnrmo.de' failed: Name does not resolve
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolved host `gwbat03.ffka.vzffnrmo.de' successfully
Sat Apr 13 05:19:35 2019 kern.info kernel: [47034.438987] batman_adv: bat0: Adding interface: mesh-vpn
Sat Apr 13 05:19:35 2019 kern.info kernel: [47034.444487] 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 Apr 13 05:19:35 2019 kern.info kernel: [47034.469571] batman_adv: bat0: Interface activated: mesh-vpn
Sat Apr 13 05:19:35 2019 user.notice firewall: Reloading firewall due to ifup of mesh_vpn (mesh-vpn)
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: sending handshake to <mesh_vpn_backbone_peer_alb1>[185.65.241.22:10140]...
Sat Apr 13 05:19:35 2019 daemon.info fastd[32765]: resolving host `gwbat02.ffka.tech' for peer <mesh_vpn_backbone_peer_alb1>...
Sat Apr 13 05:19:36 2019 daemon.info fastd[32765]: resolving host `gwbat04.ffka.tech' for peer <mesh_vpn_backbone_peer_alb3>...
Sat Apr 13 05:19:36 2019 daemon.info fastd[32765]: sending handshake to <mesh_vpn_backbone_peer_alb2>[[2001:678:6e0:103::1]:10140]...
Sat Apr 13 05:19:36 2019 daemon.warn fastd[32765]: sendmsg: Operation not permitted
Sat Apr 13 05:19:36 2019 daemon.info fastd[32765]: resolving host `gwbat03.ffka.tech' for peer <mesh_vpn_backbone_peer_alb2>...
Sat Apr 13 05:19:36 2019 daemon.info fastd[32765]: resolving host `gwbat04.ffka.tech' failed: Name does not resolve
Sat Apr 13 05:19:36 2019 daemon.info fastd[32765]: resolved host `gwbat03.ffka.tech' successfully
Sat Apr 13 05:19:36 2019 kern.warn kernel: [47035.625410] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:36 2019 kern.warn kernel: [47035.695422] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:37 2019 kern.warn kernel: [47036.285524] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:38 2019 daemon.info fastd[32765]: resolving host `gwbat01.ffka.tech' for peer <mesh_vpn_backbone_peer_alb0>...
Sat Apr 13 05:19:38 2019 daemon.info fastd[32765]: resolved host `gwbat01.ffka.tech' successfully
Sat Apr 13 05:19:38 2019 daemon.info fastd[32765]: resolved host `gwbat02.ffka.tech' successfully
Sat Apr 13 05:19:45 2019 kern.warn kernel: [47044.483239] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:46 2019 kern.warn kernel: [47045.475168] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:47 2019 kern.warn kernel: [47046.475184] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:53 2019 kern.warn kernel: [47051.986917] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:54 2019 kern.warn kernel: [47052.985172] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:55 2019 kern.warn kernel: [47053.985167] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:19:55 2019 daemon.info fastd[32765]: resolving host `gwbat04.karlsruhe.freifunk.net' for peer <mesh_vpn_backbone_peer_alb3>...
Sat Apr 13 05:19:56 2019 daemon.info fastd[32765]: resolving host `gwbat04.karlsruhe.freifunk.net' failed: Name does not resolve
Sat Apr 13 05:19:57 2019 daemon.info fastd[32765]: sending handshake to <mesh_vpn_backbone_peer_alb1>[[2001:678:6e0:102::1]:10140]...
Sat Apr 13 05:19:57 2019 daemon.info fastd[32765]: received handshake response from <mesh_vpn_backbone_peer_alb1>[[2001:678:6e0:102::1]:10140] using fastd v18
Sat Apr 13 05:19:57 2019 daemon.info fastd[32765]: [2001:678:6e0:102::1]:10140 authorized as <mesh_vpn_backbone_peer_alb1>
Sat Apr 13 05:19:57 2019 daemon.notice fastd[32765]: connection with <mesh_vpn_backbone_peer_alb1> established.
Sat Apr 13 05:19:57 2019 daemon.info fastd[32765]: new session with <mesh_vpn_backbone_peer_alb1> established using method `salsa2012+umac'.
Sat Apr 13 05:20:03 2019 kern.warn kernel: [47061.992696] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:20:03 2019 kern.warn kernel: [47062.905081] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:20:04 2019 kern.info kernel: [47063.104994] batman_adv: bat0: IGMP Querier disappeared - multicast optimizations disabled
Sat Apr 13 05:20:09 2019 kern.info kernel: [47068.104960] batman_adv: bat0: IGMP Querier appeared
Sat Apr 13 05:20:13 2019 daemon.err gluon-radv-filterd[1926]: Unable to find router fc:cb:ff:00:04:01 in transtable_{global,local}
Sat Apr 13 05:20:13 2019 daemon.err gluon-radv-filterd[1926]: Unable to find router fc:cb:ff:00:04:03 in transtable_{global,local}
Sat Apr 13 05:20:15 2019 kern.warn kernel: [47073.925298] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:20:15 2019 kern.warn kernel: [47074.425167] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:20:15 2019 kern.info kernel: [47074.604982] batman_adv: bat0: MLD Querier disappeared - multicast optimizations disabled
Sat Apr 13 05:20:15 2019 kern.warn kernel: [47074.675201] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:20:15 2019 kern.info kernel: [47074.683137] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:20:16 2019 kern.warn kernel: [47075.685419] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:20:18 2019 kern.warn kernel: [47077.265266] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:20:20 2019 kern.warn kernel: [47078.995251] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:20:20 2019 kern.info kernel: [47079.604996] batman_adv: bat0: MLD Querier appeared
Sat Apr 13 05:20:44 2019 kern.warn kernel: [47103.501713] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:21:00 2019 kern.warn kernel: [47119.375335] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:21:00 2019 kern.warn kernel: [47119.775143] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:21:00 2019 kern.info kernel: [47119.783050] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!

Kurze Zeit danach:

Sat Apr 13 05:22:42 2019 daemon.notice fastd[32765]: connection with <mesh_vpn_backbone_peer_alb1> disestablished.
Sat Apr 13 05:22:42 2019 daemon.info fastd[32765]: resolving host `gwbat02.ffka.vzffnrmo.de' for peer <mesh_vpn_backbone_peer_alb1>...
Sat Apr 13 05:22:42 2019 daemon.info fastd[32765]: resolved host `gwbat02.ffka.vzffnrmo.de' successfully
Sat Apr 13 05:22:42 2019 kern.warn kernel: [47221.775155] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:43 2019 kern.warn kernel: [47222.787484] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:44 2019 daemon.info fastd[32765]: sending handshake to <mesh_vpn_backbone_peer_alb1>[[2001:678:6e0:102::1]:10140]...
Sat Apr 13 05:22:44 2019 kern.warn kernel: [47223.785164] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:45 2019 kern.warn kernel: [47224.785145] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:46 2019 kern.warn kernel: [47225.797092] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:47 2019 kern.warn kernel: [47226.795164] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:48 2019 kern.warn kernel: [47227.795163] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:49 2019 kern.warn kernel: [47228.807268] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:50 2019 kern.warn kernel: [47229.805150] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:51 2019 kern.warn kernel: [47230.805146] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:52 2019 daemon.info fastd[32765]: resolving host `gwbat04.ffka.vzffnrmo.de' for peer <mesh_vpn_backbone_peer_alb3>...
Sat Apr 13 05:22:52 2019 daemon.info fastd[32765]: resolving host `gwbat04.ffka.vzffnrmo.de' failed: Name does not resolve
Sat Apr 13 05:22:52 2019 kern.warn kernel: [47231.817293] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:53 2019 kern.warn kernel: [47232.815158] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:54 2019 kern.warn kernel: [47233.815177] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:55 2019 daemon.info fastd[32765]: resolving host `gwbat03.ffka.vzffnrmo.de' for peer <mesh_vpn_backbone_peer_alb2>...
Sat Apr 13 05:22:55 2019 daemon.info fastd[32765]: resolved host `gwbat03.ffka.vzffnrmo.de' successfully
Sat Apr 13 05:22:55 2019 kern.warn kernel: [47234.827213] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:56 2019 daemon.info fastd[32765]: resolving host `gwbat01.ffka.vzffnrmo.de' for peer <mesh_vpn_backbone_peer_alb0>...
Sat Apr 13 05:22:56 2019 daemon.info fastd[32765]: resolving host `gwbat01.ffka.vzffnrmo.de' failed: Name does not resolve
Sat Apr 13 05:22:56 2019 kern.warn kernel: [47235.825164] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:57 2019 kern.warn kernel: [47236.825159] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:58 2019 kern.warn kernel: [47237.836802] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:22:59 2019 kern.warn kernel: [47238.835160] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:00 2019 kern.warn kernel: [47239.835179] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:01 2019 kern.warn kernel: [47240.845508] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:02 2019 kern.warn kernel: [47241.845172] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:03 2019 kern.warn kernel: [47242.845199] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:04 2019 daemon.info fastd[32765]: sending handshake to <mesh_vpn_backbone_peer_alb1>[185.65.241.22:10140]...
Sat Apr 13 05:23:04 2019 daemon.info fastd[32765]: resolving host `gwbat02.ffka.tech' for peer <mesh_vpn_backbone_peer_alb1>...
Sat Apr 13 05:23:04 2019 daemon.info fastd[32765]: resolved host `gwbat02.ffka.tech' successfully
Sat Apr 13 05:23:04 2019 daemon.info fastd[32765]: received handshake response from <mesh_vpn_backbone_peer_alb1>[185.65.241.22:10140] using fastd v18
Sat Apr 13 05:23:04 2019 daemon.info fastd[32765]: 185.65.241.22:10140 authorized as <mesh_vpn_backbone_peer_alb1>
Sat Apr 13 05:23:04 2019 daemon.notice fastd[32765]: connection with <mesh_vpn_backbone_peer_alb1> established.
Sat Apr 13 05:23:04 2019 daemon.info fastd[32765]: new session with <mesh_vpn_backbone_peer_alb1> established using method `salsa2012+umac'.
Sat Apr 13 05:23:04 2019 kern.warn kernel: [47243.854176] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:07 2019 kern.warn kernel: [47245.945177] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:07 2019 kern.info kernel: [47246.104952] batman_adv: bat0: IGMP Querier disappeared - multicast optimizations disabled
Sat Apr 13 05:23:08 2019 kern.warn kernel: [47247.635290] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:09 2019 kern.warn kernel: [47248.105235] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:09 2019 kern.warn kernel: [47248.425176] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:09 2019 kern.info kernel: [47248.433081] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:23:12 2019 kern.info kernel: [47251.104965] batman_adv: bat0: IGMP Querier appeared
Sat Apr 13 05:23:18 2019 kern.warn kernel: [47257.465110] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:18 2019 kern.info kernel: [47257.604953] batman_adv: bat0: MLD Querier disappeared - multicast optimizations disabled
Sat Apr 13 05:23:21 2019 kern.warn kernel: [47260.375452] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:21 2019 kern.warn kernel: [47260.885314] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:22 2019 kern.warn kernel: [47261.415306] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:23 2019 kern.info kernel: [47262.604975] batman_adv: bat0: MLD Querier appeared
Sat Apr 13 05:23:44 2019 kern.warn kernel: [47282.935245] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:44 2019 kern.warn kernel: [47283.015250] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:44 2019 kern.warn kernel: [47283.235174] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:23:44 2019 kern.info kernel: [47283.243069] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:24:05 2019 kern.warn kernel: [47304.615666] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:24:14 2019 kern.warn kernel: [47313.835332] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:24:15 2019 kern.warn kernel: [47314.365203] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:24:15 2019 kern.warn kernel: [47314.645138] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:24:15 2019 kern.info kernel: [47314.653041] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:24:47 2019 kern.warn kernel: [47346.565328] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:24:47 2019 kern.warn kernel: [47346.595233] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:24:48 2019 kern.warn kernel: [47347.125170] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:24:48 2019 kern.info kernel: [47347.133062] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:25:31 2019 kern.warn kernel: [47390.902723] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:25:42 2019 kern.warn kernel: [47401.205330] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:25:42 2019 kern.warn kernel: [47401.505144] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:25:42 2019 kern.info kernel: [47401.513028] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:25:43 2019 kern.warn kernel: [47401.915187] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:25:45 2019 kern.warn kernel: [47404.576557] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:25:46 2019 kern.warn kernel: [47405.575162] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:25:47 2019 kern.warn kernel: [47406.575250] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:03 2019 kern.warn kernel: [47422.179600] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:10 2019 kern.warn kernel: [47428.985054] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:10 2019 kern.info kernel: [47429.104937] batman_adv: bat0: IGMP Querier disappeared - multicast optimizations disabled
Sat Apr 13 05:26:12 2019 kern.warn kernel: [47430.915263] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:12 2019 kern.warn kernel: [47431.065192] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:12 2019 kern.info kernel: [47431.073100] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:26:12 2019 kern.warn kernel: [47431.625213] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:15 2019 kern.info kernel: [47434.104968] batman_adv: bat0: IGMP Querier appeared
Sat Apr 13 05:26:21 2019 kern.warn kernel: [47440.505113] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:21 2019 kern.info kernel: [47440.604968] batman_adv: bat0: MLD Querier disappeared - multicast optimizations disabled
Sat Apr 13 05:26:22 2019 kern.warn kernel: [47441.285262] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:22 2019 kern.warn kernel: [47441.465298] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:25 2019 kern.warn kernel: [47444.735349] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:26 2019 kern.info kernel: [47445.604971] batman_adv: bat0: MLD Querier appeared
Sat Apr 13 05:26:33 2019 kern.warn kernel: [47451.988961] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:41 2019 kern.warn kernel: [47460.595421] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:42 2019 kern.warn kernel: [47460.925147] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:26:42 2019 kern.info kernel: [47460.933067] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:26:42 2019 kern.warn kernel: [47461.055348] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:05 2019 kern.warn kernel: [47484.711515] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:19 2019 kern.warn kernel: [47498.775434] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:20 2019 kern.warn kernel: [47499.355250] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:20 2019 kern.warn kernel: [47499.715115] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:20 2019 kern.info kernel: [47499.723017] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:27:30 2019 kern.warn kernel: [47509.065227] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:30 2019 kern.warn kernel: [47509.205210] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:30 2019 kern.warn kernel: [47509.755347] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:30 2019 kern.info kernel: [47509.763256] IPv6: br-client: IPv6 duplicate address 2001:678:6e3:1050:3631:c4ff:fe9d:bb35 detected!
Sat Apr 13 05:27:38 2019 kern.warn kernel: [47516.958373] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:51 2019 kern.warn kernel: [47530.785233] br-client: received packet on eth1 with own address as source address
Sat Apr 13 05:27:51 2019 kern.warn kernel: [47530.865301] br-client: received packet on eth1 with own address as source address

Habe auch noch das hier gefunden - die sprechen bei dem Verhalten von einem Hardware-Defekt.

Wie sieht das aus mit Flash+Reset - ist das in der Konfiguration nach dem Flashen möglich, ohne neu flashen oder muss ich das im Script mit angeben? Hebe mir das als Option mal auf, falls es an einem anderen Uplink auch nicht geht.

rgr · 18. April 2019 um 12:12

Von der Verkabelung - da geht ein Kabel in den Archer von der FB aus - richtig?
ansonsten mach doch bitte mal
ip a
brctl show
batctl if

yanbec · 18. April 2019 um 12:20

Jap, Kabel WAN-Port FritzBox -> LAN-Port Archer.

root@ffka-graf-rhena-strasse:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether ee:f5:0e:c0:ce:ef brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan state UP qlen 1000
    link/ether 34:31:c4:9d:bb:34 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client state UP qlen 1000
    link/ether 34:31:c4:9d:bb:33 brd ff:ff:ff:ff:ff:ff
7: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 9e:1b:0d:8b:3f:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.162/24 brd 192.168.1.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 fd87:8970:8a09::9c1b:dff:fe8b:3fc8/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 2003:xxxx.../64 scope global dynamic 
       valid_lft 13798sec preferred_lft 1198sec
    inet6 fd87:8970:8a09::a5c/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 2003:xxx.../128 scope global dynamic 
       valid_lft 13797sec preferred_lft 1197sec
    inet6 fe80::9c1b:dff:fe8b:3fc8/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 34:31:c4:9d:bb:35 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 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff
    inet 10.214.55.254/21 brd 10.214.55.255 scope global local-node
       valid_lft forever preferred_lft forever
    inet6 2001:678:6e3:1050::1:1/128 scope global deprecated 
       valid_lft forever preferred_lft 0sec
    inet6 fe80::1441:95ff:fe40:f7dc/64 scope link 
       valid_lft forever preferred_lft forever
10: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UNKNOWN qlen 1000
    link/ether 9e:1b:0d:8b:3f:cb brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9c1b:dff:fe8b:3fcb/64 scope link 
       valid_lft forever preferred_lft forever
11: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 34:31:c4:9d:bb:35 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::3631:c4ff:fe9d:bb35/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 34:31:c4:9d:bb:35 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::3631:c4ff:fe9d:bb35/64 scope link 
       valid_lft forever preferred_lft forever
13: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 state UP qlen 1000
    link/ether 9e:1b:0d:8b:3f:c9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9c1b:dff:fe8b:3fc9/64 scope link 
       valid_lft forever preferred_lft forever
14: client0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client state UP qlen 1000
    link/ether 9e:1b:0d:8b:3f:c8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9c1b:dff:fe8b:3fc8/64 scope link 
       valid_lft forever preferred_lft forever
20: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1406 qdisc fq_codel master bat0 state UNKNOWN qlen 1000
    link/ether 9e:1b:0d:8b:3f:cf brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9c1b:dff:fe8b:3fcf/64 scope link 
       valid_lft forever preferred_lft forever
root@ffka-graf-rhena-strasse:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-wan		7fff.9e1b0d8b3fc8	no		eth0
br-client		7fff.3431c49dbb35	no		eth1
							local-port
							bat0
							client0
root@ffka-graf-rhena-strasse:~# batctl if
primary0: active
mesh0: active
mesh-vpn: active

rgr · 18. April 2019 um 13:15

Wenn ich das Log richtig verstehe, dann kommen da auf eth1 Pakete mit der Adresse, die es eigentlich auf client0 hätte.
Das ist merkwürdig, wenn an eth1 kein Kabel hängt.
Was zeigt swconfig dev switch0 show | grep link:up?
Könntest testweise auch eth1 aus der Bridge entfernen
brctl delif br-client eth1 und dann schauen ob sich nach ein paar Minuten was verändert.

yanbec · 18. April 2019 um 13:38

root@ffka-graf-rhena-strasse:~# swconfig dev switch0 show
Global attributes:
	enable_vlan: 1
Port 0:
	pvid: 1
	link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
Port 1:
	pvid: 1
	link: port:1 link:up speed:100baseT full-duplex auto
Port 2:
	pvid: 1
	link: port:2 link:down
Port 3:
	pvid: 1
	link: port:3 link:down
Port 4:
	pvid: 1
	link: port:4 link:down
VLAN 1:
	vid: 1
	ports: 0 1 2 3 4

Das einzige Ethernet-Kabel an dem Ding ist das im WAN-Port - da scheint also wirklich was falsch zu sein
eth1 aus der Bridge nehmen zeigt sofortige Besserung. Ich bekomme Namen aufgelöst, Pings durch und eine globale IPv6 Adresse auf der Karte. Der Durchsatz ist jetzt noch nich ganz so, wie ich ihn mir wünschen würde (4mbps down, 8 up), aber es funktioniert soweit wirklich einwandfrei.

Also ist Hardware-Defekt evtl. wirklich die Antwort?