Pre-programming a Wi-Fi network


#1

I have a Pi3 running piaware and I plan to give it to a friend to put at their place. They live three hours away so its not practical for me to go there to set it up, so I would like to be able to “pre-program” their wi-fi network so they don’t need to connect it to their tv/keyboard/mouse to set it up. Basically I want it to be like I’ve connected before so it automatically connects to their network when they plug it in at their house and dont have to mess with it. Is there a way to do this?


#2

Hello,
you’d need the Wi-Fi data (SSID and PSK) from your friend’s network, then you can simply do it at you location after setting up the Pi and assuring that wlan is working


ifconfig wlan0

See if Wi-Fi adapter is up and running, of yes


sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

Enter the following


network={
ssid="YOUR_NETWORK_NAME"
psk="YOUR_NETWORK_PASSWORD"
}

Assuming, you’re using Raspian Jessie and your friends have a network using WPA-PSK, that should have been all. If you want to have more networks being known to the Pi, just add such a section for each one of them.


#3

Setting up a remote site can give you greatly improved coverage. It will also introduce you to new worlds of stress, pain, and confusion.

Whenever you set up a remote site, you get a default site manager. His name is Murphy, and unless you are really well prepared, he will make your life miserable and drive you insane. If you are well prepared, he’ll just cause you grief. Remote sites don’t act up when the weather is good, when you have easy access, or when your schedule is sane. No, remote sites act up when you don’t have time to devote to them, when the weather is bad, and physical access to the site is a pain.

If you’re still thinking this is a good idea, I would STRONGLY suggest some additional steps to allow you to connect to your Pi remotely.

These steps include:

(1) add a reset switch to the enclosure containing the Pi, SDR, and other goodies. There are a pair of pads marked RUN on newer Pi models; shorting them together resets the system. Connect a momentary switch to these pads. This way you can have someone reset the system for you without power cycling the poor little beastie (as a last resort). Power cycling a Pi is about the best way known to generate a corrupted SD card, which will require a site visit to fix. You are going to put the thing in an enclosure that only exposes antenna, power, and network connections, right? And the reset switch, which should be partially hidden, or at least not operable by any inquisitive person wandering by.

(2) insure your Pi starts up with a known fixed IP address (vital for the next steps). You can do this on the Pi, or on the local router/firewall by associating a known address with the MAC address of your Pi.

(3) CHANGE THE DEFAULT PASSWORD on the Pi! Really. Change it to something long and memorable to you. Change it on all your Pis, even if they’re just local. If it’s exposed to the internet, it’s vulnerable. Horror stories available on request.

(4) Add a port forwarding rule to the local router/firewall to forward a port to port 22 of your Pi (at its static IP address) so that you can connect to it via SSH to check status and manage upgrades. Example: if your Pi is at local address 192.168.1.37, add a port forwarding rule in their router/firewall to forward TCP traffic on port 33666 (randomly chosen) to 192.168.1.37 port 22. If you don’t know why you shouldn’t be forwarding external port 22 to port 22 on your Pi, maybe this isn’t for you.

(5) TEST THIS OUT while at the remote location! If the external IP address is, say, 23.92.179.46, bring up a terminal window on some computer and try to establish a SSH connection to your Pi. On the Mac, you use the Terminal utility. At the command line, type:

SSH -p 33666 pi@23.92.179.46

This tells SSH to connect to your Pi at the remote location’s external IP address (23.92.179,46) on the port you chose (33666). If you’ve set up everything correctly, router, Pi, cabling, you’ll be asked for your password, and you can log into your Pi. If you indeed can, you’re in business. You stand half a chance of being able to manage the little beastie remotely. Check things out as best you can. Wait an hour and check them again. BACK UP THE SYSTEM AND TAKE THAT BACKUP WITH YOU. Log out and go home. When you get home, try to log in to your remote Pi. Hopefully you still can!

As you remotely administer your Pi, before you hit the return key initiating some sequence, ask yourself, “Self, how can what I’m about to do screw me to the wall and require I go out there and swap out the SD card to fix it?” Think twice before doing something that could remotely brick your Pi.

