The router provides typical stuff:

  • routing between the hackspace's internal network and our Internet provider
    • including capturing logs on networking issues we're having with them
  • the “hackspace” WiFi access point
  • DHCP
  • DNS (internal and forwarding)
  • NTP
  • a basic firewall, likely redundant, allowing all outbound/responses inbound
  • dynamic DNS ( resolves to our current PoP)
  • some basic statistics on traffic and upstream connectivity

It also reports its ability to reach the 'net, and the presence of any associated WiFi clients, to Anyone in.


The BT router is fairly new but has proven stable over its few weeks. Any problems so far have been with our Internet provider. Workarounds are in progress, but in the meantime interfering with the router only interrupts its gathering of useful logs, making things worse; you're much more likely to regain connectivity by:

  • temporarily using the BVStudio access points instead of hackspace, if you don't need wired access nor access to units on hackspace
  • power-cycling the mesh unit if you do:
    • unplug the upper, currently grey cable for a few seconds, then plug it back in
    • you'll know you picked the wrong cable if the lights stay on while it's unplugged

After two or three minutes, if that hasn't restore wired/hackspace 'net access and you have good reason to suspect the router itself has hung (e.g. you can't see/get on hackspace at all, or you can get on but the router won't give you its web page), there are two things to try:

  • You can cleanly reboot the router (safer than power-cycling) by holding down its top left (restart) button for a long time (15+ seconds). Let go when the strip light starts blinking.
  • As a last resort, you can replace the BT router with the older, D-Link DIR-615 one. This will break dynamic DNS, anyonein updates, statistics and diagnostic logging, and may throw some more fragile clients off the network entirely.
    • Disconnect the BT router from the “NEW1” unit above (at the “NEW1” end), and unplug the router's power supply.
    • Find the D-Link. It lives in the “networking” box on the shelves near the front door in G11, with its power supply. It's black and has a Do Not Hack sticker.
    • Connect its “Internet” port to the “NEW1” unit.
    • Connect any LAN port on it to the Dell switch.
    • Plug it in.


The current hardware is a BT HomeHub 5A (BTHH5; OpenWrt page, wikidevi page) running OpenWrt “Designated Driver” trunk from 2016-03 (built by Zak).

There's a serial header fitted to the front. Layout is compatible with FTDI's 6-pin serial↔USB cables, with the leftmost pin being ground.

A header for a jumper has been fitted on the PCB to provide an easy way to ground bootsel2, needed for reflashing over serial.


Consult the router if in doubt, but currently:

  • router is
  • 24h dynamic DHCP leases:
    • on and above for non-permanent hosts
    • on and above for permanent hosts
    • currently IPv6 leases are granted too but we have no upstream IPv6 route
  • DHCP designates the router as the default route and the local DNS server, passing non-local DNS requests to OpenDNS/Google
  • VLAN 1 is a bridge over ports labelled 1,2,3 and the two WiFi radios
  • VLAN 2 contains just the port labelled 4 and is the uplink to our Internet provider
  • the red port labelled WAN is unused (see Remaining issues)

If you could administrate the DIR-615 before, you can administrate the BTHH5; just visit https://brishackrout/ from a wired or hackspace WiFi connection. Username “root” and the same password as the DIR-615's configuration interface had. It has a self-signed certificate, so your browser will probably moan the first time.

For maintenance of router-related functions under OpenWrt, while you can edit the underlying config files by the routes below, it's almost always best to use the web interface. Even its base feature set is pretty featureful and flexible compared to consumer firmware, and many more modules are available than are currently installed. As with most sharp, effective tools, it takes a little practice to get the best out of it. Under OpenWrt config files are fine for backup or advanced configurations, but edits can easily get blown away by web interface changes, and are invisible (and thus potentially a source of confusion) to a user of just the web interface.

