deutschenglish
Freifunk Köln, Bonn und Umgebung

Blog

Frank Nord, 22 September 2017

VPN-Server im Eigenbau

Unverschlüsseltes Funknetz

Freifunk ist unverschlüsselt – Datenpakete werden im Klartext über den Äther gesendet. Alle Stationen in Funkreichweite können leicht abhören, welche Internetangebote genutzt werden.

Ein eigener VPN-Server bietet die Chance Daten verschlüsselt nach Hause zu übertragen und vor Angreifern im Äther zu schützen. Doch wie kannst Du Deinen eigenen VPN-Server aufsetzen? Ich beschreib’s mal mit OpenVPN und LEDE:

VPN: Idee und Setup

Der VPN-Router wird parallel zum Freifunk-Router aufgebaut: Die LAN-Ports werden verbunden, die WAN-Ports beide in den Internet-Router (z.B. die Fritzbox) gesteckt. Das gehört zum Setup:

  • VPN steht für Virtual Private Network. Das virtuelle private Netzwerk besteht aus einem Tunnel indem Daten verschlüsselt und sicher zwischen verschiedenen Geräten transportiert werden. Der Tunnel wird innerhalb des Freifunk-Netzes aufgebaut - Zugriff haben nur die eigenen Geräte.

  • OpenVPN verwaltet das virtuelle Netz. OpenVPN wird als Service gestartet und verbindet die teilnehmenden Geräte. Dabei konfiguriert es Netzwerk- und Verschlüsselungsparameter. Clients gibt es für fast alle Betriebssysteme (Linux, Windows, iOS, OS X, Android, …).

  • Ein weiterer Router (z.B. TP-Link TL-WR842nd) als VPN-Server mit dem OpenWRT Nachfolger LEDE. Standardmäßig gibt es für OpenWRT-basierte Gluon-Firmwares keine aktuellen OpenVPN Pakete. Da OpenSSL verwendet wird, brauchst Du ein Gerät mit 8 MB Flash. Alternativ kannst Du ein Lede-Image ohne Luci mit dem Image-Builder erstellen.

Zum Aufbau sind 2 Schritte notwendig:

  1. Vorbereitung: Der Router wird konfiguriert und danach wie auf auf dem Foto verkabelt.
  2. OpenVPN Konfiguration: Der OpenVPN-Daemon wird als Server und Dienst im Freifunk-Netz eingerichtet.

Vorbereitung des VPN-Routers

Bevor Du den Router wie auf dem Foto verkabeln kannst, musst Du ihn erst vorbereiten. Hierzu verbinde zunächst den LAN-Port des Routers mit Deinem Notebook (o.ä.).

Flash LEDE und setze ein Kennwort. Installiere als nächstes die Software und konfiguriere Firewall und Netzwerk. Alle Dinge passieren über die SSH command line.

1. Software installieren

Installiere die notwendigen Pakete mit opkg – führe folgende Befehle per SSH aus:

root@LEDE:~# opkg update
root@LEDE:~# opkg install openvpn-openssl openvpn-easy-rsa haveged
root@LEDE:~# /etc/init.d/haveged start
2. Firewall anpassen

Die Firewall verhindert, dass Pakete aus dem Freifunk Netz (LAN-Ports) nicht direkt ins Internet gesendet werden. Hierzu wird eine neue Firewall-Zone freifunk erstellt. Sie enthält die LAN-Ports mit zugehörigem Netz. Das VPN-Interface wird der alten LAN-Zone zugeordnet.

root@LEDE:~# uci -q batch <<EOF
  set firewall.@zone[0].network='vpn'
  add firewall zone
  set firewall.@zone[-1].forward='REJECT'
  set firewall.@zone[-1].output='ACCEPT'
  set firewall.@zone[-1].input='ACCEPT'
  set firewall.@zone[-1].network='lan'
  set firewall.@zone[-1].name='freifunk'
  commit firewall
EOF
/etc/init.d/firewall restart

Lass dich nicht verwirren: Die lan-Zone enthält nun das VPN-Interface – die freifunk-Zone hingegen das lan-Interface. ☺ Ändere aber noch nicht den Namen, da sonst die folgenden Beispiele nicht mehr funktionieren.

3. DHCP und radvd deaktivieren

DHCP und radvd stören im Freifunk-Netz. Sie müssen dort deaktiviert werden.

root@LEDE:~# uci -q batch <<EOF
  set dhcp.lan.ignore='1'
  set dhcp.lan.ra='disabled'
  set dhcp.lan.dhcpv6='disabled'c
  commit dhcp
EOF
/etc/init.d/dnsmasq restart
4. Netzwerk-Interfaces definieren

Damit der Router aus dem Freifunk-Netz erreicht werden kann, musst Du eine IP-Adresse fest zuweisen. Bitte trage die Adresse in der Wiki ein, damit sie nicht doppelt verwendet wird. Zudem braucht OpenVPN ein eigenes Interface:

root@LEDE:~# uci -q batch <<EOF
  set network.vpn='interface'
  set network.vpn.proto='none'
  set network.vpn.ifname='openvpn'
  set network.lan.ipaddr='10.158.0.42' # Beispiel - anpassen
  set network.lan.netmask='255.255.192.0' # Entspricht der Hood
  delete network.lan.ip6assign
  commit network
EOF
/etc/init.d/network restart

Mit /etc/init.d/network restart wird die IP-Adresse gesetzt und die SSH-Verbindung ist nicht mehr benutzbar. Du kannst den Router nun wie auf dem Foto verkabeln:

  1. Verbinde die LAN-Ports der beiden Router
  2. Beziehe eine neue IP-Adresse mit Deinem PC – diesmal aus dem Freifunk-Netz. Hierzu kannst Du das Kabel zu deinem Notebook oder PC kurz trennen.

Nun kannst Du den Router über Freifunk erreichen und OpenVPN konfigurieren. Ändere in Luci (Web-GUI) ruhig den Namen des lan-Netzwerk-Interfaces auf freifunk, damit keine Verwirrung entsteht.

Pass auf, dass der VPN-Router ab jetzt Dein privates Netzwerk nicht mehr erreichen kann – trenn die Netze. Beispielsweise kannst Du für das private Netz einen eigenen, weiteren Router verwenden. Falls nicht, sind bei einem Konfigurationsfehler oder Bug schnell private Daten gefährdet.

OpenVPN einrichten

Die OpenVPN-Konfiguration umfasst 3 Schritte:

  1. Schlüsselmaterial erzeugen
  2. OpenVPN-Server konfigurieren
  3. Client konfigurieren und die Verbindung testen.
1. Schlüsselmaterial erzeugen

Zum Erzeugen von Schlüsselmaterial und Zugangsdaten verbinde Dich erneut mit SSH und führe folgende Befehle aus.

1.1 Parameter laden

Die Programme zur Erzeugung des Schlüsselmaterials werden über Umgebungsvariablen konfiguriert. Lade zunächst die Parameter in die Umgebung:

root@LEDE:~# source /etc/easy-rsa/vars  
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/easy-rsa/keys

Die Parameter müssen immer geladen sein, wenn Du Schlüsselmaterial bearbeitest. Falls Du eine neue SSH-Verbindung aufbaust (o.ä.), musst Du auch die Parameter neu laden.

1.2 Certificate Authority (CA) & Hauptschlüssel instanziieren

root@LEDE:~# build-ca
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/easy-rsa/keys
Generating a 2048 bit RSA private key
.............................................................................+++
.....+++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:DE
State or Province Name (full name) [CA]:NRW
Locality Name (eg, city) [SanFrancisco]:Meine Stadt
Organization Name (eg, company) [Fort-Funston]:Meine Organisation
Organizational Unit Name (eg, section) [MyOrganizationalUnit]:Meine Sektion
Common Name (eg, your name or your server's hostname) [Fort-Funston CA]:Meine CA
Name [EasyRSA]:
Email Address [me@myhost.mydomain]:someone@somewhere.com
1.3 Router-Schlüssel erzeugen

Zuerst die Diffie-Hellman Gruppe: Dies dauert sehr lange, da viele Primzahl-Tests ausgeführt werden. Du kannst den Generator im Hintergrund laufen lassen und mit den nächsten Schritten weiter machen. Vergiss ggf. nicht die Parameter neu zu laden (vgl. 1.1 Parameter laden).

Da die Gruppe nicht geheim ist, kannst Du Sie auch bedenkenlos auf einem anderen Rechner erzeugen oder wiederverwenden.

root@LEDE:~# build-dh

Danach (oder währenddessen) den RSA-Key – IP-Adresse wieder anpassen:

root@LEDE:~# pkitool --server 10.158.0.42
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/easy-rsa/keys
Generating a 2048 bit RSA private key
...................................................................................................+++
.............+++
writing new private key to '10.158.0.42.key'
-----
Using configuration from /etc/easy-rsa/openssl-1.0.0.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :PRINTABLE:'CA'
localityName          :PRINTABLE:'SanFrancisco'
organizationName      :PRINTABLE:'Fort-Funston'
organizationalUnitName:PRINTABLE:'MyOrganizationalUnit'
commonName            :PRINTABLE:'10.158.0.42'
name                  :PRINTABLE:'EasyRSA'
emailAddress          :IA5STRING:'me@myhost.mydomain'
Certificate is to be certified until Aug 17 18:45:21 2027 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated

1.4 Zugangsdaten & Geräteschlüssel erzeugen

Zuletzt jeweils Geräteschlüssel - hier für ein Notebook:

root@LEDE:~# pkitool notebook
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/easy-rsa/keys
Generating a 2048 bit RSA private key
...........................................................................+++
.......................................+++
writing new private key to 'notebook.key'
-----
Using configuration from /etc/easy-rsa/openssl-1.0.0.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :PRINTABLE:'CA'
localityName          :PRINTABLE:'SanFrancisco'
organizationName      :PRINTABLE:'Fort-Funston'
organizationalUnitName:PRINTABLE:'MyOrganizationalUnit'
commonName            :PRINTABLE:'notebook'
name                  :PRINTABLE:'EasyRSA'
emailAddress          :IA5STRING:'me@myhost.mydomain'
Certificate is to be certified until Aug 17 18:51:54 2027 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated

Das Schlüsselmaterial wurde nun generiert und ist auf dem Router gespeichert.

2. OpenVPN Server konfigurieren

Für OpenVPN muss eine neue Konfigurationsdatei erzeugt und in uci registriert werden – IP-Adressen wieder anpassen:

root@LEDE:~# cat > /etc/openvpn/openvpn.conf <<EOF
  cert /etc/easy-rsa/keys/10.158.0.42.crt ## Anpassen
  key /etc/easy-rsa/keys/10.158.0.42.key ## Anpassen
  server 172.16.8.0 255.255.255.0  ## Ggf. anpassen, falls privat verwendet
  push "dhcp-option DNS 172.16.8.1" ## Muss zum IP-Bereich passen
  server-ipv6 fd2f:b51a:bcf6:acea::/64 ## Neu generieren: http://simpledns.com/private-ipv6.aspx
  port 1194
  proto udp
  dev-type tun
  dev openvpn
  keepalive 5 30
  persist-key
  persist-tun
  log /tmp/openvpn.log
  verb 3
  tun-mtu 1280
  cipher AES-256-CBC
  ca /etc/easy-rsa/keys/ca.crt
  dh /etc/easy-rsa/keys/dh2048.pem
  push "redirect-gateway"
  push "route-ipv6 2000::/3"
  tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
EOF

Und registrieren:

root@LEDE:~# uci -q batch <<EOF
    set openvpn.vpn_config='openvpn'
    set openvpn.vpn_config.enabled='1'
    set openvpn.vpn_config.config='/etc/openvpn/openvpn.conf'
    commit openvpn
EOF
/etc/init.d/openvpn restart

Nun wird der OpenVPN-Server gestartet und kann hoffentlich verwendet werden.

3. Abschluss und testen

Das Log liegt unter /tmp/openvpn.log – Beispiel:

Sat Aug 19 19:47:42 2017 OpenVPN 2.4.3 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sat Aug 19 19:47:42 2017 library versions: OpenSSL 1.0.2k  26 Jan 2017, LZO 2.09
Sat Aug 19 19:47:42 2017 Diffie-Hellman initialized with 2048 bit key
Sat Aug 19 19:47:42 2017 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1280)
Sat Aug 19 19:47:42 2017 TUN/TAP device openvpn opened
Sat Aug 19 19:47:42 2017 TUN/TAP TX queue length set to 100
Sat Aug 19 19:47:42 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Sat Aug 19 19:47:42 2017 /sbin/ifconfig openvpn 172.16.8.1 pointopoint 172.16.8.2 mtu 1280
Sat Aug 19 19:47:42 2017 /sbin/ifconfig openvpn add fd2f:b51a:bcf6:acea::1/64
Sat Aug 19 19:47:42 2017 /sbin/route add -net 172.16.8.0 netmask 255.255.255.0 gw 172.16.8.2
Sat Aug 19 19:47:42 2017 Could not determine IPv4/IPv6 protocol. Using AF_INET
Sat Aug 19 19:47:42 2017 Socket Buffers: R=[163840->163840] S=[163840->163840]
Sat Aug 19 19:47:42 2017 UDPv4 link local (bound): [AF_INET][undef]:1194
Sat Aug 19 19:47:42 2017 UDPv4 link remote: [AF_UNSPEC]
Sat Aug 19 19:47:42 2017 MULTI: multi_init called, r=256 v=256
Sat Aug 19 19:47:42 2017 IFCONFIG POOL IPv6: (IPv4) size=62, size_ipv6=65536, netbits=64, base_ipv6=fd2f:b51a:bcf6:acea::1000
Sat Aug 19 19:47:42 2017 IFCONFIG POOL: base=172.16.8.4 size=62, ipv6=1
Sat Aug 19 19:47:42 2017 Initialization Sequence Completed

