kls0e grüess Dich.

OLSR meshing on 5 Ghz outdoor channels using AP-STA under OpenWrt/Falter

So you have your precious outdoor freifunk hardware set up and would like to establish a mesh connection using the 5 ghz outdoor channels with higher tx power allowed and you run into the issue that there is no DFS support for neither 802.11s nor IBSS. What a bummer! As a workaround, we can use AP-STA mode (classic master and client wifi) and establish an OLSR on top of that. Here are some config snippets to help getting it running. YMMV! First, decide which device is your master (Access Point, AP). It should be positioned so that surrounding devices can see it and connect to it as clients (Stations, STA).


AP radio configuration - /etc/config/wireless
config wifi-device 'radio0' #varies, your 5ghz might be radio1
option type 'mac80211'
option channel '136'
option path 'pci0000:00/0000:00:00.0' #varies a lot
option hwmode '11a' #some put '11acn' here but in reality htmode sets n/ac
option diversity '1'
option country 'DE'
option doth '1' #important for DFS
option htmode 'HT20' #very very narrow

The important bits here are doth (802.11h) which enables frequency hopping once a DFS event occurs, obviously channel, and htmode. I chose very conservative settings here a bandwidth of only HT20. I have had trouble setting up any VHT40 and up, it would not initialize properly but I have only spent limited time trying out the combinations. Please try what works best for you.


AP wifi configuration - /etc/config/wireless
option ifname 'wlan0-apmesh'
option network 'olsrmesh'
option encryption 'none'
option device 'radio0'
option mode 'ap'
option ssid 'olsrmesh'
option hidden '1' 

So this is basic OpenWrt configuration for creating an open AP, option hidden ‘1' hides its SSID to not confuse people trying to connect. Remember, we only use this AP-STA connection for OLSR meshing between our local nodes.

Now get some IPs (IPv4) from Freifunk Berlin in advanced mode. A /29 or /28 should be fine, depending on how many local nodes you want to be AP-STA-OLSR-meshing (besides none, of course ;)).


AP wifi network configuration - /etc/config/network
config interface 'olsrmesh'
option proto 'static'
option ifname ''
option netmask '' # subnet mask of I got 
option ipaddr '' # the first usable ip from it I have found out with [ipcalc](http://jodies.de/ipcalc)
option ip6assign '64' 

The following is for STA clients. Please also set the same settings for wifi hardware as on AP in step 1.

STA CLIENT wifi configuration - /etc/config/wireless
config wifi-iface
option ifname 'wlan0-stamesh'
option network 'olsrmesh'
option encryption 'none'
option device 'radio0'
option mode 'sta'
option ssid 'olsrmesh'


STA CLIENT wifi network configuration - /etc/config/network
config interface 'olsrmesh'
option proto 'static'
option ifname ''
option netmask '' # subnet mask of my
option ipaddr '' # second usable ip from my /28
option ip6assign '64' 

Rinse and repeat on all clients, increment usable ip.

Very important: To get OLSR to work, follow the Mesh via LAN tutorial starting from ssh config STEP 10 and replace all fflan with olsrmesh. Also leave out option Mode ‘ether' in STEP 14 since this is not an ethernet connection.
It is also possible to run AP/STA simultaneously on a node to extend this dfs-semi-mesh, but the BI (Beacon Interval) of the AP/STA on the node must match.
In summary, while this way of building a half-baked local mesh network sort of works, it would be appreciated if DFS was implemented for 802.11s.

upgrade wifi on hp 17-bs notebook

The HP 17-BS XXXXX series is a widespread budget notebook line, it is somewhat affordable and has mediocre specs one can work with for every-day tasks, whatever that means.

Its build quality is on the lower edge with lotsa relatively thin plastic involved, but here is a video on how to carefully open the device without breaking it. Thanks, Christian. Cool dialect btw :)

