Preface¶
This is the third article in a series about Glanceable Displays and my efforts to create one for my household. For other articles in the series, click on the title of the article under the heading “Glanceable Displays” on the right side of the webpage.
Introduction¶
In the previous article, I detailed the steps required to get the Raspbian (Linux) operating system installed on a Raspberry Pi with remote access through SSH enabled.
This article attempts to move the needle forward by tackling a number of the issues that I had in getting necessary foundation services up and running on my Raspberry Pi. The two services that I had issues with were: ensuring that Wi-Fi was working properly and that the Raspberry Pi clock was being set properly. Until I was confident that these two issues were resolved, I was not confident that I would be able to use my glanceable display in it’s intended location, as that location does not have any wired network access.
Note
As the steps in the previous article concluded with providing SSH access to the Raspberry Pi, I performed all of the following configuration using an SSH client. While you are welcome to enter them through a keyboard directly connected to the Raspberry Pi, I did not test any of the steps in that manner.
Warning
From the experience of reviewing and retrying these steps, sudo reboot is a good friend. If it looks like something didn’t work and you think it should, consider using sudo reboot to reboot the machine and carry on from there. This is very handy when changing configuration.
Step 1: Wi-Fi Access¶
Unless you have the fortune of having a wired network outlet available near your display AND enjoy the aesthetic of having a network cable going into your display, you most likely want to enable Wi-Fi access to your display. Here are the steps I went though to get wireless access enabled.
Step 1a: Searching for Existing Wireless Access¶
The first command that I used to check for wireless network access was the ifconfig command.
This is a general command used to determine what network connections are available. I had a
network cable running into the machine, but nothing else, so the following response1
was expected:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
...
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
...
While it looks like gibberish to some, it was what I expected. Linux systems often use the
tag eth0 for the first wired connection and the tag lo for the loopback connection. The
important thing I noticed was that I didn’t see a wlan0 tag, typically used for the first
wireless connection. The clear observation I had was that the system did not currently have
a capability to have a wireless connection.
This observation on a normal computer running Linux might be farfetched, but from information gained researching the Raspberry Pi on various forums, it is relatively normal for a Raspberry Pi to not have any wireless capability built-in. As wireless components have recently become cheaper, it seems like it is only the latest versions of the Raspberry Pi 3 have wireless access built in.
Note
I have not repeated these steps on a newer Raspberry Pi, but I would expect that doing so would allow me to skip the next section on installing the adapter. I will update the article once I have tested that scenario.
Step 1b: Installing a Wireless Adapter¶
In my instance, the machine I was configuring did not have any wireless capabilities built in. That was resolved in short order by noting down the connection requirements for the household router (WPA2-PSK (AES)) and purchasing an inexpensive USB Wi-Fi adapter from a nearby store.
Note
If possible, use that store’s online presence to inspect the possible adapters, verifying 1-3 choices for adapters that meet the router’s specifications. While not necessary, it can avoid round trips to the store to try and find the right adapter. Doing this, I found that my local store had a TP-Link TL WN823N USB Adapter that was right for the job for $15.
Returning home from the store with an inexpensive TP-Link TL WN823N adapter, I powered off the
Raspberry Pi, installed the Wi-Fi adapter in one of the open USB slots, and powered up the
Raspberry Pi. Once Raspbian had booted up, I reconnected to the machine using SSH and entered
the lsusb command. This command is similar to the ls command to list files, but is used
to list various USB components that the machine has recognized. The response I received from
that command was:
Bus 001 Device 006: ID 2357:0109 TP-Link TL WN823N RTL8192EU
Bus 001 Device 005: ID 0461:4e26 Primax Electronics, Ltd
Bus 001 Device 004: ID 0461:4d64 Primax Electronics, Ltd
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Seeing as the adapter I bought was a TP-Link TL WN823N, I was relieved to see it listed as device 06. At this point it was clear to me that the Raspberry Pi recognized the adapter, and it was time to install the required drivers.
Step 1c: Installing the Wi-Fi Drivers¶
From a research point of view, this was the most frustrating part of getting wireless access
working. In most of the articles I researched, the authors seemed to assume that the drivers
for a given adapter would already be installed in the Raspbian distribution. The few articles
I found that handled missing drivers were very specific, and not very helpful. They often
used the Raspbian apt-get family of commands to look for an adapter, and each adapter
I found seemed to have a slightly different way of making sure it worked properly. As I
was writing down notes for this article to help other people, that experience was frustrating
and was far from helpful.
Everything changed when my research led me to a reference to the Fars Robotics driver install script. This breaks down the process into the following three commands:
sudo wget http://www.fars-robotics.net/install-wifi -O /usr/bin/install-wifi
sudo chmod +x /usr/bin/install-wifi
sudo /usr/bin/install-wifi
Instead of playing around with apt-get commands and looking for a specific driver, this
script automated the process, finding the correct driver and installing it. The commands
first downloaded the script into the /usr/bin directory, set it to be executable, and then
executed the downloaded script. Within 60 seconds, it had completed, and it’s output suggested
that the driver for my TP-Link TL WN823N had installed successfully.
To double check that it worked properly, I resubmitted the ifconfig command and got the
following:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.3 netmask 255.255.255.0 broadcast 192.168.2.255
...
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
...
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
...
Great! Progress! The new Wi-Fi adapter was installed, the driver was connected, and Raspbian
was reporting that it could talk with it! From experience, I now had to configure the machine
to connect to the wireless network. From the output, this was somewhat obvious. For the
eth0 and lo adapters, there was a line beginning with inet that described the current
IPv4 setup for that adapter. As the wlan0 adapter was missing the inet line (and also the
inet6 line), Raspbian could talk to the adapter, but the adapter was not connected to the
local Wi-Fi network.
Next stop, configuring Wi-Fi access.
Step 1d: Configuring Wi-Fi Access¶
Similar to the previous section on Installing the Wi-Fi Drivers, I found many articles on how
to do this by hand, each with its own little twist on how to set things up better. In my case,
I wanted to go for repeatable and easy, and the sudo raspi-config command used
to set up SSH access
in a prvious article
proved to be the best solution.
From the main menu, I selected 2 network options and then N2 WiFi. As it was my first time
setting up the network on this machine, I was prompted for my country, which I entered. Next I
was prompted with Please enter SSID, and I responded with my router’s SSID. This was
followed with the inevitable Please enter passphrase. Leave it empty if none., to which I
responded with my router’s password. Hoping everything would work out, I pressed the Next
button.
After waiting for approximately 30 seconds, the focus was returned to the main configuration
screen. Exiting out of that screen and back to the main screen, executing the ifconfig now
had the following response:
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.2.3 netmask 255.255.255.0 broadcast 192.168.2.255
...
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
...
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.67 netmask 255.255.255.0 broadcast 192.168.2.255
...
This was what I was waiting for! At the moment, the eth0 wired connection had an address of
192.168.2.3 and the wlan0 wireless connection had an address of 192.168.2.67. The address
192.168.2.3 is the one I had been SSHing into while fixing up the Wi-Fi, so that lined up.
Based on my router’s configuration, 192.168.2.67 was a likely address for a new machine, so
that lined up.
Warning
If you have your network secured, make sure you follow the normal steps for adding a new machine to your network. This may include asking your local network person to add your machine to the network. In my case, forgetting that step cost me over an hour trying to figure out why the Raspberry Pi would not connect to the network!
To verify things were working, I repeated the relevant portions of Step 5: Setting Up SSH Access from the previous article, using the new address 192.168.2.67, instead of the old one 192.168.2.3. Once this succeeded, the final test was to disconnect the physical connection and see if the wireless connection worked.
It did take a lengthy bit of time, and one trip to a local store for hardware, but it was very gratifying being able to talk to the glanceable display over a wireless connection!
Step 2: System Clock Synchronization¶
While the Raspberry Pi is a useful little machine, it’s small form causes it to not have a
component that many machine take for granted: a system clock. Not having this set up for your
glanceable display can cause any display of time to be extremely out of sync. In addition,
if the Raspberry Pi’s time is not decently close to the actual time, the downloading of extra
components through mechanisms such as the apt-get commands may fail. To avoid these issues,
setting up proper system clock synchronization is a must.
Pre-Requisite¶
The list of servers and download locations for the apt family of commands has most likely
changed since the Raspbian image was constructed. If this is the case, any apt commands
that require any kind of package updates will most likely fail. To solve this before it
becomes an issue, I issued the following command to update those tables.
sudo apt-get update
Step 2a: Installing the NTP Service¶
The quickest and most efficient solution to solve the synchronization issue was to install the
NTP time service. In the distribution of Raspbian that I was using, the NTP service was not
installed. When I entered the command sudo systemctl status ntp, I saw the following
output:
Unit ntp.service could not be found.
Based on various articles, the clear solution was to install the NTP service using apt-get
with the following command: sudo apt-get install ntp. Once that finished, when I repeated
the sudo systemctl status ntp command, I then received the following output:
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
Active: active (running) since ...
At this point, I was satisfied that the NTP service was up and running, but not that it was working correctly.
Step 2b: Diagnosing the NTP Service Configuration¶
Once the service was loaded, I needed to confirm that the NTP service was working properly.
The easy way to do this was to reboot the machine using sudo reboot and then use the
date command to check the date. When I followed that pattern, the date was over 2 weeks
off from the actual time. Time to go into debug mode.
The documentation on the NTP service mentions a useful command: ntpq -p. This command
lists information about what the current NTP service is doing. Presented as a series of
columns, the important column was the number of seconds since the service successfully
contacted a specific NTP server.
When I checked the output of the command, I was greeted with the following table:
remote refid st t when poll reach delay offset jitter
==============================================================================
0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.004
1.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.004
2.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.004
3.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.004
Looking at the when column, the issue seemed to be that it was not able to connect to those servers and get information about them. Doing a bit of research, it turned out that other people have had problems with the default servers for the NTP server, and there were ways to address that.
Step 2c: Changing the NTP Service Configuration¶
Now that I had the NTP service installed and had issues with the default configuration, it
was time to look at it. The configuration for the service is located in the file
/etc/ntp.conf. As I had found issues with the default configuration, I needed to learn
more about this configuration file to fix the problem.
Looking at the file using a command like more /etc/ntp.conf was daunting. There were a
number of 1-2 line sections with multiple lines of comments before them. When I saw that,
I was concerned. In my experience, a large comment to useful line ratio means they are
commenting the heck out of it, because people have done stupid things in the past.
Learning more about the configuration, it turned out that I only needed to look at one particular section. The most important part of the configuration is a section that started with the follow text:
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
Right after this text, there was a group of servers specified where the first part of the server name was a number between 0 and 3, and the rest of the server name was the same. Many of the articles I found didn’t touch the rest of the file, but focused on that small set of lines.
A very useful page I found during my research was the
NTP Pool Time Servers
page. Near the bottom of that page is a table that lists the various geographic areas,
from which I selected the North America selection. At the top of the next page was a
clearly marked section of text, with clear instruction to add that text to the ntp.conf file.
Given that information, I went back to the Raspbian machine, entered sudo nano /etc/ntp.conf
to edit the /etc/ntp.conf file, and replaced the default debian servers in that section
with the information from the clearly marked section of the NTP Pool Time Servers page.
Followed up with Ctrl-X to save, y to save the file, enter to use the provided file
name, and it was changed. Just to make sure, I did another sudo reboot after verifying my
changes, and the date command now returned the right date.
Step 2d: Verify that the NTP Service is Working¶
Warning
As a number of Denial-Of-Service attacks have used the NTP port to return bad information, a number of routers come pre-configured with their firewalls set to block port 119 and 123, the NTP ports. If you follow these instructions and are still having issues, check the firewall settings for your computer and your router.
Previously, when I had checked the status of the NTP service using the ntpq -p command,
I did not seeing anything other than - in the when column of the output. If things were
working properly, I would expect that column to change.
Submitting the ntpq -p command once the system rebooted, I got the following output:
remote refid st t when poll reach delay offset jitter
==============================================================================
-grom.polpo.org 127.67.113.92 2 u 21 64 1 59.302 9.614 6.053
+199.180.133.100 140.142.234.133 3 u 17 64 1 26.382 5.225 3.611
+time1-inapsales 216.218.254.202 2 u 17 64 1 41.043 -2.463 4.417
*vps5.ctyme.com 216.218.254.202 2 u 18 64 1 36.759 -5.673 2.870
Submitting the command multiple times, I observed that the when column values increased to a certain point before they started over with a low single digit number. From the documentation, this was a good indication that each of those servers was being queried successfully, then registering itself for the next time to check against that server.
Seeing the successful connections with the NTP servers, the time synchronization issues
were cleared up! Just to be sure, I did a couple of cycles of sudo reboot and checking
the time, with no errors.
What Was Accomplished¶
This article detailed the steps taken to fix two of the major issues I had after installing Raspbian on my Raspberry Pi: the Wi-Fi access and the system clock being out of sync. I worked through the various steps taken to ensure that the wireless access was up and running, including the various checks I did throughout the process. I then walked through the steps I took to ensure that the time on the Raspberry Pi was reflecting actual time, despite not having an onboard system clock.
With this accomplished, I had confidence in having firm foundations on which to start building the display part of my glanceable display.
What’s Next?¶
In the next article in this series, Glanceable Displays: Setting Up Our Display I walk through the steps I took to setup the Raspberry Pi to start the display upon boot for the glanceable display.
-
In any of these examples, a set of ellipses (“…”) are used to denote that content was removed that was either sensitive or not relevant to the example being presented. ↩
Comments
So what do you think? Did I miss something? Is any part unclear? Leave your comments below.