aoakley.com
A colleague recently won a Raspberry Pi Model A+ at Cotswold Raspberry Jam, Cheltenham, Gloucestershire. A couple of days later, he posed the question at the coffee machine: "What do I do with it?". He already had a Model B+, which was easy to connect up since you could plug a keyboard, mouse, network and monitor all in together. But with the Model A+, you can connect a monitor, and only one of a mouse, keyboard or USB wireless network dongle, and not all together. So how do you make use of this little beast?
(This whole "plus" thing is getting annoying to type, not to mention the Pi 2 B, so let's just go with A and B from now on, and you can assume A includes A+, i.e. all the models with only 1 USB and no ethernet network cable socket, and B includes Pi 1 B, B+ and Pi 2 B with multiple USB sockets and an ethernet socket. Also let's assume that "SD card" includes Micro SD.)
The simple answer is to prepare your SD card on a Model B and then swap it into your Model A, then connect over the network.
There is another method using what is called a UART cable (a fiver from eBay; four female GPIO pin sockets one end, USB at the other end) where you can control the Model A directly from another PC without needing the network set up, but Raspberry Pi over UART serial USB cable is already well documented elsewhere.
Our end goal is to use the Model A entirely over the network, without even a monitor. Using a computer without a keyboard, monitor or mouse is called being "headless".
So, let's have a look at the simple method where we just swap SD cards.
You will need:
I'm going to give the two SD cards names, to make it easier to talk about them. You will need Raspbian installed on both.
I'm also going to name the USB wireless network dongle, that will eventually end up on the Model A, as the "Alpha" WiFi dongle. This only really matters if you have two WiFi dongles of different brands. Sometimes Linux gets confused if it's been set up for one brand of WiFi dongle, but you then use a different one.
I recommend using WiFi dongles based on either the Ralink 5370 chip or the RTL 8188CUS chip. Support for both the 5370 and 8188CUS is built-in to Raspbian (the CUS is important; 8188EU requires extra drivers, for example). In my experience the 5370-based ones perform a little more consistently at the cost of not picking up weaker signals. The 8188CUS ones are great at picking up weak signals but their power requirements fluctuate, so if you don't have a top notch power supply, they can drop the connection.
I am serious about using only a recent version of Raspbian. A lot of this config stuff is much more complex and harder on older versions of Raspbian. I really do mean a new image, not just an old installation that's been updated. You can do all of this on older versions of Raspbian, but it requires a lot more installation and configuration that I'm not going to detail here.
We're not going to use the Model A yet. You can leave it switched off and disconnected.
With the Model B powered off, disconnect everything from your Model B including the SD card and any network dongle or network cable.
Put the Alpha card into your Model B. Put the Alpha WiFi dongle in your Model B. Connect the keyboard and monitor (you can also connect the mouse if it makes you feel better, but we're not going to use it).
Power on your Model B and wait for it to boot up.
Once Raspbian as booted up, you will either be at the command line (the black screen with login:) or at the desktop (the colourful screen with the mouse pointer).
You want to be at the command line. If you're at the desktop, hold down both the CTRL and ALT keys and then press the F1 key. (Don't panic: if the desktop is running, you can switch back to the desktop with CTRL-ALT-F7).
Log in as normal. The default user is pi and the default password is raspberry .
Do not type startx - we do not want to use the desktop (although if you did, you could always use CTRL-ALT-F1 and CTRL-ALT-F7 to switch back and forth between command line and desktop).
Of course, you could just run LX Terminal from the desktop. But I need to wean you off the desktop, because you won't have one on your Model A.
You can skip this step if the Alpha card already only boots to the command line.
You only need to do this step if the Alpha card automatically starts the desktop. Enter:
sudo raspi-config
Use the up/down keys to select "Enable Boot to Desktop/Scratch" and press Enter.
Select "Console Text console, requiring login (default)" and press Enter.
You should now be back at the first menu. Press TAB and use the up/down/left/right keys to select Finish, and then press Enter.
"Would you like to reboot now?" Select Yes and press Enter.
Once it's rebooted, log back in to the command line.
By default, all Raspberry Pis have the hostname raspberrypi . Since we'll need to connect to this specific Raspberry Pi over the network, we need to make the hostname unique to this SD card.
Enter:
sudo raspi-config
Use the up/down keys to select "Advanced Options" and press Enter.
Use the up/down keys to select "Hostname" and press Enter. Read the text that tells you only to use the letters a-z, numbers 0-9 and hyphen, and that it must start with a-z, then press Enter.
Use the BACKSPACE key to erase the current hostname, then type a new one. I suggest alpha but you can use anything (limited to a-z 0-9 and hyphen). You will need to remember this, so if you pick something fancy, write it down.
Press Enter once you've typed the new hostname. You should now be back at the first menu. Press TAB and use the up/down/left/right keys to select Finish, and then press Enter.
"Would you like to reboot now?" Select Yes and press Enter.
Once it's rebooted, log back in to the command line.
You should notice that instead of saying raspberrypi login: , it now says alpha login: or whatever you chose as your hostname. After logging in, you can further confirm the new hostname by entering:
SSH stands for Secure Shell, and it is the way we will securely connect from the B to the A once we're ready. So we need to make sure that the SSH server (also known as the SSH daemon) is running. Newer variants of Raspbian should have the SSH server running by default, but we can make sure with:
sudo raspi-config
Use the up/down keys to select "Advanced Options" and press Enter.
Use the up/down keys to select "SSH" and press Enter. Use the left/right/up/down keys to select "Enable" and press Enter. After a moment it should tell you that the SSH server is enabled; press Enter to okay this message.
You should now be back at the first menu. Press TAB and use the up/down/left/right keys to select Finish, and then press Enter.
"Would you like to reboot now?" Select Yes and press Enter.
Once it's rebooted, log back in to the command line.
(You may be wondering "Could I have just done all the raspi-config stuff in one go, and only had to reboot once?" The answer is yes, but I wanted to do this step-by-step and confirm each step to be sure.)
You should be still logged in on the command line. Now do:
sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
You're now editing the wireless network configuration file. It should look something like this:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
There may also be some network={ sections.
You need to make sure there is a network={ section for your wireless network. If there's isn't already one, add a section at the bottom of the file. Obviously you will also need to change YOUR_NETWORK_NAME and YOUR_NETWORK_PASSWORD.
network={
ssid="YOUR_NETWORK_NAME"
psk="YOUR_NETWORK_PASSWORD"
}
This should work for the vast majority of home networks. Older versions of Raspbian before about September 2014 required you to also know things like WPA2, TKIP and OPEN_ALG; but provided you installed a newer version you shouldn't need those details - it should work them out for itself. If you are trying to connect to an enterprise network, though, then you will need to speak to your IT department to get the right settings.
Save the file with CTRL-X and answer Yes when prompted to save the file.
Reboot the machine with:
sudo shutdown -r now
After the machine has rebooted, log back in to the command line. You may need to wait 15-90 seconds whilst the wireless network connects. Then check your wireless network connection by pinging a well-known website that's unlikey to be down:
ping -c 5 news.bbc.co.uk
After a moment, it should say 5 packets transmitted, 5 received, 0% packet loss . If it says something else, and you have waited more than 90 seconds, then check you're in a good signal strength area, and check your settings in /etc/wpa_supplicant/wpa_supplicant.conf . Remember to reboot if you change the settings (there is a way to refresh without rebooting, but let's keep it simple).
If you try to ping before the wireless network has connected, you can break out of the wait by holding down CTRL and pressing c .
Once you are certain that the wireless network is working, it's time to switch to the Model A.
Power down your Model B using:
sudo shutdown -h now
( -r means reboot; -h means halt; and yes, you can set something other than now, for example +2 for "in two minutes". It's a legacy from when Unix systems were shared between lots of users simultaneously; the assumption was you need to give them a few minutes' notice to save their work and log out)
Disconnect everything from your Model B, especially the Alpha SD card and the Alpha USB wireless network dongle.
With the Model A powered off, insert the Alpha SD card and the Alpha USB WiFi dongle into the Model A.
Power up the Model A.
Now connect up your Model B using the Beta SD card and your second USB WiFi dongle or network cable, plus your usual monitor, keyboard and (if you insist) mouse. If you haven't already configured the wireless network on the Beta SD card, it'll be the same process as above. Log in to the command line.
From the command line on the Model B, check your network is working with ping -c 5 news.bbc.co.uk again. After a moment, it should say 5 packets transmitted, 5 received, 0% packet loss . If it doesn't, check your network setup before going any further.
Now the moment of truth. After the Model A has been booted up for a good 90 seconds or so, it's time to try to connect.
From the command line on the Model B, let's ping the Model A:
ping -c 5 alpha
...or whatever you called the Alpha's hostname. After a moment, it should say 5 packets transmitted, 5 received, 0% packet loss. If it doesn't, then power down both Pis, pop the Alpha card and WiFi dongle back in the Model B and check the network setup again.
Okay, got a good ping from the Model A? Time to connect to the Model A's command line.
From the command line on the Model B, do:
ssh alpha
...or whatever the Alpha's hostname is. You may be asked to confirm the identity of the new machine - SSH does this every time it encounters a machine it's never encountered before. Type yes and press Enter.
You should then be asked for the password. The default password is raspberry .
All being well, you should now be logged in to the Model A's command line. Enter:
hostname
...and it should say alpha or whatever. The point is, it'll be different to the Model B's hostname.
You can now do whatever you want to do with the Model A, such as:
Top tip: mobile phone emergency chargers make great batteries for your portable Raspberry Pi model A project! (But bear in mind WiFi signal range)
To end the connection from the Model A's command line, enter:
exit
Now you're back on the Model B, and you can confirm this by entering hostname again.
As the name Secure Shell implies, SSH can be rather strict about security checking. One of the more annoying aspects is if the IP address of the Alpha machine changes, as it may well do if it's switched off or after many hours, then SSH will give you a security warning and may refuse to connect.
To turn off IP-based security checking, from the command line of the Model B, do:
sudo nano /etc/ssh/ssh_config
Scroll down using the arrow keys, and you'll find a line saying:
# CheckHostIP yes
Add a new line under this (move the cursor to the start of a line using the arrow keys, then press the Enter key to create a new line) saying:
CheckHostIP no
Note how your new line does not start with a # hash symbol and says no instead of yes. Save and exit with CTRL-x . You should now be able to securely connect even if Alpha's IP address has changed.
Public Domain - Andrew Oakley - 2015-02-06
