Setting up Raspbian on a Pi

February 26, 2015

I’ve been working on setting up a Raspberry Pi to do APRS using Dire Wolf and Xastir. That actually works fairly well, and I’ll write something about it later – this post is because I was using a flaky SD card, which decided to croak at an inopportune moment. Consequently, I had to reinstall Raspian again.

Since it’s easier to write it down than to remember, here’s what I did:

Burn the image

  1. Get the Raspbian image from the Raspberry Pi downloads page.
  2. Unzip it on a Linux box (mine saw the SD card as /dev/sdb, use your SD card device and don’t wipe your hard drive)
  3. Pop the card out of the Linux box and into the Pi

The command to write that I used:

sudo dd if=2015-01-31-raspbian.img of=/dev/sdb bs=4M

Configure the Pi

When the Pi boots into raspi-config, do the following:

  1. Expand Filesystem
  2. Change User Password
  3. Internationalisation Options / Change Locale, pick en_US UTF-8
  4. Internationalisation Options / Change timezones, pick yours
  5. Internationalisation Options / Change Keyboard Layout, pick US PC 104, accept defaults

Set up the network

I have my Pi configured with a static IP. The first time I boot I attach a network cable.

  1. Edit /etc/network/interfaces so the wired interface is static
  2. My /etc/resolv.conf was configured automatically by dhcp and was right
  3. Now would be a good time to edit /etc/hostname as well

The iface eth0 stanza in my interfaces file looks like:

iface eth0 inet static

Update the OS

This takes a while, but you can continue on while this is happening.

sudo aptitude update
sudo aptitude dist-upgrade

Add my user

I don’t like to use the default user, so I add my own.

  1. sudo adduser myuser
  2. edit /etc/group to add my user to all the pi groups (including sudo)
  3. log out, log in – make sure I can sudo with the new user
  4. prevent login as pi

To prevent the pi login, I do:

sudo vipw -s

and replace the password for pi with *.

Update everything else

Once the dist-upgrade has completed and it’s time to reboot:

sudo /sbin/shutdown -r now

Now you can log in again and upgrade the firmware:

sudo rpi-update
sudo /sbin/shutdown -r now

Get things I know I’ll need

I like to have an emacs clone:

sudo aptitude install zile
zile ~/.bash_aliases
alias emacs='zile'

I also like tightvncserver:

sudo aptitude install tightvncserver
(set password)

That’s about it.

Foot Switch for the Insane

December 28, 2014

I’ve been looking for a foot switch for a while now to act as a PTT for a radio. Yesterday at a thrift store, I came across the Koino KH-8012:
SPST Foot switch with NEMA 1-15 plug

Do you see anything wrong with this picture? That is indeed a SPST foot switch with a NEMA 1-15 plug on the end. I can’t think of any reason that you would want to do that – the switch is rated at 15 A / 125 V AC (as well as 14 V DC), so it’s not like it was meant for a European destination where the corresponding socket wouldn’t be found in the wild.

The label is a lie too – it’s normally open, and conducts when closed. It is not SPDT: there are only two conductors coming out of the switch.

I’ve since rendered it safe and unable to short out household wiring by cutting off the NEMA 1-15 and adding a 1/4 inch jack instead.

All I can find about this switch is that it’s available from China and Vietnam, and costs USD $6.49 each when bought in large lots. Any idea what this was originally used for, or why on earth anyone would want to terminate it in a way that seems designed to blow fuses? Leave a comment.

Using Cygwin git on Samba

December 23, 2014

When I last updated the Cygwin git, it stopped working on my Samba drive. Normally running git on a network drive is not recommended, but I do it anyway. After a git upgrade, I started seeing:

error: invalid object 
error: Error building trees

when I did a commit. After a little searching, I discovered this Stack Overflow post which suggested one answer:

git config --add "core.createobject" rename

This appears to have solved the problem for me.

Repairing a MFJ-259B Antenna Analyzer

November 29, 2014

I’ve had an MFJ-259B antenna analyzer for a while, and for the most part it’s been pretty good. However, in the last few months I’ve seen it intermittently give me really high SWR as opposed to normal SWR.

Usually, that means there’s a break in a transmission line somewhere, but I kept seeing it on different lines. Curiously, it usually went away when I touched the antenna connector.

I wondered if I was adding capacitance or something to the system, but finally I realized it happened when the feedline cable pulled down on the analyzer. It was just a break between the antenna connector and the analyzer.

I took the analyzer apart, re-soldered the SO-239 and I was back in business.

