Freifunk Things not given on some other place

This is just here to write down a few things about Freifunk and FF communities which are not written down elsewhere.

VPN technology

Currently different VPN technologies exist:

(**): Gateway side can ignore authentication for the initial connection request, via"on verify 'true', however node->gateway handshake authentication with valid fastd keys in the site.conf is still required

(***): Initial connection request can be authenticated, however payload data is not authenticated afterwards.

Authentication: Node owners need to authenticate against the supernode to the community

Encryption: Traffic from Gluon nodes to the supernode/gateway is encrpyted [no -> faster, but insecure (Internet providers can read and alter mesh traffic.)]

Kernel forwarding: [yes -> faster]

Multithreading: Multithreading increases performance on multicore devices

Single Interface: The gateway has a single interface for all peers, instead of one virtual interface per connected node

Additional, notable compatibility features:

• fastd: multiple encrypted and unencrypted methods can be handled by one daemon
• fastd: a null@l2tp peer with offloading is fully compatible to a peer with null@l2tp without offloading
• fastd+Wireguard: a single secret can be used for both fastd and Wireguard via gluon-mesh-vpn-key, so no need for a node owner switching to (or from) Wireguard from (or to) fastd to submit a new key

taken from: https://md.chaotikum.org/zRkW6JXXQs-8WCnwdtig5w?view#

Supernode configuration repositories

There are multiple supernode configuration repositories. Yet there is no recent manual of setting up a supernode yourself.

One can see though, that there are two different tech-stacks in use: salt and ansible

salt is used by ffho-salt-public as well as ffmuc-salt-public

ansible is used by ffh/ansible, ffac/ff-supernode, ffnw/ansible and ffbsee-ansible.
There were two approaches to unify this in freifunk-ansible and in ff-supernode

Supernode customization

There is this talk from barbarossa (FFHO) who said that turning of the offloading settings using ethtool on the NIC helps to improve performance by a large amount like this:

for iface in eth0 eth1; do
    for feature in sg gro gso tso rxvlan txvlan; do
        ethtool --offload ${iface} ${feature} off
    done
done

Source: page 62 from https://www.slideshare.net/slideshow/software-defined-freifunk-backbones-78288014/78288014#62

I am not sure how relevant this is 7 years later.

Move away from large Layer 2

Large Layer2 networks are not much fun. To reduce the background talking of protocols, one has two different options:

1. create smaller segments to reduce the talking - this is generally said to work woll for clouds of up to 300 nodes
2. switch to a routed setup

Segmentation of L2 domain

• Segmentation was temporarily dynamically used in freifunk hannover through this script: https://github.com/freifunkh/ffh-packages/blob/master/gluon-segment-mover/files/lib/gluon/gluon-segment-mover/relocate.lua
• FFAC does have separate segments, all nodes iterate through all segments to test if they can enter the segment. An additional watchdog checks if two segments are connected in a way which should not happen and moves keys to the fitting segment to resolve this. Additionally, nodes can be moved to the correct segment based on their geolocations from time to time.
• Hoodselector - selects the domain based on the geolocation on the gluon node from rectangle information of zones
• Freifunk Stuttgart has a DNS based approach which decides on the supernode which IP is returned on DNS based on the node information
• FFMUC and others are using the multidomain feature and let the users choose which domain their router belongs to

Routed setups

• Use Babel instead of BATMAN
• Use Parker from Freifunk Braunschweig: https://stratum0.org/blog/posts/2020/01/12/freifunk-parker/
• FFMUC has a similar idea: https://github.com/freifunkMUC/site-ffm/issues/87

Freifunk Learning materials and lectures

There is interesting workshop material available here about routing and BGP/OSPF:

https://blog.sdn.clinic/2017/09/ffrl-routingdays-learn-to-build-the-internet/

And a workshop for the usage of BATMAN:

https://github.com/freifunk-darmstadt/workshops/blob/master/2018-10-11-ophase.md

Such examples could also be used in academica to teach network usage.

EVPN Proxmox test: https://wiki.freifunk-stuttgart.net/technik:proxmox:evpn-test

Additional tools

• Various scripts from Freifunk Stuttgart to monitor the network health: https://github.com/FFS-Roland/FFS-Tools
• NodeAlarm to notify if a node goes offline: https://github.com/Philhil/FfsNodeAlarm
• Gluon Census: https://stats.darmstadt.freifunk.net/d/CA5PRFmMz/gluon-census-dashboard?orgId=1&refresh=1m&var-community=Aachen
• Freifunk-Karte: https://www.freifunk-karte.de/
• Multi-Meshviewer: https://multi.meshviewer.org/s

Closing and Freifunk Hymne

There are many things which happen to not be related to a current use case but you still want to keep track of the few links one has to a topic or an interesting collection of information to a specific topic which is just not that relevant now. It still makes sense to write it down in a blog post to go through at a later time.

https://blog.sdn.clinic/2019/04/testinglos-durch-die-nacht/