Zudem existiert ein passenden Device:

root@LEDE:~# ip addr show dev openvpn
8: openvpn: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN qlen 100
    link/[65534]
    inet 172.16.8.1 peer 172.16.8.2/32 scope global openvpn
       valid_lft forever preferred_lft forever
    inet6 fd2f:b51a:bcf6:acea::1/64 scope global
       valid_lft forever preferred_lft forever

Client-Konfiguration

Ich nutze Debian Linux (Jessie). Hier mein Setup:

1. Software installieren

Auch Debian Jessie braucht Pakete.

root@Notebook:~# apt-get install openvpn
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 500 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ftp.de.debian.org/debian stretch/main amd64 openvpn amd64 2.4.0-6+deb9u1 [500 kB]
Fetched 500 kB in 0s (760 kB/s)  
Preconfiguring packages ...
(Reading database ... 531491 files and directories currently installed.)
Preparing to unpack .../openvpn_2.4.0-6+deb9u1_amd64.deb ...
Unpacking openvpn (2.4.0-6+deb9u1)
Setting up openvpn (2.4.0-6+deb9u1) ...
[ ok ] Restarting virtual private network daemon.: jluehr_default.
insserv: warning: current start runlevel(s) (empty) of script `openvpn' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `openvpn' overrides LSB defaults (0 1 6).
Processing triggers for systemd (232-25+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
2. Verzeichnis erstellen und Schlüsselmaterial kopieren

Zur Einwahl benötigt das Notebook einen Teil des Schlüsselmaterials vom Router:

root@Notebook:~# scp 10.158.0.42:/etc/easy-rsa/keys/ca.crt /etc/openvpn/freifunk_vpn/
ca.crt                                                                                  100% 1797   800.8KB/s   00:00    
root@Notebook:~# scp 10.158.0.42:/etc/easy-rsa/keys/notebook.* /etc/openvpn/freifunk_vpn/
notebook.crt                                                                            100% 5489     1.5MB/s   00:00    
notebook.csr                                                                            100% 1102   571.1KB/s   00:00    
notebook.key                                                                            100% 1704   786.3KB/s   00:00    

Grundsätzlich ist es besser, aber auch aufwendiger, den Notebook-Schlüssel (notebook.key) auf dem Notebook und nicht auf dem Router zu erstellen. Da Du jedoch beide Geräte kontrollierst, niemand sonst Zugang hat und jeder, der Notebook oder Router kompromittiert direkt Zugriff zum VPN hat, habe ich hier darauf verzichtet – der Sicherheitsgewinn ist gering.

Falls Du anders vorgehen möchtest, kannst Du auch den RSA Schlüssel inkl. Certificate-Signing-Request (CSR) auf dem Notebook erstellen, nur den CSR zum Router übertragen und dort signieren.

In größeren Unternehmen wird das Schlüsselmaterial häufig auf verschiedenen Rechnern ohne Netzwerkzugang oder Smartcards erzeugt.

3. Client-Konfiguration erstellen
root@Notebook:~# cat > /etc/openvpn/freifunk_vpn/openvpn.conf <<EOF
  cert /etc/openvpn/freifunk_vpn/notebook.crt ## Ggf. anpassen
  key /etc/openvpn/freifunk_vpn/notebook.key ## Ggf. anpassen
  ca /etc/openvpn/freifunk_vpn/ca.crt
  client
  dev-type tun
  dev freifunk-vpn
  proto udp
  remote 10.158.0.42 1194 # Anpassen
  resolv-retry infinite
  nobind
  tun-mtu 1280
  cipher AES-256-CBC
  ns-cert-type server
  tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
EOF
4. Verbindung zum Server starten

Nun kannst Du Dich zum Server verbinden:

root@Notebook:~# openvpn --config /etc/openvpn/freifunk_vpn/openvpn.conf
Sat Aug 19 22:17:50 2017 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun 22 2017
Sat Aug 19 22:17:50 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Sat Aug 19 22:17:50 2017 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1280)
Sat Aug 19 22:17:50 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]10.158.0.42:1194
Sat Aug 19 22:17:50 2017 UDP link local: (not bound)
Sat Aug 19 22:17:50 2017 UDP link remote: [AF_INET]10.158.0.42:1194
Sat Aug 19 22:17:51 2017 [10.158.0.42] Peer Connection Initiated with [AF_INET]10.158.0.42:1194
Sat Aug 19 22:17:52 2017 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Sat Aug 19 22:17:53 2017 TUN/TAP device freifunk-vpn opened
Sat Aug 19 22:17:53 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Sat Aug 19 22:17:53 2017 /sbin/ip link set dev freifunk-vpn up mtu 1280
Sat Aug 19 22:17:53 2017 /sbin/ip addr add dev freifunk-vpn local 172.16.8.6 peer 172.16.8.5
Sat Aug 19 22:17:53 2017 /sbin/ip -6 addr add fd2f:b51a:bcf6:acea::1000/64 dev freifunk-vpn
Sat Aug 19 22:17:53 2017 add_route_ipv6(2000::/3 -> fd2f:b51a:bcf6:acea::1 metric -1) dev freifunk-vpn
Sat Aug 19 22:17:53 2017 Initialization Sequence Completed

Hier schafft mein TP Link TL-WR842nd v2 allein knapp 10 MBit/s – etwa so viel wie mein Internet-Upstream. Wenn Du magst, kannst Du openvpn auch über systemd starten oder in den Network Manager eintragen.

Für andere Betriebssysteme sind einige Anpassungen nötig. Beispielsweise muss auf Windows die Konfiguration auf .ovpn enden und routes müssen mit route-method exe gesetzt werden.

Achtung: Die Konfiguration ist nicht wasserdicht. Falls z.B. das VPN kurz ausfällt oder ein Angreifer DHCPv6-Server betreibt, bist Du verwundbar. Für einen besseren Schutz brauchst Du eine Firewall, die fast alle unverschlüsselten, ausgehenden Verbindungen blockiert. Beispiel für shorewall

OpenVPN muss zudem hin- und wieder mit Sicherheitsupdates versorgt werden. Informationen gibt es z.B. auf den Mailinglists zu OpenVPN und OpenSSL.

Das war’s …

Ich hoffe, Dein Server läuft soweit gut und die Verschlüsselung funktioniert. Zum Abschluss noch 3 Dinge:

  1. Das VPN verteilt IPv6-ULA Adressen mit route 2001::/3, damit IPv6 nicht mehr über Freifunk unverschlüsselt übertragen wird. Damit IPv6 extern funktioniert, brauchst Du einen Public IPv6 Block, den Du statt dem ULA-Netz verteilst. Tunnel gibt’s z.B. bei he.net.
  2. Das VPN schützt nur vor Angreifern im Freifunk-Netz – im Internet bist Du ungeschützt. Hier hilft nur Ende-Zu-Ende Verschlüsselung. Hilfe gibt’s auf einer Cryptoparty.
  3. Dein eigener VPN-Server entlastet das Freifunk-Netz, falls Dein Internet-Traffic nicht über die wenigen Gateways geleitet werden muss – z.B. VPN-Server direkt per Funk erreichbar. Es reicht eine Funk- oder fastd-Verbindung zwischen den beteiligten Nodes.
Frank Nord, 30 May 2016

Seid Dezentral

Dezentrales Mesh-Netzwerk

Freifunk versteht sich als dezentrales Mesh-Netzwerk. Dezentralität ist ein Ziel vieler Freifunk-Communities - aber auch ein sehr schwieriges.

Doch was ist Dezentralität? Woher kommt die Forderung und wie setzt Freifunk sie um? Ich versuche mal eine Erklärung.

Hackerethik

Im Buch Hackers – Heroes of the Computer Revolution beschreibt Steven Levy 1984 die frühe Hacker-Kultur (~1960) am MIT um den Großrechner TX-0. Levy beschreibt eine Hacker-Ethik, die 6 Leitsätze umfasst – einer davon fordert Dezentralität:

SOMETHING new was coalescing around the TX-0: a new way of life, with a philosophy, an ethic, and a dream.

[…] The precepts of this revolutionary Hacker Ethic were not so much debated and discussed as silently agreed upon. No manifestos were issued. No missionaries tried to gather converts. The computer did the converting, and those who seemed to follow the Hacker Ethic most faithfully were people like Samson, Saunders, and Kotok, whose lives before MIT seemed to be mere preludes to that moment when they fulfilled themselves behind the console of the TX-0. […] Still, even in the days of the TX-0, the planks of the platform were in place. The Hacker Ethic […]:

Mistrust Authority Promote Decentralization.

The best way to promote this free exchange of information is to have an open system, something which presents no boundaries between a hacker and a piece of information or an item of equipment that he needs in his quest for knowledge, improvement, and time on-line. The last thing you need is a bureaucracy. Bureaucracies, whether corporate, government, or university, are flawed systems, dangerous in that they cannot accommodate the exploratory impulse of true hackers. Bureaucrats hide behind arbitrary rules (as opposed to the logical algorithms by which machines and computer programs operate): they invoke those rules to consolidate power, and perceive the constructive impulse of hackers as a threat.

Die Forderung nach Dezentralität wurde auch seitens des CCC in die Hackerethik aufgenommen. Hierzu wikipedia:

Misstrauen gegenüber Autorität und Bevorzugung von Dezentralisierung.

Das Erstellen von einem offenen System ohne Grenzen ist die beste Möglichkeit, um es Hackern zu ermöglichen an notwendige Informationen oder Ausrüstung zu gelangen, welches diese benötigen um ihrer Pflicht des Sammeln von Wissen und des Verbesserns von sich selbst und der Welt benötigen. Hacker glauben daran, dass ein bürokratisches System ein fehlerbehaftetes System ist, egal wo dieses System angewendet wird.

Beide Varianten stellen Autorität und Dezentralisierung gegenüber. Keine zentrale Autorität oder Bürokratie soll den Zugang verhindern können. Dezentralität ist eine Möglichkeit, den freien Informationsaustausch zentraler Kontrolle zu entziehen. Zwei Dinge sind wichtig:

  1. Dezentralität ist kein Selbstzweck. Sie stellt den Zugang zu Wissen und Systemen sicher. Sie ist eine Grundlage in der Hackerkultur.
  2. Die Forderung nach Dezentralität ist sozial und nicht technisch. Es geht um „Wer herrscht über was?” und nicht um technische Redundanz.

Und Freifunk?

Vom Selbstverständnis her ist Freifunk ein Mitmach-Netz, zudem jede und jeder freien Zugang hat. Freifunk ist in der Hackerkultur verwurzelt. Es entscheidet keine Autorität darüber was Freifunk ist. Niemand entscheidet darüber, wer mitmachen und sich Freifunkerin (bzw. Freifunker) nennen darf. Informationen über Freifunk-Netze sind offen. Alle können Freifunk-Communities gründen, hacken und ihr Netz bauen. Jedoch fühlen sich nicht alle Freifunkerinnen und Freifunker als Hacker.

Es ist nicht zwingend notwendig, Freifunk-Netze zusätzlich redundant (d.h. technisch dezentral) zu gestalten. Beispielsweise sagt niemand, an wie vielen Orten Nodes oder Server stehen müssen. Viele unabhängige Freifunk-Communities mit eigenen, aber verbundenen Netzen bilden ein großes, dezentrales Freifunk-Netz. Das Pico-Peering-Agreement (PPA) stellt nur sicher, wie die Komponenten offen für den Datenaustausch mit anderen sein müssen. Technische Dezentralität kann sogar hinderlich sein: Je ausgeklügelter und komplexer das Setup, desto steiler ist die Lernkurve. Desto schwieriger wird es mitzumachen, sich zu orientieren und darauf aufbauend ein eigenes Netz zu bauen.

In der Anfangszeit bestand das KBU-Netz aus einem VPN-Server (Paul) und etwa 10-15 Nodes. Technisch gesehen war das Netz zentralistisch: Fiel Paul aus, so war das Netz praktisch tot. Aber die Community war dezentral organisiert: Sie existierte unabhängig von anderen Communities, veröffentlichte Sourcecode, Konzepte und Dokumentationen. Keine priviligierten Administratoren herrschten über den Server: Fast alle, die mitmachten hatten root-Zugang auf Paul per SSH.

Zudem stellt Freifunk die Forderung nach freiem Zugang zu Informationen. Jede und jeder sollen im Freifunk-Netz Informationen frei austauschen können. Die Hackerethik enthält also noch andere Punkte, die für die Freifunk-Kultur wichtig sind. Ich bleib aber mal bei der Dezentralität.

Anforderungen