Turns out it is relatively easy to swap the wifi card. This notebook sports only 1 antenna. The stock RTL8723BE performs absurdly poor with its 1x1 2.4 ghz stream. Better buy an RTL8821CE 802.11AC 1X1 Wi-Fi + BT 4.2 Combo on ebay or anywhere else for 6€, it is compatible and it is not block-listed efi-wise and delivers beyond stellar in comparison, given there is an 802.11ac access point around.

add AirPrint to a Brother MFC-7360N

With all the recent corona changes, we are in need of a home printer. Of course, b/w laser is the way to go, cheap inkjet printers are a scam and tend to break right after the warranty period. So I decided to buy a 4-in-1 Brother MFP, the MFC-7360N. It can print, scan, copy and fax and I got it from eBay kleinanzeigen for 20.- € with an empty toner cartridge.

I am really happy with this machine and can recommend it to anyone, 3rd party toners are very affordable (around 12.- €) and last for thousands of pages.

I also like to print scanned developed analog b/w photos with it as they look like photocopies, but that is a matter of taste I guess.

So the machine works well and performs great, and there is an iOS app for it which allows you to scan to your phone. You can also print with this app but I was looking for AirPrint support to integrate directly with iOS devices on the same network. The printer does not feature this relatively new protocol but if you have a linux machine on the network, maybe a raspberry pi, install CUPS properly and use the brlaser v4 ppd with it by Peter De Wachter, thanks! Presto, there’s your AirPrint, works like a charm.

Another reason I recommend Brother is that there is an undocumented “toner empty”-reset command which will just let you print along until the toner is physically used up:

1. Schalten Sie Ihr Brother MFC Gerät an
2. Öffnen Sie die Frontklappe -lassen Sie den Toner im Drucker
3. Drücken Sie die Taste STORNO 1x -nur einmal
4. Es erscheint die Anzeige "Trommel ersetzen?" 1. JA 2. NEIN -hier nichts auswählen, weiter mit
5. Drücken Sie die STERN-Taste *
6. Drücken Sie die Taste 0 zweimal nacheinander
7. Schließen Sie die Frontklappe
8. fertig

found in a german video review by VideoP, thanks.

So it turns out that the toner cartridge I got with the printer is far from empty and the Brother continues to print just fine :)

Dynamically adjusting bandwidth limits

Full quote by Perry:

“I got a request from a refugee center to set up qos so that in the evenings and on weekends the bandwidth-limit gets raised from 35Mbit to 45Mbit, and back down to 35Mbit Mon-Fri 7:00 to 20:00. To do this, I did the following. It’s a hack, which could be improved (like storing up slow speed and fast speed in a config file somewhere).

So this is what I did…. I wrote the following script (/root/qos-schedule.sh)


. /lib/functions.sh



#check to see if it's the weekend
if [[ $(date +%u) -gt 5 ]]; then
  # check to see if it's not between 7:00 and 20:00
  if [[ $(date +%H) -lt 7 ]] || [[ $(date +%H) -ge 20 ]]; then

#compare the speed to the current settings.
OLDSPEED=$(uci get qos.ffuplink.download)
if [[ $OLDSPEED -ne $SPEED ]]; then
  logger -t qos-schedule.sh "setting time-based qos to $SPEED"
  uci set qos.ffuplink.download=$SPEED
  uci commit qos
  /etc/init.d/qos reload

I added it to crontab to run every hour

Additionally I added the script to /etc/rc.local (so that the correct speed is set at startup)

Additionally I created a hotplug script /etc/hotplug.d/ntp/50-qos-schedule


#logger -t hotplug-ntp-qos-schedule "Action is $ACTION, stratum is $stratum"
[ "$ACTION" = stratum ] || exit 0

logger -t hotplug-ntp-qos-schedule "Running qos-schedule from ntp hotplug event"

Lastly, I added /root/qos-schedule.sh and /etc/hotplug.d/ntp/50-qos-schedule to /etc/sysupgrade.conf

