die knoten sind an inet leitungen klar.
aber die daten gehen durch ffnw vpn und netzwerk, also ist das netzwerk das was gemessen wird mit dem knoten der dran hängt.
Nein. (20 Zeichen 20).
dann bitte erklären.
Nur Traffic aus dem WLAN oder je nach Config des Knoten an dessen LAN Buchsen geht über die Freifunk Infrastruktur ins Internet. Jede Aktion die du von der SSH Console aus machst, geht über die am WAN Port angeschlossene Internet Verbindung raus, ohne VPN.
Wenn du die Leistungsfähigkeit eines Knoten Näherungsweise ermitteln willst, schließt du einen Test PC an den LAN Ports des Knoten an und misst direkt zu einem der Gateways. Iperf oder ne große Datei via FTP oder HTTP sind dann das mittel der Wahl.
1 „Gefällt mir“
Wobei dieser Wert schon mal erheblich vom tatsächlichen abweichen kann.
Ich tendiere daher mitlerweile zu einem Torrent Download.
Mit einem simplen Download erreiche ich z.B. auf meiner CPE210 an einem 16MBits Anschluss nur etwa 9MBits. Mit mehreren Verbindungen via Torrent nahezu die vollen 16MBits.
Ein anderer Fall mit einem 1043v2 an einem Futro S550 Offloader (VLAN Konfig) via Tkom VDSL50. Einfache Verbindung etwa 15MBits, Torrent ca. 45MBits. Das ganze im Kieler FF Netz mit Exit über hide.me.
1 „Gefällt mir“
Bei uns macht das keinen Unterschied wenn die Gegenstelle das Gateway selbst ist. Wir haben mehrere Dateien von 10 - 1000 MB auf dessen Webserver liegen und egal ob ich nun mit nur einer Session oder via Download Manager, der mehrere parallele Verbindungen aufbaut, ziehe, es nimmt sich nicht viel. Bei nem reinen Internet Speedtest kommt ja noch der OpenVPN Tunnel hinzu, und je nachdem wie der ausgelastet ist kommt es zu mehr oder weniger stark schwankenden Ergebnissen.
danke euch für die nachhilfe,
ich werde mal nachsitzen und dazu lernen 
es wird bei uns aller voraussicht nach so laufen, dass mit dem verlinkten hoodgen-tool unser „Einzugsbereich“ flächendeckend in die sog. Hoods eingeteilt wird. Jede Hood besteht dabei aus beliebig vielen Rechtecken unterschiedlicher Größe. Die Koordinaten dieser Rechtecke werden dann mit ihrer Zuordnung zu der Hood vom Hoodgen in eine json-datei geschrieben, die auf die Server wandert.
Die Router werden dann ein kleines PHP-Skript auf dem Server aufrufen, an dieses per GET die Koordinaten übergeben und als Antwort die auf der json-Datei basierend passenden Parameter (Server, Key, E/BSSID).
So ist das zumindest bisher geplant, verzögert sich allerdings gerade alles etwas, weil wir mit dieser Umstellung auch gleichzeitig dabei sind, unsere Server-Landschaft auf die Verwaltung mit Puppet umzustellen.
Hier fehlt noch IPv6 in der Erklärung.
Die Freifunkknoten haben nur eine IPv6, keine IPv4, weil sie diese gefakte haben. Alle FF-Knoten in einer Domäne haben dieselbe IPv4, deswegen können die Knoten selbst über IPv4 nur über das Netzwerk des Knotenbetreibers, nicht über das Freifunknetz kommunizieren.
Das sieht du auch daran, dass reine Meshknoten kein IPv4 können. Über IPv6 geht es aber über Freifunk, d.h. du musst dir als Testdownload etwas mit reinem IPv6 suchen.
Das haben wir auch schon drei mal mindestens durchgekaut hier ;).
Grüße
Matthias
1 „Gefällt mir“
[quote=„baranator, post:35, topic:8881“]
Die Router werden dann ein kleines PHP-Skript auf dem Server aufrufen, an dieses per GET die Koordinaten übergeben und als Antwort die auf der json-Datei basierend passenden Parameter (Server, Key, E/BSSID).[/quote]
Okay, ähnliches Schema, aber andere Datenbasis, wie bei uns.
Wobei: Ihr dynamisiert die site.conf, indem die peer-Infos von jenem PHP-Skript kommen? Hmm, interessanter Gedanke; man könnte statt nur ein paar Daten gleich eine site.conf übertragen … Hmm …
Anyway: Wir (Kreis Gütersloh) nutzen bestehende Dienste (hier: nominatim/OSM) für die Geo-Lokalisierung. Dies läuft ebenfalls serverbasiert, der Knoten schickt unserem Server seine Node-ID (== primäre MAC) sowie die aktuellen Geo-Koordinaten, das Skript spuckt die Ausgabe des Reverse-Geocodings aus (Straße wird für den Namensvorschlag verwendet, PLZ zwingend dem Namen vorangestellt) sowie einen Locode (wobei wir das Land weggelassen haben):
wusel@luggage:~$ wget -q -O /tmp/geoloc.out "http://setup.4830.org/geoloc.php?rgeo=me&node=e8:94:f6:52:4b:54&lat=51.8928414&lon=8.3838588"
wusel@luggage:~$ cat /tmp/geoloc.out
Content-Type: text/plain; charset=UTF-8
MAC: e8:94:f6:52:4b:54
LAT: 51.8928414
LON: 8.3838588
ADR: Schalueckstr-107
CTY: Guetersloh
ZIP: 33332
LOC: gut
Anhand des Locodes wird die jeweilige site.conf selektiert, ans Ziel kopiert und ausgewertet (Gluons upgrade-Skripte). So trennen wir schon heute die Netze im Kreis Gütersloh und an der Müritz (und geben Knoten im Stadtgebiet von Rheda-Wiedenbrück eine eigene SSID seufz). Der Plan ist, entsprechend auf Orts-/Gemeindeebene die Meshes/Netze zu trennen.
Der Poligon-Ansatz hat auch einen gewissen Charme, aber da wir die »Middleware« (geoloc.php) kontrollieren, könnte man darauf später umsteigen — oder auch so dafür sorgen, daß Gütersloh und Spexard in einem Mesh bleiben (räumliche Nähe), Gütersloh und Friedrichsdorf (eher keine Gefahr von Fensterbrett-Meshing) in getrennten Meshes landen.
Letzteres war der Grund für die Zwischenschaltung eigener Server, und die Nutzung bestehender Geocoding-Services basiert auf der Tatsache, daß das der einfachste Weg zu sein schien (Rad, erfinden). Zudem: nominatim kann man notfalls auch selbst hosten (was wir bislang noch nicht machen, aber auf der Agenda steht => Ausfallsicherheit, Unabhängigkeit von externen Diensten).
Und noch bißchen Backlog:
Dir scheint mittlerweile klar geworden zu sein, daß dem eben nicht so ist, wenn Du auf dem Knoten testest 
Der (Gluon-) Knoten selbst nutzt seinen Uplink direkt:
root@33334-Knoten-8d62:~# time wget -O /dev/null http://speedtest.netcologne.de/test_100mb.bin
Connecting to speedtest.netcologne.de (194.8.194.20:80)
null 100% |*******************************| 106M 0:00:00 ETA
real 0m 9.38s
user 0m 0.33s
sys 0m 3.50s
111149056 Bytes in 9.38 Sekunden => 94.796.636 Bit/sec. Hmm, nicht ganz die 155 MBit/sec, die die Leitung hergeben sollte, aber egal. Schauen wir doch mal, wo’s lang geht:
root@33334-Knoten-8d62:~# traceroute speedtest.netcologne.de
traceroute to speedtest.netcologne.de (194.8.194.20), 30 hops max, 38 byte packets
1 192.168.253.1 (192.168.253.1) 0.044 ms 0.117 ms 0.104 ms
[...]
4 d-ed1-i.D.DE.NET.DTAG.DE (62.154.15.198) 7.980 ms d-ed1-i.D.DE.NET.DTAG.DE (62.154.15.194) 8.684 ms *
5 80.157.131.218 (80.157.131.218) 9.658 ms 9.513 ms 9.448 ms
6 core-sto2-po9.netcologne.de (81.173.192.9) 17.951 ms 19.151 ms 8.670 ms
7 swrt-sto7-vl431.netcologne.de (78.35.18.22) 8.785 ms 8.936 ms 8.937 ms
8 * * *
[...]
Tja, vom Knoten geht’s immer direkt ins Netz, nicht über die Freifunk-Infrastruktur.
Um die Performance unseres Netzes zu testen, habe ich eine Gluon-VM vor eine Linux-VM gehängt:
ffgt@testvm:~$ traceroute cachefly.cachefly.net
traceroute to cachefly.cachefly.net (205.234.175.175), 30 hops max, 60 byte packets
1 gw02.ffgt (10.255.0.12) 1.007 ms 1.143 ms 1.172 ms
2 bgp1-gw02.ospf.ffgt (10.255.145.20) 3.126 ms 3.166 ms 3.159 ms
3 100.64.0.6 (100.64.0.6) 3.375 ms 3.398 ms 3.796 ms
4 xmws-gtso-de11.nw.mediaways.net (192.251.226.202) 3.275 ms 4.208 ms 4.508 ms
5 ae1.cr-mira.gut1.he-core.de (80.237.129.49) 4.322 ms 4.374 ms 4.423 ms
6 xmws-gtso-de31-chan-2.nw.mediaways.net (195.71.9.1) 4.492 ms 2.681 ms 2.754 ms
7 et-0-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.59) 8.348 ms 8.792 ms 8.736 ms
8 et-7-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.57) 9.772 ms 9.794 ms et-0-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.59) 8.742 ms
9 vip1.G-anycast1.cachefly.net (205.234.175.175) 8.754 ms 9.514 ms 8.753 ms
Das läuft alles im RZ ab, und damit wirklich über die FF-Infrastruktur, s. o.
ffgt@testvm:~$ wget -O /dev/null http://cachefly.cachefly.net/100mb.bin
[...]
2015-11-05 00:38:55 (11.2 MB/s) - ‘/dev/null’ saved [104857600/104857600]
Warum das „nur“ knapp 100 MBit/sec sind, obwohl vom Gateway aus selber es deutlich schneller ist, ist uns aber auch noch nicht ganz klar:
root@gw02:~# wget -4 --bind-address=10.255.0.12 -O /dev/null http://cachefly.cachefly.net/100mb.bin
[...]
2015-11-05 00:39:58 (56.5 MB/s) - ‘/dev/null’ saved [104857600/104857600]
Aber, ja, wie einer meiner Oberstufen-Pauker wieder und wieder skandierte: wer viel mißt mißt Mist
2 „Gefällt mir“
[quote=„MPW, post:36, topic:8881“]
Die Freifunkknoten haben nur eine IPv6, keine IPv4, weil sie diese gefakte haben. Alle FF-Knoten in einer Domäne haben dieselbe IPv4, deswegen können die Knoten selbst über IPv4 nur über das Netzwerk des Knotenbetreibers, nicht über das Freifunknetz kommunizieren.[/quote]
Jetzt wird’s schwierig. »Alle … in einer Domäne haben dieselbe IPv4«; jain. Jeder Gluon-Knoten hat die »Self-IP« (aus der site.conf) lokal, ja. Bis Gluon-2015.1.2 war das auch noch zum Debugging nutzbar:
root@33334-Knoten-8d62:~# wget -O - http://10.255.0.1/cgi-bin/status
Connecting to 10.255.0.1 (10.255.0.1:80)
<!DOCTYPE html>
<html><head><script src="/status.js"></script><title>33334-Knoten-8d62</title></head><body><h1>33334-Knoten-8d62</h1><pre>Model: TP-Link TL-WR1043N/ND v2
Firmware release: 0.7.3-1
01:56:00 up 51 days, 22:15, load average: 0.36, 0.28, 0.28
6: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether c4:6e:1f:fe:8d:62 brd ff:ff:ff:ff:ff:ff
inet6 fd42:ffee:ff12:aff:c66e:1fff:fefe:8d62/64 scope global dynamic
valid_lft 86391sec preferred_lft 14391sec
inet6 fe80::c66e:1fff:fefe:8d62/64 scope link
valid_lft forever preferred_lft forever
total used free shared buffers
Mem: 61348 33688 27660 0 2204
-/+ buffers: 31484 29864
Swap: 0 0 0
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2304 2304 0 100% /rom
/dev/mtdblock3 4672 416 4256 9% /overlay
</pre><h2>Neighbours</h2><h3>mesh0</h3><pre>Joined IBSS 00:42:de:ca:fb:ad (on mesh0)
SSID: 00:42:de:ca:fb:ad
freq: 2452
</pre><h2>VPN status</h2><pre>fastd running for 4486474.266 seconds
There are 9 peers configured, of which 1 are connected:
mesh_vpn_event_peer_test01: not connected
mesh_vpn_backbone_peer_gw06: not connected
mesh_vpn_backbone_peer_gw03: connected for 336822.923 seconds
mesh_vpn_backbone_peer_gw01: not connected
mesh_vpn_backbone_peer_gw04: not connected
mesh_vpn_backbone_peer_gw02: not connected
mesh_vpn_event_peer_event02: not connected
mesh_vpn_event_peer_event01: not connected
mesh_vpn_backbone_peer_gw05: not connected
</pre><script>update_node("mesh0-c6:71:20:fe:8d:62", "fd42:ffee:ff12:aff:c66e:1fff:fefe:8d62", "33334-Knoten-8d62");update_node("mesh0-c6:72:1f:fe:8d:62", "fd42:ffee:ff12:aff:c66e:1fff:fefe:8d62", "33334-Knoten-8d62");</script></body>- 100% |*******************************| 1946 0:00:00 ETA
Mit der neuen Statusseite ab Gluon v2015.2/im aktuellen Master geht derlei leider gar nicht mehr 
Davon unbeleckt kommen die Knoten mit RFC1918-Adressen auf dem WAN gut klar (außer, es ist dummerweise das lokale Netz, welches auch außen benutzt wird). Und IIRC sollten auch vom Host angesprochene v6-Adressen über den Uplink gehen — zumindest, falls dort v6 vorhanden ist?
Ich habe da auch mal zum Thema Performance eine Frage.
Mein FF-Router (841 ND) ist seit knapp einem Tag online und die Verbindungen sind schnarchlahm. Kurioserweise haben meine beiden Android-Tablets irre Probleme, überhaupt eine Webseite anzuzeigen, während Windows besser zurecht kommt. Der beste Speedtest (per Kabel am Router) ergab 2,9MB/s down und nur 0,1 Upload mit einer 185er IP Adresse von Freifunk Rheinland e.V.
Um mein Kabel noch mal durchzumessen, hatte ich dann den Router kurz abgezogen. Danach einen neuen Speedtest gemacht und plötzlich gabs 6,3 Down und 0,3 Up. Mit einer 178er IP-Adresse von LeaseWeb Network B.V.
Mein Android Tablet verhungert allerdings immer noch, während mein Dual Boot Tablet unter Windows Webseiten anzeigt.
Ist das ein generelles Problem derzeit?
Hi,
allgemein würde ich es nicht nennen.
Was für einen Uplink hast du?
Und um welchen Router (Mac oder Hostname) handelt es sich?
Hostname ist FF-WAL-Klusmoor-Spielplatz
Mac Adresse 30:b5:c2:9f:03:aa
Node ID 30b5c29f03aa
Meinst Du mit Uplink meine DSL Geschwindigkeit? Das ist DSL 16.000 und es kommen etwas weniger an. Bruttosync Download 14.878, Upload 1183. Ist noch klassisch ISDN/DSL, also gehen 11% für ATM Overhead runter.
Also dein 2. Speedtest mit 6.3k down kann schon gut hinkommen. Der upload scheint nur ein wenig gering. Magst du mal einen Traceroute als Client auf 8.8.8.8 machen?
Bandbreitenlimit ist nicht zufällig im Configmode aktiv oder?
Hi,
ich mußte erst mal den Router neustarten - der war scheinbar ganz offline.
Hier der Traceroute:
Routenverfolgung zu google-public-dns-a.google.com [8.8.8.8]
ber maximal 30 Hops:
1 44 ms 44 ms 50 ms 10.18.40.1
2 * 48 ms * 10.4.0.1
3 49 ms 45 ms 43 ms vlan437.fra1-ngn-cs2.de.leaseweb.net [178.162.198.125]
4 45 ms 50 ms 45 ms 178.162.223.152
5 47 ms 48 ms 45 ms 31.31.38.150
6 46 ms 45 ms 48 ms de-cix20.net.google.com [80.81.193.108]
7 52 ms 129 ms 45 ms 72.14.238.227
8 47 ms 47 ms 47 ms 209.85.250.119
9 55 ms 50 ms 47 ms google-public-dns-a.google.com [8.8.8.8]
Ablaufverfolgung beendet.
Bandbreitenlimit ist 8000/500 - die Default Werte. Der Speedtest eben war auch gut, 6160 und 300 Kbit/s. Aber weder unter Android 5.1 noch unter Windows läßt sich Heise Online öffnen. In beiden Fällen Timeout. Auf dem Android Tablet geht nicht mal die Mobil-Seite von Heise.
moin holger,
bei freifunk geht es darum das es funktioniert, wie schnell ist optional 
aber ja, das ist mir auch schon mal aufgefallen, das eine Verbindung langsamer ist als eine andere, genau wie du es beschreibst.
Hilfe zur Selbsthilfe: installiere auf einem angeschloßenen clienten oder dem Freifunk Router (ssh: opkg update und dann opkg install mtr)
Gruss
pic
Moin Picard,
Soweit klar. Aber wenn auf dem Androiden weder PlayStore, noch Kicker (als App) oder die heise-Webseite vernünftig funktionieren, dann ist die Geschwidnigkeit eher suboptimal. Windows scheint hartnäckiger zu sein, kurz nach dem Posten gestern abend baute sich dann doch die Heise-Webseite im Browser auf.
Danke für Deinen Hinweis zum Installieren von MTR. Allerdings ist mir noch unklar, was man damit macht. Noch unklarer ist mir, wie man das auf den Router bekommt, denn ansonsten wäre hier kein Linux-Client. Zum Router bekomme ich doch nur Kontakt, wenn man ihn den Config-Modus versetzt, oder?
MTR gibts auch für Windows. http://winmtr.net/download-winmtr/
MTR kann Rückschlüsse liefern wo Netzwerkpakete bei der Reise zum Ziel ins stocken geraten. Es ist ein sich immer wiederholendes Traceroute.
2 „Gefällt mir“
heise.de und Google nutzen IPv6, das läuft nicht über Leaseweb, sondern FFRL. Wahrscheinlich haben wir da netzintern noch ein MTU-Problem, da auf dem Gateway über 100Mbit Durchsatz über die FFRL-Anbindung erreicht werden.