How often does your system back itself up? At home, my Pi systems perform compressed TAR backups twice a week, transferring the date-stamped backup images to the server in the closet. For a remote system, if you have a solid high-speed internet connection, I’d probably do local compressed backups twice a week, and once a month or so transfer that compressed image offsite. My PiAware systems running on the Jessie Lite distro have backup images under 600mb in size.

You think everything is going smoothly? When is the last time you looked at device logs? Check device logs!

Advanced Options

You could install a port forwarding rule to let you view dump1090 (or better, dump1090-mutability) status remotely in your web browser. Remember that every port forwarding rule you install increases the available attack surface, making you more vulnerable to outside attack.

Use certificates on your SSH connection so you don’t need/use a password. That way others can try and guess the password but will never succeed.

Set up something to send you periodic notifications. Set up FlightAware to notify you if your site goes offline for more than 6 hours.

If you don’t like using SSH, you could install and use Webmin. Webmin is a pig, and if you know how to install and configure Webmin, you know how to use SSH and should stick to it as it’s simpler, more secure, and isn’t a pig.

Random Questions

“'But what if my friends don’t have a router/firewall?”

Get one for them. If they truly don’t have a hardware firewall between their cable or DSL modem and their computers, they are running with their pants down and it’s a matter of time until something nasty happens to their computers (it probably already has).

“How do I find their external IP address? How can I tell them to find their external IP address if it gets changed?”

On a web browser (at their location), go to whatismyip.com/ to see what the external IP address is. For extra credit, write a hack to run on your Pi that checks the external IP every 12 hours or so, and notifies you if/when it changes.

Summary

Let’s see… If I had the choice between managing a bunch of remote sites, and a two year old with a 130dB scream who is prone to middle ear infections…

bob k6rtm


#4

Either it worked, or you drove 3 hours to set it up. You popped up on my nearby sites.


#5

G’day b6rtm (Bob),

Can I ask how you do your backups to a remote server please? I’m looking at doing the same

Sorry for going a bit off topic guys…

Thanks,

Goldy


#6

My “remote” server is in the closet and on the same local area network as the Pis. That makes it a lot simpler. Cron runs a script twice a week that does a TAR backup (to a local directory on the Pi) and then copies that tar backup file to the server in the closet. The TAR backup file has the hostname and the date in its title.

What the hey, here’s the crummy code:


#!/bin/bash
# K6RTM 2014/07/17 back up raspberry pi and copy the backup to server volume /sheep/rpibackups
# using the $HOSTNAME for the backup file
# insure we have a server connection, it's in fstab
sudo mount -a
# put us in the backups directory
cd /backups
# remove old backups (dangerous, I know)
echo "Snuff old backups..."
sudo rm *.gz
# capture our startup time
T="$(date +%s)"
# capture date for date-stamping the backup file
_now=$(date +"%Y-%m-%d")
_bfile="/backups/"$HOSTNAME"backup-$_now.tar.gz"
_sfile="/sheep/rpibackups/"$HOSTNAME"backup-$_now.tar.gz"
# start doing the backup
echo "Starting backup to $_bfile..."
tar -zcpf "$_bfile" --directory=/ --exclude=proc --exclude=sys --exclude=dev/pts --exclude=backups --exclude=var/swap --exclude=sheep --exclude=pigs .
# done, let 'em know
T="$(($(date +%s)-T))"
printf "Backed up in %3d minutes.
" "$((T/60))"
# capture time again for copying to server
T="$(date +%s)"
# copy the backup file to the server
echo "Copying $_bfile to $_sfile"
sudo cp "$_bfile" "$_sfile"
T="$(($(date +%s)-T))"
printf "Copied to server in %3d minutes.
" "$((T/60))"


#7

Thanks heaps for the info Bob, I’m in a similar situation with my Rpi in the garage connected wirelessly to my home network which has a NAS box running 24/7. So I figured it would be handy to back things up once in a while.

Cheers,

Goldy