Raspi Bplus-1

Fixing bash Shellshock vulnerability on Raspberry Pi

The recent bash vulnerability, a.k.a. “Shellshock”, is pretty bad, considering it might actually have been around for a very long time, maybe even dating back to the predecessor of bash. Not good.

So what about Raspberry Pi’s?
Are they vulnerable?

Turns out they are, but there is already a fix available for them and patching a Raspi is very simple. Whether your actual Raspi is vulnerable depends on what distribution you are using, and how recently you upgraded the software in it.
The Raspi used below is running IPE-R1, which is a blackout-proof version of Raspian.

First let’s find out what bash version we have:

root@raspi-2:~# dpkg -s bash | grep Version
Version: 4.2+dfsg-0.1
root@raspi-2:~#

You can also run this little script to determine whether your Raspi is vulnerable to Shellshock

root@raspi-2:~# env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' bash --norc -c ':' 2>/dev/null;
WARNING: SHELLSHOCK DETECTED
root@raspi-2:~#

Let’s fix this. Just refresh the repos and upgrade bash (the patched version is available in the main repos).

root@raspi-2:~# apt-get update && apt-get install --only-upgrade bash
Get:1 http://archive.raspberrypi.org wheezy Release.gpg [490 B]
Get:2 http://mirrordirector.raspbian.org wheezy Release.gpg [490 B]
Get:3 http://archive.raspberrypi.org wheezy Release [10.2 kB]
...
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
 bash-doc
The following packages will be upgraded:
 bash
1 upgraded, 0 newly installed, 0 to remove and 54 not upgraded.
Need to get 1,443 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main bash armhf 4.2+dfsg-0.1+deb7u3 [1,443 kB]
Fetched 1,443 kB in 1s (1,386 kB/s)
(Reading database ... 29754 files and directories currently installed.)
Preparing to replace bash 4.2+dfsg-0.1 (using .../bash_4.2+dfsg-0.1+deb7u3_armhf.deb) ...
Unpacking replacement bash ...
Processing triggers for man-db ...
Setting up bash (4.2+dfsg-0.1+deb7u3) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
root@raspi1:~#

The installed version of bash is now +deb7u3

root@raspi-2:~# dpkg -s bash | grep Version
Version: 4.2+dfsg-0.1+deb7u3
root@raspi-2:~#

The short test script above also returns nothing:

root@raspi-2:~# env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' bash --norc -c ':' 2>/dev/null;
root@raspi-2:~#

You could of course also just do an “apt-get upgrade” to upgrade all packages on your Raspi, would take a bit longer but will work just as well.
Also, if you are not logged in as root you need to do a “sudo apt-get update”, of course.

How to get OS X 10.9 Mavericks and Arduino IDE to play nicely with each other

Apple tried to be smart with OS X Mavericks, developing their own FTDI drivers. Just too bad they don’t seem to work.

I have been getting nothing but “avrdude: stk500_recv(): programmer is not responding” errors when trying to upload sketches to various Arduino compatible boards.
In the end, the only thing that worked was programming the boards using a dedicated programmer (in my case an USBasp).

Some digging around forums and Apple’s support site, the following steps has solved the issue on all the OS X machines where I have tried it. In short, you need to replace Apple’s drivers with the ones from FTDI.

  1. Open a terminal
  2. cd /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns
  3. sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled
  4. sudo touch /System/Library/Extensions
  5. Restart computer
  6. Install FTDI’s virtual COM port drivers from http://www.ftdichip.com/Drivers/VCP.htm. In version 2.2.18 this package contains two executable files, I have had success with the one named FTDIUSBSerialDriver_10_4_10_5_10_6_10_7
  7. Restart again (might not be needed, good practise though after installing drivers)

Voila – The Arduino IDE can now upload sketches to all boards I have tried, both with the old/legacy bootloader and Optiboot.

Raspberry Pi won’t boot – only red power light comes on – SD card corrupt? Not so fast…

After having problems with SD cards failing after a few months in a Raspi that was supposed to be always-on, it was time to look for options.

The IPE distribution seemed like a perfect match – it effectively makes the Raspi only use a ramdisk, except possibly during boot. When needed the SD card file system can be made writeable, meaning that apt-get etc can be used as usual to install apps.

This worked great for ca 3 weeks, then this setup ALSO failed, with the same symptoms as before: at boot only the red power light would come on – nothing else. A fresh SD card with a fresh copy of IPE worked fine in the same Raspi hardware, thus not the Raspi itself that had fried (the cabinet where it lives is kind of warm, nothing too crazy though).

Now the weirdness starts for real. The failing SD card works perfectly fine when inserted in both an iMac and a Windows laptop. I spent hours and hours reformatting the card with various low-level tools, then writing the standard Raspian image to the card. Just for reference I did the same to a third SD card too, that card was identical to the failing one.

