Introducing wiconn: A text-based 802.11 wireless network manager for OpenBSD

When I switched back to OpenBSD as my primary daily-use operating system back in 2011, my biggest complaint was the lack of an easy-to-use tool for managing wireless networks. I only used maybe two or three different wireless networks daily. I just used a few shell scripts that statically configured the network card for each of these environments. Any time I'd go somewhere else, though, it would be a pain to manually configure it.

Almost exactly five years ago, I did something about it, and I called it wiconn.sh. Since I already had one-off scripts for my home and office networks, Wiconn started as a script to display open networks. It would display only the open ones, and prompt me for an SSID, and it could remember the BSSID (MAC Addresses) of open networks I used to protect me from things like my own Evil WiFi setup and other "evil twin" style wireless attacks.
That first version looked something like this:

Wiconn evolved over time. By late 2012, I'd given it a bunch of features and made the interface look nicer. All SSIDs were being listed with color-coded backgrounds for the network you're connected to, and open networks. Visually, it hasn't changed much since 2012. This is how Wiconn looks today:

Over this long holiday weekend, I finally got it to a place where I feel like sharing it. Since it's already in the garage for maintenance, I figured I might as well put wiconn on GitHub.

  • Written primarily in Bourne shell (/bin/sh)
  • No dependencies: Relies only on the OpenBSD base distribution
  • Built-in protection from common wireless attacks
  • Easily connect to saved networks with one command (no scanning or prompt)
  • 2-Clause Simplified BSD license
There's still some more work to do.  I'd like to have it detect that one of your saved networks is in the list and ask if you'd like to join it. I'm also using NetBSD a bit more, and feel like there might be a way to make it work well on both OpenBSD and NetBSD from the same codebase, despite small differences in command syntax and output format between them.

Anyhow, for the growing number of folks who are giving OpenBSD a shot lately, I thought I'd share. Feedback is welcome, and more information is available through the documentation via GitHub.

n0xa/wiconn on GitHub


OpenBSD vmm Hypervisor Part 1: Walk-through

Thursday night, I recorded a video while tinkering with vmm. I covered some basics of using it, networking, and installing OpenBSD inside a freshly-created VM. Sorry for the stammering and poor audio quality. Of course, the real fun was figuring out how to get it transcoded into webm and uploaded to youtube from within OpenBSD. I learned a lot about ffmpeg this week. Enjoy.

FYI, I used these same VMs to help me update and test the nginx and httpd PHP/MySQL articles. They're (finally) up-to-date for OpenBSD 6.0. Better late than never, right?


Iodine DNS Tunneling

I first wrote about DNS Tunnelling back in 2010. Even back then, commodity tools to facilitate it were at least five years old. I covered OzymanDNS, DNS2TCP,Heyoka, and DNSCAT in 2010.

A few years ago, I was introduced to Iodine, and it's been my go-to tool for DNS tunnelling ever since, frequently with great success. Iodine has several different modes, and will try various query types, packet sizes and timing parameters, usually making the connection as reliable as it can be. Without any adjustments, it doesn't try to be stealthy, but if you dig into the manual client options and you know what your adversary is looking for (e.g. Snort/Suricata rules, Bro, FQDN length, volume of queries, etc.) you might be able to get Iodine to fly below the radar.

