Now that I have the Pi set up as both a wireless client, and a Wireless Access Point, it’s time to get the different network tools configured.
Frequently visited networks
The web GUI doesn’t handle connecting to networks. The GUI looks like it will, but it doesn’t actually accomplish anything. I am sure there is a way to configure around the problem, but I haven’t dug into it. Instead, in typical Chris fashion, I just use a super ugly hack based on like 15 minutes of research into the problem. I’ll figure out how to do it the right way in the future (yeah, right.) but for now I just change the SSID and PSK entries in /etc/wpa_supplicant/wpa_supplicant.conf and reboot the Pi.
I used this command to put the SSID info and passphrase into a file:
wpa_passphrase "Totally A Starbucks" LOLnotreallySBUX | tee sbux.txtWhere “Totally A Starbucks” is the SSID for your wireless network (put the name in quotes), and LOLnotreallySBUX is the pre-shared key for your wireless network. I created a different file for each network I want to connect to (home, work, etc.) and then created copies of wpa_supplicant.conf for each network. I call them, creatively enough, home, work, hotspot, and phone.
country=US
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
ap_scan=1
update_config=1Delete any/all network entries, and then use the CTRL+R command in nano to read in the contents of your various files (sbux.txt, in the example above). Then save the file. The sbux.txt file in the example above will look like this:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
ap_scan=1
update_config=1
network={
ssid="Totally A Starbucks"
#psk="LOLnotreallySBUX"
psk=3f825ee60dff2f77fccfd2a74ac08023d69e1a66918687ec513afe438a2bd1fd
}You will need one “wpa_supplicant.conf” source file for each network. You could call them wpa_supplicant.conf.home, or just home. Then I created shell scripts to copy the home file to wpa_supplicant.conf like so:
#!/bin/sh
sudo cp /etc/wpa_supplicant/home /etc/wpa_supplicant/wpa_supplicant.conf
sudo rebootI put the shell scripts in the /usr/local/bin directory, so that I could call them simply by typing home.sh or work.sh at the command prompt, and then wait for the Pi to boot back up. It ain’t pretty, but it works… every time.
Stupid (mobile) SSH tricks
Speaking of ugly shell scripts that ignore modern practices in favor of dubious hacks from 20 years ago, using SSH on a tablet is super glitchy. In order to conserve battery power, tablets and smart phones don’t like to run processes in the background. In order to conserve mobile data, tablets and smart phones don’t like to keep network connections open for any length of time. Most smartphone apps are front ends to websites or APIs, so you only need processing and network connection when the app is open. This is fine for just about every mobile app, but it murders SSH. There is a lot of talk about mosh in the Blink documentation. It’s literally a mobile-shell. It’s purpose-built to solve this problem.
So naturally, I am not going to use it yet. I’ll look into mosh at a later date (LOL). Instead I am going to create a Rube Goldberg contraption that is held together with awful shell scripts.
Because my SSH session to the Pi gets dropped a lot, I set up a host in Blink so that I can quickly connect to the Pi just by typing ssh@raspad.
On the Pi, I installed screen so that I can keep a session running and not lose whatever I was doing when the connection drops. To save a few keystrokes, I created another shell script in /usr/local/bin called “scr”:
#!/bin/sh
screen -DR I tried some different forms of alias, but this one actually works on the Pi.
Now, all I have to type is ssh raspad to connect to the Pi, and scr to connect to my existing screen session. And if no screen session is available, it creates a new one.
The virtual keyboard on the iPad is different in some ways from a “real” keyboard. There is no CRTL key, no arrow keys, and no F keys (F1, F2, etc.)
Most of the time, my primary workstation is a Windows PC. I have a special .screenrc that I use with PuTTy. For the life of me, I cannot figure out how to press F10 in Blink. So I just changed my .screenrc on the Pi to use F3-F6:
startup_message off
# Window list at the bottom.
# I got the long line of vars from https://bbs.archlinux.org/viewtopic.php?pid=423481#p423481
hardstatus alwayslastline
hardstatus string "%{.kW}%-w%{.W}%n %t%{-}%{=b kw}%?%+w%? %=%c %d/%m/%Y" #B&W & date&time
# From Stephen Shirley
# Don't block command output if the terminal stops responding
# (like if the ssh connection times out for example).
nonblock on
# Allow editors etc. to restore display on exit
# rather than leaving existing text in place
altscreen on
# bind F3 to detach screen session (to background)
bindkey -k k3 detach
# bind F4 to create a new screen
bindkey -k k4 screen
# Bind F5 and F6 to previous and next screen window
bindkey -k k5 prev
bindkey -k k6 next
Nah, fuck that. Just use Mosh.
Mobile Networking
The more work that goes into this little project, the more this is starting to look like a mobile home lab. While I do not have plans to remotely access the Pi from the Internet, nor do I have plans to serve anything from the Pi to the Internet, there are reasons to use dynamic DNS and an overlay network.
I have written about NeoRouter before as a means for gaining remote access to my home network. I also use it on my internal network to get access to my lab servers from my wireless network. My internal wired network (which is my lab, basically) is separated from the family wireless network. Most of the time, it’s to protect the family from my lab. Sometimes it’s the other way around. My modernized smuggling server sits on my lab network, and I use NeoRouter to access its various web interfaces.
Dynamic DNS is another thing that sounds like it’s mostly for remote access, but comes in handy for other things. I used to use it with my mobile phone to do VOIP when I traveled overseas, back what that was humanly possible. The tool that I prefer to use is DDclient.
sudo apt-get install ddclientConfiguring DDclient depends on the dynamic DNS provider that you are signed up with. But once you have it configured, you can test it with this command:
sudo ddclient -daemon=0 -debug -verbose -noquietThese are the kinds of tools that you set up before you need them. I am not sure if I will ever need them, but it would be nice to have them running properly if I did.
Cool Networking Tools
Now that you can connect to the Pi reliably, and you can get the Pi to connect to the different wireless networks that you may come into contact with in a semi-automated fashion, it’s time to break out the nifty networking tools to run in your screen session.
- WaveMon
For whatever reason, iOS lacks a decent WiFi scanner. Wavemon is a command line Wi-Fi analyzer. The Wi-Fi settings will show you nearby access points, and will use a couple of bars to show you the quality of your connection, but that’s it. To get useful signal info, you need to use Wavemon:sudo apt-get install wavemonAnd you run it from the command line like so:
sudo wavemonYou need root privileges to do scans for nearby access points. There are other mischievous tools that you can put to work from there, but mostly I use Wi-Fi scanners to see how crowded a given channel is when helping my friends and family set up their wireless networks.
- Nmap
So you found a wireless network to connect to, let find out what’s on it. Nmap is probably the most complicated command line tool in existence. I am by no means and expert on using it. In fact, I really only know how to do like 3 things with it, so I’m not going to go into using Nmap pretty much at all. What I can tell you is that if the wireless network you are on has AP-host isolation enabled, you won’t see any of the wireless clients. Fortunately, the tool is small and requires very little power. This makes it ideal for running on the Raspberry Pi.
To install Nmap:sudo apt-get install nmapTo scan a single host (one IP address):
sudo nmap 192.168.50.1I don’t remember if you need to be root to run Nmap effectively. Most of my experience with these tools is from Kali Linux (of which there is a Raspberry Pi distribution) where everything runs as root.
To scan a a whole network (all the IP’s in a subnet):sudo nmap 192.168.50.0/24
- TCPdump
We are on the wireless network and we have scanned it for cool things. Now let’s see what kind of chatter is happening. I don’t do it very often, but every once in a while, being able to monitor network traffic comes in handy. On a “real” computer, I prefer to use Wireshark, but tcpdump will work in a pinch. You install it like any other commandline tool:sudo apt-get install tcpdumpAnd like most scanning and monitoring tools, you need to run it at root. Like Nmap, TCPdump is super complicated. If you want to monitor traffic on your hostAP network, you will need to specify the uap0 interface for your scans. You can filter your results by pretty much anything. For example, you filter ICMP traffic like this:
sudo tcpdump -i uap0 protocol icmp
- iPerf3
Now that you have seen what’s happening inside your wireless network, it’s time to test network thruput. For this task, I like to use iperf3. You need another computer to run iperf3 to send data to, but any Unix host should be capable of running it. I use it on my admin workstation when I am tinkering at home, and I run it on my hosted VM to test Internet links.
Like WaveMon or Nmap, it’s dead simple to install:sudo apt-get install iperf3and also dead simple to run, assuming you have the right arguments:
On your remote end (aka the hosted server):iperf3 -sOn your local machine (in this case, the Pi):
iperf3 -c hostname
Now that the Pi has expanded the iPad’s ability to connect and to troubleshoot networks, it’s time to add features that normal people will appreciate, like storage and media streaming.
You see, the monster that we fear most is the one that we see in the mirror. Spies sweep for bugs, thieves keep things in safes, and hackers enable AP-Host isolation on their wireless networks. Host isolation keeps devices that are connected to an access point from talking to each other. They can see and talk to hosts that are on the same wired network as the AP, so you can connect to servers. The reverse is also true, servers on the wired network can see and talk to hosts that are connected to the AP. What absolutely doesn’t work with AP-Host isolation is an iPad that is connected via WiFi connecting to a RaspberryPi that is also connected to WiFi. You get nothing. Good day sir.
I’ve 
With my new upgraded VLAN home network, plus my quarantined/working from home/life circumstances, I used to have a desktop computer that was on all the time to support all of 
When I first started messing with Proxmox, I crashed my home network. If you aren’t interested in the story of my journey of network sexual awakening, 
I have done a decent job keeping the family wireless network packets away from everything, and everything away from the family by putting each network segment on its own dumb switch. Now it is time to blur those boundaries a bit by plugging each of those dumb switches into the smart switch. My network is broken into 4 subnets, so my VLANs will break down something like this:
Jesus, it’s been almost a year since I posted 
I did my best to simplify the network design:
My transition to Proxmox has been a rather involved, not so much because Proxmox is hard to set up (it’s not), but because I am tired of slapping old junky hardware together and hoping it doesn’t die, and then scrambling to fix it when it inevitably betrays me. Unlike most dudes with home servers and labs, most of my acquisitions were made years ago to 
In the years since then, I have taken to playing 
chrizzle23.com 
You must be logged in to post a comment.