Should you need to edit config files via a shell, it might be useful to know that /etc is partially under git control (hopefully any files that have changed or been added over and above what's provided by the OpenWrt image). Also note that it's not kind to the onboard flash to make frequent writes. If you exhaust its write lifetime, the unit becomes a brick. So if data doesn't need to persist across reboots, put it /tmp or another tmpfs. If data must persist the unit has a USB stick (small, and used for other things too!), so if logging or packages not designed for OpenWrt are going to run on the unit then it's better if they put data there.

SSH access from within the space: credentials same as web access above. RSA pubkey fingerprint is 2b:a1:9e:bb:7e:a9:ae:21:e7:7f:27:db:ea:cd:e0:d0.

You can also get a root console via a serial connection through the header in the front of the unit. Login is automatic; just hit Enter.

You can also SSH in via Tor, but if that's suitable for you then you'll probably be fine with extracting the necessary details by logging in locally first. Tor is temporary and treacle-slow, used to escape NAT and to work around our dynamic PoP until we can solve those problems another way.

Lights and Buttons

Photo of lights

Photo of back and buttons

OpenWrt uses these as follows:

  • status (horizontal striplight) flashes green in early boot, flashes blue in late boot, solid blue in healthy operation (red, orange unused)
  • wireless flashes blue with wireless activity, solid blue with wireless idle (red, orange unused)
  • broadband light currently unused (red, orange, blue?)
  • restart switch currently does reboot the router if held for 15+ seconds
  • wireless/WPS button currently unused
  • reset (paper clip) button currently unused

Remaining issues

  • The red WAN port on the BTHH5 is intuitively the one we should be using for our backhaul to Bristol Wireless, but at install time its idiosyncrasies weren't understood, and there hasn't been a good opportunity to fix it since then. Seems like OpenWrt “Designated Driver” trunk configures the internal switch strangely, and the port has to be in a VLAN despite having a dedicated link to the CPU. Probably fine to switch to WAN-as-eth1.N, just waiting for a good moment to try.
    • tcpdump and various stats generation will have to update to honour the change
  • If we can solve problems with our Bristol Wireless uplink, network layout may have to change to accommodate.
  • For SSH, a VPN with a firewall hole would be much more responsive than Tor.
  • There are still remnants of the wires soldered straight to the board before we got the PSU, which must be removed; just waiting for a good moment.
  • Label it with the same QR code format used elsewhere, mentioning that there are troubleshooting tips and details on this wiki page.
  • Buttons should be configured up to save/export all log buffers to the USB stick, since people will mash them with abandon anyway when they have issues we'd like to diagnose.
  • Make sure reset (paper clip) button is unused, because getting wiped back to defaults would be disruptive (serial flashing is much less prone to unwitting destruction).
  • USB stick should be moved inside the case if possible, so that it's harder to borrow.
  • Check we're declaring our NTP service in our DHCP leases to clients.
    • Does LuCI let us pass raw options to dnsmasq? Neater than hiding it in the config files. Would be handy for policy routing of VPN volunteers too.
  • Gaffa the D-Link's PSU to it so they don't get separated.
  • Finish the problem report exporter (see plans).
    • should probably add Tor log and DHCP leases to stuff preserved
  • Monitoring structure from plans.
  • collectd ping didn't come up by itself (or died?) at the last reboot; needs investigation
  • Better timekeeping across reboots: make sysfixtime check a file on the USB, touched regularly with cron job
  • Give fallback router a do-not-hack.
  • Stronger password, and/or use separate SSHd instances/policies for intra/extra-hackspace access

Previous Hardware

The BT HomeHub 5A replaced a D-Link DIR-615 on 2016-03-31, the motivation being:

  • better reliability; the DIR-615 appearing to be struggling; glitchy WiFi and sometimes failing to respond to requests to its own web interface even on a wired connection
  • better diagnostics; when there are problems it's hard to pin them down to our router/to Bristol Wireless/to other equipment without tooling on the router, which is poor on the DIR-615
  • better hackability; things like data logging and scheduled jobs (which the DIR-615 stock firmware doesn't allow) could be made easier by having a fully featured, low-power, always-on, hackspace-owned Linux box available
  • better support; vendor support for consumer routers is usually somewhere between short-lived and non-existent and although the OpenWrt project makes no guarantees at all, historically it's much better with security patches and forum support

The DIR-615 is still there and still configured, so can be dropped back into service should the BTHH5 misbehave in the near term, as per Troubleshooting above. It could run OpenWrt for support/security, but only a pretty ancient version and probably not the web interface, and would leave no room for either hacks or diagnostic tooling.

  • archive/router
  • Last modified: 3 years ago
  • by