iperf3 Service auf den Gateways für Speedtests

Hier kommt ja immer mal wieder das Thema auf, wie ich denn am besten die Geschwindigkeit über meinen Knoten messe. Da es ja immer mal unterschiedliche Tests und nichts wirklich sauber verwertbares gab, habe ich jetzt auf allen Gateways einen iperf 3 Dienst am laufen, über den die Geschwindigkeit zwischen Client und Gateway gemessen werden kann (bidirektional).

Dafür reicht ein geeigneter iperf3 Client oder das Shell Tool. Für die Shell sieht der Aufruf wie folgt aus:

iperf3 -c 10.142.0.{gw_number}

Unabhängig davon ist natürlich weiterhin nur eine Messung per LAN wirklich aussagekräftig wie viel maximal über den Knoten geht.

5 „Gefällt mir“

Wollte das gerade mal testen:

root@leahsheim-006:~# iperf3 -c 10.142.0.2
-ash: iperf3: not found
root@leahsheim-006:~# opkg update
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05/ar71xx/generic/packages/base/Packages.gz.
wget: bad address 'opkg.mirror.ffrn.de'

Mache ich was falsch, oder ist der Paketserver nicht im DNS drin?

Hat wohl was hiermit zu tun:

https://github.com/Freifunk-Rhein-Neckar/site-ffrn/issues/2

Habe iperf jetzt installiert bekommen, und gemerkt, dass die Knoten ja gar keine richtige IPv4-Adresse haben. Geht also wohl auf den Knoten nicht. Ist das Absicht? Könnte man iperf zumindest über IPv6 direkt auf den Knoten laufen lassen?

Was ich auch nicht verstehe: Laut Webinterface bin ich mit gw05.freifunk-rhein-neckar.de verbunden, den Namen gibt es aber weder als A noch als AAAA record.

Ja, das ist explizit dafür gedacht, auf einem Client zu laufen. Grund dafür ist, das die Paket Generierung etc. die Werte auf einem Knoten verfälschen würde.

;; ANSWER SECTION:
gw05.freifunk-rhein-neckar.de. 900 IN CNAME gw05.ffrn.de.
gw05.ffrn.de. 900 IN A 188.68.53.119

Die Langform ist eigentlich nur für eventuelle Abmahn Anwälte gedacht. Intern läuft alles auf ffrn.de

Schade, wäre für Remote-Debugging hilfreicht gewesen. Aber Du hast Recht, auch zwischen 2 lokalen Knoten sind die Werte nicht so toll, da die CPUs zu schwach sind.

Hast Du das gerade gefixed? Könnte wetten, dass das vor ein paar Minuten noch anders aussah.

Ja. War noch deaktiviert aus der Übergangszeit vom alten Netz, damit sich die Anfragen nicht in die Quere kommen.

Was war das Problem beim „opkg update“ und wie die Loesung?

Die Antwort war, geht gerade nicht, wir arbeiten dran. :)

Im wesentlichen müsste man in der Datei /etc/opkg/distfeeds.conf

folgendes

http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/

ersetzen mit

http://openwrt.mirror.ffrn.de/chaos_calmer/

Alternativ kann man auch einfach http://openwrt.mirror.ffrn.de/chaos_calmer/15.05/ar71xx/generic/packages/base/iperf-mt_2.0.5-1_ar71xx.ipk per wget herunterladen und mit opkg install installieren (bei experimental). Bei stable müsste man wahrscheinlich noch den barrier breaker Pfad nehmen.

Danke, das mit dem Ersetzen hab ich schon versucht, das tut nicht und es gibt Mecker wegen der Signatur.
Beim haendischen Installieren fehlen Abhaengigkeiten, die ich noch aufloesen muss.