Ubiquiti AP enters reset state but never leaves

July 20, 2018

I did something dumb recently. I had a network failure at my ISP, so I had to kill my dhclient and restart it. After restarting, everything seemed cool – until I reset my Ubiquiti AP. At that point, the AP entered the “Restarting” state and never came out.

After a few minutes of poking around on the Ubiquiti management screen, I saw this:

Screenshot from 2018-07-20 13-09-11

Apparently I killed off my DHCP server too. Oops.

One restart of the DHCP server later, my AP was back online (it detected when the DHCP server started). Some day I really should put the AP on its own static IP. That’s what I get for being lazy…

Tracking and blocking BRW70188B

January 2, 2017

I’ve been monitoring wifi traffic on my network. I’ve seen a large amount sent up by one device, which was reported as starting with BR70188B (mac address 70:18:8b) with manufacturer HonHaiPr.

HonHaiPr is Hon Hai Precision Industry, which makes network devices. The one in question (with the name BRW70188Bxxyyzz) was from a Brother MFC-650DW that is on the network.

Now that I’ve identified the printer, what to do about it? It was spewing lots of uploaded data – perhaps just to the clients that printed from it, but I’m perhaps a little paranoid. (It seems strange that it’s uploading almost as much as gets downloaded to the printer, though.) So I decided to knock it off the Internet to see what happened.

First, I gave it a static IP address in my dhcpd.conf:

host mfc650dw {
    hardware ethernet 70:18:8B:xx:yy:zz;
    option host-name "mfc650dw";

Next, I updated it in DNS (db and db.rev files) just ’cause now that it’s static it’s handy to have a name to deal with.

Finally, I added a rule to my pf.conf:

block out log quick from to ! 192.168.1/24

Now if the printer’s trying to send data up to the Internet, it’s not going to make it through the firewall.

After I did all this, the printer wouldn’t work – Brother apparently stores the IP address but doesn’t refresh if it can’t find it. So I needed to download the Brother Network Connection Repair Tool to tell the Windows printer driver to look for the printer again. Sheesh.

Setting up a static IP for a Raspberry Pi over wifi using OpenBSD dhcpd

May 1, 2015

Like the rest of the world, I wanted to have a static IP for a Raspberry Pi that was on a wifi network. Like the rest of the world, I couldn’t figure out how to do it after three attempts. At that point, like the rest of the world I gave up and decided to make my DHCP server do the work instead of the Pi.

Here’s how I did it:

1. On the Pi, edit /etc/wpa_supplicant.conf and add:


2. Reboot and get an IP address through DHCP.

3. Confirm that I can see the world with the DHCP address.

4. ifconfig wlan0 and copy down the hardware Ethernet address for wlan0 (let’s pretend it was 00:11:22:33:44:56).

5. Go to the box running DHCP, and add a stanza inside my shared-network:

       host myserver {
               hardware ethernet 00:11:22:33:44:56;
               option host-name "myserver";

6. Kill and restart the DHCP daemon.

7. Reboot the pi and confirm it’s getting the right static IP address now.

Making the Netgear WGR614 a bridge

August 16, 2014

For the longest time, I’ve had a Netgear WGR614 acting as a NAT for my wifi traffic. That meant I had a separate network for wifi traffic, rather than sharing traffic with my wired network.

Eventually this lead to problems. Some phone apps want to search the network for printers or set top boxes, for instance – and because the wireless devices were on a different network, they’d never find the wired devices.

After a long time thinking about this, I decided to see what it would take to turn my wifi router into a bridge. Turns out the Netgear WGR614 is very nicely suited to that. All it takes is one plug change and a few settings changes, and now my wireless and wired traffic is all on the same IP address range.

I found a few useful posts for this:




Note that this assumes you’ve got something else on the network that’s going to serve IP addresses for you. If you don’t know, you probably shouldn’t do this.

Here’s how to do it:

  1. Unplug the Netgear WGR614 from everything except one laptop. Make sure the laptop is plugged into a regular port, not the WAN port.
  2. Hard-reset the Netgear WGR614 (push the button that’s inset next to the WAN port for 10 seconds).
  3. After the router reboots, connect to from the laptop. After a reset, the account is “admin” and the password is “password”.
  4. You’ll be asked if you want to step through the configuration. Select “No, I know what I’m doing”.
  5. First off, change that password. Choose the “Set Password” tab on the left and make it something better.
  6. Next, go into the Wireless Settings tab. Set the SSID, security to WPA2-PSK and passphrase for WPA2.
  7. If you know what channels other routers in your neighbourhood use, now is a good time to set the wifi channel as well.
  8. Go to the LAN Setup tab and unclick “Use Router as DHCP Server”.
  9. Next, on the LAN Setup tab set the IP address for the router to something in your static address range.
  10. Now unplug the laptop and plug what was the WAN uplink cable into a regular port (non-WAN) on the router.
  11. Unplug and re-plug the router.

Once you’ve done all that, your router will be acting as a bridge for traffic between the wifi and wired networks.

One warning: I originally didn’t hard-reset the router. This left it with an IP address of my internal wired network on the WAN port. Once I’d done that, I couldn’t connect to it over the LAN interface, since it saw that as an address conflict. So just hard-reset it.

Incidentally – this isn’t strictly a bridge, since the router has an IP address on the LAN. But it’s routing the packets from wifi to wired and back.

Changing MAC address on OpenBSD

December 6, 2012

A little while ago, I needed to change my MAC address on the OpenBSD firewall I’ve got running. (My ISP kept feeding me a bad IP address from an old lease and I wanted a new one.)

It’s easy to do this on OpenBSD:

ifconfig vr1 down
ifconfig vr1 lladdr 00:11:22:33:44:55
ifconfig vr1 up

The question is, where’s the right place to put this to make it permanent? A few web searches revealed that a bunch of people had modified /etc/netstart by putting the ifconfig vr1 lladdr line somewhere near the beginning. I’d rather not sully my pristine /etc scripts with changes if I don’t have to.

Linux has /etc/network/interfaces, and OpenBSD has /etc/hostname.if. I just changed my /etc/hostname.vr1 to:

dhcp lladdr 00:11:22:33:44:55

and I was requesting an IP address using my new MAC address.

Final cleanup for the ALIX firewall

July 6, 2012

Finally, there are a few things that I either forgot to do or that make life easier.

Setting up localtime
By defaut, /etc/localtime is set to Alberta, where OpenBSD has its home. I need to set it to somewhere closer.

rm /etc/localtime; ln -s /usr/share/zoneinfo/US/Mountain /etc/localtime

Now date shows the correct time.

I wrote a script to make the LEDs move back and forth. I start this at boot. (In an earlier version of the firewall, I edited /etc/rc to turn LEDs on when certain thresholds had been passed in the boot process. But now I don’t want to muck up /etc/rc so much.)

First of all, you need to allow the ports to be written before OpenBSD gets all secure on you. Edit /etc/rc.securelevel and add:

# Place local actions here.
echo -n 'enabling LED pins'
gpioctl -q /dev/gpio0 6 set out iout
gpioctl -q /dev/gpio0 25 set out iout
gpioctl -q /dev/gpio0 27 set out iout

I got these numbers from the Status LEDs section of the ALIX manual.

Then create /usr/local/bin/cylon:

#!/bin/ksh -

gpioctl -q /dev/gpio0 6 0
gpioctl -q /dev/gpio0 25 0
gpioctl -q /dev/gpio0 27 1

gpioctl -q /dev/gpio0 6 0
gpioctl -q /dev/gpio0 25 1
gpioctl -q /dev/gpio0 27 0

gpioctl -q /dev/gpio0 6 1
gpioctl -q /dev/gpio0 25 0
gpioctl -q /dev/gpio0 27 0

gpioctl -q /dev/gpio0 6 0
gpioctl -q /dev/gpio0 25 0
gpioctl -q /dev/gpio0 27 0

while [ true ] ; do
 sleep 1
 sleep 1
 sleep 1
 sleep 1

Finally, start it from /etc/rc.local:

# Add your local startup actions here.
echo -n 'cylon'
sh /usr/local/bin/cylon &

On reboot, yay, blinky! That at least tells you the kernel hasn’t crashed.

Reducing the mail
Because flashrd is really OpenBSD, it sends mail more suited to a server than a firewall with limited disk.

First thing I noticed:

Running security(8):

Checking special files and directories.
Output format is:
                criteria (shouldbe, reallyis)
        permissions (0644, 0755)

I fixed that with a chmod 0644 /etc/rc.conf.local. So now /usr/libexec/security shows no problems. Good.

Once that’s done, make things complain less:

crontab -uroot -e

and comment out:

#30     1       *       *       *       /bin/sh /etc/daily
#30     3       *       *       6       /bin/sh /etc/weekly

This prevents the daily and weekly reports, leaving just the monthly one.

Next, I noticed that sendmail gets run from root’s crontab, so it doesn’t need to run at boot:


sendmail_flags=NO       # "-L sm-mta -C/etc/mail/localhost.cf -bd -q30m"

That should keep the thing running a little longer without running out of disk. Actually, /var/mail is on the MFS, so it will keep it from running out of ramdisk.

(This post is part of Building an ALIX firewall)

Setting up BIND on the ALIX firewall

June 27, 2012

Setting up BIND is probably the part that took more thought than any other when building the firewall. This is not because of any particular technical challenges; rather, BIND is managed by a consortium and its doc is… voluminous.

In the end, I went with the default /var/named/etc/named.conf on the assumption that it would do the right thing. According to its comment, it does both “recursive and authoritative queries using one cache,” which is what I want.

There are four files that need to change:

  1. /etc/rc.conf
  2. /var/named/etc/named.conf
  3. /var/named/master/mydomain.net
  4. /var/name/master/mydomain.net.rev

The last two can be named anything, but I stuck with conventions as I saw them.

Unlike everything up to now, the BIND files live on /var/. In flashrd, /var gets unpacked at boot time into a RAM disk. So you need to save any changes you make somewhere else. Do not reboot until you’ve saved your changes! Ultimately, we’ll put these changes in /flash/var.tar so they get re-created when the device reboots.

To enable named, change:


I used the default named.conf, which is really just a copy of named-simple.conf.

I made one addition in the options section:

       forwarders {; };

This tells DNS to look for answers at the Google DNS server if it can’t find the answer on the local DNS server. (Actually, I put a few DNS servers that were specific to my ISP, but the Google server will work too.)

I also made a few changes near the end:

// Master zones
zone "mydomain.net" {
        type master;
        file "master/mydomain.net";

// Reverse mappings for mydomain.net domain
zone "150.168.192.in-addr.arpa" in {
     type master;
     file "master/mydomain.net.rev";

This tells named to look in /var/named/master/mydomain.net for mappings of mydomain.net, and to look in /var/named/master/mydomain.net.rev for mappings of 192.168.150.*.

Here’s my mydomain.net:

mydomain.net. IN SOA firewall.mydomain.net. myemail.yahoo.com. (
     1          ; Serial
     10800      ; Refresh after 3 hours
     3600       ; Retry after 1 hour
     604800     ; Expire after 1 week
     86400 )    ; Minimum TTL of 1 day

; Name Servers
mydomain.net.  IN NS   firewall.mydomain.net.

; Host addresses
localhost.mydomain.net.        IN A
firewall.mydomain.net.         IN A
firesign.mydomain.net.         IN A
frantics.mydomain.net.         IN A
bundolo.mydomain.net.          IN A

The first bit says my domain is called mydomain.net. I’ve published my email as myemail@yahoo.com (but note the dot instead of the at sign there).

The next bit is serial number / expiration times. You’re supposed to bump up the serial number every time you edit, but I usually just kill and restart named.

After that, I say that the firewall will be the nameserver for the domain.

Next is the interesting bit: the mapping of host names to host addresses. They must all end in . because BIND requires it. It’s very easy to miss a . in your config file and be confused about why things aren’t working.

In addition to DNS doing lookup for names, it usually also does lookup for IP addresses. This is what you get when you do nslookup, for instance. The reverse domain name file holds that:

150.168.192.in-addr.arpa. IN SOA firewall.mydomain.net. myemail.yahoo.com. (
     1          ; Serial
     10800      ; Refresh after 3 hours
     3600       ; Retry after 1 hour
     604800     ; Expire after 1 week
     86400 )    ; Minimum TTL of 1 day

; Name Servers
150.168.192.in-addr.arpa.       IN NS   firewall.mydomain.net.

; Addresses point to canonical name
;     IN PTR  firewall.mydomain.net.   IN PTR  firesign.mydomain.net.   IN PTR  frantics.mydomain.net.   IN PTR  bundolo.mydomain.net.

Once again, watch for . characters at the end of .arpa. and .net.

At this point, you can kill and restart named, then:

server localhost

You should see something like:

Server:         localhost

Name:   frantics.mydomain.net

The DHCP client overwrites /etc/resolv.conf, but then appends whatever/s in /etc/resolv.conf.tail to that. So let’s tell OpenBSD that Change /etc/resolv.conf to point to the running nameserver:

domain mydomain.net
search mydomain.net
lookup bind file

This sets up the firewall as the nameserver to look for, tells what my domain is, says to search foo.mydomain.net when looking for foo, and to look up via bind first and then /etc/hosts.

Now is a good time to change dhcpd.conf to point to your nameserver instead of someone else:

option domain-name-servers;

Save those changes
To save the changes that are in /var, use the following command:

tar cf /flash/var.tar -C /var .

Might as well save a copy somewhere else too:

tar cf /root/named.tar /var/named

Things are saved away as well as they’re going to be; time to reboot and hope you didn’t miss anything!

(This post is part of Building an ALIX firewall)

Setting up PF for the ALIX firewall

June 26, 2012

The next step on the firewall is to set up the packet filter PF. Most of what I do here comes from the OpenBSD PF FAQ.

Setting up PF itself
The file to edit is /etc/pf.conf. Here’s mine:

# macros

# FTP Proxy rules
anchor "ftp-proxy/*"
pass in quick on $int_if inet proto tcp to any port ftp \
    divert-to port 8021

# options
set block-policy return
set loginterface $ext_if
set skip on lo

# match rules
match out on egress inet from !(egress) to any nat-to (egress:0)

# filter rules
block in log
pass out quick
antispoof quick for { lo $int_if }
# uncomment this to respond to pings
# pass in inet proto icmp all icmp-type echoreq
pass in on $int_if

It’s basically the example config file for home or small office, with a couple of changes:

  1. I define an int_if and ext_if for internal network and external network
  2. I don’t have any port forwarding from outside through to the inside network except ftp-proxy
  3. I block all incoming ICMP traffic (which is broken according to spec, but might keep me safer from denial of service attacks).
  4. I keep port 22 closed on the firewall machine.

Basically, I present a blank wall to the Internet. Traffic I initiate can get out, but outside doesn’t get in except via ftp-proxy.

One thing to note is that if you mess up pf, you can get into a state where you can’t talk to your ALIX over the network. So make sure you have a serial port handy to talk to it. I’d recommend making changes to pf.conf over serial, and then testing with the network.

To test, run:

pfctl -F all
pfctl -f /etc/pf.conf

The first command flushes whatever existing PF config is there; the second command loads your new pf config.

Next, hook up a machine to the switch that’s connected to the LAN side of the firewall, and see if you have Internet. If you do, life is good!

Getting FTP running
You might have noticed I use ftp-proxy in my pf.conf. That’s a daemon that needs to be enabled in /etc/rc.conf:


According to the PF FAQ, you can run ftp-proxy to get the daemon going, but I rebooted instead after changing /etc/rc.conf. Also according to the FAQ, some (fussy) clients may need “-r” on ftpproxy_flags.

Blocking IP addresses using PF
I haven’t done this before, but I wanted to try blocking ad servers by IP address using PF. Some instructions are here.

My list of IP addresses came from the excellent pgl.yoyo.org/adservers site. I picked “list ad server IP addresses” as plain HTML text, checked the “view list as plain text” button, and pressed “go”. This gave me a URL that I copied.

I wanted a semi-automatic way to download this list. Luckily, OpenBSD’s ftp is a lot more than plain FTP. You can use it instead of wget/curl/etc. Here’s the command I used:

ftp -o /etc/pf.blocked.ip.conf "http://pgl.yoyo.org\

Then I updated my pf.conf to account for that:

# macros

# Table of IP addresses to block
table <blockedips> persist file "/etc/pf.blocked.ip.conf"

# FTP Proxy rules
anchor "ftp-proxy/*"
pass in quick on $int_if inet proto tcp to any port ftp \
    divert-to port 8021

# options

set block-policy return
set loginterface $ext_if
set skip on lo

# match rules

match out on egress inet from !(egress) to any nat-to (egress:0)

# filter rules

# These two rules block traffic from blacklisted IP addresses
block drop in quick on $ext_if from <blockedips> to any
block return out quick from any to <blockedips>

block in log
pass out quick

antispoof quick for { lo $int_if }

# pass in inet proto icmp all icmp-type $icmp_types

pass in on $int_if

I’m not sure if this strategy will work long term. Previously I excluded ad servers in named instead. Excluding by IP address seems to take less RAM (I’ve got about 163M free of my 256M RAM with this table loaded) and has the advantage of blocking sneaky servers that use IP address URLs. The downside is that if another server uses the same IP address, I won’t get the content, and I have no real way to unblock by name if I need to.

At any rate, to update, I just need to do the ftp command again, and then:

pfctl -t blockedips -T replace -f /etc/pf.blocked.ip.conf

(This post is part of Building an ALIX firewall)

Setting up networking for the ALIX firewall

June 24, 2012

The next step in building an ALIX firewall is to set up networking.

Setting the hostname

  1. Edit the file /etc/myname to be the hostname you want (don’t forget to rw first if you need to).
  2. Run:

    hostname `cat /etc/myname`

    to set the hostname in lieu of rebooting.

Figuring out which port is which
On my ALIX, Ethernet port vr1 is the port nearest to the
serial port and vr0 is the one nearest to the power cable. I figured this out by plugging one port into the network and running ifconfig. In my case I saw:

vr1: flags=8802 mtu 1500
        lladdr 00:0d:ba:36:d9:30
        priority: 0
        media: Ethernet autoselect (none)
        status: active

whereas vr0 had status: no carrier. That told me that vr1 was the one on the network. I labelled the ports so I wouldn’t forget. (Since my plan is to have a firewall with one port for the internal LAN and another for the world, I used labels vr0:lan and vr1:world.)

Setting up the DHCP client on vr1
My ISP assigns me an IP address using DHCP. In the older flashdist, you had to edit /etc/rc to start up dhclient to get this address. With flashrd, it’s easier once again:
echo dhcp > /etc/hostname.vr1
sh /etc/netstart

At this point the ALIX will go to your local network and request an IP address via dhclient. Hopefully you have a DHCP server somewhere on your network; otherwise you’ll need to read Section 6 of the OpenBSD FAQ.

Setting up the LAN interface
I decided that I wouldn’t mess around with IPv6 just yet… I want to set up a NAT firewall using IPv4. To start with, I had to pick an IP address for my internal network. I’m going to use my ALIX box for DHCP, name resolution, and as a gateway. (Yes, I know this is bad practice… but I’m on a limited budget!)

I picked address 192.168.150.* for my network. This means my firewall will be, and I’ll use that as the gateway address of other machines which are its DHCP clients.

echo inet NONE > /etc/hostname.vr0
sh /etc/netstart

Run the dhcpd server
So that the firewall can serve IP addresses, it needs to have dhcpd enabled. The right place to do this is in a section of rc.conf.local, but I got lazy and edited it in /etc/rc.conf. If I had to do this over, I’d use /etc/rc.conf.local. The code I changed was:


Next we need to tell it what the subnet is that it will serve DHCP addresses to. This is defined in /etc/dhcpd.conf:

option domain-name "mydomain.net";
option domain-name-servers;

subnet netmask {
option routers;


# host static-client {
# hardware ethernet 22:33:44:55:66:77;
# fixed-address;
# }

# host pxe-client {
# hardware ethernet 02:03:04:05:06:07;
# filename "pxeboot";
# next-server;
# }

In my case for absolutely arbitrary reasons, I said to serve from to I left the pxe-client and static-client things in case I needed them later.

Also note that right now I’m using Google’s as the DNS server. I could have used my ISP’s instead – either way, it’s going to change once I get BIND running on the firewall.

Add myself to hosts
This is a good time to add myself to the /etc/hosts file (both under the short name and fully-qualified domain name): myname myname.mydomain.net

Enabling port forwarding
Next we need to allow the firewall to forward IPv4 traffic. To do this, edit /etc/sysctl.conf:


Update the time from the network
Since the ALIX doesn’t have a real time clock that stores the time, we need to update it from the network every time we reboot. This is in /etc/rc.conf:


The -s says “update the time now to the server time and don’t try to adjust it slowly.” That’s the right thing to do when the box thinks the time is way in the past.

At this point, I figured it was time to reboot the device and see if everything came up as expected.

/sbin/shutdown -r now

Now plug a switch into the vr0:lan port, a computer into the switch, and see if you can get an IP address. You’re not doing enough yet to have an Internet connection, but ipconfig /all on a Windows laptop should show a correct IPv4 address, subnet mask, gateway, dhcp server and DNS server. Groovy, you’ve got a network!

(This post is part of Building an ALIX firewall)

Getting OpenBSD 5.1 on the ALIX firewall

June 20, 2012

Getting OpenBSD on the ALIX used to be quite an effort. You had to figure out what your CF card looked like, enter the right drive parameters, and hope. Now it’s dead easy:

  1. Download the flashrd binary image. I used flashimg.i386.wd0.com0-20120531.gz, which is root wd0, com0 38400 console. This matches the Alix BIOS default, which also spits out 38400 serial.
  2. Unzip the image with gzip -d
  3. Write the image to the CF card. I have Cygwin installed, so I was able to use dd. Since I’m running this on Windows 7, I had to open my Cygwin shell as Administrator. The command I used:
    dd if=flashdist.i386.wd0.com0-20120531 of=/dev/sdd bs=128k

    I was pleasantly surprised that dd worked. (I found the device by doing sfdisk -l /dev/sda, then sdb, then sdc, until I found a partition table that looked like my 4 GB flash drive.) I picked 128k as the block size because the image was evenly divisible by that. I don’t know if it makes a difference, but I figured why risk it.

  4. Next I hooked up a DB9 F/F mini null modem to my PC serial port, connected that to the Alix serial port, ran hypertrm (which I had to get from an earlier Windows release) and was talking to OpenBSD. Root password was “root” (no quotes).
  5. At this point I reset the password:
    passwd root

    rw is the flashrd way to say “mount the file system read/write”, and ro says “mount the file system read-only”. flashrd boots up read-only (which saves wear on the flash card) so you need to set it to read/write if you want to do pretty much anything.

That’s all there is to it!

(This post is part of Building an ALIX firewall)