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.
In my last post, I talked about why I wanted to do this project, which was mostly about not wanting an old iPad to sit in a box with all my other crap. It was also about a clever use of a Raspberry Pi. While 99% of the work in this project is setting up the Pi, this post is about setting up the iPad.
Blink
This Christmas, we upgraded the kids’ iPads, and I inherited my daughter’s old iPad Air 2. I had an iPad years ago, but I didn’t like it.
I also hate tablets because they come close to doing what a netbook used to, before 10 inch screens went extinct. (Yes the GPD Pocket is a thing, it’s also the price of a gaming laptop. I already have too many laptops as it is, without dropping 12 Benjamins on another one because it’s cute.) Netbooks are great for note taking in a meeting or class, or for doing light system administration tasks where you need basic networking tools like ping, ssh, or more serious tools like network scanners or wifi analyzers. Android tablets do ok in this regard, but the lineup of network tools for iOS are not great.
Using a tablet keyboard is usually pretty lame, especially a keyboard with no touchpad. Taking my hand off the keyboard to touch the screen is a major distraction. I had a touch screen laptop for years and rarely used that feature. I think I have a decent little Bluetooth keyboard somewhere, one with that ThinkPad nipple-looking thing. It’s probably sitting in a box with a bunch of broken tablets.
Amateur radio has taught me about the importance of charging batteries in the field. “Field rechargeable” is probably a better term than “solar”. Solar is more of a guideline. If something can charge from USB, you can probably charge it off of solar. If you can charge it off of solar, you can probably charge it off either 5v USB, or 12v car electrical. Wall and car chargers for smartphones are great sources of USB power, and in the family travel scenario, car and wall power make more sense. USB ports in computers can also charge USB devices, although they tend to do it very slowly. The Pi 4 can’t run reliably from a laptop USB.
The winter holidays are a depressing time for me, so the last month or so of the year I like to really throw myself into a game or project. After being ridiculed by one of my DnD bros about how inefficient and antiquated my piracy set up is, I decided to modernize by adding applications to automate the downloading and organizing of my stolen goods.
Because I am a hardware/operating system dude that dabbles in networking, LXC makes perfect sense to me. If you have a virtualization platform, like an emulator or a hypervisor, and you run a lot of similar systems on it, why not just run one Linux kernel and let the other “machines” use that? You get separate, resource efficient operating systems that have separate IP’s, memory allocation, and even storage.
I like that Docker can pop up an application very quickly with almost no configuration on my part. Docker storage and networking feels weird to me, like a bunch of things stapled on after delivering the finished product. From a networking standpoint there is an internal IP scheme with randomly generated IPs for the containers that reminds me of a home network set up on a consumer grade router. If you want the container to have access to the “outer” network, you have to map ports to it. Storage is abstracted into volumes, with each container having a dedicated volume with a randomly generated name. You don’t mount NFS on each container/volume, instead you mount it on the host and point the container to the host’s mountpoint. It’s kind of like NFS, but internal to Docker using that weird internal network. Also, in typical developer fashion, there is very little regard for memory management. The VM that I am running docker on has 16gb of RAM, and its utilization is maxed out 24/7. Maybe Docker doesn’t actually use that RAM constantly, it just reserves it and manages it internally? It’s been chewing through my media collection for a couple of months now, and slowly but surely new things are showing up in Plex. Weird as the stack is, it’s still pretty rad.
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 
During the initial setup of the Proxmox hosts on VirtualBox, you probably saw an error message about KVM virtualization. I dismissed it as not a big deal. The truth is that this whole “virtualization inside of virtualization” exercise won’t produce any useful PVEVMs. I haven’t done much troubleshooting, but I am fairly certain that while the PVEVMs boot up and you can log into their consoles, they don’t really talk to each other or your physical internal network. That’s not as cool as I had hoped, but the point of this exercise was to figure out the network design for a Proxmox Cluster, not to play with cool double-layer virtual machines. I am sure that you can so some cool router Kung Fu to get them going for real, but for this exercise, PVEVMs booting up is enough. We’re just going to move them around the cluster so see how it all works.
Once you have decided your approach, build 3 new containers. It takes a long time, but it demonstrates your need for a central data store for non-VM files. This is where a NAS would be handy. You could set up the NAS to store ISOs, container templates, and backups so that they would be accessible to all the nodes.
Replication is done on a per VM and per host basis. So you will want to make sure that each VM has a job created to replicate to the other nodes. You only need two jobs for each VM. If you migrate a VM to another host, the replication job will update. The first time the job runs it will take a while. There isn’t a progress bar or anything, so you will have to check the ZVMZ storage on each node to make sure that there are copies of all of your VMs.
I did my best to simplify the network design:
chrizzle23.com 
You must be logged in to post a comment.