One of the problems plaguing our technology-biased society is that electronics have become disposable. We are at a point that anyone who has a smartphone that is more than a year or two old is viewed poorly in certain circles. I do not run with that crowd.

You may not be aware that the Nexus 4 is a wonderful Android phone which was released less than 5 years ago. It is available with a still-impressive 16GB base, has an 8MP camera on the rear, and a 1280×768px screen.

You can find them virtually anywhere from prices of $40 to $80, depending on your luck and how scuffed they might be, partially in thanks to Google no longer providing an “in house” Android software revision after 5.1.1.

Thanks to the Android core being open sourced, there are Developers and Designers keeping this still-useful phone alive.

My favorite community-built ROM, Pure Nexus, has an unofficial port of Android 7.1.1, with security patches to-date. This brings this phone nearly to the standards of the latest and greatest- at a fraction of the cost.

I’ll be the first to tell you that I’m a big fan of the Open Source movement- I’ve built a career out of supporting “free” software. For a brief flash in the pan of the late 90s and early 2000s, most technology based corporations saw the possible future of Linux, and embraced it wholly. It’s not quite the same today..

What’s my point? Some corporations have assisted Linux development by open sourcing specifications and code samples for kernel and driver writers to add support the product with Linux. Others have offered no assistance at all (requiring a “clean-room” reverse engineering method for support, requiring a lot time and dedication), and yet others have “sparingly” supported Linux, by making their own code and releasing it pre-built to be linked to, uploaded, or otherwise sent to the device.

I am speaking of the infamous “Binary Blobs”. Committing a blob is premature obsolescence.

The first time I ran into this design was when I was stuck with an ATI video card, which forced me to use an ATI build of X11 binary so I could get my video above 800×600, and a half decent rescan rate.

This design is problematic. In the case of my video card, it just won’t work properly anymore (such as evidenced by these instructions to get “blobby” builds of X11 to work with recent versions of Debian). These old, unsupported bits of software are an enormous security risk, as they are no longer updated, supported, and won’t work well (if at all) with recent distributions.

Intel has been guilty of the same- notably with their wireless devices in the past, and formerly, their onboard video. If I had to point a finger at any specific piece of hardware which is overwrought with blobs, it would be wireless devices.

OpenWRT, and LEDE have their hands tied for new device support because of these binary blobs (DD-WRT has no problem blindly throwing blobs at devices, which is why it is so popular, and supports so many more devices).

OpenWRT-cum-LEDE have decided they’d rather have proper support for devices, so they can integrate it in their current and future builds. LEDE is currently based on a recent 4.x kernel, whereas many RealTek, MediaTek, and RALink device blobs were written for (and supported by) Linux 2.6.x to 3.x. Quite a bit has changed under the hood since then. Developers are forced to work around these old designs whenever possible, which aren’t often capable of supporting recent enhancements and security implementations.

When I’m looking to purchase hardware, if I find these blobs available, I’m just as likely to pass on the device whenever possible. I suggest everyone do the same- and support corporations that support our hardware without hindering the device with ineffectual commitments.

I don’t really have much of interest to share at the moment- we’ve got at least 8” of fresh powder outside, so no work has commenced on the various car projects this weekend.

I’ve been following DragonFlyBSD from the sidelines for nearly a decade. It’s a fork of FreeBSD 4, when Matt Dillon decided he didn’t like where things were moving.

His HAMMER filesystem is intruging, and I’ve been looking for an excuse to play with it for awhile- but until recently I haven’t had access to hardware worthy of this hungry filesystem.

I was able to get a promo 2TB drive with a lower-end colo, and have been using it as my offsite non-cold-storage backup. So far, it’s been working great- I rebooted it once in the middle of a larger operation, and it recovered quite nicely. I don’t know if I’d use it for anything super-important, since there aren’t many tools for recovery should an actual disaster occur- but for my silly little toys, it’s more than sufficient.

I promised you pork. It’s in your clam chowder. Enjoy!

Until the last decade, it was very common to have “one task per system”, or, when running on a shoestring, “a few tasks”, such as the case of a software firewall which also worked as a mail transport agent.

