My Commodore 128, (a “flat” C128CR), has suffered with a few temperamental keys on the keyboard; the symptoms being that keys are either slow to return after being pressed or don’t return at all and stay pressed resulting in undesired input, i.e. they’re “sticky”.

This can be caused either by spilling something, usually sugary, into the keyboard which leaves a sticky residue, or a failure of the plunger for each affected key. As I’m fairly sure I’ve never spilt anything I assumed it was the latter.

To get at the keyboard the machine needs to be opened up first which is simply a case of unscrewing the six screws on the underside; three along the front edge with the middle one usually underneath a warranty disclaimer sticker, two at each of the rear corners and one in the centre. The top half of the case will pop off with a bit of persuasion which allows you enough clearance to reach in and disconnect the power LED and then the top of the case can be hinged open along the right hand side of the machine which allows you to gently disconnect the keyboard cable and unscrew the grounding cable from the RF shielding of the main board. This should leave you with the following:

You might not necessarily need to remove the keyboard from the case but the size of the case makes it more unwieldy to work on. To remove the keyboard, just unscrew the six visible screws. Note the four black plastic spacers and their orientation for the screws along the top edge:

Once the keyboard is loosened the power LED will likely drop out along with the small plastic part that holds it in place. Keep all of these bits safe, ready for reassembly. You should now be left with just the keyboard itself:

Next the hardest step, which requires the use of a soldering iron. You need to desolder the wires from the three stateful keys; “Shift Lock”, “Caps Lock” and “40/80 Display”. It’s important not to let the soldering iron heat the keys up too much to prevent damaging them and thankfully the wires are not twisted together so with some tweezers and the quick application of the soldering iron the wires should separate easily:

There are now 27 small screws holding the circuit board in place to undo and then the circuit board should just lift away. Don’t miss this tiny spring that is situated above the ‘+’ key on the numeric keypad:

The circuit board can be gently cleaned with something like isopropyl alcohol if it’s dirty. To get at the plungers for each key, you just need to pull off the keycap on the top side of the keyboard, put that and the spring underneath it to one side, and then the plunger should just drop out:

The keycap snaps into the top of the plunger which rides up and down through a hole in the keyboard chassis with the spring making the plunger return and stay up. What happens is that the plunger can develop a split which means when the keycap is fitted the diameter of the plunger grows enough that it doesn’t move smoothly in the hole and becomes an interference fit causing the key to stick. Here’s one of the damaged plungers from mine with my nail showing where the split is:

It’s simply a case of replacing each damaged plunger, (I ended up replacing five along with two springs), and then reassembling the keyboard. Leave the re-soldering of the stateful keys until last and that you’ve checked all the other keys travel properly. You should now have a reassembled keyboard:

Fitting the keyboard back into the case is fairly straightforward, the trickiest bit is keeping the power LED stable while you drop the keyboard in place as it’s just sandwiched in, here’s how it should be fitted:

Reconnect the keyboard cable making sure not to bend any pins, reattach the grounding cable to the RF shielding and finally reconnect the power LED, (apparently it can be reconnected in either orientation), as you close the two halves of the case together. Then it’s just a case of powering on the machine and testing the keyboard. Make sure that you also test the stateful keys work correctly after you’ve de- & re-soldered them.

I recently powered up my old DEC Vaxstation 4000/90 out of curiosity to see if it still worked and discovered that no, it didn’t. The fans in the power supply spun up, the noisy SCSI hard disk whirred and clicked into life but nothing else happened. Anyone familiar with these and similar DEC machines knows there’s a bank of eight diagnostic LED’s that provide error reporting as the machine initialises and tests its various bits of hardware. All eight were lit and weren’t changing, it looked dead.

A lot of machines of this era have what is known as a timekeeper chip which is some non-volatile RAM with a crystal and battery piggy-backed on top and encased in resin. It keeps time and the battery allows the RAM to retain its contents whilst the machine is powered off. The contents are usually important machine settings, such as which disk to boot from, etc.

The 4000/90 has a Dallas Semiconductor DS1287 which is a fairly ubiquitous part and the batteries in these chips are only supposed to last for about 10 years so given the 4000/90 was introduced in the early 1990’s, chances are by 2016 the battery is flat. Early Sun Microsystems machines are plagued with a similar problem however they tend to still power up, but then report bad values for their host ID, MAC address, etc.

There’s two possible fixes. One, fit a new timekeeper chip which given they’re not manufactured any longer may mean fitting a “new” chip that has sat on the shelf for a number of years and so the battery has already lost much of its charge. Alternatively, and what I ended up doing, is to add a new battery to the existing chip.

The first job is to locate and extract the chip. Here is the DS1287 fitted to the 4000/90:

Note the dot identifying pin 1. Thankfully it’s in a socket so with a bit of careful coercion it should come out. The next step is to use a dremel or file to grind away the plastic and resin above where pins 16 & 20 would normally be, (they’re still present but bent up inside the package and attached to the battery):