kls0e Would you like to add that to your list of super cool tutorials?”


iPerf on Fritzbox stock firmware

iPerf is a great cli tool to measure raw network throughput between two devices. I often use it with OpenWrt and while talking about AVMs Fritzbox routers during a Freifunk Berlin meeting, Nicolas mentioned that there is a little-known support interface with their stock firmware at https://fritz.box/support.lua that offers starting an iPerf server – look for Durchsatzmessungen. Very handy.
Note that on client side, parameter -p 4711 is required for the non-standard port.

How to host a (small) website on your Freifunk node

Due to the versatility of OpenWrt, being a fully equipped Linux distribution itself, there are all tools already installed on your Freifunk node that are required turn it into a small web server. In fact its web gui LuCI is a website served by the node already. I suggest starting with static html+css and I can recommend Hugo as a Framework to generate it. So let’s use the existing infrastructure to host our own website:

selecting the best storage option for your webroot

  1. First think about where you would like to store your web files aka your webroot. This can be anywhere accessible by your nodes’ file system. Essentially, we have three options: ramdisk, external usb storage and router flash memory.
    Check out your options and the free available space with its corresponding mount points with df -h.

  2. I decided to use the routers’ ramdisk, already available at /tmp using tmpfs. If you have a device with at least 128 MB of RAM and your website is not too large, I think this is a good way to go since ram is blazing fast and tmpfs size is configured as 50% spare by default, i.e. it grows with the content it holds, up to a size of 64 MB. Rest of RAM is available to the system.
    As we know, RAM gets zapped on every boot so I set up a small script to run with /etc/rc.local. The script pulls a tarball using wget every time the router boots and extracts it to /tmp/wwwroot which is the path to my webroot.
    Of course you can also mount external usb storage and use it as a webroot, it will be slower than tmpfs but persistent. Although technically possible, I would not use the routers’ own flash chips to store a webroot if the device has NOR flash because there might be no error correction and the blocks wear out after a certain amount of write cycles.
    If your device sports a NAND flash chip, such as the Fritzbox 3370 or the GL.iNet AR-300-M, using NAND as webroot is fine.

configuring the webserver

  1. Let’s use uhttpd, which already serves LuCI on your freifunk node, as the webserver. It actually performs very well. Edit the config at /etc/config/uhttpd:

Just copy the config uhttpd ‘main' block, insert it at the end of the file and rename the new section. also adjust the path at home to your webroot, raise max_requests and max_connections a bit and, if you want to leave LuCI enabled, choose some other ports for the listen_http and listen_https entries.
Here’s my sample config:

config uhttpd 'kls0e'                      
        list listen_http ''   
        list listen_http '[::]:10178'      
        list listen_https ''  
        list listen_https '[::]:10785'     
        option home '/tmp/wwwroot'
        option max_requests '48'                
        option max_connections '400'            
        option cert '/etc/uhttpd.crt'           
        option key '/etc/uhttpd.key'            
        option cgi_prefix '/cgi-bin'            
        list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua'
        option script_timeout '60'                                      
        option network_timeout '30'                                     
        option http_keepalive '20'                                      
        option tcp_keepalive '1'                                        
        option ubus_prefix '/ubus'                                      
        option rfc1918_filter '0'                                       
        option redirect_https '0'

As you can see, this website is served at port 10178. Maybe you can guess from looking at the config that I am planning to get proper SSL running as well, so the website is reachable using https:// without certificate warnings, as every website should be, to avoid plain-text MitM manipulation.
There is a tutorial on how to do that: LE-HTTPS on OpenWRT with uhttpd by stokito
If you have an idea on how to fully automate the Let’s Encrypt certbot renewal process directly on an OpenWrt device, please let me know.

manually downgrading mesh links using olsr Link Quality Multipliers (LinkQM)

