Das hat soweit auch alles geklappt. Per SSH kann ich mich auch auf das Gerät drauf schalten.
Außerdem hab ich an den PI ein Ethernet to USB Adapter angeschlossen (eth1)
via ifconfig eth1 up hab ich den Adapter „angeschaltet“.
Per batctl if add eth1 hab ich das Interface zu einem Batman Client gemacht (hofft das ist so richtig).
An dem Interface eth1 möchte ich jetzt gerne einen Switch anschließen. An dem Switch hängt dann auch ein WAP mit der SSID „Freifunk“.
Das Problem welches ich jetzt habe: Wie bekommen die Clients, die an eth1 hängen eine IP Adresse?
Bzw. allgemeiner: Ist das Setup so richtig?
Wenn ich einen Rechner an den Switch anschließe bekommt dieser keine IP Adresse.
Muss ich einen eigenen DHCP Server betreiben, oder kann ich einen DHCP Server aus der FFM Community benutzen?
Mit Wireshark am eth1 sehe ich nur ICMPv6 Multicast Traffic. Und das eth1 Interface blinkt wie wild (ist aber glaub ich normal).
Hoffe ihr könnt mir da weiterhelfen. Ansonsten würde ich mal direkt bei der FFM Community nachfragen.
eines vorweg: Bitte bedenke, dass die PIs toll zum spielen und lernen sind, wirklich Durchsatz wirst du damit aber nicht erreichen. Die eingebaute LAN-Schnittstelle ist nur per USB angebunden, deine zweite Netzwerkkarte auch. Somit geht alles durch ein USB2.0-Interface und da wird die Performance einbrechen, wenn man mal ein bisschen mehr Durchsatz draufgibt.
Aber ein tolles Projekt, um was zu lernen.
Nein, genau falsch ;). Damit hast du auf eth1 das Meschnetz aktiviert und könntest jetzt an eth1 einen weiteren Freifunkrouter mit Kabelmesch hängen.
Wenn du Clientnetz daraus haben willst, musst du eth1 in die br-client Brücke des Kernels hängen. Das geht irgendwie mit
brctl addif br-client eth1
Beachte brctl ≠ batctl.
Die Installation bietet dann kein Meschnetz an und dürfte von den meisten Freifunkcommunities nicht erwünscht sein. Zum Spielen natürlich interessant, aber sollte so nicht produktiv laufen.
Ich würde die Einstellungen aber nicht mit dem oben genannten Befehl vornehmen, sondern in der
/etc/config/network
bei br-client das eth1-Interface hinzufügen, wie auch @Brother_Lal schon vorgeschlagen hat . Dann sollte es nach einem Neustart darin sein. (Nur das Netzwerk neu starten geht theoretisch auch, habe da aber erlebt, dass er sich manchmal verhaspelt.)
ebenso ist ein raspberry gepresster Elektroschrott / mehr als 6 MB/s schafft der einzige USB Port nicht ohne als Nebeneffekt die SD-Karte zu schreddern.
An dem einen Port hängt die gesamte Hardware es gehen maximal 6MB/s rein oder 3MB/s rein und wieder raus.
der 3er ist ein bisschen besser. ein odroid c2 und co ist da besser geeignet.
Den Aspekt, dass der RPI2 selten mehr als 5MBit/s netto auf dem Client-Interface liefert (egal ob via Fastd oder Lanmesh), hat MPW bereits erläutert.
Also technisch (Peformance, Energieeffizienz) ist das das Ding also eher im Bereich „Vollkatastrophe“. Es taugt also nichtmal als „VPN-Hardwareapplicance für Arme“.
(Von den Kosten für kompatible meshfähige und HF-technisch ansatzweise zumindest nicht schlecht spielende USB-Radios mag ich gar nicht sprechen.)
Da das Image evtl schon etwas älter ist, hat es vermutlich noch den Bug, dass für BCM die Namensauflösung auf dem WAN nicht funktioniert.
Siehe auch:
Der neue Raspberry Pi 4 ist da, daher würde ich das Thema gerne nochmal anfeuern. neuer Pi 4
Das Hauptproblem war ja die Anbindung bzw. der Durchsatz des Controllers.
Das wurde maßgeblich und wohl zufriedenstellend gelöst. Das neue Board hat nun GBit LAN, 2x USB3 und 2x USB2, 1-4 GB RAM und ~50-60% mehr CPU-Leistung.
Als reiner FF-Knoten wohl eher nicht (schwaches WLAN), aber als Offloader dürfte dem doch nun nichts mehr entgegensprechen.
Wenns die SD-Karte wäre, könnte man das dann nicht mit einem RAM drive lösen (Zugriffe auf die SD-Karte minimieren - neue Version hat bis zu 4 GB)?
Vielleicht bekommt ja einer mal einen in die Hände.
wobei ihm dann natürlich immernoch der zweite Lanport fehlt. Man braucht also trotzdem noch einen externen Vlan-Switch als Portmultiplier zum Untagen.
(Oder aber man hat total noble Hardware drumherum, die bereits VLAN-getagt anliefert/abholt… aber dann wird man vermutlich keinen Bastelrechner wie einen RPI einsetzen wollen, sondern eher einen NUC…)
Ich habe das neue Raspberry PI 4 mit 1GB RAM bereits als Offloader getestet, bis jetzt sieht die Performance ziemlich gut aus. Ich bekomme bei so 75-80Mbit/s fastd Traffic auf eine CPU Last von 40-50%.
root@raspberrypi:~# speedtest-cli --server 8908
Retrieving speedtest.net configuration...
Testing from SpaceNet AG (195.30.193.36)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by Net-D-Sign GmbH (Garching) [12.13 km]: 35.185 ms
Testing download speed................................................................................
Download: 86.03 Mbit/s
Ansonsten ist die Performance mit aktiviertem VLAN tagging und NAT echt nicht zu verachten. Setup hier zwei Rechner in unterschiedlichen VLANs und NATing auf dem PI:
bash-3.2$ iperf -c 10.80.199.214
------------------------------------------------------------
Client connecting to 10.80.199.214, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local 172.16.166.2 port 60885 connected with 10.80.199.214 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 878 MBytes 737 Mbits/sec
Für uns könnte es auf jeden Fall eine günstige Alternative für Messeaufbauten oder temporäre Outdoorinstallationen sein.
Wenn jemand bestimmte Tests mit dem PI machen will, der kann mir gerne seinen SSH-Publickey schicken und bekommt Zugriff :).
Im Moment stellt es per VLAN und per Wifi das Clientnetz bereit. Und hängt per USB-Tethering an einem iPad.
Wifi AC funktioniert auch und liefert mit einem 2GB Testfile direkt vom PI Durchsätze von 90 - 130Mbit/s. Wenn ich die 4GB Variante da habe, werde ich das mal aus ner RAM Disk probieren, da ich mir nicht sicher bin ob gerade meine marode SD-Karte das Bottle Neck ist ;).
Schade eigentlich.
Ich hätte gehofft, dass das so ein moderner Prozesser den inzwischen gut 10 Jahre alten Sempron im FutroS550 locker in die Tasche steckt.
Die Futros sind ja da. Nur halt (vergleichsweise) groß und schwer, gerade bei solche Installationen bei denen man den ganzen Krempel meist noch ein paar Meter bei Auf- und Abbau schleppen muss.
Aber solange die Futros einen 200er-Anschluss besser saturieren können: bleibt’s wie gehabt.
Ich kann nicht sagen wieviel das PI wirklich schafft, die 40-50% CPU sind auch im Peak. Meistens pendelt es sich bei 80 Mbit/s auf 20 - 30% ein.
Sobald das 4GB PI da ist werden ich die zwei untereinander per fastd verbinden und mal im LAN testen was wirklich durchgeht.
Für Außeneinsätze bei denen Stromverbrauch und Platz ein Thema ist sind sie auf jeden Fall eine schöne Alternative. Und man kann sie halt neu kaufen + sie können lokal selbst Hotspot spielen.
Interessant wäre, ob man einen passenden USB3-Ethernet-Adapter findet, bei dem die Prozessor/IO-Load erträglich bleibt.
So dass man auf den externen Switch zum VLAN-(Un-)Tagging verzichten könnte.
An was für einem Broadband-Anschluss habt ihr denn getestet?
Ich teste an meinem Telekom VDSL 100. Mehr als die oben genannten MBit/s bekommt mein Xeon da auch nicht durch.
Zusätzliche Ports brauchen wir eher nicht, da wir genug VLAN-fähige Switche für Messen etc vorrätig haben.
Wie gesagt ich werde den Durchsatz mal zwischen zwei PIs testen oder eines davon mal mit in die Arbeit nehmen, da stört auf jeden Fall kein Uplink die Performance ;).
Danke, die Relation fehlte mir! Dann sind 80MBit/s netto auf einem 100er Broadband ein guter Wert und angesichts der CPU-Last wird mann dann auch 160-Tunnel-netto auf 200 etc erwarten können.
Danke @awlnx !
So einen kleinen Vorabtest habe ich mir gewünscht.
Magst du vielleicht nochmal näheres zum 80 MBit Tunneltest verraten? (womit hast du den Pi bestückt? / wie war die Softwarekonfiguration?)
Nicht nur du. Definitiv sind die Futro nicht vom Tisch, jedoch macht eine kleine Box auf dem Knoten teilweise den Unterschied zum Knoten am „PC“ (wenn man den Offloader nicht verstecken kann).
Jedoch finde ich den Wert eigentlich gar nicht mal soo doof. Theoretisch wäre dann ja immernoch genug Luft um daraus Offloader + kleiner Workstation zu machen (wenn man nicht die komplette Power für den Offload braucht)
Die Kompatiblität von den Adaptern soll bisher schon recht gut sein, ich denke nicht das dies nachher das Problem darstellt.
Die Software ist halt noch sehr frisch.
Darauf läuft ein raspbian Buster mit fastd aus den normalen Quellen und batman_adv 2019.1.
fastd.conf:
#
# uml_west FASTd configuration (Salt managed)
#
log to syslog level info;
interface "fastd-uml_west";
#method "aes128-ctr+umac"; # Not supported by CPU on this machine
method "salsa2012+umac";
method "null";
# Mark packets to make sure they are associated to VRF vrf_external.
# Specifying the interface and setsockopt() isn't enough for fastd.
#packet mark 0x1023;
secret "<key>";
mtu 1406;
status socket "/var/run/fastd.uml_west.sock";
on up "
ip link set $INTERFACE down
ip link set address f2:00:22:9:99:99 dev $INTERFACE
ip link set $INTERFACE up
batctl -m bat-uml_west if add $INTERFACE
";
on down "
batctl -m bat-uml_west if del $INTERFACE
";
peer "gw02.in.ffmuc.net" {
key "<key>";
remote ipv4 "gw02.ext.ffmuc.net" port 30010;
}
root@raspberrypi:~# ip ro sh
default via 10.80.192.3 dev br-uml_west
10.80.192.0/21 dev br-uml_west proto kernel scope link src 10.80.197.186
172.20.10.0/28 dev eth1 proto kernel scope link src 172.20.10.4
195.30.193.36 via 172.20.10.1 dev eth1
root@raspberrypi:~# ip -6 ro sh
::1 dev lo proto kernel metric 256 pref medium
2001:608:a01:108::/64 dev br-uml_west proto kernel metric 256 expires 1496sec pref medium
fe80::/64 dev dummy-uml_west proto kernel metric 256 pref medium
fe80::/64 dev br-uml_west proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev fastd-uml_west proto kernel metric 256 pref medium
default via fe80::f000:29ff:fe09:0 dev br-uml_west proto ra metric 1024 expires 1796sec hoplimit 64 pref medium
default via fe80::f000:22ff:fe09:0 dev br-uml_west proto ra metric 1024 expires 1796sec hoplimit 64 pref medium
default via fe80::f000:23ff:fe09:0 dev br-uml_west proto ra metric 1024 expires 1726sec hoplimit 64 pref medium
Das Problem ist der USB-ETH-Chipsatz. Es gibt zwar einige Adapter der 10€-Klasse, diese sind jedoch (was ich bislang gefinden habe) so „doof“, dass sie zwar theoretisch 1MBit/s hinbekommen, auch für TCP mit großen Paketen. Aber wenn man dort Batman&FastD (oder auch nur L2TP) UDP mit teilweise absurd vielen kleinen Paketen drüberjagt, dann geht die IO-Last an der CPU des USB-hosts durch die Decke, da hilft dann auch kein I7 im Laptop.
Will sagen: Guter USB3-eth-nic gesucht!