Still the same issue: that one card would still prevent the Raspi from booting.

The card in question is a Kingston 16 GB microSDHC card marked SDC4/16GB 081. It comes with an adapter that makes it usable also in large SD card connectors.

Photo on 11-09-14 at 06.52 #2

Finally, and I of course should have thought of this sooner, I tried swapping the two different microSD to SD adaptors. And of course… the solution was simple. It was not the SD card that had failed, it was the adapter. For some reason (heat? just poor quality?) the adapter had a small crack in its plastic housing, and as a result most likely some poor connection inside, between the microSD card itself and the surrounding adapter. When inserted into a proper computer, there was probably enough pressure on the adapter to squeeze it against the actual microSD card, while the SD card holder on the Raspi is kind of flimsy, and did not provide the needed pressure. When using a working adapter all three microSD cards work flawlessly in the Raspi.

Note to self: Use full sized SD cards in Rasperry Pis….

 

 

 

 

2014-03-24_10-38-42

HP 6632A power supply cleanup and modifications

 

There is a new tool in the lab: An HP 6632A power supply.

It might be a a bit dated, but it has some pretty good and useful specs (0-20 V, 5 A). True, modern supplies are more compact and offer more features in a smaller box, but a major advantage of an older supply like this, is that all schematics are available, they use large, easy-to-change components, and you have a decent chance of actually understanding how they work. A great thing about this particular model is that it can not only source current, but also act as a current sink. Useful when you need to see how other power supplies behave under load.

The HP 6632A is programmable over GPIB (or HPIB – it’s more or less the same thing), but given the costs of GPIB adapters, I doubt I will get one.. Most functions of the supply can be controlled locally from the front panel anyway. A main exception is however the calibration, which requires a HPIB connection. Bummer… especially as this unit at first inspection seems to show slightly incorrect readings.

Turning the supply on it worked a treat, but it is LOUD! Checking the schematics (available in the service manual) reveals that there is no intelligent fan control – it starts at full speed, and there it remains. No matter if the supply is loaded or not. Given my previous work on fan speed control, this is a challenge too good to pass on.. More on that later. So let’s take it apart. Ooohhhh… it is INSANELY dirty inside.

That fan is just clogged with dust and I don’t know what.. That’s got to be bad for the bearings. Sure, Papst make great fans, but this one has taken a serious beating. And all the dirt inside the heat sink.. Nasty. Time to bring out the compressor and blow all the dirt away.

2014-03-24_14-40-52 2014-03-24_14-40-39

The result is pretty good – almost all dirt was removed from the fan and heat sink, at least it is way, way better than before.

The original Papst fan still sounds like a jet engine though, it is probably worth looking into a replacement. It is a 60x60x25 mm 12V fan, but the only 60×60 fans I had around here was a slimmer (ca 12 mm) variant. It is quieter, but does not provide as much airflow. Given that a) I will rarely load the supply heavily, and b) the supply has over-temperature protection built in, I am not too worried about replacing the fan. One small problem though: The screws for the old fan (they are screwed into threaded holes in the main heat sink) are too long. No suitable screws could be found, but wait – those springs that I scavenged from the first electronics kit I got when I was 10..? Hmmm… Worked a treat – almost better than the original!

Next up: front output terminals. This is a factory fitted option (option 020) to the HP 6632A supply, but it is an easy thing to do yourself. The front panel is made of aluminium on the outside, with a plastic sheet on the inside. That plastic already has a cut-out for mounting output jacks, and there are solder tabs on the main PCB just beneath where the jacks go. Just drill a couple of holes in the aluminium and we’re good to go. But  wait… it doesn’t work. The over-current protection kicks in as soon as I turn the supply on. Is it toast? No… silly mistake. The banana jacks I just were not the kind with insulated mounting. In a plastic box they would have worked nicely, but here.. they just created a short through the supply’s front panel. Duh. New, insulated jacks and all works fine.

 

Make sure to use proper, heavy duty wires between the PCB and the jacks, in theory 5A at 20V could be flowing through there. I used the kind found in mains power centrals in residential housing, the copper is so thick it actually takes some effort to bend it. Should be plenty.

Finally, regarding calibration. Setting the supply to 5V, the display shows 4.996 V. The 0.004 V error shown by the supply itself is 0.08 %, which is actually within spec compared to the 0.05% + 10 mV accuracy (i.e. 0.0125 V at 5 V programmed level) of the supply. A connected multimeter (Fluke 89 IV, known to be spot on with respect to multiple different precision voltage sources) shows 4.9957 V, so it appears at least the supply’s output voltage is actually within spec and calibration, after all. However, setting the output to 15 V, the supply shows 14.995 V, and the multimeter shows the same. So about the same offset as before. It might be within spec, but there does seem to be a ca 4-5 mV negative offset in the output. Not a problem in any way, this is not a precision power supply, and things will anyway change when loads are connected. And with that, the supply is in a much improved shape. It is still really heavy (not much to be done about that, I am afraid), the fan is a bit loud for continuous use, and no calibration without a GPIB adapter. Still some room for improvement thus!