Machen wir es formal – Anforderungen an dezentrale Freifunk-Communities:

  1. Dokumentiert Eure Setups – Ermöglicht anderen das gleiche Netz zu bauen.
  2. Denkt nicht territorial – Ihr seid nicht die zentrale Freifunk-Autorität in Eurer Stadt oder Eurem Kreis. Eine andere Community ist wichtiger als Eure eigene.
  3. Schafft keine Autoritäten – Herrscht nicht als Administratoren über das Freifunk-Netz.
  4. Hackt – Nutzt die Dezentralität: Tut Dinge, erkundet und schafft Wissen. Habt Spaß am Gerät.

Und:
Lebt Widersprüche in bester diskordianischer Tradition: Natürlich ist das Freifunk Advisory Council eine Autorität. Natürlich schließt ein offenes Mitmach-Netz alle Menschen aus, die Rechnernetze nicht verstehen können. Aber diese Widersprüche sind kein Grund die Ideale der Hackerkultur aufzugeben.
Kommt damit klar.

Rampone, 15 May 2016

KBU Mini Routing Day

22.5.2016: C5 - KBU Mini Routing Day

Zwei Deppen bringen euch Routing bei

An diesem Sonntag veranstalten die beiden Freifunker K3v1n und Rampone ein C5 (Chaos Computer Club Cologne Cafe) unter dem Titel: KBU - Mini Routing day - Zwei Deppen bringen euch Routing bei.

Freifunk ist mehr als nur Firmware runterladen, flashen und anschliessen. Ohne Nodes, die als Gateways fungieren, funktioniert ein Freifunknetz nicht. Routing, IP-Netze, Meshprotokolle und Konfiguration der Gateways/Supernodes sind vielen nicht geläufig, teilweise sind Dinge auch nicht gut dokumentiert oder es hakt an Stellen, die einen alleine frustriert aufgeben lassen, aber gemeinsam einfach zu lösen sind.

Um dieses Wissen konzentriert weiterzuverteilen, werden bei diesem C5 u.a. von den Freifunkern K3v1n und Rampone Grundwissen über IP-Netzwerke, Routing und Meshprotokolle erklärt, um danach in einem Workshop zu vermitteln, wie man einen eigenen Supernode, Firmware und eine eigene Hood aufbaut.

Am 22.5. von 10:00 bis 12:00 Uhr wollen wir noch Linuxanfängern einen kleinen Crashkurs geben. Der eigentliche Vortrag mit Workshop beginnt ab ca. 12:00Uhr - Ende ist offen - angedacht ist aber bis 18 Uhr den Hauptteil abgeschlossen zu haben.

Bringt euren Laptop mitoptional auch Kuchen, Freifunk-Router und “Super"nodehardware.

Frank Nord, 10 April 2016

Impulse Geben

Die Technik ist da - die Situation ist verfahren

Die Serie Supernodes sind Nodes erklärt was Nodes und Supernodes ausmacht. Einige technische Details sind recht tief und kompliziert. Aber Du weißt nun, wie die verschiedenen Dinge ineinander greifen können. Du hast gesehen, wie ein Freifunk-Netz aussehen kann. Und jetzt?

Die KBU-Community hat Gluon eingeführt - ein Standardprodukt wird nun eingesetzt. Durch den Fokus auf Wachstum wurde das Netz überlastet.

Im Rahme der Öffentlichkeitsarbeit vermarktet die KBU-Community den Internet-Zugang im Freifunk Netz - für Bäckereien, Organisationen oder selbst für die komplette Bonner Stadtverwaltung. Schnelle und zuverlässige Internet-Zugänge werden suggeriert. Eine de-facto Anbieter-Verbraucher-Beziehung wird geschaffen. Nur wenige Kunden haben ein Interesse daran, sich in die Community einzubringen, Dinge zu hinterfragen und weiter zu entwickeln.

Eine Note zu Freifunk

Im Januar 2015 verfasste kinolux seinen Blog-Artikel Eine Note zu freifunk. Es entstand eine lebhafte Diskussion darüber, was Freifunk eigentlich ausmacht. Er schreibt:

[…] Im Westen der Republik sehe ich, dass freifunk Vereine und ISP Konstrukte entstehen, die leider nicht den Bau freier Netzwerke fördern, sondern selbst offiziell als Anbieter von Internetzugängen agieren. Die Ideen des Teilens und der Allmende gehen damit verloren.

Es ist paradox, da die freifunk Idee nicht nur dem Namen nach für “freies funken” steht, sondern auch konzeptionell niemals für ein reguliertes, zentralisiertes Gratis-Hot-Spot-Netz mit integriertem Vereins- oder ISP-Betrieb stand. Das geht nicht gut zusammen und darüber muss in der freifunk Community dringend geredet werden.

Ich möchte darum alle Freifunkerinnen dazu auffordern miteinander zu sprechen, wie wir unsere Netze gestalten, ob wir freie, offene, unregulierte und flache (auch sozial flache) Strukturen bauen oder ob wir mit einer Servicementalität von kommunalen Internet Lieferanten zu Werke gehen. Freifunk kennt keine Kunden und sollte niemals mit dem Lieferversprechen eines Providers konzeptioniert und betrieben werden, denn neben der Idee des hierarchielosen und freien “people owned” Netzwerkes ist freifunk auch eine soziale Community idee, die so dezentral und führungslos funktioniert, wie der im Mesh benutzte algo. Und so wie die Nodes die Informationen über Routen und erreichbare Knoten austauschen, sollten die freifunkerinnen auch ihr Wissen miteinander teilen. Echtes freifunk ist darum auch nicht durch externe, einzelne Eingriffe abschaltbar.

Wir müssen uns klar sein, dass die ISP Lösung nur bei der Umgehung der Störerhaftungsfrage half und ohne die Störerhaftung der freien Funkidee sogar hinderlich werden kann. Sollte die Störerhaftung für private, offene WLANs fallen, so müssen umgehend alle juristischen und technischen ISP-konstrukte im freifunk beseitigt werden.

Ein ideales freifunk Mesh besteht aus autonomen, vom User selbstverwalteten Routern auf jedem einzelnen Fensterbrett einer Strasse und eines Kiezes; eine Meshwolke, die die Menschen lokal vernetzt – eine alternative offene Infrastruktur im urbanen Nachbarschaftsraum. Alle darüber hinaus von einzelnen angebotene Dienste und Gateways innerhalb dieses Mesh’ sind quasi Extras, die sich das offene freifunk Netz lediglich als Transportnetz zu nutze machen. Darum kann auch auf das schon erwähnte Pico Peering Agreement im freifunk an keiner Stelle verzichtet werden.

Wer jetzt die freifunk Idee und ihren Namen benutzt, um regulierte und zentralisierte Hot-Spot Wolken zu bauen oder lokale ISP-Instanzen zu gründen, der verschenkt fahrlässig zuvor mühsam erkämpften politischen und sozialen Raum, den die freifunk Community mit ihrer Idee immer schon definiert hatte. Lokale, selbstverwaltete und nicht-kommerzielle ISPs sind wichtig und wünschenswert. Allerdings haben sie bezüglich ihres Designs und ihrer Funktion nichts mehr mit der ursprünglichen freifunk Vision zu tun. freifunk kann per Definition niemals ISP sein. […]

Lasst uns wieder unregulierte Netze bauen, freie freifunk Netze.

Frefiunk vs. Internet Service Provider (ISP)

Kinolux unterscheidet zwischen freifunk und lokalen, selbstverwalteten und nicht-kommerziellen ISPs ohne zu werten. Entsprechende ISPs seien „wichtig und wünschenswert“. Er argumentiert, dass „Freifunk […] niemals mit dem Lieferversprechen eines Providers konzeptioniert und betrieben werden [sollte]“.

Diese Unterscheidung ist wichtig: Freifunk kann aufgrund seiner sozialen Struktur nicht das Lieferversprechen eines Providers erfüllen. So zielt die technische Konzeption nur darauf, ein Mesh aus „autonomen, vom User selbstverwalteten Routern“ zu bauen. Auch das Netz kann kein Lieferversprechen erfüllen.

Versteh kinolux Beitrag nicht als Vorwurf falschen Freifunk zu machen. Er zeigt auf, wie sich Freifunk-Communities von ISPs unterscheiden. Er bezieht sich jedoch auf Freifunk, wie er es „Anfang der 2000er Jahre“ erlebt hatte.

Kinolux Artikel hatte Sprengkraft: Viele, die sich mit Freifunk identifizierten wurden mit der Meinung konfrontiert, dass ihre Projekte kein Freifunk seien. Hier liegt der große Fehler in kinolux Artikel: Viele fühlten sich attackiert und verteidigten ihre Projekte reflexartig. Die Freifunk-Community war gespalten; ein großer Teil fühlte sich angegriffen und ausgeschlossen. Dabei richtet sich die Aufforderung zur Diskussion insbesondere an sie.

Heute führt der Freifunk Rheinland e.V. immer noch Freifunk im Namen, obwohl er ein lokaler, selbstverwalteter und nicht-kommerzieller ISP ist. Viele, die dort mitarbeiten identifizieren sich mit Freifunk und bekennen sich dazu. 10 Jahre später ist Freifunk etwas anderes. Viele in der Community haben völlig verschiedene Vorstellungen.

Ich finde es schade, dass es nicht gelang Freifunk klarer von lokalen, selbstverwalteten und nicht-kommerziellen ISPs abzugrenzen.

Ist die KBU ein Internet Service Provider?

Als Projekt des Chaos Computer Club Cologne (C4) e.V. kann die KBU kein ISP sein. Eine Tätigkeit als ISP entspricht nicht dem Vereinszwecke des C4. Falls der C4 als Konkurrenz zu etablierten Providern agiert, so gefährdet er seine Gemeinnützigkeit.

Aber: Die KBU vermarktet Internetzugänge. Der Internetzugang wird beworben (siehe Foto) und auf der Mailingliste eingefordert. KBU wirbt aktiv für Hotspots in Bäckereien oder in anderen Unternehmen.

Hier entstehen Konflikte. Freifunker, die ihr Netzwerk bauen möchten werden mit dem Lieferversprechen anderer konfrontiert. Sie werden genötigt, das Werbeversprechen entweder zu erfüllen oder das Freifunk-Netz wegen Überlastung nicht weiter verwenden zu können. Sie fühlen sich überlastet, da sie immer mehr Kunden versorgen müssen. Aus freien Funkern werden Administratoren. Es kommen kaum neue hinzu: Es ist nicht attraktiv eine kommerzielle Dienstleistung für lau zu erbringen und sich daran aufzureiben. Alternative technische Konzepte werden in weiten Teilen der Community nur dann akzeptiert, wenn sie die Servicequalität verbessern und das Werbeversprechen einhalten.

Einige möchten jedoch Netze bauen, die Vorteile eines Meshes aus autonomen, vom User selbstverwalteten Routern auf jedem einzelnen Fensterbrett einer Straße und eines Kiezes haben.

Die Diskussion starten

Ich stimme kinolux ohne Vorbehalt zu. In allen Punkten. Freifunk kann kein lokaler, selbstverwalteter und nicht-kommerzieller ISP sein.

Wofür steht die KBU? Zwei Vorschläge:

  1. Hotspot-Netz mit Internet
  2. Dezentrales freifunk Mesh-Netz

Wenn ihr ein Hotspot-Netz haben wollt, dann werdet ISP. Stoppt Broadcasts auf den Supernodes und damit die Kommunikation unter den Accesspoints und Clients. Löst fastd nach und nach durch L2TP ab. Konfiguriert DHCP-Relays auf den Hotspots und nehmt die L2TP-Verbindungen aus den Layer-2 Segmenten mit Wifi-Uplinks. Bezahlt eure Admins anständig.

Andernfalls nehmt beispielsweise die Supernodes-Sind-Nodes-Artikel als Blaupause für Meshes aus autonomen, selbstverwalteten Routern. Released nicht weiter Gluon Off-the-Shelf. Entwerft ein Vorgehen, wie Neulinge ihre OpenWRT-Router konfigurieren können.

Die Diskussion ist überfällig.

Ich möchte unregulierte Netze, freie freifunk Netze bauen - Und Du?

Frank Nord, 11 February 2016

Supernodes sind Nodes

Nicht als Server gedacht - Teil 3

Mesh-On-WAN, Babel, fastd, L2TP, DNS, etc. . Bau’ Deinen Node aus!

Diese Serie besteht aus 3 Teilen. Teil 1 ist ein Howto zu Supernodes und Nodes. Teil 2 geht auf Dezentralisierung und die Probleme des KBU Netzes im Dezember / Januar ein. Teil 3 gibt einen technischen Ausblick. Dies ist Teil 3.

Zusammenfassung Teil 1+2

Freifunk-Netze bestehen aus Nodes. Nodes routen Traffic. Sie verbinden Clients mit dem Freifunk-Netz, ohne dass auf Endgeräten Software installiert werden muss.

In Teil 1 hab’ ich erzählt, wie Du eine OpenWRT-Box als Node konfigurieren kannst. Dabei habe ich OpenWRT-Boardmittel benutzt und jede Menge Einstellungen gesetzt. Am Ende existierte ein Node, der IPv4-Adressen per DHCP verteilt, das Internet über ein hide.me-VPN freigibt und über das KBU-Backbone-VPN routed.

In Teil 2 hab’ ich die Entwicklung des Freifunk-KBU Netzes dargelegt. Dabei ich hab’ Probleme aufgezeigt, die entstanden sind: Wenige zentrale Nodes sind überlastet, werden auf dedizierten Servern betrieben und von 3-4 Admins gewartet. Technische Impulse fehlen.