Using a multimeter across these two terminals showed there was only 220-230 mV left in the battery so it was almost flat. Now the battery needs to be disconnected by breaking the contact on pin 16 so that the multimeter shows no voltage when placed across the exposed contacts near the base of the chip. With that done add some small wires, soldering them to the same contacts with the aim of attaching them to a battery holder:

Then add the battery holder and battery; I used a standard CR2032 Lithium coin cell. The positive terminal goes to pin 20 and the negative terminal goes to pin 16. I also put some more hot glue over the exposed contacts:

Now reinstall the chip back into the 4000/90 taking care to both orientate it correctly and not bend any of the pins:

At this point it was time to try and power on the Vaxstation and this time it worked and emitted its little warble and dropped me to the SRM console:

It was a bit confused as it had lost all of its settings so didn’t know where to boot from, etc. but other than that seemed fine. After fixing this I figured my DEC 3000/600 Alpha might also have the same issue so powered that up to find yes it did, but it at least boots to the SRM console and reports an NVR (Non-Volative RAM) fault. Here’s the timekeeper chip hidden underneath the middle TURBOchannel expansion slot and bingo, it’s another DS1287:

I performed the exact same steps as before and refitted the modified chip:

The NVR fault has now disappeared. Both machines should now be good for another 10 years or so, although it’s likely the elderly hard disks will seize up, or maybe a capacitor in the power supply will leak.

The first change adds platform detection that should in fact work on all Soekris boards, (I think this change actually went in circa 5.4 but I never posted about it). Normally this information comes via the SMBIOS extensions but Soekris boards have a much stripped-down BIOS that lacks any of this support. There are however some vendor and product strings embedded in the BIOS image (probably used for printing on the serial console at POST) so they get picked out and used. For example:

The second change adds the skgpio(4) driver which provides access to the GPIO & LEDs on the net6501. Two GPIO devices are provided; gpio0 for the 16 real GPIO pins, (JP8 in the net6501 manual); and gpio1 for the error and ready LEDs coerced into the GPIO framework as output-only pins. Here is what is displayed in dmesg at boot:

As I’ve secured my main Wi-Fi network with WPA2 Enterprise, my Apple Airport devices are pointed at a RADIUS server, which in turn is pointed at an LDAP directory which contains the user details. The LDAP directory does not store the password in the clear which means that authentication methods like CHAP, MSCHAP and MSCHAPv2 don’t work as they require the original password. I need to use EAP-TTLS with PAP authentication however iOS and OS X clients will not attempt this method by default.

It’s theoretically easy to make iOS and OS X clients use this method, you simply install a Mobile Configuration Profile (a file with a .mobileconfig extension) which amongst other things instructs the client how to connect to a given Wi-Fi network. The tricky part is generating this file if you maybe don’t have access to an OS X Server. Apple originally provided the iPhone Configuration Utility (iPCU) which has been deprecated in favour of the Apple Configurator utility. This works fine for iOS devices that you can attach directly by USB but sometimes you might want to transfer a profile to someone via e-mail or install it on an OS X client. It’s not obvious how to export a profile from the tool, but there is a way.

When you open Apple Configurator it looks like this:

If you enable Supervision the Profiles section changes to allow you to click + and create a new profile:

In my profile as a minimum I needed to import the root certificate of the authority used to sign the certificate on my RADIUS server. Then configure my Wi-Fi network with the SSID, Security Type, EAP Type of TTLS and then select PAP as the Inner Authentication. I also trusted the certificate I’d just imported which prevents iOS and OS X prompting you to trust it. By not setting the Username and Password this keeps the profile generic for any user. Then after saving the profile you can then export it:

This gives you the familiar .mobileconfig profile which can then be imported on any iOS or OS X client.

The feature of being able to configure a separate guest Wi-Fi network has been present for a while now on Apple Airport gear. However, the documentation only ever alludes to this feature working when the Airport device is running in router/NAT mode, i.e. it’s in charge of connecting directly to the Internet and sharing the connection from your ISP.

Quite often people (like myself) use the Airport device(s) in bridging mode, i.e. as regular access points to attach Wi-Fi clients onto the Local Area Network and then some other device handles the routing and NAT function, (in my case an OpenBSD host), and it would be nice if you could also create a guest Wi-Fi network in this mode. The obvious way I would expect it to work is to utilise VLANs; the Airport device uses a single unique VLAN ID to tag Ethernet frames from clients on the guest Wi-Fi network. As the administrator you can then use that tag to segregate the traffic on your network; usually to allow guests some form of heavily-restricted Internet-only access, and not be able to access the rest of the network. The Airport Utility lets you create the guest network in bridging mode but doesn’t give you any details as to the mechanics of it.

