Nicolas314

All my geeky stuff ends up here. Mostly Unix-related

Posts Tagged ‘openwrt

OpenWRT on EdgeRouter Lite

leave a comment »

erlite-3-900x500Installing OpenWRT on EdgeRouter Lite

This installation procedure does not require any extra hardware beyond a Phillips screwdriver to open the router box. I believe it is completely reversible and (hopefully) does not void your warranty.

Objective: replace EdgeOS on your EdgeRouter Lite by a recent version of
OpenWRT picked from the LEDE project.

You need:

  • A powerful Linux box, preferrably a multi-proc 64-bit machine with tons of RAM. This will only be used just once to compile OpenWRT.
  • An extra USB thumb drive. Its dimensions should be short: less than a few centimeters, otherwise it won’t fit inside the box.

Ok now off to build an OpenWRT image:

. Log onto your Linux box

. Download the latest sources from LEDE project:

 git clone https://github.com/lede-project/source
 cd source

. Prepare the tree for compilation for ERLITE:
You will have to select a number of options to build an image tailored to
the EdgeRouter Lite. I could put here a ready-made config file but as these
things tend to evolve quickly, it would probably be obsolete in a matter of
days. So bear with me: start the configuration with

make menuconfig

. Target System: Cavium Networks Octeon
. Target Profile: Ubiquiti EdgeRouter Lite

. Target Images: make sure ‘ext4’ is selected, then Select that line to
open up a menu for ext4 configuration. Change the number of inodes to
60,000 instead of the default 6,000. Also select GZip images, and finally modify the root filesystem partition size to something more comfortable,
say 500 MB. This space will be taken off your USB stick so if you have
more space you can increase that to whatever you have. With 500 MB you
should have enough space to put all the packages you need.
. Global build settings: select Select all kernel module packages by
default.

Beyond that take your pick for packages you want included by default in
your image. My selection is:

  • Base system: base-files, block-mount, busybox, ca-bundle, ca-certificates, dnsmasq, dropbear, firewall, fstools, jsonfilter, lede-keyring, libc, libgcc,
    libpthread, librt, libstdcpp, mtd, netifd, opkg, procd, rpcd, sqm-scripts, sqm-scripts-extra, swconfig, ubox, ubus, ubusd, uci, usign
  • Administration: sudo
  • Development: ar, binutils, gcc, gdb, make, objdump
  • Kernel modules: everything should already be selected as module. You want
    to change some of these to be compiled into the kernel otherwise it will
    fail to find the ext4 root on USB:

    • Filesystems: select kmod-fs-ext4, kmod-fs-msdos
    • USB Support: kmod-usb-core, kmod-usb-storage, kmod-usb-storage-extras
  • Languages: select whatever programming languages you want to see in a
    default install. I usually make sure at least Lua and Python are selected.
  • LuCI: make sure LuCI is selected. Take your pick for applications you
    want to install. I usually select luci-app-openvpn, luci-app-commands,
    luci-app-firewall.
  • Network: if you want your router to act as an OpenVPN client or server,
    make sure it is selected under VPN. Pick either openvpn-openssl or openssl-polarssl.
  • Utilities: bash, bc, file, grep, gzip, less, lsof, openssl-util, strace, tar, tmux, usbutils

Feel free to select more packages but each additional one will take extra
compilation time.

. Type ‘make’ and let the magic go on.
. When finished, the result is stored as:

bin/targets/octeon/generic/lede-octen-erlite-ext4-sysupgrade.tar

This file contains everything we need to build a bootable USB drive for
the EdgeRouter Lite. This file should be 500 MB large since you
selected that size above for your root filesystem, but it is mostly made
of zeroes so if you use bzip2 you should be able to reduce its size to a
more manageable 50-60 MB, which is more convenient if you need to toss it
around the network.

. Put the sysupgrade.tar file onto a local Linux machine and extract it:

tar xvf lede-octen-erlite-ext4-sysupgrade.tar

. The directory contents are:

sysupgrade-erlite/
sysupgrade-erlite/kernel
sysupgrade-erlite/root
sysupgrade-erlite/CONTROL

. Now insert your USB thumb drive into a local Linux machine and prepare
the filesystem. We need a first (small) FAT32 partition to hold the kernel,
a second 500 MB partition to hold the root:

fdisk /dev/sdX # Where X is the letter assigned to your USB drive
New partition: 1, 32 MB in size, type c (WIN95 FAT32 LBA)
New partition: 2, 500 MB in size, type Linux (default)
Optional: New partition: 3, the rest of your drive, type Linux (default)
Make the first partition bootable (a).
Type 'w' to save your changes.

Create the FAT32 filesystem with:
mkfs.vfat /dev/sdX1

. The default uboot configuration on the EdgeRouter Lite wants a file
called ‘vmlinux.64’ in the first (DOS) partition, so let’s do just that:

mount /dev/sdX1 /mnt # Mount the DOS partition
cp sysupgrade-erlite/kernel /mnt/vmlinux.64
umount /mnt

. Dump the root filesystem contents onto the second partition:

dd if=sysupgrade-lite/root of=/dev/sdX2 bs=1M

. If you have a third partition, create a new filesystem on it with:

mkfs.ext4 /dev/sdX3

. You are done with the USB drive!
. Open the EdgeRouter Lite. There are three small screws to remove on the
back. The box slides open if you push gently.

. Remove the existing USB stick inserted in the reader on the motherboard.
Be gentle: you need to insist a bit to take it off but it is not stuck.

. Insert the USB drive you prepared. Close the box, put the screws back,
and boot the router.

. If you connect a PC to the central NIC (labeled eth1) you should receive
an address on 192.168.1.0/24 from which you can ssh to 192.168.1.1 or open
a browser to http://192.168.1.1

. Welcome to OpenWRT/LEDE! Set a root password and you should be done.

The first things you probably want to do:

  • Change interface names to associate eth0 to WAN, and bridge eth1 and eth2 to
    LAN.
  • Edit the configuration to mount the third partition on the USB drive on /home. This is cool to add non-root users and give them a real flash storage.
  • Run ‘opkg update’, install missing packages.
  • Install OpenVPN configurations and test them.
  • Add ssh keys for root login in /etc/dropbear/authorized_keys
  • Install dotfiles to feel at home

Problems I have seen and their solutions:

The LEDE build is not so robust, sometimes it fails in parallel mode
because some dependencies seem to be compiled too late. If you get
compilation errors, using ‘make -j1’ should solve all issues. On a powerful
server with tons of RAM you need 2-3 hours to compile the whole set,
depending on how many packages you selected.

The version of LEDE you just compiled will quickly be out of sync with the
official package repositories. As soon as the kernel is changed in the LEDE project HEAD, all kmod packages from the LEDE repositories will refuse to install with opkg. This is the reason why you had to select “Build all kernel modules” in menuconfig: all kernel modules are already part of the image you created. This problem should go away once LEDE has released its first stable version.

I had most trouble with the ext4 filesystem definition: my first attempt
generated an ext4 of 50 MB which is far too small. After increasing that
size to 1GB, I still ran into “not enough disk space” errors and figured
out the number of inodes was too low (6,000). If you install a lot of
packages you need more inodes. Both points are addressed in the above
procedure. I also tried with an insanely high number (600k inodes) and the
resulting filesystem cannot be mounted.

Filesystem size is indicated in bytes, but fdisk counts in MB, based on a
power of 2. This yields a small discrepancy between the 500MiB filesystem
you generated with the build and the 500MB you reserved in the partition
table.

Once up and running, my router quickly ran into starvation problems. One
machine on the network could use the whole bandwidth and cut off every
other machine. I installed QoS packages: sqm-scripts, sqm-scripts-extra,
and luci-app-sqm, configured the queue to a fair scheduler, and got rid of
starvation issues. For some reason I could not get the pre-compiled
versions of these packages to work, I had to re-install them from official
repositories.

I wanted to add a Samba server to be able to use the rest of the USB drive
as a shared space but it is not a good idea. Samba takes ages to compile
and the daemon uses too many resources for such a small piece of hardware.

If you want to add ssh keys for the root user, remember the default ssh
server is dropbear, not openssh. dropbear expects root ssh keys to be
stored in /etc/dropbear/authorized_keys. You can also add root ssh keys
through LuCI.

The default shell for root is /bin/sh. You can change it to /bin/bash after
installing it and modifying the root entry in /etc/passwd.

Enjoy your fancy new router!

 

Advertisements

Written by nicolas314

Sunday 16 October 2016 at 4:58 pm

EdgeRouter Lite

with 3 comments

erlite-3-900x500

My endless search for the ideal home router made me buy a piece of hardware called EdgeRouter Lite by Ubiquiti. The price point is sweet (around $100), making it a damn expensive home router or a damn cheap professional one. For that price you get:

  • A Cavium Octeon processor: 500MHz, two cores, rated 1000 bogomips, MIPS64 architecture, big-endian.
  • Half a gig of RAM
  • Three GBit NICs
  • No wireless
  • No fan, no noise
  • OS completely contained on an easily accessed USB stick on the motherboard, so essentially as much drive space as you want.

The last point is the most important: by just removing three small Phillips screws you can unplug the original USB thumb drive and replace it with your own, equipped with your favourite operating system. If everything fails you can always switch back to your previous state, put the screws back and call it a day. That should not void your warranty but I am no lawyer.

The provided operating system is called EdgeOS, based on Vyatta, itself based on Debian. It seems Vyatta development is now halted and Ubiquiti is now steering EdgeOS alone. I used EdgeOS on that router for about six months and have to admit being rather satisfied. The router is sold as the fastest switching home appliance on the market, claiming 1 million packets per second. In order to reach that kind of speed with a (dual-core) 500MHz processor on three GBit NICs you need additional specialized hardware that is only available through proprietary drivers provided with EdgeOS. So be it.

I have a beef with proprietary router firmware though: each vendor seems to feel obliged to invent their own management language. Cisco, Mikrotik, Ubiquiti, you name it. Everything is meant to be controlled from the command line, which is great, but instead of navigating through a familiar Unix environment you need to learn half a million new (proprietary) commands, their syntax, side effects, and how to commit, save, or restore configurations.  This is a royal pain in the butt and I have no desire to go get some training to configure a home appliance.

