Hi,

TR geht phone Probleme und die SBG gehen auch. SBG hat manchmal nur ein Wireless Mesh Problem wenn die Bewohner die Kisten in der Wohnung rum tragen…

Grüße Enno

Am 13.01.2023 um 15:42 schrieb Sven Eckelmann sven@narfation.org:

On Tuesday, 6 September 2022 09:11:50 CET Sven Eckelmann wrote:

...

gestern wurde Gluon 2022.1 veroeffentlicht [1,2]. Ich habe dafuer eine experimentelle Firmware fuer Freifunk Vogtland gebaut und auf unsere Server geladen [3]. Diese kann getestet werden und falls Probleme bestehen auch den Gluon-Entwicklern mitgeteilt [4] werden.

Hat hier jemand eins dieser Geraete:

• gluon-ffv-b20221022-exp-8devices-jalapeno-sysupgrade.bin
• gluon-ffv-b20221022-exp-aruba-ap-303h-sysupgrade.bin
• gluon-ffv-b20221022-exp-aruba-ap-303-sysupgrade.bin
• gluon-ffv-b20221022-exp-aruba-ap-365-sysupgrade.bin
• gluon-ffv-b20221022-exp-aruba-instant-on-ap11d-sysupgrade.bin
• gluon-ffv-b20221022-exp-aruba-instant-on-ap11-sysupgrade.bin
• gluon-ffv-b20221022-exp-aruba-instant-on-ap17-sysupgrade.bin
• gluon-ffv-b20221022-exp-avm-fritz-box-4040-sysupgrade.bin
• gluon-ffv-b20221022-exp-avm-fritz-box-7530-sysupgrade.bin
• gluon-ffv-b20221022-exp-avm-fritz-repeater-1200-sysupgrade.bin
• gluon-ffv-b20221022-exp-engenius-ens620ext-sysupgrade.bin
• gluon-ffv-b20221022-exp-gl.inet-gl-ap1300-sysupgrade.bin
• gluon-ffv-b20221022-exp-gl.inet-gl-b1300-sysupgrade.bin
• gluon-ffv-b20221022-exp-linksys-ea6350v3-sysupgrade.bin
• gluon-ffv-b20221022-exp-netgear-ex6100v2-sysupgrade.bin
• gluon-ffv-b20221022-exp-netgear-ex6150v2-sysupgrade.bin
• gluon-ffv-b20221022-exp-openmesh-a42-sysupgrade.bin
• gluon-ffv-b20221022-exp-openmesh-a62-sysupgrade.bin
• gluon-ffv-b20221022-exp-plasma-cloud-pa1200-sysupgrade.bin
• gluon-ffv-b20221022-exp-plasma-cloud-pa2200-sysupgrade.bin
• gluon-ffv-b20221022-exp-zyxel-nbg6617-sysupgrade.bin
• gluon-ffv-b20221022-exp-zyxel-wre6606-sysupgrade.bin

mit dieser Firmware (b20221022-exp, b20221022-exp) und hat da irgendwelche Probleme mit dem WLAN festgestellt?

Kandidaten waeren hier:

• PL-Goethe34-Paulushaus-5
• SBG-Berg8-02
• SBG-Berg9
• SBG-Berg8-01
• TR-Markt10

Gruesse, Sven

On Tuesday, 24 January 2023 17:56:33 CET Enno M. wrote:

Hey, hab hier einen pa1200 liegen, das war der SBG-Berg8-02… dieser hat irgendwie gemesht, aber keine wifi Verbindung zu Clients gemacht. Er war per reinen mesh verbunden. Ich würde den neu flashen und zum Test irgendwo hin bauen. Oder ist es besser euch den zu geben, um evtl. Tests zu machen?

Probier erstmal den neu zu flashen und irgendwo hin zu haengen. Falls danach aber auch nichts geht, waere ein Test bei uns vielleicht ganz sinnvoll.

Gruesse, Sven

On Wednesday, 25 January 2023 23:06:07 CET Enno M. wrote:

Habe die stable gestern drauf gemacht jetzt ist er selbst mit dem WAN uplink halb tot. Wifi geht nicht mehr, ob wohl er die Ssid ausstrahlt und ich auch iov4 und IPv6 bekomme… aber das routing anscheinend hinübergebracht ist… ich schau morgen mal per console drauf… gibt es irgendwelche commands zum testen von VPN, wifi etc? Damit ich evtl. Debug logs aus dem ding bekomme mit dem aktuellen Zustand?

Wenn du IPv4 + IPv6 bekommst, geht die Verbindung zum VPN-Server eigentlich - denn der antwortet auf diese Art von Anfragen.

Interessant waere zu wissen welcher VPN-Server verbunden ist und ob es mittels Ethernet-Kabel besser geht.

