Hallo zusammen,
im Augenblick scheint sich unser Freifunk nicht gut anzufühlen. Die Geschwindigkeit ist mal schlecht, mal nicht gegeben. Ist mit dem Backbone alles in Ordnung?
Hallo phip,
ich hatte gestern ähnliche Probleme, die sehr schnell gelöst worden sind, nachdem ich mich direkt an die Admins unter request@freifunk-rheinland.net gewendet habe.
Ich würde dir daher diese Vorgehensweise empfehlen.
Grüße
Lukas
Danke Lukas. Ich habe es auch auf diesem Weg gemeldet.
Anfangs dachte ich, dass dies durch die Aufschaltung von Radevormwald verursacht wurde. Aber selbst in der alten Konfiguration ist das Internet nicht stabil.
Dieser Sreenahot zeigt die Verbindungsqualität auf Wupper1. Auf Wupper0 ist sie nicht ganz so drastisch. wupper1 ist derzeit unzumutbar – die Uploads brechen ab – und fungiert nicht als Gateway
im dmesg von Wupper0 finden sich lauter
UDP: bad checksum. From xxx.xxx.xxx.xxx:34721 to 185.66.194.20:1024 ulen 1391
UDP: bad checksum. From xxx.xxx.xxx.xxx:24093 to 185.66.194.20:25901 ulen 1388
diese waren schon immer da, manche von denen haben den Bug in bat15 provoziert, der bei uns gepatcht ist.
neu sind diese Meldungen:
diese tauchen sehr selten auf, bis jetzt 3 Mal beobachtet
net_ratelimit: 1 callbacks suppressed
net_ratelimit: 5 callbacks suppressed
und diese tauchen 362 s nachdem bat15 von gw client auf server wechselt:
nr_pdflush_threads exported in /proc is scheduled for removal
sysctl: The scan_unevictable_pages sysctl/node-interface has been disabled for lack of a legitimate use case. If you have one, please send an email to linux-mm@kvack.org.
Die auf w0 beschriebenen dmesg-Meldungen waren auch bei w1 zu sehen, als dieser das GW war.
hier ein auszug aus der w1-Konfiguration:
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
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
inet 185.66.194.21/32 scope global 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 state UP group default qlen 1000
link/ether 00:1a:4a:4c:d9:83 brd ff:ff:ff:ff:ff:ff
inet 84.22.100.2/24 brd 84.22.100.255 scope global dynamic eth0
valid_lft 536476sec preferred_lft 536476sec
inet6 2a02:2770:12:0:21a:4aff:fe4c:d983/64 scope global mngtmpaddr dynamic
valid_lft 2591782sec preferred_lft 604582sec
inet6 fe80::21a:4aff:fe4c:d983/64 scope link
valid_lft forever preferred_lft forever
3: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default
link/gre 0.0.0.0 brd 0.0.0.0
4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: tun-ffw-fra@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default
link/gre 84.22.100.2 peer 185.66.194.0
inet 100.64.0.39/31 scope global tun-ffw-fra
valid_lft forever preferred_lft forever
inet6 2a03:2260:0:16::2/126 scope global
valid_lft forever preferred_lft forever
inet6 fe80::200:5efe:5416:6402/64 scope link
valid_lft forever preferred_lft forever
6: tun-ffw-ber@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default
link/gre 84.22.100.2 peer 185.66.195.0
inet 100.64.0.37/31 scope global tun-ffw-ber
valid_lft forever preferred_lft forever
inet6 2a03:2260:0:15::2/126 scope global
valid_lft forever preferred_lft forever
inet6 fe80::200:5efe:5416:6402/64 scope link
valid_lft forever preferred_lft forever
7: fastd-wup: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1426 qdisc fq_codel master bat-wup state UNKNOWN group default qlen 500
link/ether 04:be:e1:ba:fe:10 brd ff:ff:ff:ff:ff:ff
inet6 fe80::6be:e1ff:feba:fe10/64 scope link
valid_lft forever preferred_lft forever
8: bat-wup: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 5e:b2:1d:a3:da:98 brd ff:ff:ff:ff:ff:ff
inet 10.3.0.241/16 brd 10.3.255.255 scope global bat-wup
valid_lft forever preferred_lft forever
inet6 fda0:747e:ab29:e1ba:ff01::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5cb2:1dff:fea3:da98/64 scope link
valid_lft forever preferred_lft forever
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@wupper1 ~]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- !100.64.0.0/16 anywhere to:185.66.194.21
ip rule show
0: from all lookup local
32763: from all iif bat-rdv [detached] lookup 16
32764: from all iif bat-wup lookup 16
32765: from 185.66.194.16/29 lookup 16
32766: from all lookup main
32767: from all lookup default
ip route show
default via 84.22.100.1 dev eth0 proto dhcp src 84.22.100.2 metric 1024
10.3.0.0/16 dev bat-wup proto kernel scope link src 10.3.0.241
84.22.100.0/24 dev eth0 proto kernel scope link src 84.22.100.2
84.22.100.1 dev eth0 proto dhcp scope link src 84.22.100.2 metric 1024
100.64.0.36/31 dev tun-ffw-ber proto kernel scope link src 100.64.0.37
100.64.0.38/31 dev tun-ffw-fra proto kernel scope link src 100.64.0.39
bird> show route
0.0.0.0/0 via 100.64.0.38 on tun-ffw-fra [ffrl_fra 07:46:23] * (100/0) [AS201701i]
via 100.64.0.36 on tun-ffw-ber [ffrl_ber 15:27:52] (100/0) [AS201701i]
10.3.0.0/16 dev bat-wup [direct1 15:27:48] * (240)
185.66.194.21/32 dev lo [direct1 15:27:48] * (240)
84.22.100.0/24 dev eth0 [direct1 15:27:48] * (240)
100.64.0.36/31 dev tun-ffw-ber [direct1 15:27:48] * (240)
100.64.0.38/31 dev tun-ffw-fra [direct1 15:27:48] * (240)
Es scheint sich um ein GRE/BGP-Problem zu handeln. Der Fehler ist im Tunnel eingenistet.
von w1 nach w0 über FFRL-ISP
von hier nach w1
minimale Fehler bei w0
Wo kann der Wurm stecken?
Für mich sieht das eher nach packetloss auf der Anbindung von Unitymedia aus.
Vergiss bitte die Unitymedia-Anbindung. Nicht jeder Internet-Router muss einen Ping beantworten. Die dahinterliegenden Pings kommen ja durch …
Ich behaupte das liegt am GRE/BGP. Um noch deutlicher zu werden:
[root@wupper0 ~]# mtr --address 185.66.194.20 185.66.194.21
[root@wupper1 ~]# mtr --address 185.66.194.21 185.66.194.20
bei den nicht beantworteten Pings kommen auch keine Daten durch. Bei Unitymedia dagegen kommen bei nicht beantworteten Pings Daten durch.
Wie gesagt, das Problem mit 55% ist auf w1 extrem, bei w0 mit 2,4% zu verschmerzen. Woran liegt das Problem, wenn bei uns die Konfiguration nicht geändert wurde?
Den Fehler hat @thomasDOTwtf gestern behoben. Vielen Dank dafür! Bitte bei Zeit und irgendeiner Gelegenheit beschreiben, damit man d’raus lernen kann.
1 „Gefällt mir“