Am Ende vom zweiten Teil steht das Fazit, dass die alte Unterscheidung zwischen Nodes und Supernodes keinen Sinn macht. Jeder Node muss routen um das Netz zu entlasten und zu demokratisieren. Accesspoints unterstützen Nodes dabei, Clients zu verbinden.

Hier ist nun der dritte und letzte Teil.

Den Node erweitern

Der Node aus Teil 1 funktioniert - einige Dinge fehlen aber:

  • Routing findet nur über VPN statt - nicht über das WLAN.
  • Roaming ist nur über WLAN möglich - eine Entlastung per Kabel nicht.
  • Eine Einbindung von Richtfunkstrecken ist nicht möglich.

Zudem wird Tinc und OpenVPN mit AES / OpenSSL verwendet. Die Verfahren sind sicher, aber langsam und benötigen viel Speicherplatz. Einige Geräte (bspw. TP-Link TL-WR841n) haben dafür zu wenig Flash-Speicher.

In diesem Artikel schreibe ich über Ideen, mit diesen Problemen umzugehen. Anders als in Teil 1 wird die Technik bei Freifunk-KBU noch nicht verwendet. Alles ist experimentell. Möglicherweise stellst Du fest, dass das eine oder das andere eine ziemlich dumme Idee ist. Melde Dich dann auf der Mailingsliste und diskutiere darüber. Der Fahrplan:

  1. Mesh-Routing über Babel
  2. Roaming über Kabel: batman-adv und tinc über WAN / LAN
  3. Ohne Tinc: fastd und Babel.
  4. Ersatz für OpenVPN: hide.me mit PPTP
  5. Gerichtete Links: L2TP
  6. Platz schaffen: OpenWRT ohne Webgui
1. Mesh-Routing über Babel

In Teil 1 hab’ ich gezeigt, wie Du Routing über Tinc konfigurieren kannst. Zusätzlich kannst Du Routes mit benachbarten Nodes austauschen. Installiere hierzu babel. Konfiguriere es, Routes aus table 66 im Netz zu verbreiten. wlan0 ist das Ad-Hoc interface, das in Babel eingebunden wird. Weiterhin muss der IP-Range in table 66 eingetragen werden, damit er von Babel exportiert wird.

opkg install babeld

uci -q batch <<EOF
        set babeld.@general[0].export_table='66'
        set babeld.@general[0].import_table='66'

        add babeld interface
        set babeld.@interface[-1].ifname='wlan0'
        commit babeld

        add network route
        set network.@route[-1]=route
        set network.@route[-1].interface='freifunk'
        set network.@route[-1].target='172.27.8.0'
        set network.@route[-1].netmask='255.255.255.128'
        set network.@route[-1].gateway='0.0.0.0'
        set network.@route[-1].metric='0'
        set network.@route[-1].mtu='1500'
        set network.@route[-1].table='66'
        commit network

EOF
/etc/init.d/babeld restart

Debugging

Der Start von babeld generiert die config /var/etc/babeld.conf. Falls generiert, kannst Du babeld auch im Vorderung starten.

/etc/init.d/babeld stop
babeld -d 2 -c /var/etc/babeld.conf

Falls Du /etc/config/babeld änderst, musst Du Config durch den Start von babeld neu generieren. Das geht bspw. mit /etc/init.d/babeld restart; /etc/init.d/babeld stop

2. batman-adv / tinc über Draht

Der Nodes erlauben Roaming: Stehen mehrere in einem Gebäude, so können sich Endgeräte von einem WLAN zum anderen verbinden ohne das IP-Verbindungen getrennt werden. Dabei werden die Datenpakete innerhalb des Meshes zu dem Node gesendet, von dem das Endgerät die IP-Adresse hat. Bei größeren Installation ist es daher hilfreich, die Geräte zusätzlich per Kabel zu verbinden um die Funkverbindung zu entlasten. Dies erreichst Du, indem Du das WAN-Interface dem bat0-Interface hinzufügst. batman-adv Frames werden dann über das WAN-Interface gesendet

Gleichzeitig kannst Du Tinc-Peerings über Draht konfigurieren um direkte, unverschlüsselte Verbindungen zu erlauben. Hierzu wird Tinc in der Firewall freigegeben.

uci -q batch <<EOF
        add firewall rule 
        
    set firewall.@rule[-1].name='Tinc (Mesh-On-WAN)'
    set firewall.@rule[-1].src='wan'
    set firewall.@rule[-1].dest_port='655'
    set firewall.@rule[-1].proto='tcpudp'
    set firewall.@rule[-1].target='ACCEPT'
    set firewall.@rule[-1].family='ipv4'   
    commit firewall

        set network.mesh_wan='interface'
        set network.mesh_wan.ifname='eth1' # Durch tatsaechliches WAN-Interface ersetzen!
        set network.mesh_wan.mesh='bat0'
        set network.mesh_wan.proto='batadv'
        commit network

EOF
/etc/init.d/firewall restart
/etc/init.d/network restart

Zusätzlich müssen für die Tinc-Peers noch lokale Adressen eingetragen werden, damit die Verbindung aufgebaut wird. Hier wird der node mein_anderer_node als lokaler Peer definiert und die Crypto ausgeschaltet. Das Beispiel zeigt die Konfigurationsdateien.

Tinc-Konfiguration

# /etc/tinc/kbubackbone/tinc.conf 
Mode =  Router
Name =  mein_neuer_supernode
Device= /dev/net/tun
ConnectTo = paul
ConnectTo = paula
ConnectTo = mein_anderer_node

Node-Konfiguration

# /etc/tinc/kbubackbone/hosts/mein_anderer_node 
# LAN-Adresse
Address=192.168.41.27 
Subnet=172.27.8.128/25
# Crypto ist aus
Cipher=none

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEA1nroE8C062MsqDbPetfh/1ZjoljlrCZnVdu/d3w463tEZ4kVksKP
k+WD9YwJn06Z8SU9D2G16fHrZINvmMhCnWZ/5oLMsupfoV5BFy6O87OlaHcXQ3e3
D2nMplsSnaUo8XEYiYncep2nkewmUnsoHF86SSzTi8/mCknVVrTvmK8ssB4ZR7nu
98LSZ5yeGvJ8Ysbg0a/hE8lKeLmSI3+PJy3CiyJaEzdM0FGBkoshLC3jL/bMwxk4
J7CYpbaf/rphshg0LvWbjzs7EOdI5HpwdrTj9jNc5gkebDvnklYb8rLTOcLz07Y+
dPDcn+ohgUts/pNrGo7jPIAWhu8R0j9OvwIDAQAB
-----END RSA PUBLIC KEY-----
3. Backbone-Routing ohne Tinc

In Teil 1 wird Tinc verwendet, um Datenpakete mit anderen Nodes auszutauschen. Tinc benötigt OpenSSL und damit viel Speicherplatz. Als Link-State-Routing-Protokoll belastet es die Nodes zusätzlich. Babel benötigt weniger. Komplizierter ist das Routing zu anderen Nodes, die nicht per Funk oder Kabel erreichbar sind:

  • Mit welchen anderen Nodes möchte ich Daten austauschen?
  • Welches Routing-Protokoll verwende ich?

Da ich einen IP-Adressbereich der KBU-Community verwende, entscheide ich mich für babel und fastd-Tunnel. Babel ist dabei das Interior Gateway Protocol (IGP). Aktuell gibt es kaum fastd-Babel-Peerings im KBU-Netz. Alles ist experimentell.

Es gibt zwei naheliegende Alternativen:

  1. Kein fastd oder ein anderes VPN verwenden. Das Freifunk-Netz besteht dann autark ohne Internet.
  2. Das Intercity-VPN (ICVPN) und BGP verwenden.

In der Praxis könnten alle Alternativen relevant sein: Bei Nodes ohne Internet-Uplink macht ein VPN keinen Sinn. Gleichzeitig wird es hoffentlich Peerings mit dem ICVPN-Zugang geben. Alles ist experimentell und ich kann nicht absehen, was sich am Ende durchsetzt. Ich zeig’ einfach mal wie’s geht.

Netzwerk-Konfiguration

Das VLAN für Babel wird als babel_vlan mit tag 42 definiert. eth1 ist hier das WAN-Interface. Das fastd-Interface wird als tun-Interface gesetzt. Beiden Interfaces wird 172.27.8.1/32 zugewiesen. Weitere Routes werden über babel ermittelt

uci -q batch <<EOF
        set network.babel_vlan='interface'
        set network.babel_vlan.proto='static'
        set network.babel_vlan.ifname='eth1.42'
    set network.babel_vlan.ipaddr='172.27.8.1'
    set network.babel_vlan.netmask='255.255.255.255'
        set network.babel_vlan.ip4table='66'


    set network.fastd='interface'
    set network.fastd.ifname='tap-fastd'
    set network.fastd.proto='static'
    set network.fastd.ipaddr='172.27.8.1'
        set network.fastd.netmask='255.255.255.255'
        set network.fastd.ip4table='66'


    commit network

    add babeld interface
        add babeld interface
        set babeld.@interface[-1].ifname='eth1.42'
        set babeld.@interface[-2].ifname='tap-fastd'
        commit babeld

EOF
/etc/init.d/network restart

In /etc/config/firewall muss die Freifunk-Zone nun insb. fastd und babel_vlan enthalten.

config zone                                     
        option forward 'ACCEPT'        
        option output 'ACCEPT'        
        option input 'REJECT'      
        option mtu_fix '1'                  
        option name 'freifunk'              
        option network 'bat0 freifunk mesh kbubackbone babel_vlan fastd'

Fastd-Konfiguration

Fastd lauscht auf Port 10000. Keys werden generiert. Ein Peer ist definiert.

opkg install fastd


uci -q batch <<EOF

    set fastd.mein_anderer_node='peer'
        set fastd.mein_anderer_node.enabled='1'
        set fastd.mein_anderer_node.net='backbone'
        set fastd.mein_anderer_node.key='25c4332cafaaf350e9cf0969d755121b6f7015b9cd99dc421a29445edfb0629b'
        set fastd.backbone=fastd
        set fastd.backbone.secret='generate'
        set fastd.backbone.enabled='1'
        set fastd.backbone.syslog_level='info'
        set fastd.backbone.mode='tap'
        set fastd.backbone.interface='tap-fastd'
        set fastd.backbone.mtu='1312'
        set fastd.backbone.forward='0'
        set fastd.backbone.secure_handshakes='1'

        add_list fastd.backbone.method='salsa2012+umac'
        add_list fastd.backbone.bind='any:10000'
        commit fastd

        add firewall rule 
        
    set firewall.@rule[-1].name='fastd'
    set firewall.@rule[-1].src='wan'
    set firewall.@rule[-1].dest_port='10000'
    set firewall.@rule[-1].proto='udp'
    set firewall.@rule[-1].target='ACCEPT'
    set firewall.@rule[-1].family='ipv4'   
    commit firewall

EOF
/etc/init.d/firewall restart
/etc/init.d/fastd restart

Hier ist Beispielhaft ein peer mein_anderer_node konfiguriert. Hier musst Du wahrscheinlich Dinge anpassen.

Wenn Du mit anderen peeren möchtest, musst Du Port 10000/tcp in Deiner Firewall (z.B. auf Deiner Fritzbox) freigeben. Dann kannst Du auf der Mailingliste fragen, wer mit Dir peeren will. Deinen Public-Key siehst Du mit echo "secret \"$(uci get fastd.backbone.secret)\";" | fastd -c - --show-key.

4. Hide.me mit PPTP

Hide.me bietet auf Verbindungen über PPTP an. PPTP ist nicht so sicher wie OpenVPN und kann gebrochen werden. Trotzdem hilft es gegen Deep-Packet-Inspection. Der PPTP-Client kommt ohne SSL-Library aus, benötigt weniger Platz und ist schneller als OpenVPN. Der Zugang wird wie folgt konfiguriert.

Hinweise

opkg install ppp-mod-pptp kmod-nf-nathelper-extra

uci -q batch <<EOF
        set network.hideme=interface
        set network.hideme.proto='pptp'
        set network.hideme.server='DE.HIDE.ME'
        set network.hideme.username='hideme_test'
        set network.hideme.password='ganz geheim und inzwischen geaendert'
        set network.hideme.ip4table='66'
        set network.hideme.peerdns='0'

        commit network
EOF

/etc/init.d/network restart
5. Gerichtete Verbindungen - L2TP

L2TP, das Layer-2 Tunnel Protocol erlaubt schnelle VPN-Verbindung. Die wichtigsten Unterschiede zu fastd:

  • L2TP ist ein Kernel-Modul, damit kaum CPU-Last
  • L2TP kann kein Crypto, damit ist Deep-Packet-Inspection möglich
  • L2TP ist kein Deamon. Jeder Peer muss einzeln konfiguriert werden.

L2TP ist wichtig, wenn Richtfunk-Strecken eingesetzt werden. Da Broadcast / Multicast eine wesentlich geringer Datenrate hat, wird die Kapazität von den batman-adv oder Babel Paketen schnell aufgebraucht. In L2TP-Pakete verpackt können sie aber als Unicast an das andere Ende der Richtfunkstrecke gesendet werden.

