Gluon braucht Menschen die Tunneldigger-Änderungen testen

Technik Gluon
1

Von Zeit zu Zeit haben wir Änderungen, die die Tunneldigger-Implementierung in Gluon betreffen. Bedauerlicherweise ist keiner der aktiven Gluon-Entwickler auch aktiver Nutzer einer Tunneldigger-Infrastruktur. Daher fehlen uns regelmäßig Menschen, die Änderungen im Tunneldigger-Umfeld testen können.

Gut wäre, wenn wir euch einfach auf GitHub markieren könnten, so dass ihr dann eine Nachricht erhaltet, wenn Tests notwendig sind.

Wer mal reinschauen mag, worum es aktuell geht, der kann unter Pull-Requests auf das „Topic: Tunneldigger“ Label filtern.

[Issues · freifunk-gluon/gluon · GitHub]

Ohne, dass jemand diese Änderungen testet können sich unangenehme Fehler in Releases befinden, die man leicht im vornhinein beheben könnte. Eure Beteiligung ist also gefragt.

1 „Gefällt mir“
2

Hast Du evtl. einen Link zu einer Kurzanleitung, wie Leute das am einfachsten für ihre Community bauen können? Also „Master-Build von welchem Fork/Gitit“? Einfach um ein paar mehr Communities dafür zu interessieren.

3

Kurz und knapp:

Gluon bauen, wie üblich, aber an passender Stelle die Änderung reinmergen:

# Zunächst Gluon vom Master Branch auschecken
git clone https://github.com/freifunk-gluon/gluon.git 

cd gluon

# Dann die eigene Site clonen, hier müssen ggf. Änderungen gemacht
# werden damit diese mit dem Gluon master Branch kompatibel ist
git clone https://github.com/example/site.git

# Hier dann den passenden Branch reinmergen
# siehe unten

make update

# Dann für Target, mit dem man testen will bauen
make -j $(nproc) GLUON_TARGET=ipq40xx

Für

git merge mesh-vpn-fix-limits

und für

git remote add MPW1412 https://github.com/MPW1412/gluon.git
git fetch MPW1412
git merge MPW1412/add-td-watchdog
1 „Gefällt mir“
4

Änderungen in master sind z.z. Nur, dass man die Felder basic_rates und supported_Rates raus nehmen muss und dass alle alten obsolete Werte zu einem fatalen Error führen

5

Korrekt, denn die 802.11b (Legacy Data Rates) sind ab dem kommenden v2019.1 Release standardmäßig deaktiviert.

6

Gibt es da irgendwo einen Konverter/Filter für site.conf/site.mk von 2018.2.x auf den upcomfing 2019.x?
(ich sehe schon wieder einen Haufen Communites auf der Strecke bleiben bei breaking changes)

7

Nein, werden wir auch mangels Manpower nicht anbieten.

Allerdings gibt es seit kurzem ein Feature, mit dem wir Fehler werfen können, wenn alte bzw. überholte Felder in der site.conf gesetzt sind. Es geht also bergauf. Leider passiert das erst am Ende des Builds, weil vorher nicht klar ist, was in der site.conf stehen darf und was nicht.

8

Und welche Module sind dann der site.mk hinzuzufügen?
offensichtlich keine. Der alte gluon-tunneldigger-watchdog aus dem ffrl-repository muss natürlich entfernt werden aus der site.mk.
Und es hilft wenn man in der site.conf das statement opkt.lede gegen opkt.openwrt zu tauschen.

9

looks fine, killed tunneldigger manually, waited 5 minutes:

