Rasbperry Pi als [-Gateway-]Offloader

Hallo,
ich möchte gerne mein Raspberry Pi 2 als Freifunk Router einsetzen.

Dazu habe ich mir von der Freifunk Community aus Frankfurt das passende image für den RPI2 heruntergeladen. ( Firmware-Selektor )

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.

Hier noch nen paar Zusatz Infos:

Ausgabe von ifconfig:

root@color-pi:~# ifconfig 
bat0      Link encap:Ethernet  HWaddr B8:27:EB:BF:9F:47  
          inet6 addr: fe80::ba27:ebff:febf:9f47/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1208654 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2044 errors:0 dropped:5 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:132981985 (126.8 MiB)  TX bytes:263095 (256.9 KiB)

br-client Link encap:Ethernet  HWaddr B8:27:EB:BF:9F:47  
          inet6 addr: fddd:5d16:b5dd:0:ba27:ebff:febf:9f47/64 Scope:Global
          inet6 addr: 2a06:8187:fbba:1234:ba27:ebff:febf:9f47/64 Scope:Global
          inet6 addr: fe80::ba27:ebff:febf:9f47/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1208653 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8007 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:116060713 (110.6 MiB)  TX bytes:776606 (758.4 KiB)

br-wan    Link encap:Ethernet  HWaddr 12:8D:87:DE:41:A8  
          inet addr:192.168.178.27  Bcast:192.168.178.255  Mask:255.255.255.0
          inet6 addr: fe80::108d:87ff:fede:41a8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1246668 errors:0 dropped:12 overruns:0 frame:0
          TX packets:18383 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:237025390 (226.0 MiB)  TX bytes:4870422 (4.6 MiB)

eth0      Link encap:Ethernet  HWaddr B8:27:EB:BF:9F:47  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1247624 errors:0 dropped:23 overruns:0 frame:0
          TX packets:18383 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:237791066 (226.7 MiB)  TX bytes:5090706 (4.8 MiB)

eth1      Link encap:Ethernet  HWaddr 00:0E:C6:D9:6A:CC  
          inet6 addr: fe80::20e:c6ff:fed9:6acc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4792 errors:0 dropped:0 overruns:0 frame:0
          TX packets:568363 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:240391 (234.7 KiB)  TX bytes:81420805 (77.6 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1715 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1715 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:157948 (154.2 KiB)  TX bytes:157948 (154.2 KiB)

local-node Link encap:Ethernet  HWaddr 16:41:95:40:F7:DC  
          inet addr:10.126.0.1  Bcast:10.126.255.255  Mask:255.255.0.0
          inet6 addr: fe80::1441:95ff:fe40:f7dc/64 Scope:Link
          inet6 addr: fddd:5d16:b5dd::1/128 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38937 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5970 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2619394 (2.4 MiB)  TX bytes:513628 (501.5 KiB)

mesh-vpn  Link encap:Ethernet  HWaddr 12:8D:87:DE:41:AF  
          inet6 addr: fe80::108d:87ff:fede:41af/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1374  Metric:1
          RX packets:1244368 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17667 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:172116839 (164.1 MiB)  TX bytes:3534629 (3.3 MiB)

primary0  Link encap:Ethernet  HWaddr 12:8D:87:DE:41:AB  
          UP BROADCAST RUNNING NOARP  MTU:1528  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1222684 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:170137937 (162.2 MiB)

Ausgabe von batctl if

mesh-vpn: active
eth1: active
primary0: active

MfG

Mhhh, ich würde das über uci erledigen:

in /etc/config/wireless
unter
config interface 'client'
einfach hinter
list ifname 'bat0'
das eth1 hinzufügen:

list ifname 'eth1'

danach dann #/etc/init.d/network restart`

das müsste dann auch einen reboot überleben.

Edit:
als Erklärung:
Das ganze hängt das eth1 interface in the client bridge mit rein, und damit dann auch ins clientnetz.

Hallo John,

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.)

Viele Grüße
Matthias

1 Like

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.

1 Like

Danke das hast funktioniert.

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.