To be fair, open source versions have had the same issue for years, though some made a huge effort to provide good web-based GUIs for configuration and avoid having to invent a new configuration language altogether. Tomato and DD-WRT have really pushed things forward to reach a decent level of user-friendliness. You only need to know about networking and do not have to worry about learning yet another obscure syntax to handle those.

Too bad: both projects seem to be pretty much abandoned today. DD-WRT has not seen a stable release in almost a decade and Tomato still courageously lives on, maintained by a handful of dedicated devs working from home. The communities for Tomato and DD-WRT are dwindling fast in favour of OpenWRT.

OpenWRT is the most advanced open source router project today. It is well designed, based on a single syntax for configuration files, and supports pretty much every piece of router hardware under the sun. The project was recently forked by its own developers into the LEDE project, which is now the version I am following as closely as possible.

Back to the EdgeRouter Lite: what’s not to love?

Beyond the proprietary software and syntax, EdgeOS offers a web-based GUI that looks fancy and neat but covers only a very, very limited portion of what can be achieved through a command-line interface. This is very frustrating. I love command lines as your next geek but don’t force me to learn a syntax I will use nowhere else just to achieve mundane stuff.

After six months of customizing my home router to my own needs, I had gathered scripts lying around e.g. to extract a list of known MACs or some stats.  And when I updated EdgeOS to another minor version, everything fell apart.  That irked me to no end, pushing me once more into the arms of an open source alternative.

Support for alternative firmware for this router is not obvious to find.  OpenWRT has an incomplete wiki page about it. A couple of guys have succeeded in installing FreeBSD but I did not feel up to the task. Debian supports big-endian MIPS64 machines, and a project called DebWRT offers support for this router, merging both Debian and OpenWRT in a single solution. This is cool but I am a bit terrified about using a straight Linux distro to build a router. If all I have to handle iptables is a bash shell and miles of manual pages, this is not going to work, I hate the iptables syntax with a true passion. The unique config file format used by OpenWRT is a real blessing, there is no way I am going back to one config file format per daemon.

So I started from scratch, built my very own version of a LEDE instance, including all the software I want to run on this box. The process is error-prone and it took me several evenings to get straight. In order not to lose information, I will be detailing everything I did in a next post, hoping it could be useful for someone else.

The net result is a pure LEDE box that has been running without hiccups for a few days now. Configuring routes, VPN, DHCP, DNS is a walk in the park thanks to user-friendly OpenWRT. All my scripts are working again, I can handle backups myself, and I even installed dedicated web and Samba servers. Next step will be to install an ad-blocking name server.

I am certainly losing in terms of performance but I won’t see the difference. Without proprietary drivers, hardware acceleration is gone.  This should not be an issue considering my home GBit network is currently handled by a separate switch and my Internet connection is limited to a mere 20MBit/s, magnitudes below what the router needs to provide. The day I get a GBit Internet connection at home, I will always have a choice to switch back to EdgeOS with just one unplug/plug of a USB key. Or maybe someone will have reverse-engineered the proprietary drivers by then?

There is one alternative I have been looking deep into: using pfSense or OPNsense to build my own firewall. The approach sounds good. I believe the BSD family is technically a lot better than anything Linux-based. This is particularly true in terms of network security software.

Trouble is: pfSense/OPNsense is extremely greedy. You can build a 15 euro router with OpenWRT but you need PC-sized gear to run pfSense, including at least 1 GB of memory and a lot more than mere megabytes of storage (OpenWRT fits in just 4 megs). The cost of a pfSense appliance can easily run in 400-500 euros, which does not make any sense from a budget point of view.  Most people going down that road recommend re-purposing an old PC for the task, but I have absolutely no intention of storing a hungry 300W loud old PC box next to my 20Mbit/s DSL modem, this would be insane.

There lies the whole beauty of this exercise: find the cheapest, least power-hungry, and most efficient way to set up a home routing solution that is easy and fun to configure, flexible enough, and secure. I stopped building my own PCs years ago and cover that need now by building small appliances from scratch, compiling the whole OS myself.

Tinkering is fun!

Written by nicolas314

Wednesday 5 October 2016 at 10:03 pm

OpenWRT on Ubiquiti AC Lite

with 4 comments

unifi-ac-lite

Stealth AP with hidden logo

A year ago, I thought I had upgraded my home WiFi to AC with the purchase of a cheap TP-Link Archer C5, but it only gave me trouble. The 2.4GHz band is working perfectly, the 5GHz not so. The first version of OpenWRT I installed had no support at all for the 5GHz mode, I had to dig out from the openwrt mailing-lists that something was under way to add support for it, find the right rxxxx release, compile it myself and install it, only to be disappointed. In the end I got it almost working: network would drop every minute or so, and the range would not exceed a few meters away from the access point. Quite worthless.

Ars Technica reported last year about switching from consumer-grade WiFi access points to professional ones here:

Ars Technica review of Ubiquiti Access Points

Took me a while to finally give up on the Archer C5 and decided to get the cheapest Access Point from Ubiquiti: the Unifi AC Lite unit.