Let’s say you have a node that sees two other nodes in the mesh with a fairly good connection but you want to shape the traffic flow because there are reasons to do so. To achieve this, we can apply link quality multipliers to certain routes. The router will multiply the routes’ priority by this factor and thus downgrade it if we choose a number lower than 1, e.g. 0.5.

  1. Find out which ip your mesh interface and the other nodes’ mesh interface has:
    The left column consists of mesh interface ips of the router you are logged into, the right column consists of remote mesh interface ips. If you are lucky, a third column to the right will appear, showing the remote olsr hostnames.
    Note your mesh ip and the remote mesh ip.

  2. You need to know your local mesh interface name you want to apply the LinkQM rule to. In the following command, insert your mesh ip (left column from step 0) that sees the other node you want to downgrade the link to:
    ip a | grep <your mesh ip from neigh.sh>

The last phrase of the output is the local interface mesh name, common results include wlan0-mesh-2, wlan1-adhoc-5, fflan, … - depending on your setup.
Important: If it is a wireless mesh interface, we need to know the network name assigned to it. You can find this information in /etc/config/wireless. Everything that starts with wlan0- is most probably wireless0, everything that starts with wlan1- is most probably wireless1.

  1. With this information, we can edit the olsr config at /etc/config/olsrd. We need to scroll down to the appropriate interface section with the local mesh interface network name we have found out in step 1.
    We can now add a new option for it:

option LinkQualityMult ‘<remote mesh ip> <multiplier>'

So as an example, my result for step 1 was fflan, because the link I want to downgrade is reachable through a lan mesh interface. The remote mesh ip from step 0 in my example is and I would like to downgrade the link by factor 2, so my multiplier is 0.5. So I am scrolling down to where the olsr config says option interface ‘fflan' and I add the corresponding LinkQM option like so:

config Interface                                 
        option ignore '0'                    
        option interface 'fflan'             
        option Mode 'ether'        
        option LinkQualityMult ' 0.5'

Keep in mind, for wireless mesh interfaces, you need to look for wireless0 or wireless1 instead of fflan. To apply the changes, restart olsrd by issuing /etc/init.d/olsrd restart. Wait some minutes before testing the new routing until the router reworks its routing priorities.

Freifunk Berlin can be complicated sometimes but you can learn a lot.

Measuring network throughput between two nodes with iPerf

In mesh networks, throughput between nodes that are supposed to talk to each other is the key performance factor. There is a handy tool called iPerf already pre-installed with our Freifunk images that can measure the actual bandwidth between two nodes. It is client-server based, so to benchmark, run
iperf -s on one of the nodes, this will start an iperf server listening to connections, and on the second node, run
iperf -c <server> -d -t 15 -i 1 -P 2, this will connect the iperf client to the server and will run a heavy raw network throughput benchmark for 15 seconds. It is always good to play around with the options a bit to get the idea and maybe fine-tune the command.
If you are about to reposition an antenna and would like to check out a continuous iperf feed while doing so, I suggest using
iperf -c <server> -d -t 360 -i 1, this will be a bit easier to lift for the tcp stack of the device.

By the way, there is iPerf3, which has been around for a couple of years now, and I hope we will include it in our future Freifunk images, so have a look at this newer version, too.

How to run your own Freifunk Berlin service

Martin, a fellow Freifunker from Freifunk Fürstenwalde asked me to publish a tutorial on how to set up your own service in the Freifunk Berlin network. It is actually quite easy once you know how.

Note: Your service has to have an ip reachable from within Freifunk Berlin, you can configure a static ip for it from your Freifunk dhcp pool. If you use the first dhcp ip your Freifunk router would issue to a client, edit its /etc/config/dhcp and raise option start ‘2' to option start ‘3' in the lower dhcp config block. This reserves the ip for your static configured service host and avoids duplicate ip delegation via dhcp.

