HP Remote Management card and newer versions of Java

October 17th, 2019

I was having some problems with DKMS and the ZFS kernel modules on my HP Microserver and I figured when it came to the inevitable reboot, this would be when the OS decides to kernel panic because the modules weren’t built properly and not boot back up again.

“No problem, I have the Remote Management card, I’ll just connect to that and watch it boot to make sure everything works.”, I thought. So once I remembered the password and logged in, clicked to launch the KVM Viewer, then discovered this Mac doesn’t have Java installed, (and I’ve managed for this long without it), go off to the Oracle website, relinquish all rights to my soul, and finally download and install Java 8.

I then retried launching the KVM Viewer and was met with a “Connection Failed” error. Now, this definitely used to work, so I went searching for clues. Nobody else had reported problems specifically with the Microserver card, but plenty were having problems with the iLO cards that are fitted to the Microserver’s bigger siblings, and also the iDRAC cards fitted to Dell servers; they all use pretty much the same Avocent-based Java client.

Some people suggested downgrading to Java 7 would get things working however Oracle have pulled all downloads of Java 7 unless you also promise them your first-born. Then I got the clue that it might simply be that the client is trying to use some crypto algorithm that has since been disabled in newer Java versions. Given the last firmware release for the management card was released in 2014, a lot has changed in the crypto landscape since then.

The security policy for Java is configured in a file named java.security which for the default Java install on a Mac, lives under /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/. In that file, I found the following lines:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, 3DES_EDE_CBC, anon, NULL

So for a first attempt, I commented both lines out and retried the KVM Viewer, and bingo, it worked again. Through a process of elimination, I figured out that it’s the 3DES_EDE_CBC algorithm that needs to be re-enabled. So here is that pro-tip for anyone else that is still using one of these, you should amend the line to:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
    EC keySize < 224, anon, NULL

And in the end after all of that faffing, the Microserver rebooted without a hiccup, no kernel panic. Typical.

Commodore 128 Keyboard Repair

September 18th, 2016

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.

Reviving a DEC Vaxstation 4000/90

August 4th, 2016

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.

Further Soekris net6501 improvements for OpenBSD

April 30th, 2015

The release of OpenBSD 5.7 brings the latest batch of improvements I made for Soekris net6501 users.

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:

# sysctl hw.vendor hw.product
hw.vendor=Soekris Engineering

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:

skgpio0 at isa0 port 0x680/32                                                  
gpio0 at skgpio0: 16 pins                                                      
gpio1 at skgpio0: 2 pins

You still need to configure the GPIO pins prior to raising the securelevel so add the following to /etc/rc.securelevel as a minimum:

gpioctl -q gpio1 0 set out error_led
gpioctl -q gpio1 1 set out ready_led

Now once the system is booted you can toggle the error LED with the following:

# gpioctl gpio1 error_led 2
pin error_led: state 0 -> 1
# gpioctl gpio1 error_led 2
pin error_led: state 1 -> 0

Exporting Mobile Configuration Profiles from Apple Configurator

January 9th, 2015

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.

Apple Airport devices and guest networks in bridging mode

January 9th, 2015

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:

switch#configure terminal
switch(config)#vlan database
switch(config-vlan)#vlan 1003
switch(config)#interface vlan 1003
switch(config-if)#name wifi
switch(config)#interface GigabitEthernet 1
switch(config-if)#switchport mode trunk
switch(config-if)#switchport trunk allowed vlan add 1003
switch(config)#interface GigabitEthernet 2
switch(config-if)#switchport mode trunk
switch(config-if)#switchport trunk allowed vlan add 1003
switch#show vlan
Created by: D-Default, S-Static, G-GVRP, R-Radius Assigned VLAN, V-Voice VLAN
Vlan       Name           Tagged Ports      UnTagged Ports      Created by    
---- ----------------- ------------------ ------------------ ---------------- 
 1           1                               gi1-8,Po1-8            D         
1003       wifi             gi1,gi2                                 S

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:

# cat /etc/hostname.vlan1003
inet vlan 1003 vlandev em0

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.

Monitoring file modifications with auditd with exceptions

November 19th, 2014

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

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:

-a exit,never -F dir=/directory/directory-to-exclude/
-a exit,never -F path=/directory/file-to-exclude
-a exit,always -F dir=/directory/ -F perm=wa

According to this post order is important; list the exceptions before the main rule.

Building mod_proxy_wstunnel for CentOS 6

August 6th, 2014

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 various instructions 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.

Using Ultimate GPS to bootstrap Maxim DS3231M

June 11th, 2014

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:


I’ve uploaded the sketch I wrote to GitHub: https://github.com/bodgit/ds3231-from-gps

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.

Enabling $GPZDA NMEA sentence on Adafruit Ultimate GPS

June 10th, 2014

I’ve been using an Adafruit Ultimate GPS module as a time source which with their standard GPS Library provides the $GPRMC NMEA 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:


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:


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.