Sobald es im OpenWRT-Master etwas gibt,

Dort ist aber noch nichts angekommen:
https://openwrt.org/toh/raspberry_pi_foundation/raspberry_pi

Startpunkt für Gluon dann:
https://gluon.readthedocs.io/en/v2018.2.x/dev/hardware.html

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 :).

Hier auch auf der Knotenkarte sichtbar.

Im Moment stellt es per VLAN und per Wifi das Clientnetz bereit. Und hängt per USB-Tethering an einem iPad.

52

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 ;).

Ein paar Stats vom PI:
http://[2001:608:a01:108:d07e:19ff:feb2:74b7]
https://stats.ffmuc.net/d/hRIn3dRWk/mesh-nodes?orgId=1&var-nodeid=d27e19b274b7&refresh=5m

1 Like

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.

1 Like

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.

3 Likes

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;
}

batman_adv:

root@raspberrypi:~# modinfo batman_adv
filename:       /lib/modules/4.19.50-v7l+/extra/batman-adv.ko
alias:          net-pf-16-proto-16-family-batadv
alias:          rtnl-link-batadv
version:        2019.1
description:    B.A.T.M.A.N. advanced
author:         Marek Lindner <mareklindner@neomailbox.ch>, Simon Wunderlich <sw@simonwunderlich.de>
license:        GPL
srcversion:     352E3FBF63FB669FDDB15D5
depends:        bridge,cfg80211
name:           batman_adv
vermagic:       4.19.50-v7l+ SMP mod_unload modversions ARMv7 p2v8 

batman:
root@raspberrypi:~# batctl ra

Active routing protocol configuration:

 * bat-uml_west: BATMAN_V

Selected routing algorithm (used when next batX interface is created):

 => BATMAN_V

Available routing algorithms:

 * BATMAN_IV
 * BATMAN_V

/etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

auto eth0.333
iface eth0.333 inet manual

# Segment uml_west
auto bat-uml_west
iface bat-uml_west
        batman-ifaces dummy-uml_west
        batman-routing-algo BATMAN_V
        batman-ifaces-ignore-regex fastd-.*
        mtu 1500

auto dummy-uml_west
iface dummy-uml_west
        link-type dummy


auto br-uml_west
iface br-uml_west inet dhcp
        bridge-ports bat-uml_west wlan0 eth0.333

allow-hotplug eth1
iface eth1 inet dhcp

/etc/hostapd/hostapd.conf:

ssid=FFMUC-test

country_code=DE
interface=wlan0
driver=nl80211

macaddr_acl=0
logger_syslog=
logger_syslog_level=4
logger_stdout=-1
logger_stdout_level=0

hw_mode=a
wmm_enabled=1
# N
ieee80211n=1
require_ht=1
ht_capab=[MAX-AMSDU-3839][HT40+][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]

# AC
ieee80211ac=1
require_vht=1
ieee80211d=0
ieee80211h=0
vht_capab=[MAX-AMSDU-3839][SHORT-GI-80]
vht_oper_chwidth=1
channel=36
vht_oper_centr_freq_seg0_idx=42

Routing:

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

Brauchst du sonst noch Infos? :slight_smile:

1 Like

Schon viel zu viele aber vielen Dank!
Ich hatte ja auf eine schlechtere Lösung gehofft, damit der noch mehr Leistung hat :wink:

1 Like

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!

Gerade noch mit einer besseren Internetleitung gespielt, CPU-Last zwischen 60-80% auf einem Core:

speedtest-cli:
Testing download speed…
Download: 94.89 Mbit/s

wget von Hetzner:

wget -4 -O /dev/null https://speed.hetzner.de/10GB.bin --report-speed=bits
--2019-07-01 09:12:45-- https://speed.hetzner.de/10GB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10485760000 (9.8G) [application/octet-stream]
Saving to: ‘/dev/null’
/dev/null            2%[===>           ] 288.96M   115Mb/s    eta 14m 34s

Und damit hast Du was gemessen?

In wiefern besser? Weniger Packetloss oder weniger Routtripdelay? Wie schlecht war die vorherige denn?