Thanks to the magic of hardware and operating system assisted virtualization, we no longer have to directly emulate a complete machine. We can literally take a system and carve it into several smaller slices, each performing it’s own isolated task.

For instance: This webserver running my website isn’t only running a handful of different websites- it has a “heartbeat” monitor system watching my other personal machines that are on the internet, and will alert me to any issue, and several other projects at any one time.

Linux is one of the top KVM virtualization hosts (along with SmartOS and Hyper-V), which allows you to run completely different operating systems beneath it. I like to run my nameservers on OpenBSD as it’s very lean, and it’s PF implementation runs circles around iptables. I now accomplish this utilizing KVM.

Nameservers are a special sort of service- it commonly uses UDP (although TCP is supported), which means that if your machine isn’t fast enough, the client will just go to another one down the list and ask it where to find what it’s looking for. This is a good example where you need to tune your firewall/host rules to keep things fast.

I run my services as NAT KVMs, rather than a bridged MAC address IP, as it keeps all services off of the internet, except those I wish to expose. This adds a bit of trivial overhead to forward the DNS requests on port 53 via TCP/UDP to the client. This can be accomplished with rules similar to the following (showing separately to illustrate what each does):

The following accepts traffic on the bridge device for both TCP and UDP and forwards it to the NAT host located at 192.168.0.100:

/sbin/iptables -A PREROUTING -t nat -i br0 -p tcp --dport 53 \
 -j DNAT --to 192.168.0.100:53
/sbin/iptables -A PREROUTING -t nat -i br0 -p udp --dport 53 \
-j DNAT --to 192.168.0.100:53

This just makes sure that data that went to the NAT host makes it back out:

/sbin/iptables -A FORWARD -p tcp -d 192.168.0.100 \
--dport 53 -j ACCEPT
/sbin/iptables -A FORWARD -p udp -d 192.168.0.100 \
--dport 53 -j ACCEPT

Now, this is fine, but this traffic can actually hit iptables TWICE. Packets on the bridge first hits iptables’ INPUT, then a second time after it sees that the destination is a local virtual MAC. So, I’ve setup this rule so it only goes through once. Keep in mind that action verbs for broute are inappropriately named (DROP means that the frame has to be routed, ACCEPT means that this frame has to be bridged):

/sbin/ebtables -t broute -A BROUTING -d the:bridge:mac:addy:goes:here \
-j redirect --redirect-target DROP

Note that I have not specified a protocol, as I only use ipv4/ipv6 on this machine. This has removed in-kernel time for manipulating this data, which is pretty important if you have a busy nameserver (which mine isn’t).

If you aren’t familiar with LEDE, don’t feel alone. It’s an embedded Linux based upon OpenWRT’s foundations.

I’ve been a fan of OpenWRT for years- it follows the Debian “Unencumbered” design (which is why it supports less devices than DD-WRT or Tomato), and leaves it up to the administrator of the device to configure it as necessary, rather than throwing in many unnecessary features or other assorted bloat.

I opted to try it on the most “baseline” system available, my ancient Airlink 101 AR-670W. This base model router has 4MB flash, and 32MB RAM, which was awesome a decade ago- not so much now.

The interface for LEDE is familiar for any OpenWRT users, and LuCI is essentially unchanged to the naked eye.

It uses a Linux 4.5.x kernel base, and as such does make the old 280Mhz CPU a little slower to start, and does have a bit more overhead. However, the problem I have with it is that it:

♦ Is not compatible with OpenWRT configuations, but blindly accepts and installs them

Granted, there should be some differences moving forward, but it will still accept a standard OpenWRT configuration backup, and obliterate itself with two clicks, requiring a config rebuild. I tried this after it pulled the next stunt on me- just to see what it would do.

♦ Various new driver/configuration issues exist

With OpenWRT Chaos Calmer (15.05.1), this machine works perfectly, allowing me to set my own MAC addresses for any physical interface. Under LEDE 17.01, it accepts the data, but continues to send the hardware MAC address- which annoyed my provider’s DHCP Radius with it’s constant requests for a couple minutes’ time, prompting them to null route me for a couple hours while I got to enjoy dealing with it.

I like that it’s a step forward with a newer code base. Hopefully in a few releases, it’ll be a worthy adversary to Tomato and DD-WRT.