How to announce your service in the Freifunk Berlin network:

  1. log in to your router via ssh

  2. edit the olsr config of your router:
    vim /etc/config/olsrd

  3. scroll down to the section that starts with

config LoadPlugin
     option library 'olsrd_nameservice'
  1. press i to insert text

  2. add

list hosts '<freifunk-ip> <hostname without .olsr>'
list service 'http://<freifunk-IP:port>|tcp|<name of service>'

example: let’s say my service has and I would like the host to be known as kls0e.olsr, and let’s say there is a web server up at port 10178, and every router at Freifunk Berlin should show a link named kls0e to this server under Services on its web gui, then my nameservice plugin section would look like so:

config LoadPlugin
        option library 'olsrd_nameservice'
        option suffix '.olsr'
        option hosts_file '/tmp/hosts/olsr'
        option latlon_file '/var/run/latlon.js'
        option services_file '/var/etc/services.olsr'
        list hosts ' kls0e'
        list service '|tcp|kls0e'

udp protocol is also an option instead of tcp. Port info is mandatory, even if it is port 80.

Give it 5-15 minutes to propagate your service announcement across the network.

From my experience, sometimes not all nodes can resolve the hosts entry, so I have chosen to publish the service with its direct Freifunk ip instead of an OLSR host name. The latter would be cooler but form follows function, I am glad if it works for you tho, please try.
Update: Noki kindly mentioned that it makes sense to issue a static dhcp lease for the device hosting the service.

Freifunk Berlin mesh protocol snippets

We are moving from IBSS to 802.11s as the main mesh protocol used for our meshes in the Freifunk Berlin network.

I think the easiest way to adjust the mesh protocol of a freifunk router is to edit /etc/config/wireless and insert or replace the config blocks accordingly.

Please pay attention to the interface names of dual-band devices, the majority of routers call their 2.4 ghz module radio0 and their 5 ghz module radio1, but a Ubiquiti UAP Pro flying saucer frisbee for that matter keeps it vice versa.

If your router only has one radio (radio0), just use the radio0 snippet.

# 802.11s for 2.4 ghz                         
config wifi-iface                   
        option network 'wireless0' 
        option device 'radio0'     
        option ifname 'wlan0-mesh-2'
        option mode 'mesh'               
        option encryption 'none'             
        option mesh_fwding '0'               
        option mesh_id 'Mesh-Freifunk-Berlin'
        option mcast_rate '12000'

# 802.11s for 5 ghz                                   
config wifi-iface                             
        option network 'wireless1'            
        option device 'radio1'                
        option ifname 'wlan1-mesh-5'          
        option mode 'mesh'                    
        option encryption 'none'              
        option mesh_fwding '0'                
        option mesh_id 'Mesh-Freifunk-Berlin'
        option mcast_rate '12000'
# Ad-Hoc / IBSS  for 2.4 ghz         
config wifi-iface                            
       option ssid 'intern-ch13.freifunk.net'
       option ifname 'wlan0-adhoc-2'
       option network 'wireless0'
       option encryption 'none'
       option device 'radio0'          
       option bssid 'D2:CA:FF:EE:BA:BE'
       option mcast_rate '6000'
       option mode 'adhoc'

# Ad-Hoc / IBSS for 5 ghz         
config wifi-iface                           
       option bssid '02:36:CA:FF:EE:EE'     
       option ifname 'wlan1-adhoc-5'        
       option network 'wireless1'           
       option ssid 'intern-ch36.freifunk.net'
       option mcast_rate '12000'             
       option mode 'adhoc'                   
       option device 'radio1'

You can apply all changes made to /etc/config/wireless simply by issuing wifi. There is no need to reboot. If you want the new set mesh interfaces to be monitored with the stats monitor, edit /etc/config/luci_statistics and replace or adjust the interface names in the corresponding sections. To apply these changes, run /etc/init.d/luci_statistics restart.
Bonus: If you have made changes to /etc/config/network, just run service network reload to apply.