Just like the very first articles I wrote, the technique requires you to set up a sub-domain with a name server. Here, I set up a subdomain for *.t.h-i-r.net, and I've assigned it a name server of tn.h-i-r.net. I had to specify an A record for it: the IP address of a VPS I'm leasing (which also hosts much of HiR's presence aside from this blog). You could easily point it to your home IP address -- so long as you can NAT port 53 UDP to it.

I'm using Google Domains for this, but almost any DNS control panel should let you define NS records for subdomains and A records for hosts similar to how it shows up above. Previously, I'd demonstrated using GoDaddy and ZoneEdit DNS control panels.

Once you have established these DNS configuration entries, and made sure that UDP traffic can get to port 53 on the tunnel server, you should be ready to get Iodine installed. Most GNU/Linux and BSD flavors I've used lately have Iodine in the package repository. That includes OpenBSD, Arch Linux, Kali, and Ubuntu. If you're using Mac OS X, there's a Homebrew recipe that seemed to work last time I tried.  The Iodine page has Windows and Android binaries available for download. I have not yet tried them.

You probably want to leave the iodine server (iodined) running on your tunnel server at all times, so that it's ready when you need to use it. Since iodine uses a privileged port and creates TUN/TAP interfaces, you need to run it as root. At a minimum, to start the Iodine server, you need to specify a password, a network (in CIDR notation) to allocate for the tunnel, and the subdomain you configured above. I'm using a pretty small network mask (/29) which allocates only five client IP addresses. As I'm the only one using this tunnel server, this is fine. It might even be overkill.

# iodined -P r3d4c73d t.h-i-r.net
Opened /dev/tun0
Setting IP of tun0 to
Adding route to
add net gateway
Setting MTU of tun0 to 1130
Opened IPv4 UDP socket
Limiting to 5 simultaneous users because of netmask /29
Listening to dns for domain t.h-i-r.net
Detaching from terminal...

On the client machine, it's assumed that you can connect to a network, but unrestricted Internet access isn't working. In my example, I'm on a somewhat restricted hospital Wi-Fi network that isn't allowing SSH, and has restrictions on what one can browse on the web. Most of my favorites are being blocked because they're "hacking" related.

Ideally, a recursing DNS server is available. As long as you can see the NS record you set up, there's a pretty good chance Iodine will work. The client also needs to run as root (or via sudo) and the bare minimum configuration requires a password and the subdomain.

$ host -t ns t.h-i-r.net
t.h-i-r.net name server ns.t.h-i-r.net.

$ sudo iodine -P r3d4c73d t.h-i-r.net
Opened /dev/tun0
Opened IPv4 UDP socket
Sending DNS queries for t.h-i-r.net to
Autodetecting DNS query type (use -T to override).
Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #0
Setting IP of tun0 to
Adding route to
add net gateway
Setting MTU of tun0 to 1130
Server tunnel IP is
Testing raw UDP data to the server (skip with -r)
Server is at, trying raw login: OK
Sending raw traffic directly to
Connection setup complete, transmitting data.
Detaching from terminal...

Once you have the connection established, the remote end should be reachable via the "Server tunnel IP" shown in the output. In this case, that's Typically, this is where I set up a Dynamic proxy with ssh.

$ ssh -D 1080
Last login: Thu Oct 20 17:44:19 2016 from
OpenBSD 6.0 (GENERIC.MP) #0: Fri Sep  2 16:10:46 CEST 2016


Back in the real world, I set Firefox proxy settings up to use localhost at port 1080, and enabled remote DNS. Configuring the proxy in other browsers may vary. You may even have a system-wide SOCKS proxy setting.

Firefox now can browse through this SSH session, which is tunnelling over DNS.

Back on the tunnelled SSH session, I used the ~# SSH escape command to list open tunnel connections. This will verify that you are browsing through the tunnel.

The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
  #3 direct-tcpip: listening port 1080 for www.h-i-r.net port 80, connect from port 16128 to port 1080 (t4 r1 i0/0 o0/0 fd 9/9 cc -1)
  #4 direct-tcpip: listening port 1080 for www.blogger.com port 443, connect from port 25392 to port 1080 (t4 r2 i0/0 o0/0 fd 10/10 cc -1)
  #5 direct-tcpip: listening port 1080 for apis.google.com port 443, connect from port 46746 to port 1080 (t4 r3 i0/0 o0/0 fd 11/11 cc -1)

It's hard to see here, but I grabbed a Wireshark screen shot of Iodine in action a few weeks ago. The heartbeat packets are all pretty short. They can get quite large when the time comes to send a lot of data. Here, Iodine has chosen to use NULL records.


Laptop CPU upgrade -OR- The quest for OpenBSD vmm(4)

I have been itching to play with vmm. I tried to get it working on an old Acer laptop and an IBM System X server, without any luck. I asked what was up, and heard from jbg@ that vmm requires a CPU with Nehalem microarchitecture or newer, and that the Intel P6200 in this machine lacks some of the instructions needed for vmm. Well, that would have been nice to put in the documentation. Perhaps I'll submit a diff.

I decided it'd be fun to try to upgrade the CPU in the Acer so I can finally play around with vmm in -CURRENT. Believe it or not, I've never attempted a laptop CPU upgrade. I've only replaced CPUs with the same spec before, replaced thermal interface compound, and upgraded RAM and hard drives. I went on the hunt for  PGA988 (Socket G1) Arrandale-based processors with 35w TDP (so the existing heat sink and fan, designed with the P6200 in mind, can keep up).  Sure enough, some of the first-generation i5 and i7 mobile processors fit the bill nicely.

On a really tight budget, I scored an i5 540M for $12 shipped. At the high-end, I could have splurged on an i7 640M to really wring everything out of it -- as far as I can tell. The only difference between the CPU I bought and the best i7 I could shoehorn into this laptop are an additional 1MB of SmartCache and 250MHz. Since my goal was simply to get vmm working, $12 was a bargain.

Many laptops make it a breeze to change hard drives. Some even have easy access to swap RAM, WiFi adapters, and optical drives. This Acer is easily serviceable for these parts. The CPU is a bit more difficult to get to. It's on the bottom of the motherboard, and it requires one to remove the keyboard, the top of the base, remove a handful of ribbon cables and connectors, and completely remove the motherboard, heat sink and cooling fan as a single assembly. Once the board is exposed, it's pretty simple to remove the heat sink, open the socket and swap processors.

P6200 (left) and i5 540m (right) immediately after swapping processors
The most crucial part of upgrading the CPU is making sure you have a good thermal interface between the processor dies (shiny metallic parts) and the body of the heat sink. I used a thermal paste that I've had good luck with in the past. For a 35w CPU, you don't need to splurge, but you should follow the instructions closely if you are unfamiliar with the process.

I slapped most of the parts back together without re-assembling the entire laptop case to see if it would even boot. Remember, this was uncharted territory for me. Looks like success!

Core i5!
Of course, there's still a matter of whether the BIOS will pass the virtualization options to OpenBSD. This is basically the worst BIOS setup I've ever seen, and it doesn't give me any options for virtualization.

I had already compiled a fresh OpenBSD kernel with vmm(4) enabled, so I went ahead and put the laptop back together, and booted the vmm capable kernel,started vmd and fired up the virtual machine.  No errors! I attached to the virtual serial console, and a few seconds later, saw the kernel booting.

Sweet success!

This coming weekend, I'll probably try to figure out how to get networking configured. This definitely isn't Parallels Desktop, but it's not any more daunting to set up than QEMU was.


Pretty WordPress permalinks under OpenBSD's httpd(8)

I run a bunch of websites on OpenBSD. One of them is running WordPress for a local group. When I upgraded the server from OpenBSD 5.7 to 5.8 last year, I finally switched from the version of Apache 1.3 that used to come in the base install, to the new relayd-based httpd that had been in the works. Without mod_rewrite, I disabled the so-called "pretty" permalinks with useful titles, going back to the old numbered-posts setup.

This had been bothering me last weekend, and earlier this week, I saw someone else with the same problem. I had written a totally custom CMS for one of my other websites, and it also uses an awkward set of front-controllers written in PHP in order to make friendly-looking URLs. I decided to explore my method of setting that site up, applied to WordPress.

You have the option of using so-called "PATHINFO" Permalink URLs in WordPress. Those might look like:

That's getting there. I opted to make my site more like:

I started by creating a symbolic link called "posts" pointed to index.php.

ln -s index.php posts

Since I'm using PHP-FPM, I had to also make sure that FPM would acknowledge this new file since it lacks the .php extension.  Beware the rule of unintended consequences here. You'll want an airtight httpd.conf when it comes to what things it decided to toss over to the PHP-FPM socket. Blank out the security.limit_extensions variable in /etc/php-fpm.conf

security.limit_extensions =

Next, adjust your httpd.conf to send stuff destined to the /posts URI (note the * at the end, it's important!) to PHP-FPM. All of my sites are under /var/www/sites/ (including the one I'm setting up WordPress on). My httpd.conf clause for this site looks kind of like this:

server "blog.foo.com" {
    listen on $ext_if port 80
    alias "fooblog.com"

    log access fooblog-access.log
    log error fooblog-error.log
    directory {index "index.php" }
    location "/*.php*" {
        root { "/sites/fooblog" }
        fastcgi socket "/run/php-fpm.sock"
    location "/posts*" {
        root { "/sites/fooblog" }
        fastcgi socket "/run/php-fpm.sock"
    location "/*" {
        root { "/sites/fooblog" }

You'll need to restart php_fpm and httpd for this to take effect.

doas rcctl restart httpd
doas rcctl restart php_fpm

After that, log in to your site's admin panel and change the permalink structure to include "/posts/" at the beginning. You should be all set.


NetBSD 7.0 working on the Raspberry Pi Zero

The NetBSD Wiki has a nice page about Raspberry Pi support, including instructions for finding a nightly snapshot image for Raspberry Pi SBCs.

Trying to boot the latest snapshot (201512311300Z) on my Pi Zero resulted in 8 flashes of the OK/ACT LED (bootcode.bin and/or start.elf problems, according to the documentation). This image boots fine on my Pi B+ and Pi 2.

I over-wrote bootcode.bin, start.elf and start_cd.elf on the freshly imaged NetBSD SD card from the version on my Pi Zero Lapdock (installed from a recent Arch Linux image. NetBSD 7 now boots on the Raspberry Pi Zero. I don't know if these are exactly the correct files, but I suspect they likely require updating in the NetBSD base image.

I've included MD5 sums of the files for your convenience: From the NetBSD Image: 
MD5 (bootcode.bin) = 9a4ad6a12ad7dc1aae279888c25d2252 
MD5 (start.elf) = a2c4b9ea3ae986f88ea01e05bef46904 
MD5 (start_cd.elf) = 85924312c9b51d1ef5b7ca301bb18d54

Files I copied over from Arch Linux that make it bootable: 
MD5 (bootcode.bin) = 6cc6560c0178c10928d14b8768969dab 
MD5 (start.elf) = f5b2a422d863efe5d47b1ac291ccaa3a 
MD5 (start_cd.elf) = f0dfc1462c5d9b003b64428fd52406ed

(I posted a variant of this as a comment on the NetBSD wiki. It hasn't shown up yet. It likely requires approval)