Sun Jun 16 06:00:00 2019 user.notice tunneldigger-watchdog: Process-Pid does not match with pid-File.
Sun Jun 16 06:00:00 2019 user.notice tunneldigger-watchdog: Restarting Tunneldigger.
Sun Jun 16 06:00:01 2019 daemon.info td-client: Performing broker selection...
Sun Jun 16 06:00:02 2019 daemon.debug td-client: Broker usage of flingern-l.ffdus.de:10000: 1215
Sun Jun 16 06:00:02 2019 daemon.debug td-client: Broker usage of flingern-m.ffdus.de:10000: 1215
Sun Jun 16 06:00:02 2019 daemon.info td-client: Selected flingern-l.ffdus.de:10000 as the best broker.
Sun Jun 16 06:00:03 2019 daemon.info td-client: Tunnel successfully established.
Sun Jun 16 06:00:03 2019 daemon.info td-client: Requesting the broker to configure downstream bandwidth limit of 8000 kbps.
Sun Jun 16 06:00:03 2019 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Sun Jun 16 06:00:03 2019 daemon.notice netifd: Network device 'mesh-vpn' link is up
Sun Jun 16 06:00:03 2019 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Sun Jun 16 06:00:03 2019 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Sun Jun 16 06:00:04 2019 daemon.notice netifd: Interface 'mesh_vpn' is now up
Sun Jun 16 06:00:04 2019 user.notice firewall: Reloading firewall due to ifup of mesh_vpn (mesh-vpn)
Sun Jun 16 06:00:05 2019 kern.warn kernel: [  725.579304] batman_adv: [Deprecated]: sh (pid 4918) Use of sysfs file "mesh_iface".
Sun Jun 16 06:00:05 2019 kern.warn kernel: [  725.579304] Use batadv genl family instead
Sun Jun 16 06:00:05 2019 kern.warn kernel: [  725.927405] batman_adv: [Deprecated]: sh (pid 4918) Use of sysfs file "mesh_iface".
Sun Jun 16 06:00:05 2019 kern.warn kernel: [  725.927405] Use batadv genl family instead
Sun Jun 16 06:00:05 2019 kern.info kernel: [  725.940876] batman_adv: bat0: Adding interface: mesh-vpn
Sun Jun 16 06:00:05 2019 kern.info kernel: [  725.946430] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1364) 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.
Sun Jun 16 06:00:05 2019 kern.info kernel: [  725.971746] batman_adv: bat0: Interface activated: mesh-vpn
Sun Jun 16 06:00:05 2019 daemon.err gluon-radv-filterd[1609]: Unable to find router ea:4f:f5:df:b6:94 in transtable_{global,local}
Sun Jun 16 06:00:05 2019 daemon.err gluon-radv-filterd[1609]: Switching to ea:4f:f5:df:b6:94 (TQ=0)
Sun Jun 16 06:00:12 2019 user.notice gluon-linkcheck: batadv.primary0:0 batadv.mesh0:0 mesh0.neighbours:1 mesh0.wadhoc:26
10

Auf welche Adresse wurde der respondd umgestellt? Der knoten ist online, wird vom Kartenserver aber nur noch indirekt über seine Nachbarn gesehen?

Sieht defekt aus!

 Thu May  9 18:04:30 2019 daemon.info td-client: Requesting the broker to configure downstream bandwidth limit of 12000 kbps.

habe dann nochmal ein „firstboot“ und dann Setup per WebUI versucht, und obwohl der Haken „Bandbreite begrenzen“ ganz klar NICHT gesetzt war und auch der UCI-Output damit stimmig aussieht:

gluon.mesh_vpn.limit_ingress='12000'
gluon.mesh_vpn.limit_enabled='0'
gluon.mesh_vpn.limit_egress='1000'

obiges bleibt, zumindest wird der egres angefordert laut syslog.

p.S. auch wenn man es umstellt:

uci set gluon.mesh_vpn.limit_enabled=1
uci commit

bleibt es dabei: Es wird beim upstream ein limit angefragt, die logik ist als NICHT invertiert, sondern wird offensichtlich immer angewendet

Sun Jun 16 17:40:06 2019 daemon.info td-client: Requesting the broker to configure downstream bandwidth limit of 12000 kbps.

ich hab noch ein paar mal getoggelt und jeweils neu gebootet, es bleibt dabei:

Sun Jun 16 17:46:35 2019 daemon.info td-client: Requesting the broker to configure downstream bandwidth limit of 15000 kbps.
2 „Gefällt mir“
11

Ist das der übliche Fehlerfall? Also dass der Tunneldigger wegstirbt? Ansonsten gibt es auch noch den Testfall, dass einfach keine batman-adv Nachbarn mehr existieren, aka die Verbindung tot ist.

12

Kann ich gern testen, den Tunnel auf der Supernode-Seite mal aus der batman-Bridge zu hängen.
Aber vorher…

grafik
grafik1029×308 41.7 KB

13

tunnel per brctl delif auf dem supernode ausgehangen, gewartet. Knoten kommt zurück. → OK

