Wie einige schon mitbekommen haben, gibt es seit einigen Tagen zwei laufende Offloader in unserem Netz. Diese dienen der schnellen Anbindung von Geflüchtetenunterkünften in Lampertheim und Heppenheim an unser Netz, da wir dort sonst mit den Plaste Routern an deren Grenzen kommen würden. Da so ein Offloader auch in anderen Unterkünften oder Setups sinnvoll sein kann, haben ich eine entsprechende Anleitung im Wiki veröffentlicht.
Bei den von uns verwendeten Geräten handelt es sich um die sehr günstigen, gebrauchten, Fujitsu Futro S550 Thin Clients mit x86 Architektur auf denen ein x86 Gluon Image läuft. Diese bekommt man zum Teil schon für 20€. Allerdings braucht es noch einen passenden USB2Ethernet Adapter (ca. 12€), da der S550 nur einen Ethernet Port hat. Welcher passt, steht auch in dem Wiki Artikel.
Mit dem Offroader habe ich bis zu 88,9 Mbit/s gemessen. Das ist quasi das Maximum was auf einem Gateway geht, der im Betrieb ist. Das bedeutet aber auch, dass ihr mit einem solchen Offloder einen Gateway ganz alleine quasi auslasten könnt. Überlegt euch daher bitte gut, ob ihr wirklich solche Kapazitäten für euer Setup braucht, da wir diese Kapazitäten auch entsprechend im Backbone vorhalten müssen und das kostet Aufwand und vorallem Geld.
Für Setups im Rahmen von FFRN Hilft hat der Verein bereits ein paar dieser Offloader angeschafft.
Bin strikt nach Anleitung vorgegangen, habe auch einen Futro S550.
Wenn man 2x entpackt, bootet es.
Wenn man dann die Kabel richtig reinsteckt, geht es auch. Ich habe intuitiv die On-Board für Uplink und USB für Mesh benutzt, es muss aber genau andersherum.
Jetzt geht es, aber nicht schneller als ohne Offloader (ca. 20MBit mit einem Acher C7) :-( Die Pakete laufen aber durch den Offloader durch, sieht man daran, dass die CPU-Last von fastd auf dem Offloader beim Speedtest ansteigt. Außerdem haben wir den Uplink bei allen anderen Knoten gekappt.
Kann es sein, dass auf Gatewayseite gedrosselt wird oder zu viel Last auf dem Gateway ist?
Nein weder drosseln wir auf den Gateways noch ist auf einem der Gateways aktuell größere Last. Auch nicht auf dem, mit dem der Offloader gerade Verbunden ist.
Da ich mir gerade nicht sicher bin, ob du beim Treffen da warst, da ich es dort erklärt hatte, aber ein Offloader ist nicht gleich eine Garantie für einen schnellen Uplink. Es kann jeder Zeit sein, dass du nur einen Teil der Kapazität nutzen kannst. Sei es dadurch das auch andere Gerade viele Daten über den Gateway beziehen, durch ein Peering Problem oder durch lokale Gegebenheiten.
Ich hoffe jetzt mal das dein Test via Kabel war und wir somit schon mal das WLAN als Ursache ausschließen können.
Nächste Frage wäre, bei welchen ISP der Anschluss ist? Es kann nämlich auch sein, dass einfach der Peering Port am Upstream Router deines Providers dich/überlastet ist. Zumindest im Peering zu unseren Gateway Servern.
Gerade getestet, kann ich nicht besättigen.Ein mal mit gunzip entpackt und läuft.
[quote=„tobox, post:7, topic:773, full:true“]
Mesh-on-WLAN ist auf dem Archer C7 aktiviert, zusätzlich haben wir fastd deaktiviert. Kann es daran liegen?
[/quote].
Nein.
Sollte aber trozdem auf dem Server gefixed werden, da früher oder später auch andere Leute mit dem Firefox diese Datei runterladen werden und dann dumm aus der Wäsche gucken.
Das Problem ist vermutlich unter anderem der Unitymedia Router Port in Frankfurt. Der ist bei euch im Gebiet etwas dicht. Das kann ich auch zu quasi allen anderen Gateways für die Offloader in Heppenheim und Lampertheim bestätigen. Aber das schwankt auch. Wenn du willst, kannst du mir ja nochmal nen Traceroute aus eurem zum Gateway oder files.leahoswald.de als PM schicken, dann kann ich das da auch nochmal prüfen.
Also jetzt läuft der Offloader (lorsch-050-offloader) mit 30-55 Mbit recht stabil. Ist das OK so oder sollte es mehr sein? Bis jetzt hing er immer an GW06.
Wenn hier noch ein paar Tage Test Gut aus sehen wird der dann wohl in die Unterkunft mit dem 100Mbit VDSL wandern.
Beim Treffen habe ich mit einem Ohr gehört, es gäbe auch ein Image für den Ras-Pi ?
Was bekommt ein R-Pi 2 denn da so durch?
Ich kann das Problem bestätigen:
Klicke ich in Safari auf den Link, lädt er die Datei und entpackt sie automatisch zu einer .img. Die entpackte Datei hat die MD5-Summe a6b0e6032d33afd08f67fef7ee4b2aef. file sagt zu der, von Safari automatisch entpackten Datei: gluon-ffrn-0.5.1-20160113-x86-generic.img: gzip compressed data, was "gluon-combined-ext4.img", from Unix, last modified: Wed Jan 13 17:01:33 2016, max compression
Lade ich die Datei mit wget, bekomme ich eine img.gz, die den gleichen Hash wie die von Safari entpackte .img hat. file sagt: gluon-ffrn-0.5.1-20160113-x86-generic.img.gz: gzip compressed data, was "gluon-combined-ext4.img", from Unix, last modified: Wed Jan 13 17:01:33 2016, max compression.
Entpacke ich beide Dateien (das .img.gz von wget und das .img von Safari) erhalte ich beide male eine funktionierende .img mit dem Hash c49d16bb48251a2ec6e590201fbd3cc6.
Da fast alle anderen Dateien auf der Seite .bin (nicht .bin.gz) sind und sogar die vmdk- und und vdi-images nicht komprimiert sind, denke ich auch, dass das Problem irgendwo auf fw.ffrn.de liegt und die Datei “doppelt” komprimiert und es eigentlich ein .img.gz.gz ist ;)
Nein, das Image fällt so aus dem Build Prozess raus und ist auch nur ein mal gezippt, das ist schon richtig so.
Das ist in der Regel, wie oben verlinkt, ein Bug in den Browsern, der Auftritt wenn der Webserver gzip Compression aktiviert hat und du von dort ein gzip komprimiertes File runter lädst. Dann vergessen die Browser einfach einmal die Compression zu entfernen. Im Chrom(ium) ist das seit 2 Jahren gefixt, in Firefox noch nicht. Daher habe ich die Compression auf dem Server deaktiviert, damit der Fehler nicht mehr auftritt. Das Safari das gz jetzt gleich selbst entpackt ist wohl der umgekehrte Bug in Safari, das der meint erstmal alles was mit gzip verpackt ist entpacken zu müssen.