Several things play in favour of this access point: it is designed to be hanging on a wall or a ceiling for a better wave spread, offers much higher power than your usual consumer-grade WiFi device, and the firmware is in the hands of Ubiquiti so they are taking care of making sure the unit is performing as it should. Or so I thought.

First surprise: the device cannot be started out of the box. You need to download the Unifi Controller software, a 200MB piece of java software that is meant to control the unit. Install the Controller on any computer on your local network, start it up, let it discover your access point, and you are good to go. The Controller starts up a local web-based interface which is accessed via a local web browser.

Ubiquiti designed it this way because this product is not meant to be purchased as a single unit but in batches and installed in hotels or offices. The Controller software has obviously been designed to maintain a long list of such access points. Having just one looks a bit ridiculous but Ok, I’ll play along.
To be fair: if you do not want to install the Controller locally you can also run it from an internet box (look Ma, it’s the cloud!). For companies or hotels who do not have servers on site it is an excellent idea but for a single AP this is largely overkill. I am not keeping a java server up full time on the Internet to manage an Access Point in my living-room. And if you do not want to run the Controller at all, you can also just start it whenever you need to modify your AP configuration and shut it down afterwards, which is what I did.
I mounted my AP on a top shelf, ran the initial configuration, and was delighted to see a double-band WiFi emerge immediately. Strong signal everywhere in the house, no connection issues, great! A welcome enhancement to my home network.

The only notable modification I brought was to stick a white Apple sticker on the Ubiquiti logo to hide it. The point was not to rebrand it as an Apple product but to hide this ugly U and this was the only sticker I had available that day. The Ubiquiti guys are probably not aware that they have the very same logo as a cheap French supermarket brand and I got tired of seeing that prominently displayed in my living-room.

After about a month, a few things started bothering me though. The AP seemed to have trouble waking up after losing power. First boot would report everything fine but WiFi would drop every connection immediately.  Rebooting the AP solved it every time. Did not feel too good about this.

Nmap’ing the unit revealed an open ssh port, which accepted the admin credentials that were set on the controller software. Once logged in, I found myself in front of some kind of heavily modified OpenWRT. Interesting… So is there anything on the Ubiquiti web site about this modified OpenWRT? After all, OpenWRT is under GNU license (v2) so I expected to find sources, some kind of build system, or anything related to the modified OpenWRT version running on my Access Point, but I could not find anything, at least nothing obvious from the Ubiquiti web site. Bad point for Ubiquiti but I am not a lawyer.

Nosing around the logs for some explanation for the needed reboots, I found nothing obvious. What I found was that a process was spitting a few lines every five seconds about having no contact with the Ubiquiti Controller software. Several questions on the Ubiquiti forums on that topic were answered with: “yes we know, this is a low-priority fix, just ignore it for the moment”. I have to say that just pushed me over the edge. I understand that my case is not the general use case and I truly do not blame Ubiquiti, but this is not the way I want my AP to work. I do not care much about log files filling up with useless messages but the lack of interest for single-AP users like me is disturbing.

So off to installing a real OpenWRT firmware this time. I finally got it working but it took me a whole afternoon of research to do so, which is summarized here in case it can be useful to somebody else.

First: the current (3.7) firmware embeds an RSA signature check preventing any attempt to install non-Ubiquiti firmware. This is probably due to the recent FCC firmware lockup rules. While I do understand the FCC concerns and the important role they play in Homeland Security, I regretfully do not feel obliged to follow US rules on European ground. This is my hardware now, if I decide to mess it up with another firmware I should be able to do so.

Solution: downgrade the firmware to version 3.4, which is signed by Ubiquiti and does not check firmware update signatures. This firmware can be found by googling a bit around, I got a working URL and the complete procedure from this page:

LEDE/OpenWRT for Ubiquiti UniFi AP AC (LITE + LR + PRO)

While we’re at it, it may be a good idea to switch from OpenWRT in favour of the recent project fork called LEDE project. Seems they have added official support for this hardware and the documentation seems a lot cleaner, though very, very incomplete for the moment, which is perfectly Ok for a two-week old project.

If you did not follow what happened to the OpenWRT project recently, you may be interested in learning a bit more about why the team forked:
https://lwn.net/Articles/686767/

Some pre-built images are available from the LEDE project site, but I chose to go all the way and clone the github repository, configure the build to include the software I need, and recompile everything myself. On a beefy x64 server this took about 2 hours and 11GB of disk space, ending up with a 3.3MB image that was happily installed in a single command on the downgraded Access Point.

The default configuration is smart: the AP tries to obtain an address for itself through DHCP on its only wired interface and acts as a bridge for wireless clients, making it immediately operational when connected to a network equipped with a proper DHCP server. Sweet.

Net result: my Unifi AC AP is now completely stand-alone. I happily removed the Ubiquiti Controller software and customized my AP to death with various scheduling and logging scripts. Wireless range in the 5GHz band covers the whole house and the 2.4GHz allows me to walk outside during Skype calls without losing signal. No more spontaneous rebooting, my logs are clean, and most importantly: I feel empowered :-)

I have to say I do not see Open-source firmware disappearing any time soon.  For tinkerers like me who like to have complete control over their network, this is absolutely brilliant.

