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.

It was time to renew several certificates, and I noticed that Lets Encrypt’ new certbot (as of 0.10 or 0.11) was issuing single certificates for zones grouped together, with the Alt Name set for the other DNS entries for zones sharing a single IP.

What does this mean in English? Think of an SNI SSL setup “virtual host” working like a party line (if you’re old enough to remember what those are). Everyone gets a different “ring”, and picks up when appropriate. Well, since they’re all on the same line, Lets Encrypt (LE) now sticks them all on the same certificate.

While this likely cleans a few things up on their end- having possibly only one certificate for the entire set of hosts- you may not always want that. In fact it’s quite unlikely that you do.

For instance: I run several personal, business, and other’s domains on this colocated machine. Several are “vanity” domains, and have no place being seen when someone clicks “View Certificate” on a business site. “saab.party” is cute (at least I think so), but doesn’t need to be there, just because it’s on the same machine.

A counterargument might be “Don’t use LE for business”, but for smaller businesses- it makes sense if you are using it only for web security, and not for purchasing or selling items. Many smaller business are also configured as VirtualHosts, rather than having their own machine, or even their own IP. It just isn’t part of their actual business- which can be hard to remember for those of us who live vicariously through the internet.

For now, I’m going to group my LE update and new requests separately for (www.?)domain.tld groups, the way it used to work.

I figure I might as well follow up on yesterdays’ post:

  • Writing Tech 2 binaries onto a PCMCIA card is as simple as ‘dd’.

All you need to do is load Linux on a machine with a supported PCMCIA cardbus interface, load drivers, and write the image to the drive’s /dev/ entry using ‘dd’.

I used conv=dsync just to be safe- but it worked perfectly, which is more than I can say than how I would feel about shelling out hundreds of dollars to do the same under Windows.

I was able to get data from the Impala (4th digit of VIN is production series, or, ‘W’ in this case), and found that the front passenger speed sensor is not reporting. Time to check the harness and sensor!

The local pub has a $2 Taco Tuesday special- Tacos are $2, and Burgers are $2 off. It’s become a bit of a weakly followed tradition in our household. As usual, they were delicious, even a bit overloaded. I certainly wouldn’t have ordered two if I had known.

I’ve got the battery installed in the Impala, which is running perfectly- but it is still throwing an ABS light. I have owned a Tech 2 for use with my SAABs, and I have a secondary GM card which is semi-generic for all GMs through 2010ish- which I had never used.

I tried to use it today, and no go- it’s not formatted properly. The Tech 2 hangs solid after downloading it, so that just doesn’t do.

The GM image is a single binary blob, and the Tech 2 only works with linear memory, so I’m going to boot from a Puppy/DSL USB drive and DD the image directly to the flash device.

It’s about 20 degrees out and dark, so I won’t be testing anything until tomorrow.

As someone who has been in charge of not only managing equipment, but specifications, and design- it’s just good sense to not always go for the cheapest product. Sometimes it works well, and sometimes it doesn’t even make it to the point of depreciation to make it a worthwhile venture. This is pretty well known- the axiom “measure twice, cut once” by doing appropriate research before purchase works quite well, but when it comes time to replace that hardware- how many times have you considered a new purpose for a device after replacement? It may still have a function to fill.

This picture above is a small project I’ve been meaning to undertake – adding a portable Ethernet/wireless repeater for use downstairs. This router was replaced recently with a smaller, feature rich unit by GL.iNet, so other than keeping it as a backup, I didn’t really have much use for it.. or did I?

It was running Advanced Tomato firmware, which worked great, but just wasn’t what I needed as it’s repeating capabilities just aren’t quite there- it’ll bridge, and it’s a decent AP, but that’s where it ends.

Having read of people bricking units, I decided to open it ahead of time, connecting a JTAG (USB to Serial) adapter so I had console access should things go wrong.

I had the unit erase the NVRAM, resetting to defaults, then rebooted, stopped it before chaining to the OS, started it as a TFTP server, and uploaded the latest DD-WRT firmware.

Now, I have nearly 100% signal strength downstairs, and a handy place to plug in wired devices if necessary. Total cost: about an hour of time, while still learning how to reuse equipment that can (barely) still be depreciated.