L2TP ist nicht wirklich in OpenWRT integriert - Tunnel können nicht über /etc/config/network konfiguriert werden. Die Protocol-Option erwartet einen IPSec-Server auf der Gegenseite. In diesem Beispiel ist der Node mit zwei Richtfunkstrecken verbunden

Software Installation

ip kann keine L2TP Tunnel einrichten - Du benötigst das Paket ip-full und ein paar Kernel-Module

opkg remove ip
opkg install ip-full kmod-l2tp kmod-l2tp-eth kmod-l2tp-ip
Tunnel konfigurieren

In diesem Beispiel hängen beide Richtfunkstrecken am Lan-Interface des Nodes. Das ist nicht klug, aber in diesem Beispiel verzichten wir auf die Partitionierung des Switches.

/etc/init.d/l2tp-tunnel

#!/bin/sh /etc/rc.common
#Copyright (C) 2016 Frank Nord <frank.nord@mailbox.org>



START=99
STOP=22

# Kirchturm 1: Tunnel 1000 / Session 1000
# Kirchturm 2: Tunnel 2000 / Session 2000

start () {
        /usr/sbin/ip l2tp add tunnel tunnel_id 1000 peer_tunnel_id 1000 encap ip local 192.168.1.1 remote 192.168.1.2
        /usr/sbin/ip l2tp add tunnel tunnel_id 2000 peer_tunnel_id 2000 encap ip local 192.168.1.1 remote 192.168.1.3
        /usr/sbin/ip l2tp add session tunnel_id 1000 session_id 1000 peer_session_id 1000
        /usr/sbin/ip l2tp add session tunnel_id 2000 session_id 2000 peer_session_id 2000

        # Interfaces starten - Devices sind nun verfuegbar
        /sbin/ifup kirchturm0
        /sbin/ifup kirchturm1
}

stop () {
        /usr/sbin/ip l2tp del session tunnel_id 1000 session_id 1000 peer_session_id 1000
        /usr/sbin/ip l2tp del session tunnel_id 2000 session_id 2000 peer_session_id 2000
        /usr/sbin/ip l2tp del tunnel tunnel_id 1000 peer_tunnel_id 1000 encap ip local 192.168.1.1 remote 192.168.1.2
        /usr/sbin/ip l2tp del tunnel tunnel_id 2000 peer_tunnel_id 2000 encap ip local 192.168.1.1 remote 192.168.1.3

}

Hinweise:

  • chmod 755 /etc/init.d/l2tp-tunnel nicht vergessen.
  • Es können nur tunnel mit existierenden Adressen aufgebaut werden
  • /etc/init.d/l2tp-tunnel start ausführen
UCI Konfiguration
uci -q batch <<EOF
        set network.kirchturm0='interface'
        set network.kirchturm0.ifname='l2tpeth0'
        set network.kirchturm0.proto='static'
        set network.kirchturm0.ipaddr='172.27.254.2.1/30'
        set network.kirchturm0.ip4table='66'
        set network.kirchturm0.auto='0'

        set network.kirchturm1='interface'
        set network.kirchturm1.ifname='l2tpeth1'
        set network.kirchturm1.proto='static'
        set network.kirchturm1.ipaddr='172.27.254.2.5/30'
        set network.kirchturm1.ip4table='66'
        set network.kirchturm1.auto='0'
        
        commit network

EOF
/etc/init.d/network restart

Hinweise:

  1. Die IP-Adressbereiche 172.27.254.2.1 und 172.27.254.2.5/30 sind Transit-Netze für babel-Routing. Es sind die Adressen im Tunnel, nicht die äußeren Endpunktadressen.
  2. Die erzeugen Interfaces müssen wieder zur firewall, babel und batman-adv hinzugefügt werden. Das spare ich mir hier - das geht genau so wie bei fastd-Verbindungen (siehe oben).
  3. Das Setup ist noch ein wenig bugged - die Tunnel starten beim Boot nicht. Workaround /etc/init.d/l2tp-tunnel start in /etc/rc.local eintragen.
6. OpenWRT ohne Webgui

Mein TP-Link WDR3500 hat 8 MB Flash-Speicher - einige Geräte (z.B TP-Link TL-WR841n) haben nur 4 MB. Wenn Du auf OpenVPN und Tinc verzichtest (d.h. babel und pptp verwendest), kannst Du mit dem OpenWRT Image-Builder auch OpenWRT mit den notwendigen Paketen für kleinere Geräte bauen.

# Auf dem Laptop ausführen - nicht unter OpenWRT
# Download
wget http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/OpenWrt-ImageBuilder-15.05-ar71xx-generic.Linux-x86_64.tar.bz2
# Entpacken
tar xjf OpenWrt-ImageBuilder-15.05-ar71xx-generic.Linux-x86_64.tar.bz2
cd OpenWrt-ImageBuilder-15.05-ar71xx-generic.Linux-x86_64
# Beispiel fuer TL-WR841n - make info zeigt alle Optionen
make image PROFILE="TLWR841" PACKAGES="ip-full babeld kmod-batman-adv batctl fastd ppp-mod-pptp kmod-nf-nathelper-extra kmod-l2tp kmod-l2tp-eth kmod-l2tp-ip"

Fazit

Du hast bis hierhin durchgehalten. Glückwunsch. In Teil 1 und Teil 3 habe ich Dir gezeigt, wie Du Nodes für ein Freifunk-Netz bauen kannst. In Teil 2 habe ich aus der Geschichte von Freifunk-KBU erzählt. Die Bash-Scripts aus diesen Artikel sind noch nicht “rund”. Ich hab’ diesmal auch darauf verzichtet, sie in ein git zu stellen, da es lose Snipplets sind, die angepasst werden müssen.

Egal zu welcher Freifunk-Community Du gehörst oder ob Du eine gründen möchtest: Du hast hier Wissen bekommen, dass Dir auch dabei hilft Gluon zu verstehen. Diese Blog-Artikel sagen nichts darüber aus, welche Hardware wie viel schafft oder wie Du die Bash-Scripte und Snipplets am besten verteilst. Was soll davon in eine Freifunk-Firmware? Finde es heraus.

Einige Dinge fehlen hier, da sie mit Nodes an sich wenig zu tun haben. Schreib Du doch mal einen Blog-Artikel zum Monitoring via SSH, collectd, DNS, IPv6, map-Anzeige oder irgendetwas anderem.

Frank Nord, 2 February 2016

Supernodes sind Nodes

Nicht als Server gedacht - Teil 2

Im Dezember 2015 / Januar 2016 war das Netz zeitweise unbenutzbar. Was ist geschehen?

Diese Serie besteht aus 3 Teilen. Teil 1 ist ein Howto zu Supernodes und Nodes. Teil 2 geht auf Dezentralisierung und die Probleme des KBU Netzes im Dezember / Januar ein. Teil 3 gibt einen technische Ausblick. Dies ist Teil 2.

Zusammenfassung Teil 1

Freifunk-Netze bestehen aus Nodes. Nodes sind dabei alle möglichen Geräte, die in ein Freifunk-Netz eingebunden sind. Supernodes sind Router die VPN-Tunnel aufbauen können.

  • Nodes sind kleinere Geräte mit begrenzten Ressourcen.
  • Supernodes sind größere Geräte, die Traffic routen.

In Teil 1 hab’ ich erzählt, wie Du eine OpenWRT-Box als Node und schließlich als Supernode konfigurieren kannst. Dabei habe ich OpenWRT-Boardmittel benutzt und jede Menge Einstellungen gesetzt. Am Ende existierte ein Supernode, der IPv4-Adressen per DHCP verteilt, das Internet über ein hide.me-VPN freigibt und über das KBU-Backbone-VPN routed.

Supernodes auf OpenWRT-Basis existieren im Freifunk-KBU Netz aber praktisch nicht. Fast alle aktiven Supernodes werden auf Server-Hardware in Rechenzentren betrieben und sind über VPN-Strecken angebunden.

Dieser Artikel geht auf die Situation im KBU-Netz, die Geschichte und Probleme ein.

Es ging kaputt

Vor etwa zwei Jahren - Anfang 2014 - war das Netz wieder einmal überlastet. Rampone bemerkte, dass die komplette WLAN-Kapazität immer wieder durch broadcast und anycast Peaks belegt wurde. Die Anzahl der Knoten hat sich seitdem mehrmals verdoppelt. Die Last auf den wenigen Servern, die als Supernodes eingesetzt waren schoss nach oben. Im Dezember 2015 / Januar 2016 war das Netz u.a. deswegen zeitweise unbenutzbar.

Verschiedene Techniken (fastd, mcast-Rate, ebtables, no-rebroadcast) konnten die Last kurzzeitig reduzieren, helfen aber auf längere Sicht nicht.

Die Entwicklung bei Freifunk-KBU

Das Netz war nie wirklich dazu gedacht, schnellen Internetzugang in einem großen Rahmen anzubieten. Anders als Hotspot-Netze ist Freifunk-KBU nicht einfach ein Internet-Provider.

Freifunk-KBU entstand im C4 als Erfa-Projekt mit CCC-Projektmitteln. Der Chaos Computer Club ist in Erfa-, d.h. Erfahrungsaustausch, Kreisen organisiert. Ein solcher Kreis ist der Chaos Computer Club Cologne (C4) e.V.. Vereinszweck des C4 sind unter anderem Forschung, Wissenschaft und Bildung.

Freifunk ist eine lose und dezentrale Initiative. Sie besteht aus Menschen, die sich zu Freifunk bekennen und freie Funknetze bauen. Freifunk und Erfa-Kreis passen gut zusammen: Freifunk heißt, Netze zu bauen, an dem jede / jeder aktiv teilnehmen kann - ohne Gremium, Admins oder zentrale Autoritäten. Der Erfa-Anspruch ist hier freie Netze zu erforschen und Wissen darüber zu vermitteln.

Viele Design-Entscheidungen bei KBU kommen daher:

  • Die komplette Dokumentation ist offen. Sie kann von anderen Freifunk-Netzen verwendet werden. Auch in Köln oder Bonn.
  • Mit Tinc, wird ein dezentrales P2P-VPN verwendet um Supernodes zu verbinden.
  • Die Ressourcenvergabe (Namen, IP-Adressen) wird in Wikis koordiniert. Es gibt keine zentrale Autorität.

