Dieses Thema wurde automatisch 4 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.
1.1.5~2 hat “l2tp.” als Prefix vor der SSID sowie eine andere SSID für das WLAN-Meshing, die Netze sind für saubere Tests nun komplett getrennt. Das l2tp-Test-GW tut noch nicht wieder, dafür war gestern leider keine Zeit 
Grmbl!
root@l2tp-gut02:~# ls -la /srv/tunneldigger/tunneldigger/broker/l2tp_broker.cfg*
-rw-r--r-- 1 root root 1869 Mär 23 15:34 /srv/tunneldigger/tunneldigger/broker/l2tp_broker.cfg
-rw-r--r-- 1 root root 1909 Feb 15 10:43 /srv/tunneldigger/tunneldigger/broker/l2tp_broker.cfg.example
Lies: irgendwas hat die Config-Datei zurückgesetzt Fixing …
Toll, kaum macht man’s richtig … Augenscheinlich gibt es derzeit 5 Knoten mit TNG-Firmware (vgl. http://hopglass.4830.org/tng/)?
(Infra für Müritz/Feldberg kommt am Wochenende …)
Yay, DNS funktioniert! Und IPv6!
Fritzbox4020 bei einer Vodafone 50/10 Leitung. Auf jeden Fall besser als mit fastd 
Oh, good catch. Die Signaturen fehlen, tststs!
Edit: Odd one: Aus Platzgründen liegt das Arbeitsverzeichnis gluon-ffgt-v2018.2-tng auf einer anderen Partition, im Build-Skript in dem Verzeichnis wurde auf die Signaturen per …/ referenziert, was aus mir noch nicht so ganz plausiblen Gründen fehlschlägt — die commandline completition von bash komplettiert auch problemlos zu ../secret-build:
ffgt@colosses:~/jenkins_data/build/gluon-ffgt-v2018.2-tng$ ls ../secret-build
ls: cannot access '../secret-build': No such file or directory
ffgt@colosses:~/jenkins_data/build/gluon-ffgt-v2018.2-tng$ ls ../secret-*
ls: cannot access '../secret-*': No such file or directory
ffgt@colosses:~/jenkins_data/build/gluon-ffgt-v2018.2-tng$ (cd .. ; ls secret*)
secret-build secret-xyz
Das. verstehe. ich. grade. nicht? Anyway, Skript auf absoluten Pfad umgestrickt, die betroffenen Dateien nachsigniert — sollte nun tun tun.
Nun klappts 
6 Geräte erfolgreich auf 1.1.5~2 upgedated. Eins via autoupdater -f und den Rest via wget und sysupgrade.
1 „Gefällt mir“
Ansich sollte da mehr gehen.
TP-Link 3600v1, 2.4 GHz (Testgerät: Samsung Note4):
TP-Link 3600v1, 5 GHz (SSID manipuliert zwecks Test):
Zum Vergleich 841 mit fastd:
Alles via Telekom VVDSL2 100/40. Vielleicht sollte ich auch 'ne 4020 mal testen 
Tja, kaum macht man’s richtig … [EDIT: 1300 != 1310 sigh]
Habe mal mit dem Notebook getestet, 3-4 verschiedene Server bei speedtest.net durchprobiert… Schwankt doch relativ stark je nach gewähltem Server 
Hier mein bestes Ergebnis (bei 50/10 Leitung):
Vorher (mit fastd) war meist bei 10-15 Mbit/s Schluss.
Das wiederum dürfte am Routing liegen.
root@l2tp-client:~# speedtest --list | grep -i frankf
3585) LeaseWeb (Frankfurt, Germany) [200.09 km]
10260) Interoute VDC (Frankfurt, Germany) [200.09 km]
7560) 23media GmbH (Frankfurt, Germany) [200.09 km]
9273) DEAC (Frankfurt, Germany) [200.09 km]
10010) fdcservers.net (Frankfurt, Germany) [200.09 km]
18667) meerfarbig GmbH & Co. KG (Frankfurt, Germany) [200.09 km]
19034) Vodafone Kabel Deutschland (Frankfurt, Germany) [200.09 km]
19116) synch.cc (Frankfurt, Germany) [200.09 km]
8040) IP-Projects GmbH & Co. KG (Frankfurt, Germany) [200.09 km]
17312) creoline.de (Frankfurt, Germany) [200.09 km]
21528) Gemnet LLC (Frankfurt, Germany) [200.09 km]
18488) MK Netzdienste (Frankfurt, Germany) [200.09 km]
23870) Kantor System (Frankfurt am Main, Germany) [200.09 km]
23095) 31173 Services AB (Frankfurt, Germany) [200.09 km]
23414) GameMania (Frankfurt, Germany) [200.09 km]
root@l2tp-client:~# speedtest --server 18488
Retrieving speedtest.net configuration...
Testing from Kai Siering (192.251.226.125)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by MK Netzdienste (Frankfurt) [200.09 km]: 32.697 ms
Testing download speed................................................................................
Download: 313.39 Mbit/s
Testing upload speed.....................................................................................................
.Upload: 111.94 Mbit/s
root@l2tp-client:~# traceroute mx4.mk.de.
traceroute to mx4.mk.de. (85.220.139.163), 30 hops max, 60 byte packets
1 _gateway (10.255.8.62) 0.753 ms 0.759 ms 0.710 ms
2 * * *
3 bgp-fra01.4830.org (193.26.120.81) 9.633 ms 9.799 ms 9.778 ms
4 mk-netzdienste.interxion.kleyrex.net (193.189.82.125) 15.142 ms 15.096 ms 15.045 ms
5 ae2.c3.mk.de (213.172.120.10) 16.058 ms 16.052 ms 16.013 ms
6 fw-fra2.mk.de (85.220.206.52) 15.970 ms 15.541 ms 15.119 ms
7 mailin4.mk.de (85.220.139.163) 15.076 ms 15.591 ms 15.281 ms
Zu MK haben wir ein privates Peering via KleyReX, allerdings ist unsere Anbindung zum KleyReX nur 100 MBit/sec breit (100 MBit-Link ist kostenlos, darüber muß man zahlen) => daher höherer Down- als Upload trotz VM im RZ.
Ich nehme daher i. d. R. LeaseWeb in Frankfurt, IIRC haben sie einen 10G-Zugang, d. h. mehrere parallele Tests sollten das Ergebnis nicht so beeinflussen:
root@l2tp-client:~# speedtest --server 3585
Retrieving speedtest.net configuration...
Testing from Kai Siering (192.251.226.125)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by LeaseWeb (Frankfurt) [200.09 km]: 26.802 ms
Testing download speed................................................................................
Download: 378.62 Mbit/s
Testing upload speed......................................................................................................
Upload: 297.51 Mbit/s
Aber ja, die Werte schwanken auch über vermeintlich “dicke” Leitungen:
root@l2tp-client:~# speedtest --server 20764
Retrieving speedtest.net configuration...
Testing from Kai Siering (192.251.226.125)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by Vodafone Deutschland (Hamburg) [214.77 km]: 40.222 ms
Testing download speed................................................................................
Download: 182.92 Mbit/s
Testing upload speed......................................................................................................
Upload: 191.68 Mbit/s
root@l2tp-client:~# traceroute ns3.vodafone.com.
traceroute to ns3.vodafone.com. (47.73.20.173), 30 hops max, 60 byte packets
1 _gateway (10.255.8.62) 0.871 ms 0.848 ms 0.881 ms
2 * * *
3 bgp-ber01.4830.org (193.26.120.86) 15.377 ms 15.353 ms 15.306 ms
4 vodafone.a36.community-ix.de (185.1.74.18) 19.352 ms 19.314 ms 19.268 ms
5 ae5-xcr1.hac.cw.net (195.2.25.233) 43.185 ms 43.138 ms 43.140 ms
6 ae5-xcr1.ham.cw.net (195.2.24.181) 43.116 ms 41.018 ms 40.962 ms
[…]
Zu Vodafone (Hamburg) hätte ich mehr Durchsatz erwartet, Vodafone (nicht: Vodafone Kabel Deutschland) ist Sponsor am Community-IX Berlin.
Vodafone Kabel Deutschland hingegen “paßt”:
root@l2tp-client:~# speedtest --server 19034
Retrieving speedtest.net configuration...
Testing from Kai Siering (192.251.226.125)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by Vodafone Kabel Deutschland (Frankfurt) [200.09 km]: 25.061 ms
Testing download speed................................................................................
Download: 282.56 Mbit/s
Testing upload speed......................................................................................................
Upload: 259.03 Mbit/s
root@l2tp-client:~# traceroute -T www.kabel-deutschland.de
traceroute to www.kabel-deutschland.de (83.169.145.7), 30 hops max, 60 byte packets
1 _gateway (10.255.8.62) 0.826 ms 0.853 ms 0.867 ms
2 * * *
3 bgp-ham02.4830.org (193.26.120.85) 12.784 ms 12.828 ms 14.185 ms
4 iphh.ham.ecix.net (193.42.155.30) 15.099 ms 15.092 ms 15.071 ms
5 kdg.dus.ecix.net (194.146.118.117) 14.497 ms 14.491 ms 14.459 ms
6 ip5886edce.static.kabel-deutschland.de (88.134.237.206) 17.067 ms ip5886edb6.static.kabel-deutschland.de (88.134.237.182) 14.820 ms 17.160 ms
7 ip5886eb0b.static.kabel-deutschland.de (88.134.235.11) 24.667 ms ip5886ca63.static.kabel-deutschland.de (88.134.202.99) 24.003 ms ip5886eb0b.static.kabel-deutschland.de (88.134.235.11) 23.950 ms
8 ip5886edb3.static.kabel-deutschland.de (88.134.237.179) 23.934 ms ip5886edb1.static.kabel-deutschland.de (88.134.237.177) 23.481 ms ip5886edb3.static.kabel-deutschland.de (88.134.237.179) 23.740 ms
9 ip5886cae7.static.kabel-deutschland.de (88.134.202.231) 23.725 ms ip5886caf7.static.kabel-deutschland.de (88.134.202.247) 27.357 ms ip5886cae7.static.kabel-deutschland.de (88.134.202.231) 26.297 ms
10 * * *
11 * * *
12 * * *
13 giga-tv.kabel-deutschland.de (83.169.145.7) 24.168 ms 24.229 ms 23.646 ms
Auch Netcologne sieht besser aus:
root@l2tp-client:~# speedtest --server 6601
Retrieving speedtest.net configuration...
Testing from Kai Siering (192.251.226.125)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by NetCologne (Cologne) [146.07 km]: 42.583 ms
Testing download speed................................................................................
Download: 322.75 Mbit/s
Testing upload speed......................................................................................................
Upload: 312.74 Mbit/s
root@l2tp-client:~# traceroute -T speedtest.netcologne.de
traceroute to speedtest.netcologne.de (78.35.18.142), 30 hops max, 60 byte packets
1 _gateway (10.255.8.62) 0.883 ms 0.840 ms 0.799 ms
2 * * *
3 bgp-ham02.4830.org (193.26.120.85) 12.246 ms 12.222 ms 12.190 ms
4 rtdecix2-po1-2.netcologne.de (80.81.193.212) 12.790 ms 12.747 ms 12.685 ms
5 ip-core-eup1-ae3.netcologne.de (195.14.195.49) 13.324 ms ip-core-eup2-ae3.netcologne.de (195.14.195.53) 13.270 ms 13.201 ms
6 ip-core-sto2-et2-2-2.netcologne.de (87.79.17.22) 12.560 ms ip-core-sto1-et2-2-2.netcologne.de (87.79.17.18) 14.259 ms ip-core-sto1-et10-3-2.netcologne.de (87.79.17.26) 14.226 ms
7 swrt-sto7-te1-2.netcologne.de (78.35.18.22) 14.180 ms swrt-sto7-te1-1.netcologne.de (78.35.18.18) 13.468 ms swrt-sto7-te1-2.netcologne.de (78.35.18.22) 13.436 ms
8 tacho.netcologne.de (78.35.18.142) 13.342 ms 12.936 ms 12.885 ms
Dürfte über unser Remote-Peering am DE-CIX FRA in Hamburg laufen, jenes ist auf 500 MBit/sec derzeit gedrosselt (der gesamte Link an den DE-CIX Hamburg auf 1 GBit/sec).
Von “hier” sieht man halt auch nur den Hinweg (und die genauen Gegenstellen von speedtest kenne ich nicht); 192.251.226.0/24 wird von unserem AS announciert, parallel auch noch von Plusservers AS. Da wir noch keine Routen von PS bekommen, routen wir IPv4 über Berlin, Hamburg, Amsterdam oder Frankfurt IN Richtung Internet, die Antwort kann darüber reinkommen oder auch über Plusserver. (Bei IPv6 hingehen können wir genauer steuern, welches /48 an welchem Standort/über welche Peerings primär laufen soll — das können wir bei IPv4 ohne weitere Netze leider nicht.)
Ohne jetzt alles hier gelesen zu haben.
was mir gestern aufgefallen ist, ist das über den 841 mein Laptop 40Down bei einer 50 Leitung gemessen hat über wieistmeineip.de.
mache ich einen speedtest über speedtest. Net by okla, dann komme ich nur auf 25-30, scheinbar ist da irgendwo etwas voll.
Wie gesagt, ohne die Angabe des Ziels (Hostname oder zumindest ASN) ist die Angabe des Durchsatzes nicht wirklich nachvollziehbar.
Was ich aber klar sehe: meshing halbiert den Durchsatz locker, 841 4m Luftlinie vom 3600er entfernt bringt nicht mal die Hälfte des Durchsatzes am 3600 (beim gleichen Ziel in der Speedtest-App, versteht sich 
). Ist zwar in der Theorie nichts Neues, scheint bei L2TP jedoch stärker ins Gewicht zu fallen als bei fastd — evtl. ‘Fallout’ der höheren Airtime-Nutzung?
FTR, hab’ die meisten meiner Knoten umgestellt auf ‚tng‘. Sieht ganz gut aus, dieser Steckdosenknoten z. B. hängt an Powerline, was offensichtlich arg unsymmetrisch ist:
Den Mesh only Knoten habe ich auf die 1.1. gebracht. Er sendet jetzt ein fröhliches FF_OFFLINE. Jedoch bekomme ich das neue Image nicht auf die 4040, da es scheinbar nicht kompatibel ist 
root@33332-Buschkoettersweg-a86c:/tmp# sysupgrade gluon-4830-1.1.5~5-avm-fritz-box-4040-bootloader.bin
Image metadata not found
Use sysupgrade -F to override this check when downgrading or flashing to vendor firmware
Image check 'fwtool_check_image' failed.
root@33332-Buschkoettersweg-a86c:/tmp# sysupgrade -F gluon-4830-1.1.5~5-avm-fritz-box-4040-bootloader.bin
Image metadata not found
Image check 'fwtool_check_image' failed but --force given - will update anyway!
Saving config files...
Commencing upgrade. Closing all shell sessions.
Nach dem force habe ich nach der Initial Anleitung die 4040 wieder zum Leben erwecken müssen 
Das hätte eigentlich das Vorgehen sein sollen, wie wir es gestern Abend besprochen haben.
Force beim sysupgrade führt fast immer zum Brick, besser nicht machen. (Ich spreche da aus leidvoller Erfahrung — mit Blech, das weniger leicht wieder flott zu machen war.) Kurzum: da ist/war was Mist
Aber das müßte man dann wohl nochmal testen: tut ein Autoupdate von 1.1.2 auf 1.1.5 insbesondere bei der 4040?
Es ging ja noch mal gut. Und ich werde es nicht wieder tun. 
Ich stelle mal eben den branch auf TNG auf der 4040 und teste…
root@33332-Buschkoettersweg-63-a86c:~# autoupdater -f
Retrieving manifest from http://firmware.ipv6.4830.org/tng/sysupgrade/tng.manifest ...
Stopping cron...
Stopping haveged...
Stopping micrond...
Stopping sysntpd...
Stopping gluon-radvd...
Stopping uhttpd...
Stopping sse-multiplexd...
Stopping alfred...
sed: /etc/crontabs/root: No such file or directory
Command failed: Not found
Stopping gluon-respondd...
vm.drop_caches = 3
Downloading image: 6400 / 6400 KiB
Stopping network...
Jetzt bin ich gespannt…
Ist drauf und läuft 
SSID auf default geändert und den 841 wieder auf tng per autoupdater gebracht. Dort gleich auch die SSID ändern und Mesh only testen…
Fazit: Es läuft alles.
- branch auf tng gestellt
- SSID auf KreisGT.freifunkt.net geändert
- der Mesh über Wifi only Knoten ist weiterhin online
- auf der Karte tauchen die beiden Knoten nicht auf, bzw. sind als offline dargestellt
Die Geschwindigkeit sieht auch gut aus. 841 im Wohnzimmer, 4040 auf dem Dachboden und ich bekomme auf dem 841 8,5 MBit down und 4,5 MBit up.
Danke @wusel
Nice. BTW, das “Client-Connect-für-Autoupdater”-Feature sucht nach “freifunk” (in beliebiger Schreibweise, also auch “FrEifunK”) in den SSIDs, und verbindet sich mit dem, IIRC, erstgefundenen offenen Freifunk-Netz. Sprich: SSID hättest Du gar nicht zu ändern brauchen 
Die hatte ich geändert um nicht l2tp auf beiden Knoten zu haben. So verhalten die sich die die Nutzer wie “ganz normale” Knoten.