Here’s what I learned when I took the antenna analyzer apart:

  1. Take the battery cover off first (two screws on the bottom)
  2. Next, unscrew both sides (four screws on each side)
  3. At this point, you’ll have access to the battery compartment. Take out the two top batteries and the two bottom batteries (don’t need to take out the rest).
  4. You’ll see four screws that hold the battery compartment to the analyzer. Actually, that’s a lie – only the two right-side screws hold the battery compartment to the analyzer. The left screws are screwed into Delrin insulators. Don’t unscrew the left screws or the insulators will drop off and you’ll have to look under the table for them. Just unscrew the right screws (top and bottom).
  5. At this point you can move the battery compartment to the side, and get easy access to the SO-239 connector. Don’t lose the lock washers that are under the screws.
  6. I suspect they used lead-free solder to solder the connector, which is more prone to cracking than 60/40. I upped the heat a little and mixed in some 60/40 solder to make it more durable.
  7. At this point you can put the 4 batteries back in and test with a dummy load and a good cable. I did this and verified my problems with mystery SWR were gone.
  8. Put things back together in the reverse order that you took them apart.

Signal out of range on Soyo Topaz S

November 25, 2014

I recently upgraded my monitor from an old Sharp 12″ to a Soyo Topaz S. Things seemed to be going well with the new monitor until I rebooted my Ubuntu Server (which was on 12.04 LTS). When I did that, I got the message “Signal Out of Range” from the monitor, and I couldn’t see what was being displayed.

According to a number of sources, this was because my monitor was being detected incorrectly and choosing the wrong resolution or colour depth. Lots of articles explained that you can change the mode in the config file /etc/default/grub.

To start with, I booted SysRescCD with the option gfxpayload=640×480. This got me to the point where I could see the file system, do an fsck (I’d gone 327 days without one) and mount my root drive in /mnt.

Naturally, when I did that, I discovered the file /mnt/etc/default/grub didn’t exist. That’s because I had upgraded originally from 8.04 LTS and that had never upgraded my grub to grub2.

But at least now I could ssh into my server again. I updated, then upgraded to 14.04.1 LTS because hey, the server needed it anyway. Immediately after doing that, I saw an error with every command, “no talloc stackframe at ../source3/param/loadparm.c, leaking memory”. The quick fix for that (as described in this ubuntuforums thread) was to run pam-auth-update and remove “SMB password synchronization”. As far as I can tell, that hasn’t changed anything with respect to what passwords are used for my shares.

Then I followed the instructions to upgrade from grub to grub2.

After that, I still couldn’t see my screen when I booted… but I had an /etc/default/grub. So I edited it, uncommented the line:


and had a booting system again. Yay! Eventually I figured out that I could go up to 1024×768 with no problems.

After that I realized I couldn’t do anything with the grub menu. I booted into the system, but couldn’t choose the OS to load with my USB keyboard.

So the next time I booted, I had to switch “USB Keyboard Support” in my BIOS from “OS” to “BIOS”. That fixed the grub menu problem.

Trying to resurrect a dead Linksys WRT54GS router

September 1, 2014

I recently went through heroic efforts to bring a dead Linksys WRT54GS router back to life. These routers are great for Broadband Hamnet so I really wanted to get it working, but no dice.

But I don’t want to forget what I did, so I’m documenting it here.

Fix the hardware

The first problem was that the router made a strange buzzing sound. I opened the router and discovered that LX2 in particular, but also LX1 (two chokes at the power supply input) were actually vibrating when I put my finger on them. In addition, the capacitors near it were hot to the touch.

This was described in this post as an electrolytic capacitor problem. Sure enough, when I replaced CX2 with a new 220 uF 25 V electrolytic capacitor, the device settled down. At this point, the power LED was flashing (a bad sign) but at least it was now flashing at a regular speed. While I was soldering, I took the time to add a 12-pin header to the router’s JTAG port.

Reflash the Firmware

Following the unbrick article here, I wasn’t able to ping the router. No matter what, I’d get “destination host unreachable” – even though my IP was the same as the router, ostensibly. So I figured flashing was required.

I started out by trying to get a SEGGER J-Link talking to the JTAG port. I used the pinouts for the WRT54G described here for the WRT54GS, and the pinouts for the J-Link described here. Note that RESET on the J-Link is nSRST on the WRT54GS.

After I’d done that, I wasn’t able to get the J-Link talking. It looks as if the J-Link software wants to talk only to devices it knows about – or at least, that’s all I could figure out about it. Trying to set it to MIPS mode to impersonate EJTAG didn’t yield any success either.