Dennoch hängt der komplette Freifunk-Betrieb im Köln-Bonner-Raum an ca. 3-4 Admistratoren und einer Hand voll zentralen Supernodes. Sie laufen auf virtuellen Servern in Rechenzentren und können wegen Überlastung abgeschaltet oder gedrosselt werden (https://lists.kbu.freifunk.net/pipermail/freifunk-bonn/2016-January/005730.html). Freifunk-Firmware wird nur noch für die Nutzung im Netz released, d.h. freigegeben.

Das alles hat nur noch wenig mit Erfa-Arbeit zu tun. Der Stand bei Freifunk-KBU ist das Ergebnis einer Entwicklung und er wird aktuell nicht wirklich in Frage gestellt.

Gluon

Vor kurzem wurde Gluon im Netz der KBU eingeführt.

Technisch hat sich wenig geändert. Die KBU verwendet seit ihrem Bestehen einen Fork der Lübecker Freifunk-Firmware. Grundlage ist nach wie vor batman-adv auf fastd-Tunneln. Ein paar Neuerungen wurden übernommen: Shellscripts erweitern das OpenWRT Buildsystem. Ein alfred-Server existiert nun neben dem Register-Server, die collectd-Statistiken werden nicht mehr gepflegt und die Software liegt in neuren Versionen vor. Neben der Gluon-Firmware wird die Gluon Map eingesetzt. Register-Informationen und Batman-adv-VIS-Daten werden ausgeblendet. Die Änderungen beteffen also Details.

Das Verständnis hat sich aber geändert. Gluon bringt Features einfach mit, die für Freifunk interessant sind. Anders als bei früheren Releases interessieren sich aber nicht mehr viele für die Technik. Von vielen wird Gluon als Produkt verstanden, dass einfach eingesetzt wird.

Kurzum: Die Gluon-Umstellung betrifft die Mentalität und nicht die Technik. Die Probleme bleiben bestehen.

Freifunk Richtig und Wahr

Es ist kompliziert. Niemand sagt, dass dieser Freifunk „falscher Freifunk” ist oder jenes Netz stinkt. Konsenz bei Freifunk ist das Pico Peering Agreement. Es wird im KBU-Netz umgesetzt. Wie bei allen anderen Freifunk-Communities.

Bei KBU engagieren sich viele Menschen dafür, freies Internet in öffentlichen Gebäuden oder Flüchtlingsunterkünften zu bauen. Das Engagement dafür ist gut - macht weiter. Ich finde es aber beispielsweise besser, ein Netz mit, als ein Netz für Flüchtlinge oder andere zu bauen. Diesen Anspruch vertreten nicht alle in der Freifunk-KBU Community.

Dennoch muss sich die Freifunk-KBU Community entscheiden, welche technischen Konsequenzen aus der Ausrichtung entstehen. Viele Entscheidungen (fester Funkkanal zum Meshing, Roaming über weite Gebiete) beeinträchtigen die WLAN- und Internet-Geschwindigkeit stark. Die Überlastung der KBU-Supernodes wäre auch so evtl. vermeidbar. Auch wären eine bessere Organisation & Aufteilung der Arbeit sowie viele neue Freifunkerinnen und Freifunker, wichtig um die Arbeit zu bewältigen.

Das Wachstum ist aber beschränkt: Nur wenige werden Super-Nodes betreiben, wenn die Hürde hoch ist, Dokumentation fehlt und Wissen nicht aktiv und progressiv vermittelt wird. Lernen, Verstehen und Ausprobieren gehört dazu.

Unvereinbare Positionen?

Die Positionen sind nicht unvereinbar. Niemand in der Freifunk-KBU Community meint, dass Erfa-Arbeit schlecht ist. Niemand im C4 meint, dass es eine schlechte Idee ist, Flüchtlingsunterkünfte mit kostenlosem WLAN auszustatten. Beide Positionen ergänzen sich.

Fragen an die Community

Die Freifunk-KBU Community muss sich überlegen:

  1. Ist das Netz noch dezentral und Freifunk, wenn es von 3-4 Admins administriert wird?
  2. Wie soll das Projekt bestehen, wenn die Last auf den Servern nicht handhabbar ist?
  3. Was ist das Ziel des Projekts?

Kurz und knapp - meine Antworten:

  1. Es ist sehr schlecht, dass das Netz von 3-4 Admins zentral gesteuert wird.
  2. Es gibt keine Lastprobleme auf Servern, falls keine zentralen Server als Supernodes verwendet werden.
  3. Bauen wir gemeinsam ein freies Netz, dass von niemandem einfach abgeschaltet werden kann. (Lisa in “Freifunk verbindet!”)

Wenn Du zustimmst, dann:

  • Bau Deinen Supernode. Bau Dein eigenes Freifunk-Netz im Freifunk-Netz.
  • Erzähl Leuten davon und verbreite das Wissen. Schreib’ Wiki-Seiten oder Blogs.
  • Forsche und fordere die Technik heraus: Entwickle Deinen Supernode weiter.

Fazit

Vor kurzem wurde das Netzwerk in drei Segmente eingeteilt. Es besteht aus den Hoods Köln, Bonn, Umgebung. Die Last auf den Supernodes wurde wieder geringer - 1/3 weniger Broadcast-Pakete werden versendet. So war es bereits bei Einführung des no-rebroadcast-Patches. Das Netz konnte für ein paar Monate stabilisiert werden.

Die KBU-Supernodes betreiben nun drei Netze. Einrichtung und Setup wurden komplexer. Die Netze werden von dem kleinen Admin-Team verwaltet. Gluon ist technisch komplexer als die Classic-Firmware und damit schwerer zu debuggen und zu verstehen. Kaum einer stellt das aktuelle Konzept aus Nodes, Supernodes und der “Komplettes-Bridging”-Strategie in Frage.

Ich fange mal damit an:

  • Nodes sind Geräte, die Traffic routen.
  • Accesspoints sind kleinere Geräte mit begrenzten Ressourcen.

Kleine Geräte bauen kein Netz. Sie sind Accesspoints, d.h. Zugangspunkte zu den Supernodes. Supernodes sind die einzigen Nodes im Freifunk-Netz - ich nenne sie fortan einfach Nodes. Der in Teil 1 vorgestellte Supernode ist ein Node der genau das umsetzt. Die alte Unterscheidung zwischen Nodes und Supernodes ist hinfällig.

Du musst Dich entscheiden, wie Du Freifunk machst, baust und was Dir dabei wichtig ist. Ich hab’ Dir erzählt, wie die Dinge funktionieren. Ideen zur Weiterentwicklung, zum Testen und Forschen gibt’s dann in Teil 3 dieser Blog-Serie.

Und nun mach Freifunk. Viel Spaß am Gerät.

Frank Nord, 1 February 2016

Supernodes sind Nodes

Nicht als Server gedacht - Teil 1

Freifunk Nodes bestehen aus Nodes, den einzelnen Knoten. Supernodes sind Nodes - keine zentralen Server. Denk daran.

Diese Serie besteht aus 3 Teilen. Teil 1 ist ein Howto zu Supernodes und Nodes. Teil 2 geht auf Dezentralisierung und die Probleme des KBU Netzes im Dezember / Januar ein. Teil 3 gibt einen technische Ausblick. Dies ist Teil 1.

Wie baut man ein Freifunk-Netz aus WLAN-Routern?

Speicherplatz, Arbeitsspeicher und CPU-Leistung sind auf WLAN-Routern sehr begrenzt.

Nimm TP-Link TP-WR841n als Beispiel. Er ist günstig (ca. 15 €), hat aber nicht genug Ressourcen für Verschlüsselung und Routing - es gibt einfach zu wenig Speicherplatz um die notwendige Software zu installieren. Dennoch ist er sehr populär, da er günstig ist.

Oder nimm den TP-Link TP-WR842nd als Beispiel. Er ist nicht ganz so günstig (ca. 30 €), hat aber doppelt so viel Speicherplatz und einen USB-Port. Alix und APU boards sind weitaus teurer, haben aber auch deutlich mehr CPU-Leitung, Arbeitsspeicher und Speicherplatz.

Freifunk-Netze sind daher nicht einheitlich: Kleine Geräte machen nicht viel - sie sind einfach zu schwach. Andere haben genug Kapazität um VPN-Tunnel zu verschlüsseln oder Routing-Daemons zu starten. Damit gibt es zwei Kategorien:

  • Nodes sind kleinere Geräte mit begrenzten Ressourcen
  • Supernodes sind größere Geräte, die Traffic routen.

Das macht Supernodes offensichtlich interessant. Wenn Du jedoch nur wenig Geld ausgeben willst oder eine große Fläche abdecken möchtest, sind Nodes jedoch auch Option.

Die Fahrt beginnt

Hier erfährst, wie Du einen Node oder einen Supernode aufsetzen kannst.

Im Prinzip ist es egal, welche Hardware du verwendest - einige Supernodes laufen beispielsweise auf Server-Hardware. In diesem Tutorial gehe ich aber davon aus, dass Du vor einem OpenWRT WLAN-Router sitzt. Ich verwende hier einen TP-Link WDR3500 (ca. 35 €).

Die Installation ist nicht schwer, aber aufwendig. Fehler passieren schnell.

  • Verwende das Kommando logread und sehe damit wo es klemmt
  • Alle Einstellung kannst Du per Copy & Paste in Deine SSH-Sitzung übertragen - es gibt aber auch Shell-Scripts: https://github.com/franknord/node-scripts)

Unser Fahrplan ist recht übersichtlich. Zuerst richte ich einen Node ein, danach mache ich ihn zum Supernode. Am Ende ziehe kommt ein Fazit. Konkret:

  1. Node aufsetzen
    1. Voraussetzungen
    2. Software installieren
    3. WLAN und Netzkwer konfigurieren
    4. Firewall Regeln setzen
  2. Den Node zum Supernode machen
    1. Software installieren
    2. IP-Adressen zuweisen
    3. DHCP-Server konfigurieren
    4. Routing einrichten
    5. Internet-Zugang über VPN (hide.me) freigeben
    6. Das KBU-Backbone VPN (Tinc) konfigurieren
  3. Fazit

Einen Node aufsetzen

0. Voraussetzungen

Ein paar Voraussetzungen gibt es.

  1. Auf dem WLAN-Router läuft OpenWRT 15.05 (“Chaos Calmer”)
  2. Du hast ein Kennwort gesetzt und bist per SSH verbunden.
  3. Der Router ist mit dem Internet verbunden.

Weiterhin sollte der Router:

  • Nicht weiter konfiguriert sein
  • Mehrere WLAN-Netze gleichzeitig (Virtual AP - VAP) auf einem Radio unterstützen

Falls Du den Router bereits weiter konfiguriert hast, ist das grundsätzlich kein Problem. Da ich jedoch nicht voraussehen kann, was Du geändert hast, kann es im Einzelfall zu Konflikten kommen. Viele Router (TP-Link Serie, usw.) unterstützen VAP. Falls Du Dir nicht sicher bist, sehe im OpenWRT-Wiki nach, was Dein Router kann.

1. Software installieren

Der Node benötigt batman-adv. Es wird mittels opkg installiert. (https://github.com/franknord/node-scripts/blob/master/node/01_install_software.sh )

opkg update
opkg install kmod-batman-adv batctl 
batctl -v

Wenn alles ok ist, gibt das letzte Kommando die Version aus: batctl 2014.4.0 [batman-adv: 2014.4.0].

2. WLAN- und Netzwerk-Konfiguration

Es gibt zwei Netzwerke:

  • Ein Accesspoint mit SSID Freifunk
  • Ein Ad-Hoc Netz mit IBSSID / EBSSID 42:42:42:42:42.

Verwende uci um die Konfigration anzupassen. Führe dazu folgende Kommandos via SSH aus (https://github.com/franknord/node-scripts/blob/master/node/02_wlan_lan.sh ).

Hinweis: Wenn Du bereits ein WLAN konfiguriert hast, entferne die Zeile delete wireless.@wifi-iface[0] aus der Liste. Dein WLAN bleibt bestehen.

uci -q batch <<EOF
        delete wireless.radio0.disabled                 # WLAN Einschalten
        delete wireless.@wifi-iface[0]                  # OpenWRT-Default WLAN loeschen
        set wireless.radio0.channel='1'                 # Funkeinstellungen
        set wireless.radio0.htmode='HT20'
        set wireless.radio0.country='DE'
        
        set wireless.wifi_freifunk='wifi-iface'         # 1. WLAN: Accesspoint
        set wireless.wifi_freifunk.device='radio0'
        set wireless.wifi_freifunk.network='freifunk'
        set wireless.wifi_freifunk.mode='ap'
        set wireless.wifi_freifunk.ssid='Freifunk'
        
        set wireless.wifi_mesh='wifi-iface'             # 2. WLAN: Ad-Hoc Mesh
        set wireless.wifi_mesh.device='radio0'
        set wireless.wifi_mesh.network='mesh'
        set wireless.wifi_mesh.mode='adhoc'
        set wireless.wifi_mesh.ssid='42:42:42:42:42:42'
        set wireless.wifi_mesh.bssid='42:42:42:42:42:42'
        set wireless.wifi_mesh.mcast_rate='12000'
        commit wireless

        set batman-adv.bat0.gw_mode='client'            # Batman-adv: Router ist Node - kein Supernode
        set batman-adv.bat0.orig_interval='5000'        # Beacon alle 5 Sekunden senden
        set batman-adv.bat0.bridge_loop_avoidance='1'   # Bride Loop-Avoidance Feature einschalten
        commit batman-adv

        set network.bat0='interface'                    # Interface bat0 (batman-adv) im System bekannt machen
        set network.bat0.proto='none'
        set network.bat0.ifname='bat0'

        set network.freifunk='interface'                # Interface "Freifunk" im System bekannt machen
        set network.freifunk.ifname="bat0"                # Enhaelt als Bridge bat0 und den Freifunk-AP (siehe wireless)
        set network.freifunk.type='bridge'              
        set network.freifunk.proto='none'               # Keine IP usw. setzen.
        set network.freifunk.auto='1'
        
        set network.mesh='interface'                    # Mesh als Interface im System bekannt machen
        set network.mesh.proto='batadv'                 # Nutze batman-adv
        set network.mesh.mtu='1532'                     # MTU ist seit batman-adv 2014.0: 1532 Bytes
        set network.mesh.mesh='bat0'                    # Nutze das bat0 Interface fuer das Mesh
        commit network
EOF
/etc/init.d/network restart
3. Firewall-Konfiguration

Aus Sicherheitsgründen muss das Freifunk-Netz abgeschirmt werden. ICMP und IGMP sind aber erlaubt (https://github.com/franknord/node-scripts/blob/master/node/03_firewall.sh ):

uci -q batch <<EOF
        add firewall zone
        set firewall.@zone[-1].forward='ACCEPT'
        set firewall.@zone[-1].output='ACCEPT'
        set firewall.@zone[-1].input='REJECT'
        set firewall.@zone[-1].network='bat0 freifunk mesh kbubackbone'
        set firewall.@zone[-1].mtu_fix='1'
        set firewall.@zone[-1].name='freifunk'

        add firewall rule 
        add firewall rule 

        set firewall.@rule[-1].name='Allow ICMP (Mesh)'
        set firewall.@rule[-1].src='freifunk'
        set firewall.@rule[-1].proto='icmp'                     
        set firewall.@rule[-1].family='ipv4'                    
        set firewall.@rule[-1].target='ACCEPT'                  

        set firewall.@rule[-2].name='Allow IGMP (Mesh)'
        set firewall.@rule[-2].src='freifunk'
        set firewall.@rule[-2].proto='igmp'                     
        set firewall.@rule[-2].family='ipv4'                    
        set firewall.@rule[-2].target='ACCEPT'                  

        commit firewall
EOF
/etc/init.d/firewall restart
Zwischenstand

Der erste Teil ist geschafft: Das WLAN läuft, aber der Router verteilt noch keine IP-Adressen. Wenn ein Supernode in Funkreichweite ist, erreichst Du ihn aber und bekommst von dort eine IP-Adresse zugewiesen.

Den Node zum Supernode machen

Nun wird es komplizierter. Vor Einrichtung des Supernodes musst Du Dir ein paar Gedanken machen:

  • Welche IP-Adressen soll der Supernode verteilen?
  • Wie soll der Supernode routen?
    • Wie werden Pakete zu anderen Freifunk-Supernodes übertragen?
    • Sollen Clients auf das Internet zugreifen können? Und wie?

In diesem Blog-Artikel mache ich es mir einfach. Zu anderen Supernodes nutze ich das Backbone-VPN der KBU-Community routed. Das Internet erreiche ich über einen VPN-Tunnel bei https://hide.me - das KBU-VPN wird verwendet, wenn hide.me nicht verfügbar ist.

Es gibt viele Alternativen: Du kannst das Intercity-VPN oder auch babel und das ad-hoc Netz verwenden um anderen Supernodes zu erreichen. Wenn Du Erfahrung mit Abuse-Handling hast, kannst Du Deinen Internet Zugang auch direkt freigeben.

1. Software installieren

Der Supernode braucht zusätzlich ip, openvpn und tinc (https://github.com/franknord/node-scripts/blob/master/supernode/01_install_software.sh ).

opkg install openvpn-openssl tinc ip git
2. IP-Adressen und Subnet

Wie bei freifunk.net gibt es auch bei KBU eine Wiki für IP-Adressen. https://kbu.freifunk.net/wiki/index.php?title=IP_Subnetze Grundsätzlich kannst Du Dir einen freien IP-Adressbereich suchen und dort eintragen. Leider ist die Seite zur Zeit nicht aktuell - frag einfach auf der Mailingliste und helf mit die Seite aufzumöbeln.

Ich verwende hier 172.27.8.0/25, d.h. 172.27.8.0 - .127. Das musst Du anpassen.

Die IP-Adresse musst Du auf dem Freifunk-Interface konfigurieren, da das Gerät nun routed (https://github.com/franknord/node-scripts/blob/master/supernode/02_ip_addresses.sh ).

uci -q batch <<EOF
        set network.freifunk.proto='static'
        set network.freifunk.ipaddr='172.27.8.1'
        set network.freifunk.netmask='255.255.255.128'
        commit network
EOF
/etc/init.d/network restart
3. DHCP-Server konfigurieren

Für das Freifunk-Interface muss ein DHCP-Server konfiguriert und in der Firewall erlaubt werden (https://github.com/franknord/node-scripts/blob/master/supernode/03_dhcp.sh ).

uci -q batch <<EOF
    set dhcp.freifunk='dhcp'
    set dhcp.freifunk.interface='freifunk'
    set dhcp.freifunk.start='2'
    set dhcp.freifunk.limit='125'
    set dhcp.freifunk.leasetime='10m'
    set dhcp.freifunk.dhcpv6='disabled'
    set dhcp.freifunk.ra='disabled'
    set dhcp.freifunk.dhcp_option='6,172.27.255.3' # Freifunk-KBU: Paul
    commit dhcp

    set batman-adv.bat0.gw_mode='server'            # Batman-adv: Router ist Server, da DHCP
    commit batman-adv

    add firewall rule 
    
    set firewall.@rule[-1].name='Allow DHCP request (Mesh)'
    set firewall.@rule[-1].src='freifunk'
    set firewall.@rule[-1].dest_port='67-68'
    set firewall.@rule[-1].proto='udp'
    set firewall.@rule[-1].target='ACCEPT'
    set firewall.@rule[-1].family='ipv4'   

    commit firewall
EOF
/etc/init.d/dnsmasq restart
/etc/init.d/firewall restart
4. Policy Routing einrichten

Da Traffic aus dem Mesh anders routed werden soll als lokaler Traffic, müssen Policies definiert werden. Der genutzte IP-Adressbereich muss wieder angepasst werden (https://github.com/franknord/node-scripts/blob/master/supernode/04_routing.sh ).

uci -q batch <<EOF
    add network rule
    add network rule

    set network.@rule[-1].in='freifunk'
    set network.@rule[-1].lookup='66'

    set network.@rule[-2].dest='172.27.8.0/25' # Anpassen!
    set network.@rule[-2].lookup='66'
    commit network
EOF
/etc/init.d/network restart
5. Hide.me VPN: Internet freigeben

Hide.me benötigt ein tun-Device mit Firewall-Zone für das Masquerading (https://github.com/franknord/node-scripts/blob/master/supernode/05a_hideme.sh ).

uci -q batch <<EOF
    set network.hideme='interface'
    set network.hideme.proto='none'
    set network.hideme.ifname='tun-hideme'
    commit network

    add firewall zone
    set firewall.@zone[-1].forward='REJECT'
    set firewall.@zone[-1].output='ACCEPT'
    set firewall.@zone[-1].input='REJECT'
    set firewall.@zone[-1].network='hideme'
    set firewall.@zone[-1].mtu_fix='1'
    set firewall.@zone[-1].masq='1'
    set firewall.@zone[-1].name='hidemezone'

    add firewall forwarding 
    set firewall.@forwarding[-1].src='freifunk'
    set firewall.@forwarding[-1].dest='hidemezone'
    commit firewall

EOF
/etc/init.d/network restart
/etc/init.d/firewall restart

Nachdem das Interface vorhanden und registiert ist, erstelle ich das Verzeichnis /etc/hide.me/. Nun lege ich Konfiguration und Zertifikat dort ab. Dabei enthält login meine (inzwischen geänderten) hide.me-Zugangsdaten.

$ ls -l /etc/hide.me/
-rwxr-xr-x    1 root     root           526 Jan 24 20:00 Roosendaal.ovpn
-rwxr-xr-x    1 root     root          1367 Jan 24 15:42 TrustedRoot.pem
-rwxr-xr-x    1 root     root            94 Jan 24 20:07 down.sh
-rwx------    1 root     root            27 Jan 24 16:29 login
-rwxr-xr-x    1 root     root            95 Jan 24 20:07 up.sh
$ cat /etc/hide.me/login 
hideme_test
03aanLp58UNv

Die Dateien up.sh erledigt das setzen der Default-Route. Sie wird so erstellt (https://github.com/franknord/node-scripts/blob/master/supernode/05b_hideme.sh ):

cat > /etc/hide.me/up.sh <<EOF
#!/bin/sh
ip route add 0.0.0.0/1 table 66 dev \$dev
ip route add 128.0.0.0/1 table 66 dev \$dev 
EOF
chmod 755 /etc/hide.me/up.sh

Die Konfiguration (hier: Roosendaal.ovpn) wird geändert. Ergebnis:

client
dev tun-hideme                          # Interface-Name angepasst - passt zu /etc/config/network/
proto udp
remote free-nl.hide.me 3478
cipher AES-128-CBC
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca /etc/hide.me/TrustedRoot.pem         # Pfad angepasst - Muss absolut sein
verb 1                                  # Weniger Logging
auth-user-pass /etc/hide.me/login       # Verweis auf Login-Daten
reneg-sec 0
remote-cert-tls server
verify-x509-name "*.hide.me" name
route-nopull                            # Aufgenommen - keine Default-Route
script-security 2                        # Aufgenommen - Default-Route manuell setzen
up /etc/hide.me/up.sh                   # Aufgenommen - Default-Route manuell setzen

Mit openvpn --config /etc/hide.me/Roosendaal.ovpn kannst Du testen, ob die Einwahl soweit funktioniert.

Zuletzt muss die OpenVPN Instanz in uci registriert werden, damit die Einwahl automatisch erfolgt (https://github.com/franknord/node-scripts/blob/master/supernode/05c_hideme.sh ).

uci -q batch <<EOF
    set openvpn.hideme_config='openvpn'
    set openvpn.hideme_config.enabled='1'
    set openvpn.hideme_config.config='/etc/hide.me/Roosendaal.ovpn'
    commit openvpn
EOF
/etc/init.d/openvpn restart
6. Tinc konfigurieren

Tinc baut die Verbindung zum KBU-Backbone auf. Das Tinc-Setup ist etwas komplizierter. Es gibt doch ein paar Schritte:

  1. Vorbereiten der Verzeichnisse und herunterladen fremder Public-Keys
  2. Erstellen der Konfiguration
  3. Public-Key erzeugen und verteilen
  4. Routing für Tinc erstellen
  5. Tinc-Instanz in UCI registrieren

Vorbereiten der Verzeichnisse und Herunterladen der Public-Keys

Zunächst musst Du ein Verzeichnis für die Tinc-Konfiguration vorbereiten und die existierenden Hosts dort hinterlegen. (https://github.com/franknord/node-scripts/blob/master/supernode/06a_tinc.sh ).

mkdir /etc/tinc/kbubackbone
cd /etc/tinc/kbubackbone
git clone git://github.com/ff-kbu/bbkeys.git hosts

Erstellen der Konfiguration

Um Dich per Tinc zu verbinden, musst auf auf der Mailingliste fragen, wer bereit wäre mir Dir zu peeren. Da Tinc ein dezentrales System ist, kann jeder mit Dir peeren, der Tinc bereits installiert hat. Weiterhin musst Du einen Namen für Deinen Supernode wählen. Ich nutze hier mein_neuer_supernode.

In diesem Beispiel geben die admins von Paul und Paula ihr Ok. Sie sind meine Peering-Partner. Nun müssen Konfiguration und Public Key erstellt werden. (https://github.com/franknord/node-scripts/blob/master/supernode/06b_tinc.sh ).

# Name anpassen!
cat > /etc/tinc/kbubackbone/hosts/mein_neuer_supernode <<EOF
Subnet=172.27.8.0/25
Compression=11
Cipher=aes-256-cbc 
EOF

# Name anpassen!
cat > /etc/tinc/kbubackbone/tinc.conf <<EOF
Mode =  Router
ConnectTo = paul
ConnectTo = paula
Name =  mein_neuer_supernode
Device= /dev/net/tun
EOF

Public-Key erzeugen

Zunächst muss der Public-Key erstellt werden

# Public Key erstellen
# Fragen nach dem Speicherort mit <ENTER> quittieren
tincd -n kbubackbone -K
… und verteilen

Den erstellten Public-Key musst Du nun bekannt machen. Da die keys in einem git-Repository verwaltet werden, verwende ich dazu einen Patch.

Die ganze Dinge musst Du natürlich anpassen - Du bist ja nicht Frank Nord.

(https://github.com/franknord/node-scripts/blob/master/supernode/06c_tinc.sh ).

# Patch erstellen
# Git konfigurieren - Anpassen (!)
git config --global user.name "Frank Nord"
git config --global user.email "frank.nord@mailbox.org"

cd /etc/tinc/kbubackbone/hosts/
git add mein_neuer_supernode
git commit -a -m "Added mein_neuer_supernode"
git format-patch HEAD~..HEAD -o /tmp/
cat /tmp/0001-Added-mein_neuer_supernode.patch
# /tmp/0001-Added-mein_neuer_supernode.patch

Die erstellte Datei /tmp/0001-Added-mein_neuer_supernode.patch kannst Du an Deine Peering-Partner senden. Falls Dein Supernode fester Bestandteil des Netzes werden soll, stelle einen Pullrequest.

Routing Konfiguration für Tinc erstellen

Beim Start bzw. Stop von tinc müssen passenden Routes eingetragen werden. Der IP-Range muss wieder angepasst werden. Die anderen IP-Ranges 172.26.0.0/15 und 10.158.0.0/15 richten sich dabei nach dem KBU-Netz (https://github.com/franknord/node-scripts/blob/master/supernode/06d_tinc.sh ).

cat > /etc/tinc/kbubackbone/tinc-up <<EOF
#!/bin/sh
ifconfig 172.27.8.1 netmask 255.255.255.255 \$INTERFACE up
ip route add 172.26.0.0/15 dev \$INTERFACE table 66 
ip route add 10.158.0.0/15 dev \$INTERFACE table 66 
ip route add 172.26.0.0/15 dev \$INTERFACE 
ip route add 10.158.0.0/15 dev \$INTERFACE 
ip route add default dev \$INTERFACE table 66 
ip route add 172.27.8.0/25 dev br-freifunk table 66 
EOF

chmod 755 /etc/tinc/kbubackbone/tinc-up

In UCI registrieren

Nun trage ich die Tinc-Instanz noch in UCI ein, damit sie automatisch gestartet wird (https://github.com/franknord/node-scripts/blob/master/supernode/06e_tinc.sh ).

uci -q batch <<EOF
    set tinc.kbubackbone='tinc-net'
    set tinc.kbubackbone.enabled='1'
    set tinc.kbubackbone.Name='mein_neuer_supernode' # Anpassen!
    commit tinc

    set network.kbubackbone='interface'
    set network.kbubackbone.proto='none'
    commit network
EOF
/etc/init.d/network restart
/etc/init.d/tinc restart

Fazit

Der Supernode ist nun konfiguriert. Zu vielen Dingen hab’ ich nur wenig gesagt. Frag auf der Mailinglist, falls Dir Dinge unklar sind. Auch bei DNS hab’ gespart: Ein eigener resolver wäre besser als ein Verweis auf 172.27.255.3 (Paul).

Das Ausführen der Shell-Befehle ist sicher mühselig. Anderseits hast Du genau gesehen, was einen Supernode ausmacht und welche Dinge konfiguriert werden müssen. Bau einen Supernode und spiel damit. Dann werden viele Dinge klar.

Technisch richtet sich der Artikel nach dem Status Quo. Zum Beispiel wird Tinc als Backbone-VPN verwendet und es werden keine neuen Dinge eingeführt. Es wäre cool, tinc durch babel und fastd zu erstzen. Das wird Bestandteil von Teil 3 - also eins nach dem anderen.

Im nächsten Blog-Post Nicht als Server gedacht - Teil 2 geht es erst einmal um kaputte Dinge und Konsequenzen.

Und IPv6?

Zu IPv6 kann ich leider keine Schritt-für-Schritt Anleitung schreiben.

  • Es gibt kaum IPv6-Tunnel anbieter, die benutzbare VPN-Tunnel anbieten. Die Konfigration unterscheidet sich bei allen.
  • OpenVPN hat noch keine push redirect-gateway-Option für IPv6.
  • Viele Fragen bei der IPv6-Adressvergabe sind für mich offen:
    • Welche Konsequenzen hat der fehlende IPv6 Gateway-Mode in batman-adv?
    • Wie sollen Public IPv6-Netze vergeben werden? Wie findet die Zurordnung zwischen Supernode mit passendem Tunnel und Client statt?
    • Sollen ULA IPv6-Adressen vergeben werden? Wie kommen Anwendungen mit nat66 - insb. bei Roaming - zurecht?
    • In welchen Netzen (ad-hoc, Infrastuktur, VPN-Strecken) werden Adressen wie verteilt? Stateless / Stateful Autoconfiguration? Prefix Delegation?

Damit ist IPv6 leider noch kein Thema für ein Supernode-Tutorial - aber spannendes Feld für Experimente. 😎

‘N Tach auch,

große Veränderungen kündigen sich an. In kleinen Schritten.

Wie die kbu-H@cker am frühen Donnerstagmorgen verkündeten, haben sie in der vorhergehenden Nacht ein revolutionäres, fehlerfreies und neues Release der Firmware erstellt. Der Versionstag ist “v1.4”.

Gleichzeitig bringt die neue Firmware die Unterteilung des KBU Netzes in mehrere Segmente (Hood Köln, Bonn und Umland/Umgebung). Dies ist notwendig, da die aktuelle Struktur des Netzes den Zuwachs an neuen Nodes nicht mehr lange hätte verkraften können. Durch die Aufteilung gewinnen wir neue Kapazitäten und können den freifunk-Gedanken ohne 'Bauchschmerzen’ weiter verbreiten. (/Missionarsmodus off) ;-)

Zitat: “Der Release basiert auf den branch v2015.1.x von github.com/freifunk-gluon/gluon und unserer Site Konfiguration.

Nur bei der Version 'classicupgrad#’ wird ein OpenWRT Upgrade Skript verändert.

Bei dieser Version ist MDNS Multicast blockiert. Bei fast allen derzeitig genutzten Firmwares ist MDNS ins Mesh erlaubt und announcen teils sogar Dienste. Dies führt derzeit zu starken Überlasterscheinungen bei gleichzeitigem (temporären) Supernodemangel.

Daher bitten wir alle zu updaten und dabei die entsprechende Hood zu wählen (bedenkt beim updaten und Hoodwechsel, dass unterschiedliche Hoods nicht miteinander meshen).

Wenn ihr auf Kölner Stadtgebiet seid: Hood Köln Wenn ihr auf Bonner Stadtgebiet seid: Hood Bonn Alle anderen nehmen: Hood Umland/Umgebung”

Die Firmware für Router, die bereits auf gluon aktualisiert wurden, findet Ihr HIER, wer bisher noch die classic-Firmware auf seinem Router fährt und die Gelegenheit nutzen möchte, auf die aktuelle Firmware zu wechseln kann diese Version ebenfalls nutzen.

Nutzer der Classic-Firmware, die Ihre Einstellungen unbedingt übernehmen möchten, werden HIER fündig.

Bei konkreteren Fragen zum Release oder Unklarheiten, schaut bitte im Wiki nach Lösungen oder wendet Euch an die Mailingliste.

Mir bleibt nur noch, den fleißigen Codern zu danken, dass sie sich trotz Erholungsphase nach dem C32C3 die aktuellen Engpässe so zügig angehen und Lösungen bieten.

Ciao, MoNeo

kevin, 3 January 2016

32c3 Review

Hey,

leider ist nun der #32c3 vorbei und wir haben soweit nun alle denn Input verarbeitet. So dass wir das ganze mal in einem Blogeintrag niederschreiben können. Wir haben uns der Freifunk Assembly angeschlossen und so sehr viele Kontakte zu den anderen Communities herstellen können. Für alle von uns die vor Ort waren, waren es spannende Tage mit sehr viel “Input”. Wie einige von euch auf der Mailingliste mitbekommen haben, gab es diesmal eine Support Hotline die sehr rege für so einige $dinge genutzt wurde! 24/4 besetzung hat nicht geklappt, teils menschlich, teils technisch :-D Auch haben wir erstmals unser Blech Omni in die Congress Colo gesteckt, der dann zu einem Supernode für das KBU Netz inkl. grösstem Tor Exit beim Congress (Tor Fingerprint schon Monate vorher gespawned :) umfunktioniert. Wofür hat der Congress sonst so eine tolle Bandbreite?

Eines der tollsten Dinge, waren die Abstecher in die Lounge…… Um es zu verstehen seid beim 33c3 dabei, wenn man die Lounge ueberhaupt denn findet! :-P

Es gab auch sehr viele spannende Talks die ihr alle unter https://media.ccc.de/b/congress/2015 schauen könnt. Wir haben es selbst nicht in viele Talks geschafft da, das Leben an der Freifunk Assebly um einiges spannender war. CHAOS CHAOS CHAOS :-D

Ich haben nun eine kleine Einführung in BGP und IPTABLES erhalten, die mir nun endlich die Anbindung an den Freifunk Rheinland AS ermöglicht hat. Sobald wir auch endlich GRE Tunnel für die restlichen Supernodes bekommen, können wir diese auch umstellen. Wie jedes Jahr ging wieder eine Seuche herum, die uns allen Energie geklaut hat. Ich hoffe dass, wir in Zukunft noch einige innovative dinge hier tun können und Spass an der Technik haben werden. Ich denke das sollte für uns alle das Wichtigste sein! Wir haben mittlerweile über 500 Nodes im Netz und es wird nicht weniger werden. Auch müssen wir mehr Menschen für die Technik begeistern, die auch offen sind, nicht gewohnte Tools zu erlernen, damit sie aktiv am Projekt mitwirken können und ihre Ideen einfließen lassen!

Gruß Kevin

gevatter, 14 August 2015

We are working on it

Ein Teil der Freifunker von KBU verweilen gerade auf dem Chaos Communication Camp. Die Zeit auf dem Camp bedeutet Urlaub, aber auch, sich Zeit nehmen zu können um an Dingen zu schrauben. Wir arbeiten an der Karte, ander Firmware und mal gucken, was uns sonst auch noch einfällt.

Heißt aber auch, das es mal passieren kann, dass Dinge nicht funktionieren, auch mal mehrere Stunden lang. Hat aber auch keiner versprochen, dass irgendwelche Dienste vorhanden sind ;)

Bis Anfang nächster Woche ist noch mit diesem Zustand zu rechnen. Bitte haltet euch daher mit Mails zurück, die 20. Mail zu einem hängenden Service ist auf der Mailingliste nicht hilfreich.

Wenn ihr mit uns quatschen wollt, lasst euch doch mal im IRC-Channel #ff-kbu auf irc.paranode.net oder per Webclient blicken.

gruß
gevatter

yanosz, 21 April 2015

Building OpenWRT

What is this about?

Freifunk Firmware is distributed via firmware image files - usually. It’s plug and play for the user: Fire up a browser, open your router’s WebUI, upload a it and you’re done. But how to create theses images? Is there room for tinkering? Usually, every Freifunk-Firmware uses OpenWRT / Linux. Thats the big common ground for all networks out there.

OpenWRT is a specialized Linux distribution focusing on wifi routers - but out-of-the stock releases builds cannot be used, ‘cause every community must ship their network configuration. This blog post explains how to create custom firmware images. It provides a detailed view on http://wiki.openwrt.org/doc/howto/obtain.firmware while having Freifunk in mind.

Make It - The Buildroot

OpenWRT features a build system (aka Buildroot - http://wiki.openwrt.org/doc/howto/build). It is used to build OpenWRT from source, completely. I use it like this:

$ git clone git://git.openwrt.org/openwrt.git
$ cd openwrt
$ scripts/feeds update -a && scripts/feeds install -a
$ make menuconfig  # Select all options you need
$ make clean install

Afterwards, firmware images will be in ./bin/ - Keep calm and carry one:

  • If it fails, try again using make V=99.
  • To speed up, use more cores: make -j 8.There’ll be dragons.

Note that all selected packages will be installed in each firmware image file: If you select USB-drivers, they will be available on models without USB. If you skip 'em, they’ll be missing on models having USB.

Alternatives

Using the Buildroot is annoying. You have to wait a looooong time for the build to finish. Each and every dependency is downloaded, checked, extracted, built and installed. If one thing screws up, the build breaks. But there’s more. If you try to install OpenWRT’s packages on machines running your build, you may run into trouble.

root@OpenWRT:~# opkg install kmod-usb-storage
Installing kmod-usb-storage (3.10.49-1) to root...
Downloading http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base/kmod-usb-storage_3.10.49-1_ar71xx.ipk.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-usb-storage:
 *      kernel (= 3.10.49-1-0114c71ed85677c9c1e4911437af4743)
 * opkg_install_cmd: Cannot install package kmod-usb-storage.
root@OpenWRT:~# opkg list-installed kernel
kernel - 3.10.49-1-a785eb58641150b9f09fe8279e1cde49

In OpenWRT all kernel features are encoded in the kernel’s version number. If you change anything, it breaks. You cannot use other build’s kernel packages.

Luckily, there are other options:

Both are created when compiling the Buildroot. Furthermore, they’re included in all official releases of OpenWRT. By using 'em, you’re able to create images based on released kernel configurations. The version-number-issue disappears.

The OpenWRT SDK

The SDK is used for building packages - in contrast to complete firmware files. Starting with OpenWRT 14.07 (Barrier Breaker) it is possible to build kernel packages, too. Platform-dependent, binary versions are provided by OpenWRT for their stock releases.

Let’s compile a pre-release of olsr v2 (tag: v0.7.1) to be used on a TP-Link WR841n:

$ wget https://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2
$ tar xjf OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2
$ cd OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2
$ git clone git://olsr.org/oonf.git -b v0.7.1 package/oonf
$ make world

Looking into ./ar71xx/packages/base, there’s a complete opkg-feed. Just copy it to a web server, put it in your router’s /etc/opkg.conf and use it.

Image Builder

The Image Builder is for creating firmware images to be uploaded on routers. Sometimes it’s called Image Generator. It’s for post-processing a Buildroot-output - such as an OpenWRT stock release. You can select packages and files to be included. Creating a minimal image including the previous olsr v2 build for a TP-Link WR841n works like this:

$ wget https://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/OpenWrt-ImageBuilder-ar71xx_generic-for-linux-x86_64.tar.bz2
$ tar xjf OpenWrt-ImageBuilder-ar71xx_generic-for-linux-x86_64.tar.bz2
$ cd OpenWrt-ImageBuilder-ar71xx_generic-for-linux-x86_64
$ #### Append to repositories.conf: src/gz my_packages https://your.web.server/uploaded/sdk_output/
$  make image PROFILE=TLWR841 PACKAGES="olsrv2"

Result is: ./bin/ar71xx/openwrt-ar71xx-generic-tl-wr841n*. Keep in mind that make profile gives a list of all available profiles for the sdk’s platform. There are generic ones, too.

Summary

OpenWRT’s build system appears redundant. Both SDK and Image Builder do serve their purpose and have justified use cases. For generating Freifunk-Firmware, SDK + Imagebuilder seem to be a reasonable choice: Software packages released by OpenWRT can be used and post-processing allows including USB-drivers only for models having USB. Building a non-released version of OpenWRT (trunk, stable branch) seems to be one of the few cases, where you actually need the Buildroot.

Feature Buildroot SDK Image Builder
Purpose Do everything Build packages Create firmware files
Turnaround time Slow Fast Fast
Build stability Unstable Stable Stable
Space needed for building - Freifunk scenario 9647 MB 398 MB 402 MB
Use unreleased (patched) versions of OpenWRT’s core packages
Build 3rd party software
Build 3rd party kernel modules for OpenWRT stock releases
Create opkg-feed directories
Create firmware image files (.bin / .trx)
Post-process builds according to target devices (ie add USB-drivers)
Re-pack (KBU-)firmware releases for other communities

One of the next posts will be on doing release builds for KBU - but this is a different story. In the meantime: try to build your community’s firmware by yourself.

That’s it - Happy Hacking.

Piek2tei, 3 April 2015

A new blog

Propaganda incoming…

We’re starting a blog. From time to time, we’re going to deal with different issues all around Freifunk and the KBU-community. Posts are going to appear infrequently.

  • This blog is jekyll based. If you’re interested in blogging, file a pull-request for https://github.com/ff-kbu/website
  • It’s not translated by default. Posts will in English (mostly) or German. Hardly anybody will take care of translating ‘em all.
  • It’s opinionated and does not reflect a consensus within our community.

Due to technical limitations of jekyll, there will be no comments. Join the maillist if you’re up for discussing things and thinkings.

Cheers, Piek2tei