Well it turns out my hunch was correct, it does use VLANs; Ethernet frames from clients on the normal Wireless network stay untagged so they Just Work on your network as before, however Ethernet frames from clients on your guest network are tagged with the VLAN ID 1003. This ID is not mentioned anywhere, nor can it be changed so you’d better hope you’ve not already used that ID for something else.

Armed with that information, I configured my Cisco SG300 switch like so:

This creates the VLAN, names it, configures two trunk ports where my Airport and OpenBSD router are attached and adds the new VLAN to the list of allowed ones on each port. Finally all that is left to do is to create a VLAN interface on the OpenBSD router:

Providing any DHCP and/or DNS services and firewalling the traffic is outside the scope of this post but you now have a separate interface and subnet that you can treat it like any other regular network.

So now I have two separate wireless networks; one that gives me access to my LAN which I can secure using WPA2 Enterprise and another that can only reach the Internet which can be unrestricted or more likely secured with WPA2 Personal.

Playing with auditd, I had a need to monitor file modifications for all files recursively underneath a given directory. According to the auditctl(8) man page there are two ways of writing a rule to do this:

-w /directory/ -p wa
-a exit,always -F dir=/directory/ -F perm=wa

-w /directory/ -p wa
-a exit,always -F dir=/directory/ -F perm=wa

The former rule is basically a shortcut for the latter rule; the latter rule is also potentially more expressive with the addition of extra -F conditions. I also needed to ideally exclude certain files and/or sub-directories in the directory from triggering the audit rule and it turns out you do this:

I had a need to be able to put an Apache-based reverse proxy in front of an install of Uchiwa which is a Node.js-based dashboard for Sensu. The only problem is that it uses WebSockets which means it doesn’t work with the regular mod_proxy_http module. In version 2.4.5 onwards there is mod_proxy_wstunnel which fills in the gap however CentOS 6 only has a 2.2.15 (albeit heavily patched) package.

There are variousinstructions on how to backport the module for 2.2.x (mostly for Ubuntu) but these involve compiling the whole of Apache from source again with the module added via an additional patch. I don’t want to maintain my own Apache packages but more importantly Apache has provided apxs a.k.a the APache eXtenSion tool to compile external modules without requiring the whole source tree available.

So, I have created a standalone RPM package for CentOS 6 that just installs the mod_proxy_wstunnel module alongside the standard httpd RPM package. In order to do this I took the original patch and removed the alterations to the various build files and also flattened the source into a single file, (the code changes were basically adding whole new functions so they were fine to just inline together). The revised source file and accompanying RPM spec file are available in this Github gist.

I’m currently building a project that is based around a Maxim DS3231M, which is an I2C-attached RTC.

I’m currently using the chip through the TinyTempus breakout from Phenoptix which only lacks the 32.768 KHz output which I don’t use anyway. I’m using the provided CR1216 battery to keep the clock ticking at all times however I had a need to get the clock set to the right time.

As I had an Adafruit Ultimate GPS breakout I figured it would be easy to just use the time from that to bootstrap the clock to the right time rather than deal with user input. I put together the following basic circuit:

The sketch uses the undocumented $GPZDA NMEA sentence to retrieve the time from the GPS module and reprograms the DS3231 on receipt of every new sentence so you just need to run the sketch long enough to get the message that the clock is set. Assuming your battery is good, the clock will keep ticking and maintain time accurately after you pull the power.

I’ve been using an Adafruit Ultimate GPS module as a time source which with their standard GPS Library provides the $GPRMCNMEA 0183 sentence containing the time and date however I had a preference for the $GPZDA sentence for the simple fact it provides the year as four digits instead of only two.

This forum post suggested it was possible on the MTK3339 chip by sending an unsupported variant of the command that enables the various sentences:

$PMTK314,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0*29

$PMTK314,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0*29

However, this didn’t work. The datasheet provided by Adafruit doesn’t document the majority of the data fields in this command, just identifying them as reserved. I found another datasheet elsewhere which I think is just an older revision of the same document and this has slightly better information. In fact, the command was only slightly wrong, it’s in fact this:

$PMTK314,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0*29

$PMTK314,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0*29

It’s the 18th field, not the 17th as the forum post originally suggested. Sending this command to the GPS module now returns the $GPZDA NMEA sentence. It can be enabled with other sentences, you just need to update the XOR checksum after the * using something like this online tool.

Just been bitten by this annoying bug on Mavericks after a seemingly innocuous reboot whereby I’m prompted repeatedly to unlock my “Local Items” keychain. No password I’m aware of works and mashing Cancel just puts you in an endless loop cycling through each application or framework that wants to access said keychain.

The solution is simple as outlined in the linked support document; just nuke the UUID-named folder in ~/Library/Keychains and reboot. The same folder will reappear afterwards but it’s fine to leave it if you’re not prompted to unlock it again. Obviously something got corrupted, possibly related to iCloud.