ReadyNAS RN312 + 8GB RAM = FAIL

My RN312 has worked flawlessly since the upgrade from the standard 2 GB RAM to 4 GB ditto. I would however like to run some memory intensive applications on the NAS, so an upgrade to 8GB would be nice. Turns out this is not as easy – might not even be possible.

I have tried both a Kingston KVR1333D3S9/8G, and a DDR3 1600 from my iMac – no luck. Guess the RN312 just does not support 8GB – too bad.

By the way, the 4GB SODIMM that does work is a Hynix HMT351S6BFR8C.

Fail of the day #2: SSD drives out of spec

A while back I got an SSD drive with the question whether it could be repaired. At first glance it looked fine. But wait… the PCB is not level. In fact, it is seriously wobbly. What on earth happened to this SSD??

That PCB should really not have that shape..

That PCB should really not have that shape.

Looking closer at the flash ICs, it turns out several of them have pins that have disconnected from the PCB. Ok – that’s tough but nothing some careful soldering cannot fix.

But after inspecting the rest of the PCB it is clear that some inductors and capacitors have been torn off too. Wow – this drive took a real beating – nothing here to be salvaged except maybe a crystal or inductor. Could possibly be useful in other projects. Well – it goes into the to-be-used-in-future-projects box.

 

That’s only half the story… Quite a while back I came across another pair of PCBs. Another SSD, in fact – broken in two. Probably on purpose to prevent data extraction from the drive, but it gives a good opportunity to have a closer look at what is inside an Intel SSD drive.

2014-01-01_22-51-10

No rescue possible here, no matter how good soldering skills..

All the passive components (capacitors, resistors) are so small they are impossible to hand solder – no point in salvaging them. Most of the other components are held in place with epoxy, making removal impossible (but I will for sure buy Intel SSDs from now on – these things are built to last!).

The PCB seems to have multiple layers. There is for sure at least a ground plane in there, probably 1-2 signal layers too (hard to count them without a microscope).

The one component that might be of interest in other projects (adding memory to OpenWRT based routers comes to mind) is the SDRAM, is a Samsung K4S281632I-UC60 8Mbyte x 16 IC.  On the other hand – hand soldering that one will be… difficult (understatement) and require rebuilding the OpenWRT kernel. Hmm.. Will probably just recycle it.

FAIL of the day #1: Repair of NiMH charger

2014-01-01_16-25-22

When buying some GP branded NiMH rechargeable batteries about a year ago, a “GP PowerBank Travel” charger (model GPPB03GS) was included as a promotion. It’s a nice little charger that runs both off 220 V and 12 V (for use in car, I presume). It can charge 1-4 AA batteries, or 1-2 AAA batteries, with additional trickle charging after full capacity has been reached.

The charger worked well for some months, but one day after charging some batteries overnight the LED blinked red, and when removing the batteries it was clear something had gone wrong. See the melted plastic? Not good.

As this was very much an el-cheapo charger, one should probably not expect much from it. But I was still curious about how the 220V was brought down to more useful voltage levels, and if the internals would live up to safety standards. I was actually quite surprised at how complex and well designed the internals were:

Looking closer, there are three distinct parts of the PCB:

- 220V section, which is shielded with plastic blast shields towards rest of the electronics – nice! This is a classic Switched Mode Power Supply (=SMPS), with an optocoupler feedback loop. Looks like a SMD type TL431 voltage reference – very common in SMPS designs.

- 12V section, with some protection diodes, filter caps etc – but no other major components.

- Charger circuit, using an unknown controller IC. The markings have been shaved off. I just don’t understand why they go through the trouble of doing that… It’s not like this is some super classified product where the design should be kept secret at any cost.

A closer look at the components and PCB around where the plastic had melted does not give any clues of what has gone wrong – in fact nothing visible anywhere on the PCB indicates a catastrophic failure of the charger.

Bringing out the multimeter and measuring the output from both SMPS and 12V section shows that those voltages are all good – most likely the problem is instead in the unknown charging controller IC, or possibly some of the tiny SMD FETs, diodes etc that complement the charging IC.

So… given that this kind of charger cost next to nothing these days, I’ll leave it for dead for now. The SMPS works as it should, so maybe that part can be reused in some other project – I’ll stash it in the “possible-future-use” parts bin.