So it was time for a different option. I didn’t have a parallel port handy, but I did have a Raspberry Pi. And a wonderful individual has taken the time to port tjtag to the Raspberry Pi. I cloned the Git repo to my Pi and built it. I had to use:

git clone git://

to grab the Git repo, since https wants an auth key and I don’t have one. After that I followed the Setup instructions and got tjtag built.

I connected things up as described in the wiring diagram, and had success! I was able to probe the router. (I had to run sudo ./tjtag -probeonly instead of just ./tjtag.)

Then I went off to the tjtag instructions here. The first few times I did:

sudo ./tjtag -backup:cfe

I got different results. It appears that tjtag on the Pi spends so much time sending output to the console that it messes up its timing. So I redirected the output to /dev/null, and after that I got consistent backups.

Once I had an nvram backup, I tried erasing the nvram:

sudo ./tjtag -erase:nvram

This worked, but didn’t solve my problem. So I thought I might have had a corrupted CFE. I located the CFE for my router here and modified it to have my IP addresses using imgtool_nvram. I used the following command:

imgtool_nvram.exe wrt54gs1.0-CFE.
BIN et0macaddr=00:11:22:33:44:55 il0macaddr=00:11:22:33:44:56

(substituting my real MAC address and one higher than it.) Then I dumped that back on the Pi as CFE.BIN, and did:

sudo ./tjtag -flash:cfe > /tmp/out

That worked, but still no joy in Mudville after I did the flash. No matter what, when I pinged I got destination unreachable. I wondered if it was Windows messing with me, so I booted to Kali to see what happened there. Still no dice.

Finally, I thought it might be a bad kernel, so I nuked it:

sudo ./tjtag -erase:kernel

Even with that, the router’s still not responding. Other than re-reflashing the CFE on the assumption that the bad kernel corrupted it, I’m out of ideas.

Drat, I thought I had it when I saw the instructions about setting the address with arp. (arp -s aa-bb-cc-dd-ee-ff if you’re on Windows.) But even when I did that (using the MAC address that I flashed), I still had nothing. I even stuffed Wireshark on the end to listen for any packets. He’s dead, Jim.


Making the Netgear WGR614 a bridge

August 16, 2014

For the longest time, I’ve had a Netgear WGR614 acting as a NAT for my wifi traffic. That meant I had a separate network for wifi traffic, rather than sharing traffic with my wired network.

Eventually this lead to problems. Some phone apps want to search the network for printers or set top boxes, for instance – and because the wireless devices were on a different network, they’d never find the wired devices.

After a long time thinking about this, I decided to see what it would take to turn my wifi router into a bridge. Turns out the Netgear WGR614 is very nicely suited to that. All it takes is one plug change and a few settings changes, and now my wireless and wired traffic is all on the same IP address range.

I found a few useful posts for this:

Note that this assumes you’ve got something else on the network that’s going to serve IP addresses for you. If you don’t know, you probably shouldn’t do this.

Here’s how to do it:

  1. Unplug the Netgear WGR614 from everything except one laptop. Make sure the laptop is plugged into a regular port, not the WAN port.
  2. Hard-reset the Netgear WGR614 (push the button that’s inset next to the WAN port for 10 seconds).
  3. After the router reboots, connect to from the laptop. After a reset, the account is “admin” and the password is “password”.
  4. You’ll be asked if you want to step through the configuration. Select “No, I know what I’m doing”.
  5. First off, change that password. Choose the “Set Password” tab on the left and make it something better.
  6. Next, go into the Wireless Settings tab. Set the SSID, security to WPA2-PSK and passphrase for WPA2.
  7. If you know what channels other routers in your neighbourhood use, now is a good time to set the wifi channel as well.
  8. Go to the LAN Setup tab and unclick “Use Router as DHCP Server”.
  9. Next, on the LAN Setup tab set the IP address for the router to something static your address range.
  10. Now unplug the laptop and plug what was the WAN uplink cable into a regular port (non-WAN) on the router.
  11. Unplug and re-plug the router.

Once you’ve done all that, your router will be acting as a bridge for traffic between the wifi and wired networks.

One warning: I originally didn’t hard-reset the router. This left it with an IP address of my internal wired network on the WAN port. Once I’d done that, I couldn’t connect to it over the LAN interface, since it saw that as an address conflict. So just hard-reset it.

Incidentally – this isn’t strictly a bridge, since the router has an IP address on the LAN. But it’s routing the packets from wifi to wired and back.


Get every new post delivered to your Inbox.