Edit: 2016-12-09 Adding some config files and diagnostics to this page, might be helpful if you are trying to replicate this

/etc/config/wireless defines two access points: ap24 for 2.4GHz and ap50 for 5GHz, with passwords SECRETPASSWORD.

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path 'platform/qca956x_wmac'
    option txpower '20'
    option country 'FR'
    option distance '50'
    option channel '3'

config wifi-iface
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option ssid 'ap24'
    option encryption 'psk2+tkip+ccmp'
    option macfilter 'deny'
    option key 'SECRETPASSWORD'

config wifi-device 'radio1'
    option type 'mac80211'
    option hwmode '11a'
    option path 'pci0000:00/0000:00:00.0'
    option htmode 'VHT80'
    option txpower '20'
    option country 'FR'
    option distance '50'
    option channel '136'

config wifi-iface
    option device 'radio1'
    option network 'lan'
    option mode 'ap'
    option ssid 'ap50'
    option encryption 'psk2+tkip+ccmp'
    option key 'SECRETPASSWORD'

Here are the outputs of iw phy0 info:

#iw phy0 info
Wiphy phy0
 max # scan SSIDs: 16
 max scan IEs length: 199 bytes
 max # sched scan SSIDs: 0
 max # match sets: 0
 Retry short limit: 7
 Retry long limit: 4
 Coverage class: 0 (up to 0m)
 Device supports AP-side u-APSD.
 Available Antennas: TX 0x3 RX 0x3
 Configured Antennas: TX 0x3 RX 0x3
 Supported interface modes:
 * managed
 * AP
 * AP/VLAN
 * monitor
 * mesh point
 Band 2:
 Capabilities: 0x19ef
 RX LDPC
 HT20/HT40
 SM Power Save disabled
 RX HT20 SGI
 RX HT40 SGI
 TX STBC
 RX STBC 1-stream
 Max AMSDU length: 7935 bytes
 DSSS/CCK HT40
 Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
 Minimum RX AMPDU time spacing: 8 usec (0x06)
 HT TX/RX MCS rate indexes supported: 0-15
 VHT Capabilities (0x338001b2):
 Max MPDU length: 11454
 Supported Channel Width: neither 160 nor 80+80
 RX LDPC
 short GI (80 MHz)
 TX STBC
 RX antenna pattern consistency
 TX antenna pattern consistency
 VHT RX MCS set:
 1 streams: MCS 0-9
 2 streams: MCS 0-9
 3 streams: not supported
 4 streams: not supported
 5 streams: not supported
 6 streams: not supported
 7 streams: not supported
 8 streams: not supported
 VHT RX highest supported: 0 Mbps
 VHT TX MCS set:
 1 streams: MCS 0-9
 2 streams: MCS 0-9
 3 streams: not supported
 4 streams: not supported
 5 streams: not supported
 6 streams: not supported
 7 streams: not supported
 8 streams: not supported
 VHT TX highest supported: 0 Mbps
 Frequencies:
 * 5180 MHz [36] (20.0 dBm)
 * 5200 MHz [40] (20.0 dBm)
 * 5220 MHz [44] (20.0 dBm)
 * 5240 MHz [48] (20.0 dBm)
 * 5260 MHz [52] (20.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5280 MHz [56] (20.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5300 MHz [60] (20.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5320 MHz [64] (20.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5500 MHz [100] (27.0 dBm) (radar detection)
   DFS state: available (for 2032379 sec)
   DFS CAC time: 60000 ms
 * 5520 MHz [104] (27.0 dBm) (radar detection)
   DFS state: available (for 2032379 sec)
   DFS CAC time: 60000 ms
 * 5540 MHz [108] (27.0 dBm) (radar detection)
   DFS state: available (for 2032379 sec)
   DFS CAC time: 60000 ms
 * 5560 MHz [112] (27.0 dBm) (radar detection)
   DFS state: available (for 2032379 sec)
   DFS CAC time: 60000 ms
 * 5580 MHz [116] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5600 MHz [120] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5620 MHz [124] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5640 MHz [128] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5660 MHz [132] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5680 MHz [136] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5700 MHz [140] (27.0 dBm) (radar detection)
   DFS state: usable (for 2032442 sec)
   DFS CAC time: 60000 ms
 * 5720 MHz [144] (disabled)
 * 5745 MHz [149] (disabled)
 * 5765 MHz [153] (disabled)
 * 5785 MHz [157] (disabled)
 * 5805 MHz [161] (disabled)
 * 5825 MHz [165] (disabled)
 valid interface combinations:
 * #{ AP, mesh point } <= 8, #{ managed } <= 1,
   total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
 HT Capability overrides
 * MCS: ff ff ff ff ff ff ff ff ff ff
 * maximum A-MSDU length
 * supported channel width
 * short GI for 40 MHz
 * max A-MPDU length exponent
 * min MPDU start spacing
 Device supports VHT-IBSS.

Here are the ouputs of iw phy1 info:

# iw phy1 info
Wiphy phy1
 max # scan SSIDs: 4
 max scan IEs length: 2257 bytes
 max # sched scan SSIDs: 0
 max # match sets: 0
 Retry short limit: 7
 Retry long limit: 4
 Coverage class: 1 (up to 450m)
 Device supports AP-side u-APS.
 Device supports T-DLS.
 Available Antennas: TX 0x3 RX 0x3
 Configured Antennas: TX 0x3 RX 0x3
 Supported interface modes:
 * IBSS
 * managed
 * AP
 * AP/VLAN
 * WDS
 * monitor
 * mesh point
 * P2P-client
 * P2P-GO
 * outside context of a BSS
 Band 1:
 Capabilities: 0x11ee
 HT20/HT40
 SM Power Save disabled
 RX HT20 SGI
 RX HT40 SGI
 TX STBC
 RX STBC 1-stream
 Max AMSDU length: 3839 bytes
 DSSS/CCK HT40
 Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
 Minimum RX AMPDU time spacing: 8 usec (0x06)
 HT TX/RX MCS rate indexes supported: 0-15
 Frequencies:
 * 2412 MHz [1] (20.0 dBm)
 * 2417 MHz [2] (20.0 dBm)
 * 2422 MHz [3] (20.0 dBm)
 * 2427 MHz [4] (20.0 dBm)
 * 2432 MHz [5] (20.0 dBm)
 * 2437 MHz [6] (20.0 dBm)
 * 2442 MHz [7] (20.0 dBm)
 * 2447 MHz [8] (20.0 dBm)
 * 2452 MHz [9] (20.0 dBm)
 * 2457 MHz [10] (20.0 dBm)
 * 2462 MHz [11] (20.0 dBm)
 * 2467 MHz [12] (20.0 dBm)
 * 2472 MHz [13] (20.0 dBm)
 * 2484 MHz [14] (disabled)
 valid interface combinations:
 * #{ managed } <= 2048, #{ AP, mesh point } <= 8, #{ P2P-client, P2P-GO } <= 1, #{ IBSS } <= 1,
   total <= 2048, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz }
 * #{ WDS } <= 2048,
   total <= 2048, #channels <= 1, STA/AP BI must match
 HT Capability overrides:
 * MCS: ff ff ff ff ff ff ff ff ff ff
 * maximum A-MSDU length
 * supported channel width
 * short GI for 40 MHz
 * max A-MPDU length exponent
 * min MPDU start spacing

 

Written by nicolas314

Monday 30 May 2016 at 4:41 pm

OpenWRT on MR3020

with one comment

TL-MR3020_3_1600x1600

 

Situation: you live in a one-room appartment and receive Internet through a single RJ45 plug in the wall. How do you extend it to all devices in the room for the cheapest price?

Objective: provide WiFi connectivity on a dedicated LAN where users can see each other and share files easily. The system should be easy to repair or upgrade. Bonus points for extra functionalities like VPN provided to the whole WiFi LAN, ad filtering, or shared folders on Samba.

My first go-to for anything cheap related to computing is the RaspberryPi.  How can you beat it? For 35 euros (amazon.fr in December 2015) you get a full-powered Linux box with RJ45 and enough USB ports to power an external disk and a WiFi dongle. I gave it a try and came to the conclusion that the result would probably be a little too expensive and probably brittle. I have several WiFI USB adapters lying around and none of them was able to create a WiFi Access Point on a RPi, though they do work flawlessly as WiFi clients. They almost got there but not completely. You need to recompile your own WiFi access point software, and taking care of my own iptables rules is just beyond my patience.

Better option: Openwrt! This open-source Linux distribution is not meant for your average PC but to run on screen-less network appliances. You won’t find desktop apps or anything related to X11 but you have all possible network daemons and tools running there. Openwrt runs on low-power processors like ARM, MIPS, and x86 too of course. It comes bundled with its own package distribution tools (opkg) making administration relatively easy. It is really meant for tinkerers, people who like to open the box and modify what’s inside to do different stuff.

Obvious applications for Openwrt are of course network-related. Build your home router for 25 euros supporting IPv6, customized firewalling, guest WiFi, kid protection, quality of service, network monitoring, Virtual Private Networks, or file sharing, to name a few. A popular application is PirateBox: start the box, create a local WiFi network, all clients connected to it can easily share files through the local access point.  Other cool projects include running your own home telephony over the Internet (asterisk), making a sound box or an Internet radio.

There are also thousands of cool projects if you are so inclined and ready to take your soldering iron out of the dust. Most router hardware parts have hackable GPIO ports you can connect to a breadboard to pilot a 0-5V trigger or even read signals at a reasonable frequency. Check out the DIY section at the bottom of this page to get a few ideas:

https://wiki.openwrt.org/toh/tp-link/tl-wr703n

Note that the WR703N is a 10-20 euro piece of hardware so it is about half of the retail price of an Arduino with Ethernet shield, or a RaspberryPi.  Sure, you get less hardware, but if your project is purely network-oriented this is by far a better alternative.

Back to our task: find cheap hardware that gets Internet from an RJ45 plug and offers decent WiFi for a few devices.  I set my limit to 25 euros and chose the TP-Link MR3020.  It has the minimal 4MB of internal storage needed to install Openwrt. You read that right: 4 megabytes of persistent storage, in an era where your average smartphone sports several gigabytes of RAM.

There are several ways to obtain an Openwrt image for a given piece of hardware. First and simplest one is to download it directly off openwrt.org. That does not always fit the bill though, because the team had to make choices about the packages that are present in each image. If space is tight (4 megs is kind of narrow) you may not be able to install anything more than was pre-bundled already. That is actually the case for the MR3020. Solution: extend the local storage. So I plugged in an 8GB USB dongle (5 euros).

Plug the USB in, wait, and… nothing. ‘dmesg’ shows the kernel recognized something USB but did not offer to mount the filesystem. Of course: the kernel modules have been trimmed down to a minimum and USB storage was not in. Quick install with opkg? No way. There is not enough space left to install a mere kernel module for USB storage so the default image falls a bit flat. Removing packages also does not work. I first tried to trim down all un-needed packages until I realized that every time I uninstalled something, space was running even lower on the root filesystem. How comes?

To understand why, you need to know that the default firmware image is built on top of squashfs, a read-only compressed filesystem. On top of that, openwrt adds an overlay filesystem, an image that registers all changes from the underlying read-only partition. When you delete a file from such a setup you actually write on top of it in the overlay filesystem a mention that this file should not appear any more. There is another option using a read-write filesystem (jffs2) for the firmware but apparently it can get into trouble on many routers so I did not even try.

One solution is to build your own openwrt image and embed only the modules you need. That one is tough. You need to dedicate an x64 machine for that, download a million source files, prepare all the compilers and build tools you ever heard of, fine tune the package configuration, press make, and wait for a few hours. You end up with an image a bit smaller than the four dreaded megabytes with a build system taking about 3GB of space on the build host.

To be fair, the openwrt build system is a wonderful thing. It starts by creating its own toolchain for cross-compilation for your target hardware, then builds up a whole Unix from scratch and ends up packaging everything into this tiny image. Very impressive. I have seen very few professional build systems that are as clean as this one. Congratulations to the Openwrt for working out such a beautiful system!

If you are not into compiling your own stuff, you have another option:
Image Generator
https://wiki.openwrt.org/doc/howto/obtain.firmware.generate

This method uses pre-built components which you assemble into a minimal firmware image. That goes a lot faster (a matter of seconds) and does not eat up gigabytes of disk space. Select the few minimal modules you need to at least boot up the router on the network, and be able to mount USB storage. That is what I ended up doing.

I flashed an image that contained just enough software to run a kernel with network support (duh), USB storage support, package management, and some basic utilities. Plugging the USB storage worked immediately. Yay!

Let’s start again: I have 8GB of space on USB dongle, far more than I will ever need for the router itself. I created a first ext4 partition for 700 megs, which should be enough to hold every possible package, configuration files, and even log files if needed. I added a second 128 meg partition for swap space, and left the rest as a single ext4 partition.

The router was booted again with USB dongle plugged in. Let it boot, log onto it as root, and set up the root filesystem as an overlay from the USB first partition. Reboot the router and there you go: your router space has grown from 4 megs to 700.

This brilliant howto here explains exactly how to do it:
https://wiki.openwrt.org/doc/howto/extroot

Once you have enough space you can start adding back all the packages you need. Just to give you an idea, I have there:

  • A web interface to set everything up
  • Tools to monitor the device and display nice graphs on the web interface
  • DNS server, WiFi Access Point, Firewall
  • Development tools: gcc, git, python, lua, strace, screen, vim
  • A Samba server
  • sshfs to mount remote filesystems locally
  • OpenVPN either as client or server

After that it is a matter of taking time to configure each service specifically. The Openwrt wiki pages are a real treasure in this respect.  Everything you need is there, together with additional ideas for cool stuff to do. One hour later I was done adding VPN support, Samba service for the remaining of the USB dongle space, an ad blocker, a local web site, and a local fixed address for administration (an alias on eth0).

There is one point really worth mentioning about the Openwrt philosophy.  If you have some Unix experience, you know that every piece of server software you install comes with its own system of configuration directories and files with a specific new syntax to learn, a different place to find log files, and another way to handle PID files. Sure there is some standardization on the way with most config files under /etc and logs under /var/log, but it seems everybody needs to invent a new syntax for configuration and logging. See a previous blog post about that topic.

Openwrt places all configuration files in a single place and they all respect the same key/value syntax. It is straightforward to understand, edit, diff, store in version control, or pretty-print. That alone helps smooth out the learning curve every step of the way. Gives you a definite feeling of things done in a proper, consistent, and very clean manner. So there you go: for all your network-y things, you know where to look. The Internet of things starts right here with these boxes, guys.

My next endeavours with OpenWRT will probably need my soldering iron. Those GPIOs on the board look tempting…

Written by nicolas314

Wednesday 9 December 2015 at 12:31 am

Posted in hardware, openwrt, router

Tagged with , ,

Parental control with OpenWRT and OpenDNS

with 9 comments

images

The following recipe took me a whole evening to find, so I am documenting it here in hope it could be useful to somebody else.

I recently upgraded my home network to a beefier TP-Link C5 Archer (75 euros on Amazon). This little box packs two Wi-Fi access points in 2.4 and 5GHz (Wi-Fi ac), which pushes wireless speeds up to 500Mbit/s within a few meters range. The main selling point for me was that it runs the latest OpenWRT firmware with absolutely no issue whatsoever. Flash firmware, done.

OpenWRT has become a real Linux distribution today, packing more power than you could ever imagine achieving with such hardware. I certainly miss the Tomato user-friendly GUI, but I do enjoy the power at my fingertips when it comes to network configuration. Kudos to the OpenWRT team for such a technical achievement!

Back to the point: parental control. I have kids at home and all sorts of networked devices: smartphones, tablets, computers, servers, printers, you name it. I want to be able to disable adult site browsing and the like from kids hardware. The easiest solution I found so far is OpenDNS (http://www.opendns.com), which offers you free DNS filtering for one IP address. Create an account, configure your home IP address, set the categories you want to ban, and done. Any machine on my internal network using OpenDNS will receive re-directs for unwanted sites. In the past I used to manually modify the DNS settings on all kids hardware to switch to OpenDNS servers, but that quickly becomes old, and sometimes requires some sleight-of-hand to configure. Forget it.

Enter OpenWRT: you can actually assign different DHCP settings to hosts on your network, e.g. different DNS servers. Even if the documentation is respectfully thick on that topic, it took me a while to understand it.

In its latest incarnation Barrier Breaker (Dec 2014), OpenWRT packs all DHCP information into /etc/config/dhcp. Make your modifications there and restart the dnsmasq daemon to activate them.

Procedure:

1. edit /etc/config/dhcp to add a new section

config tag 'kids'
    list dhcp_option '6,208.67.222.222,208.67.220.220'

2. Now add individual sections for all devices you want to include in the ‘kids’ section:

config host
    option name 'pluto'
    option mac 'YOUR DEVICE MAC ADDRESS'
    option ip 'YOUR DEVICE ADDRESS ON THE INTERNAL NETWORK'
    option tag 'kids'

3. Restart dnsmasq with: /etc/init.d/dnsmasq restart

And you are done. Just tag the hosts you want to be part of the kids zone to distribute the OpenDNS servers instead of the default one.

References:

Written by nicolas314

Wednesday 10 December 2014 at 10:24 pm

Posted in Uncategorized

Tagged with , ,

Tomato vs OpenWRT

with 11 comments

If you really are into home computing, you probably have one or more WRT54G-type routers hanging around, taking care of your home network. These tiny jewels do everything a Cisco router does and more for a fraction of the price. Interestingly, the company who initially produced these poor man’s Cisco boxes (Linksys) was later bought by Cisco. A better description can be found on e.g. Wikipedia: Wikipedia page about WRT54G

The key selling point for these boxes is that you can upgrade the native firmware to alternative versions produced by a vibrant community of Linux users. I tried several firmware versions: DD-WRT, HyperWRT, OpenWRT and finally Tomato. While DD-WRT and HyperWRT concentrate on providing a better firmware than the one initially distributed on the box, I found they tend to only touch on the surface of what can be achieved.

Out of all alternative firmwares, OpenWRT really stands out as the geek-favoured one. This firmware is actually a tiny Debian-like Linux distribution provided with a complete development environment, allowing you to port existing software or even program your own if you feel so inclined. It is pretty easy to run a Web server, a print server, mount external storage through sshfs or handle syslogs from all machines on the local network.

I run two of these boxes, one on each side of my house, distributing a WiFi signal everywhere I might want to connect something wirelessly. One box is the main router attached to my ISP’s Internet box, the other one is enslaved by WDS. Each of these has been used as host for various kinds of services in the past, mostly as toy servers for me to learn more about firewall rules, VLAN configurations, WiFi hotspot setting and related security issues. I have played with OpenWRT for a while, compiling all sorts of stuff and installing tons of new software at regular intervals. A great time-eater but the trip was worthwhile, I learned quite a few things about Linux networking by doing so.

Today these boxes have been obsoleted on my home network by MicroClient units. These tiny Linux boxes are much easier to program: they behave like regular PCs, run Debian directly and do not need specific porting skills or compilation environment. And they have their own hard disks or Compact Flash memory, in addition to USB support!

End of the road for WRT54G? Not at all. ‘Tomato’ was recommended to me as yet another alternative firmware and since I tried it I cannot get back to OpenWRT. Where the latter is rich in potential, Tomato is rich in achievements. If you want to setup a basic service with OpenWRT you have to skim through pages and pages of (well-written) documentation to understand all the details of what you are trying to do, then absorb all needed knowledge to configure that stuff, and then several full evenings of experimentation to get things straight. And even then performance might be poor or you may get into dark corners not covered by any documentation and then your only hope lies in some IRC channels. Nice but tiresome.

Tomato is the straight thing: it does not offer as many options as OpenWRT but everything it covers is user-friendly, works immediately as described, and does not need countless hours of painful experimentations. Overall network performance also seems to be better with Tomato but I did not try to benchmark the whole thing. Judging by what I have seen over the last two weeks, my bandwidth seems to have increased by 15-20% on average.

Relevant pages:

Written by nicolas314

Monday 9 June 2008 at 1:00 am

Posted in Unix

Tagged with , ,