Verbundenen VPN-Server siehst du auf der Status-Seite (siehe IPv6-Adresse auf der Map). Ausserdem waere noch die default Route auf deinem Entgeraet interessant (IPv4 + IPv6) - weiss natuerlich jetzt wie das jetzt bei deinem speziellen Entgeraet funktioniert - bei Linux einfach `ip -4 route` und `ip -6 route`. Ansonsten koennte noch interessant sein ob das Routing das Problem ist oder sowas wie DNS. Daher mal 8.8.8.8 + 2001:4860:4860::8888 pingen und sehen ob es geht oder mal ne DNS-Aufloesung (nslookup/dig/...) probieren. Beides von deinem Entgeraet.

Gruesse, Sven

On Thursday, 26 January 2023 18:33:20 CET Enrico Meinel wrote:

# ###################################################################################### # ip -v4 route default via 10.204.48.2 dev wlp0s26u1u4i2 proto dhcp src 10.204.48.183 metric 20600 10.204.48.0/20 dev wlp0s26u1u4i2 proto kernel scope link src 10.204.48.183 metric 600 # ###################################################################################### # ip -v6 route :1 dev lo proto kernel metric 256 pref medium 2a03:2260:200f:102::/64 dev wlp0s26u1u4i2 proto ra metric 600 pref medium fd01:fd59:0:2200::/64 dev wlp0s26u1u4i2 proto ra metric 600 pref medium fe80::/64 dev wlp0s26u1u4i2 proto kernel metric 1024 pref medium default via fe80::ba:7aff:fedf:102 dev wlp0s26u1u4i2 proto ra metric 20600 pref medium # ######################################################################################

Also hier sieht es so aus als waere bei IPv4+IPv6 der VPN01 ausgewaehlt. Man koennte jetzt mittels `batctl n` schauen ob mesh-vpn anzeigt, dass man auf VPN01 mittels fastd verbunden ist (02:12:7b:00:01:02). Aber da du vpn04 anpingen kannst, haette ich jetzt darauf getippt, dass es ein Problem auf dem VPN-Server waere. Wobei auch dieser Traffic nicht direkt zwischen unseren Servern ausgetauscht wird, sondern auch ueber Freifunk-Rheinland geht.

Uebrigens der Test mit dem IPv6 ist scheinbar nicht soooo gut gewaehlt. Vielleicht macht 2a02:2e0:3fe:1001:302:: mehr Sinn

Und du koenntest halt auch mal traceroute nach 8.8.8.8 bzw. 2a02:2e0:3fe:1001:302:: anschauen. Hier nur mal als Vergleich (wenn es funktioniert ueber VPN01 + ffv_tr):

Host Loss% Snt Last Avg Best Wrst StDev 1. 10.204.48.2 0.0% 11 26.1 37.4 24.7 87.8 19.2 2. 185.66.194.0 0.0% 10 50.6 45.0 35.6 72.2 11.4 3. 80.81.192.108 0.0% 10 40.2 46.1 40.2 65.4 8.9 4. 108.170.252.1 0.0% 10 59.2 56.4 46.6 92.3 14.4 5. 142.250.214.193 0.0% 10 46.8 47.9 44.7 60.5 4.6 6. 8.8.8.8 0.0% 10 45.3 74.2 44.6 214.4 52.6

Host Loss% Snt Last Avg Best Wrst StDev 1. 2a03:2260:200f:102::1 0.0% 12 28.1 29.3 24.7 53.5 8.6 2. 2a03:2260::1 0.0% 12 41.8 44.0 39.2 62.1 6.3 3. (waiting for reply) 4. (waiting for reply) 5. 2a02:2e0:12:34::2 0.0% 11 50.7 61.6 50.0 94.0 14.9 6. 2a02:2e0:3fe:0:c::1 0.0% 11 60.6 62.1 46.7 101.7 16.5 7. 2a02:2e0:3fe:1001:302:: 0.0% 11 69.0 55.3 48.0 73.3 10.0

On Thursday, 26 January 2023 18:33:20 CET Enrico Meinel wrote:

Ich habe jetzt die aktuelle experimental per sysupgrade nochmal drauf geschoben ohne einer Datenübernahme. Mal sehen was wird. Ich teste dann die Tage nochmal. Gibt es evtl. irgendwelche Sachen, welche man auf dem Knoten ausführen kann?

Fuer diesen Fall nicht so viel, da der Traffic einfach nur in den Tunnel zum VPN gebridged wird (oder halt zum naechsten Knoten im Mesh). Man kann halt mal schauen ob der Tunnel korrekt funktioniert. Vielleicht mal mit tcpdump auf mesh-vpn nutzen um ein PCap zu schreiben (am besten direkt ueber Ethernet schreiben: `ssh root@2a03:2260:200f:302:4e13:65ff:fe00:16c0 tcpdump -ni mesh-vpn -w- > test.pcap` .Wireshark kann die diversen Header auch parsen.

Da hatte ich ping und nslookup probiert, aber auch da ging kein Routing durch, bzw. war das auch wie auf dem Client ohne erfolg.

Ich habe gerade beir mir lokal mal einen Knoten auf VPN01 und ffv_tr umgestellt - um zu sehen ob ich das Verhalten nachvollziehen kann. Leider sehe ich da keine Probleme bei mir. Ich schreibe gerade selber ueber diese Verbindung.

Gruesse, Sven