x86 Offloader Install Guide

…für die Praxis wäre das praktisch zu wissen. Ich kann mich auch nochmal dran versuchen, jedoch befürchte ich, dass in gluon selber was konfigurationstechnisch verkabelt werden muss…

Jepp!

http://gluon.readthedocs.org/en/v2015.1.2/releases/v2015.1.1.html

Wichtig dabei ist, dass die Interfaces bereits beim ersten Booten vorhanden sind. Nachträglich lüppt das nicht.

1 Like

ah! Interessant, dass es erst jetzt als „feature“ ausgelobt wird…

Was heißt „erst jetzt“? Ist ja „schon“ seit 2015.1.1 so.
Vorher ging das auch, aber da musstest Du Dich dann selbst um das Interface-Up und das Bridgen kümmern.

1 Like

Ein paar Tipps zum nativen Booten, was hier mittlerweile an einem Standort solide läuft:

  • Wie schon erwähnt, müssen beide Netzwerkkarten beim ersten Booten vorhanden sein. Firstboot geht nicht auf x86-Images, dann muss man das Image mit dd neu draufkopieren.

  • eth0 ist meist das Clientinterface, eth1 das Uplink-Interface

  • Im v2015.1.2 fehlen noch ein paar Netzwerktreiber. Ggfs. eine aktuelle Desktopdistribution booten, dann gucken, welche Kerneltreiber geladen werden:

    lspci -k

  • Diese dann in gluon/targets/x86-generic/profiles.mk oben ergänzen und neu kompilieren. Dann sollten die Karten auch erkannt werden.

  • Die Konfiguration kann ganz normal über das Webinterface erfolgen, oder eben über die Kommandozeile. Hinweis: Gluon hat keine USB-Tastaturtreiber, daher funktionieren höchstens PS2-Tastaturen

Grüße
MPW

2 Likes

Ich habe mal einen speedtest auf einem x86-Image in virtualbox in meinem Lenovo Yoga 2 Pro mit Intel Core i5 4200U gemacht:

t=$(date +"%s"); wget http://speedtest.netcologne.de/test_100mb.bin -O ->/dev/null ; echo -n "Mbit/s: "; expr 8 \* 100 / $(($(date +"%s")-$t))

Dort kommt in der box über fastd genau die selben Ergebnisse raus wie ausserhalb im Host, also jeweils ca 30 MBit/s, bei eigentlich verfügbaren 40 Mbit/s aber anscheinend liefert netcologne nicht mehr. Ich hab das hier noch mal erklaert: http://askubuntu.com/a/667039/34298

Bitte tragt doch eure testergebnisse hier im Wiki ein.

Die nicht-paravirtualisierten Netzwerktreiber (egal ob nun AMD oder Intel oder Ne2k) liefern keine optimale Performance, um es mal freundlich auszudrücken.
Wie man die virtio-Nets zum Rennen bekommt für Openwrt und Virtualbox: da braucht es wohl Forschungsarbeit oder zumindest ein howto für Trottel wie mich.

Der Output des Targets x86-kvm_guest soll angeblich virtio können. Test steht aber noch aus.

Jetzt hab ich nochmal eine Frage:

Folgendes habe ich angeschlossen
lubuntu netbook (vbox-gluon - meshvpn+meshonwan) <— LAN —> Switch <— LAN —> FF-Router (mesh on wan)

Das funktioniert.

Wenn ich jetzt aber das netbook an irgend einen anderen Ort hänge, zb. an einen Repeater statt direkt am Switch geht es nicht mehr.

Müssen beide Geräte also an einem Switch hängen?
Netzwerktechnisch macht es doch keinen Unterschied wo ich die Geräte im Heimnetz anschließe oder?

Was meinst du mit Repeater?

Generell kommen einige Geräte nicht mit dem Mesh-Traffic klar, ich würde versuchen möglichst direkt zu verbinden.

Repeater = Erweiterung des Heimnetztes mit Steckdosengerät

Anscheinend ist das so. Das würde auch den Fehlschlag erklären, warum das bridgen mit dem wlan interface nicht funktioniert…schade. Muss also physikalisch in nächstmöglicher Nähe angeschlossen sein.

Dass das virtioNet dieses Images unter „echtem“ KVM funktionieren wird, davon gehe ich mal aus.

Fraglich ist, was Virtualbox (5.0.2 etc) im KVM-Modus (und womöglich auch auf einem Windows-Host) daraus macht. Ob es z.B an einen Linuxhost gebunden ist.

Testest du das auf einem virtualisierten Gluon? Dann muss ich dich leider enttäuschen, weil das über deine private Leitung rausging.

Der lädt das über IPv4, Gluon kann IPv4 nur über das private Netz, nicht über FF. Das merkst du auch daran, dass das auf reinen Meshknoten nicht funktioniert. Die können kein IPv4.

Ich suche gerade eine Testdatei, die nur über IPv6 erreichbar ist. Habe aber noch keine gefunden.

Wie kann man das denn über die fastd leitung laufen lassen? Ipv6 only waere anscheinend eine lösung, aber eine option für ping waere auch gut, bloss der ping auf dem router ist so stark beschnitten, dass diese option weg ist ;(

Guckt mal hier vielleicht hilft euch das:
Http://speedtest6.tele2.net/
Http://www.thinkbroadband.com/download.html

Danke, @anon68922371. tele2 scheint down zu sein, aber mit dem anderen geht was:

t=$(date +"%s"); wget http://ipv6.download.thinkbroadband.com/100MB.zip -O ->/dev/null ; echo -n "Mbit/s: "; expr 8 * 100 / $(($(date +"%s")-$t))

Speed-URLs (IPv4)

http://proof.ovh.net/files/100Mb.dat
http://www.speedtestx.de/testfiles/data_100mb.test
http://download.thinkbroadband.com/100MB.zip
http://208.43.102.250/downloads/test100.zip
http://speedtest.qsc.de/100MB.qsc
http://speedtest.netcologne.de/test_100mb.bin

kann alles auch mit 10 statt 100 MB getestet werden, entsprechend umbenennen

http://www.speedtestx.de/testfiles/data_100mb.test -> IPV4
http://208.43.102.250/downloads/test100.zip -> IPV4
http://speedtest.qsc.de/100MB.qsc -> IPV4
http://speedtest.netcologne.de/test_100mb.bin -> IPV4

Die anderen gehen.

sry hatte ich vergessen dabei zu sagen, dass es sich nur um ipv4 handelt…