Logs:

Sun Jun 16 20:40:00 2019 user.notice tunneldigger-watchdog: No vpn-mesh neighbours found.
Sun Jun 16 20:40:00 2019 user.notice tunneldigger-watchdog: Restarting Tunneldigger.
Sun Jun 16 20:40:01 2019 daemon.warn td-client: Got termination signal, shutting down tunnel...
Sun Jun 16 20:40:01 2019 daemon.notice netifd: Network device 'mesh-vpn' link is down
Sun Jun 16 20:40:01 2019 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity loss
Sun Jun 16 20:40:01 2019 kern.info kernel: [10415.480034] batman_adv: bat0: Interface deactivated: mesh-vpn
Sun Jun 16 20:40:01 2019 kern.info kernel: [10415.551417] batman_adv: bat0: Removing interface: mesh-vpn
Sun Jun 16 20:40:01 2019 daemon.notice netifd: Interface 'mesh_vpn' is disabled
Sun Jun 16 20:40:02 2019 daemon.info td-client: Performing broker selection...
Sun Jun 16 20:40:03 2019 daemon.debug td-client: Broker usage of flingern-l.ffdus.de:10000: 1023
Sun Jun 16 20:40:03 2019 daemon.debug td-client: Broker usage of flingern-m.ffdus.de:10000: 1343
Sun Jun 16 20:40:03 2019 daemon.info td-client: Selected flingern-l.ffdus.de:10000 as the best broker.
Sun Jun 16 20:40:04 2019 daemon.info td-client: Tunnel successfully established.
Sun Jun 16 20:40:04 2019 daemon.info td-client: Requesting the broker to configure downstream bandwidth limit of 15000 kbps.
Sun Jun 16 20:40:04 2019 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Sun Jun 16 20:40:04 2019 daemon.notice netifd: Network device 'mesh-vpn' link is up
Sun Jun 16 20:40:04 2019 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Sun Jun 16 20:40:04 2019 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Sun Jun 16 20:40:05 2019 daemon.notice netifd: Interface 'mesh_vpn' is now up
2 „Gefällt mir“
14

Awesome, danke! Merge ich dann nun.

1 „Gefällt mir“
15

wobei das Tunndeldigger-bwlimit immernoch defekt zu sein scheint, egal was man einstellt… er requested in limit.

root@Alfred-Koppel:~# uci show |grep vpn|grep limit
gluon.mesh_vpn.limit_egress='1000'
gluon.mesh_vpn.limit_ingress='131313'
gluon.mesh_vpn.limit_enabled='0'
simple-tc.mesh_vpn.limit_egress='1000'
tunneldigger.mesh_vpn.limit_bw_down='131313'
root@Alfred-Koppel:~# logread|grep limit
[..]
Sun Jun 16 21:07:05 2019 daemon.info td-client: Requesting the broker to configure downstream bandwidth limit of 131313 kbps.

da half jetzt auch kein Neubauen nach https://github.com/freifunk-gluon/gluon/compare/mesh-vpn-fix-limits

BTW: der arme 841er wird weitergenutzt…

grafik
grafik1280×960 333 KB

16

Danke für’s Testen, @adorfer :grinning:.

18

Apropos Tunndeldigger-Änderungen:

git://-URLS sind wohl seit kurzen nicht nur deprecated, sondern schlicht nicht mehr nutzbar.

tunneldigger-2020-05-17-8995046a.tar.xz: Download from git://github.com/wlanslovenija/tunneldigger.git failed

Für gluon 2021.1.x habe ich jetzt übergangsweise einen Patch, damit es weiterhin baut.

1 „Gefällt mir“
19

Gestern (11.01.2022) stand der finale Brownout bei GitHub für das git:// Protokoll auf dem Programm.

Am 15.03. wird es dann wohl die Finale Abschaltung geben. Bis dahin sollte das also möglichst umgestellt werden.

20

Ich habe dann mal einen PR upstream gemacht.

2 „Gefällt mir“
21

Das bedeutet auch, dass alle ältere Gluon-Versionen ohne Anpassungen nicht mehr gebaut werden können, oder? Weil die Abhängigkeiten, zumindest die von Github, nicht mehr nachgeladen werden können, oder?

1 „Gefällt mir“