Unbricking My TRENDnet TEW-812DRU Wireless Router

Upgrading my TRENDnet TEW-812DRU v2 router with DD-WRT firmware sometimes goes smoothly, and sometimes not. Usually if the upgrade fails on the first try, I can just unplug the router, wait 10 seconds, plug it in again, wait for the web UI to come up again, re-upload the firmware (and wait), and the upgrade will work on the second try.

But sometimes the router won't boot up correctly. All the blinking lights come on as normal, but it doesn't do any actual routing — or provide any DHCP services, which makes the router look bricked, even for devices connected to it physically with an ethernet cord.

But fortunately, it's not actually bricked. The router still grabs its usual local address (192.168.1.1, if you haven't configured it to be something else), and runs its nifty "TRENDnet - Emergency miniWeb Server" on port 80. The emergency page served up allows you to upload a new firmware image — and every time (so far) that I've gotten to that page, I've simply been able to upload the firmware image I've been trying to install (ie the latest trendnet-812dru-webflash.bin file from DD-WRT); and the router accepts it, installs it, and reboots itself, and everything is back to normal and happy in a few minutes.

The trick to accessing the router when its usual networking services are down is to 1) connect a computer to the router via wired ethernet connection (if you don't have one set up that way already), and 2) configure that computer with a static IP on the router's local subnet.

Since I'm running my router at 192.168.1.1, I just set the computer's static IP address to 192.168.1.10, and point its browser to http://192.168.1.1. The emergency web server seems to listen only for a minute or two after booting, though, and then goes way; so if the emergency page won't load, I unplug the router, wait 10 seconds, and plug it in again.

And since that wired computer is running Ubuntu 16.04 (with a wired interface named enp1s2f3 — look it up via a command like ifconfig or ip address etc), I set its static IP address by adding the following to my /etc/network/interfaces:

iface enp1s2f3 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1

And then run sudo service network-manager stop to make NetworkManager cool its butt, and sudo service networking restart to use the static IP.

DD-WRT Firmware for TRENDnet TEW-812DRU Wireless Router

I'm lucky enough to get gigabit internet access at home, from Wave Broadband, with which I'm quite happy. And I don't even need a modem — with my apartment building, I can just jack directly into the Ethernet port in my living room wall. I originally got a Kasada router, but its firmware hasn't been updated in a couple years, so I decided to get a new router that I knew would be updateable with the Free Software DD-WRT firmware.

I got a TRENDnet TEW-812DRU v2, which although it's like 5 years old, is as fast as I need (supporting gigabit ethernet, plus 1.3 Gbps 802.11ac and 450 Mbps 802.11n wireless on separate 5 GHz and 2.4 GHz channels) — and a quarter of the price of comparable new routers. And, importantly, it looked like it was well supported by DD-WRT.

And it did turn out to be well supported by DD-WRT. Having first read through all the forum posts about the TEW-812DRU, I found that, unlike some other routers, you don't need anything special to use DD-WRT on the TEW-812DRU — just upload the new firmware to the router through its web UI and let it do its thing, no tricks needed.

So the first thing I did when I plugged in the router was login to its web UI and flash it with the "Open Source" firmware I downloaded from the TRENDnet TEW-812DRU downloads page. That turned out to be DD-WRT v24-sp2 r23194, compiled on 12/21/2013. I was happy it worked, but that firmware was just way too old.

So next I looked up the TEW-812DRU in the DD-WRT router database, and that prompted me to download something labeled DD-WRT v24-sp2 r23804 (but turned out actually to be r23808), compiled on 3/27/2014. I flashed that firmware through the web UI — but when the router rebooted, it presented me with an "Emergency Web Server" page. I went to look up what that meant via a working internet connection, and when I checked on the router again, the Emergency Web Server page had been replaced with the working DD-WRT web UI. I figure it must have just taken a little extra while for the router to boot everything up, no big deal.

But that firmware was also way older than I was hoping for, so I went searching through the downloads directory of the DD-WRT site — and finally found the latest version of the TEW-812DRU firmware here:

https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2018/07-16-2018-r36330/trendnet-812DRUv2/

I flashed that firmware through the router's web UI, and was very pleased to see the router reboot with no issues at all, happily running DD-WRT v3.0-r36330 mini — compiled just a few days ago on 7/16/2018. Finally, peace of mind that no bears, pandas, or kittens will be making themselves at home inside my router!

Skip the Pre-Commit Hook on Git Rebase or Merge

When you want to skip the git pre-commit hook for a single commit, it's easy — you just add the --no-verify flag (or -n for short) to the git commit command:

git commit --no-verify

But to skip multiple commits executed by another git command, like rebase or merge, the --no-verify flag doesn't work. The best way I've found to skip the pre-commit hook in that case is to code the hook to check for a custom environment variable (I like to use NO_VERIFY), and skip the pre-commit logic if it's not empty. For example, the pre-commit.sh script in my Google Java Format Pre-Commit Hook has a block of code like this at the top of the file, which skips the main functionality of the pre-commit hook if the NO_VERIFY environment variable has been set to anything other than an empty string:

if [ "$NO_VERIFY" ]; then
    echo 'pre-commit hook skipped' 1>&2
    exit 0
fi

So when I want to skip that pre-commit hook when doing a complicated rebase or merge, I simply run the following commands in the same shell:

export NO_VERIFY=1
git rebase -i master # or `git merge some-branch` or whatever
export NO_VERIFY=

Google Java Format Pre-Commit Hook

My team decided to standardize on the Google Java Style Guide for formatting Java code; and not finding a drop-in git pre-commit hook for the Google Java Format library, I whipped one up and pushed it to GitHub as the Google Java Format Pre-Commit Hook project.

To use it, clone the repo, and link its pre-commit.sh script as the .git/hooks/pre-commit script in whatever project you want to use it with (or call it from your existing .git/hooks/pre-commit script, if you already have one). The script automatically downloads the Google Java Format library, and runs it over all staged .java files whenever you make a commit (and fails the commit if there are any formatting issues it can't automatically clean up).

You can skip the hook by including the --no-verify flag on an individual commit, or by setting the NO_VERIFY environment variable in your shell to be not empty prior to running a sequence of commits (like a merge or rebase). Full details for install and usage are in the project README.

OpenDKIM Key Retrieval Failed

I set up OpenDKIM on my mailserver years ago, but while I got it working for signing just fine, I could never get it working for verification. Whenever I'd receive a message signed with DKIM, I'd see an error message like this in my mailserver logs:

May  4 01:20:20 mail opendkim[24874]: 7EE5982132: key retrieval failed (s=20161025, d=gmail.com): '20161025._domainkey.gmail.com' query timed out

When I tried dig on the DNS record listed in the logs, however, I was able to retrieve it just fine:

dig TXT 20161025._domainkey.gmail.com

Recently I set aside some time to "dig" into it further. I found I could use the opendkim-testkey command to at least reproduce the issue (instead of having to keep sending test emails from other accounts to myself). For example, the following command tries to retrieve the DKIM key from the 20161025._domainkey.gmail.com DNS TXT record (20161025 is the DKIM selector and gmail.com is the signing domain):

opendkim-testkey -s 20161025 -d gmail.com

This command gave me the same "query timed out" error message that I saw in my logs. Through a lot of trial and error, I figured out that I could avoid the error by setting the Nameservers property in my /etc/opendkim.conf file to an external DNS server (any external one will do), and restarting the OpenDKIM daemon. I've been running my mailserver on an Ubuntu EC2 instance, and apparently OpenDKIM does not like something about the combination of the Ubuntu DNS resolver and the internal EC2 DNS servers.

So, I added this line to my /etc/opendkim.conf, restarted the OpenDKIM daemon, and now I no longer see the "key retrieval failed" error message in my logs (instead I get a nice Authentication-Results header added by OpenDKIM to my incoming mail)!:

Nameservers 1.1.1.1

1.1.1.1 is Cloudflare's DNS servers — but any external DNS servers should work. One thing to keep in mind with using external DNS servers is that if your network has a stateless firewall, you need to allow inbound access to UDP in the "ephemeral" port range. If you're using EC2's Network ACLs (and not just using the defaults), this means adding a rule like the following to the ACL for the subnet in which your mailserver lives (32768-61000 is Ubuntu's ephemeral port range):

Rule #: [any number lower than your DENY rules]
Type: Custom UDP Rule
Protocol: UDP (17)
Port Range: 32768-61000
Source: 1.1.1.1/32
Allow/Deny: ALLOW