Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Raspberry Pi: Amazing Projects from Scratch

You're reading from   Raspberry Pi: Amazing Projects from Scratch Explore the powers of Raspberry Pi and build your very own projects right out of the box

Arrow left icon
Product type Course
Published in Sep 2016
Publisher
ISBN-13 9781787128491
Length 593 pages
Edition 1st Edition
Arrow right icon
Authors (4):
Arrow left icon
Matthew Poole Matthew Poole
Author Profile Icon Matthew Poole
Matthew Poole
Ashwin Pajankar Ashwin Pajankar
Author Profile Icon Ashwin Pajankar
Ashwin Pajankar
Richard Grimmett Richard Grimmett
Author Profile Icon Richard Grimmett
Richard Grimmett
Arush Kakkar Arush Kakkar
Author Profile Icon Arush Kakkar
Arush Kakkar
Arrow right icon
View More author details
Toc

Chapter 12. Advanced Networking with Raspberry Pi

In the previous chapter, we built a cluster of Raspberry Pis that all interact with each other on a common network to accomplish a single task at a much greater speed than a single Raspberry Pi would perform. In fact, the MPI library is basically a networking library that delegates some computations to other processors connected in a network so that the master node doesn't have to deal with them. Now, in this chapter, we will learn about special networking concepts that power them kinds of cluster computers and in fact, the whole Internet. In this chapter, we will learn about:

  • Adding DHCP capabilities to our cluster
  • Adding a domain name system capability to our cluster
  • Writing a script for the autodetection of nodes
  • Writing scripts for the remote shutdown of cluster nodes

Introducing DHCP

DHCP (Dynamic Host Configuration Protocol): The host is simply a server, which means that the host computer is responsible for providing a service. The service could be of any kind. For example, a web server is responsible for hosting the files required for viewing a website. Again, the server implements the necessary communication protocols to allow many players to play against each other. A computer or application that uses the services offered by a server is called a client. Now you might know that every computer on the Internet is identified by a unique address known as the IP address.

A DHCP server is responsible for allocating such IP addresses to all the nodes in a network, and keeping track of the allocated addresses. In DHCP, dynamic means constantly changing, host means server, configuration refers to configuring your network settings, and protocol means a set of rules on how to do things. Described next is the procedure for the allocation of IP addresses by a DHCP server.

Suppose a node wants to join a network. It first sends a message to the server asking to be allocated an IP address. The server sends a message with an IP address and a time duration for which the node might keep that IP address. Then the server notes down the IP address given to the node in a table, along with the time it was given at and the validity duration.

Now, when the node joins a network, it has no way of knowing if there is a DHCP server. So it sends out a broadcast signal to the whole network intended just for the DHCP server. If there is a server, it sends out a reply offering an address.

Now, consider the situation when a node is shutting down or leaving the network cleanly. It sends out a signal to the server identifying itself and offers the IP address back to the DHCP server. The server then modifies the table, strikes off the host's name from the IP address, and then marks it available for allocation to other nodes in the network. But what if the node doesn't exit cleanly? For example, when the machine loses power or the network cable is just yanked out of it. This is where the time duration of allocation comes in handy. Once the duration of allocation of that IP address has passed, the node is automatically struck off from the table and that address becomes available again. Every time the server receives a packet of data from the host, its duration of allocation is automatically refreshed.

A few networking concepts

Since we have learned how a DHCP server operates, we will now work through an introduction to some important concepts related to networking that might be useful in understanding the operation of the network and also for debugging any errors we may encounter.

Though it might not look like it on first read, an IP address follows a predefined set of conventions and it is not handed out randomly. The IP address that is visible, for example 192.168.1.10, is actually composed of binary numbers. Each number separated by a decimal is actually a binary octet. So the preceding IP address actually looks like the following:

11000000 10101000 00000001 00001010

Now, an IP address is classified into multiple classes according to the address allocated to it by the DHCP server. They serve as a hierarchical system and also help to segment the IP address into classes such as private address and external address. They also help in distributing the IP address ranges to entities such as countries, service providers, and so on. There are the following classes of IP addresses:

  • Class A: In this class, the first bit of the first octet is always set to zero. So, the first octet ranges from 0000000001111111, or 0127.

    So Class A can only have an IP address from 1.X.X.X126.X.X.X as 127.0.0.1 is reserved for loopback IP addresses, that is, for the machine to refer to itself. Hence, this class can only have 126 networks (2^7 – 2) and 16777214 (2^24 -2) hosts.

  • Class B: Here, the first two bits of the first are set to 1 and 0 respectively. So, the first octet ranges from 1000000010111111 or, 128191.

    So, Class B can only have IP addresses ranging from 128.0.X.X191.255.X.X. Hence, this class can have 16,384 (2^14) networks and 65,534 (2^16 – 2) hosts.

  • Class C: The first three bits of the first octet are set to 110. The range of the first octet is from 1100000011011111, or 192223. So, Class C can have IP addresses ranging from 192.0.0.X234.255.255.X. This means that Class C has a total of 20,97,152 ( 2^21 ) networks and 254 ( 2^8 -2 ) host addresses.
  • Class D: This class of network has the first four bits of the first octet set as 1110. That gives it a range of 1110000011101111 or 235239. However, unlike the preceding three classes, Class D is used exclusively for multicasting. So, there is no need to get individual IP addresses, because individual host data is not required for this network to operate.
  • Class E: This class is reserved exclusively use for experiments, or R&D, or study. The IP addresses in this class can range from 240.0.0.0255.255.255.254.

Now, we move on to the concept of a subnet mask. A subnet mask is basically a 32-bit address that divides an IP address into the network and host addresses. A subnet mask sets all the bits for the network as 1 and all the bits for the host as 0. So, the subnet masks for the different classes of networks are given as follows:

  • Class A: 255.0.0.0
  • Class B: 255.255.0.0
  • Class C: 255.255.255.0

Class D and Class E do not have subnet addresses because Class D has multicast addresses and Class E only consists of reserved addresses.

Configuring a Raspberry Pi to act as a DHCP server

Now, we will perform a hands-on implementation of the preceding concept by setting up a Raspberry Pi from our cluster to act as the DHCP server. The Raspberry Pi selected for the purpose should be properly marked for identification because there can be only one DHCP server in a network. More than one can cause a lot of problems! If we have more than one DHCP server in a single network, the client nodes will get confused as to which server to send the IP allocation request to. We first need to install a program called dnsmasq, and we can do that with the following commands:

sudo apt-get update
sudo apt-get install dnsmasq

Once this is installed, we can go ahead and disconnect the Internet from the LAN and connect the network to a non-DHCP hub. Why, you may ask? Because the conventional routers that we use have a DHCP server built into them. So configuring a Raspberry Pi as a server and connecting it to the router might cause some problems. So we just connect it to a networking hub that interconnects all the nodes. We are now ready to modify the Raspberry Pi to get it running as a server.

By convention, DHCP servers will have the lowest IP address in a network from the range of IP addresses. And for a lot of private networks, this IP address space looks like this: 192.168.0.X. This means that the DHCP server will generally have 192.168.0.1 as the IP address and the other nodes will have 192.168.0.2, 3, 4, and so on up to 254 IP addresses.

So, logically, we need our Raspberry Pi to have this address and hold on to it so it defaults to the DHCP server every time the network is initiated. So, edit the network interfaces file:

sudo nano /etc/network/interfaces

In the interfaces file, eth0 refers to the connection from the ethernet port. If you've connected a Wi-Fi dongle to it, you will also see a wlan0 interface. This translates to Wireless LAN 0. Now, since our Pi is connected via an ethernet port, we find the following statement:

iface eth0 inet dhcp

Basically, this line is the one responsible for the Raspberry Pi acting as a DHCP client because it tells the Pi to try to get an IP address from a DHCP server, from the interface eth0. But since we want our Raspberry Pi to act as a DHCP server in the network, we comment this line out. Then, to set a static IP address for our server, we add the following lines:

# iface eth0 inet dhcp
auto eth0
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0

The interfaces file might look something like:

Configuring a Raspberry Pi to act as a DHCP server

The static option tells the Raspberry Pi to configure a static IP address and netmask, which is given in the statement below. Now, save this file by pressing Ctrl + X and Enter. To restart the networking service, enter the following command:

sudo service networking restart

Now, the Raspberry Pi's IP address will always be set to 192.168.1.1. We can also check this, as we did previously, by entering the command:

ifconfig

Now, we need to set up the software we installed earlier: dnsmasq. This is nothing but a DHCP server application for which we need to manually specify a configuration file according to our preferences. But since there already exists a default configuration file, we will make a backup of it. To do that, enter the following commands:

cd /etc
sudo mv dnsmasq.conf dnsmasq.default

The following command creates a new configuration file for dnsmasq:

sudo nano dnsmasq.conf

Once in the editing screen, enter the following lines into the configuration file:

interface=eth0
dhcp-range=192.168.1.2,192.168.1.254,255.255.255.0,12h

The first line in the file specifies the interface on which to listen to incoming DHCP requests. In this case, we have set it up to be the ethernet port of the Pi. The dhcp-range takes in four parameters:

  • Lowest IP address to be allotted
  • Highest IP address to be allotted
  • Netmask
  • Lease duration

We can now save and close the file by pressing Ctrl + X and Enter. For the settings to take effect, we need to ensure that our DHCP serves the Raspberry Pi and is the only device connected to the networking hub. Once all the other devices are removed, we can restart the DHCP service by:

sudo service dnsmasq restart

The DHCP server is now running and can listen to requests from clients connected to the same networking hub.

Finally, ensure that none of the other Raspberry Pis have a static IP address that is in conflict with our DHCP server. Preferably, there should not be any Pi with a static IP configured. The /etc/network/interfaces file should be as follows:

iface eth0 inet dhcp
# auto eth0
# iface eth0 inet static
# address 192.168.0.1
# netmask 255.255.255.0

Exit nano and restart the networking service with the following command:

sudo service networking restart

Now, we can connect all the Client Raspberry Pis to the networking hub. Once they are all switched on, they should be able to acquire their respective IP addresses from the DHCP server immediately. We can also check the allocated IP addresses by running the ifconfig command on the clients. The IP addresses are allocated randomly from the range given to the DHCP server.

Once the IP addresses are acquired, everything should work as expected. We can check the connections by pinging different nodes from another node. Do this with the following command:

ping 192.168.1.X

where X is the IP address of the other node. We can also check the connection to the DHCP server with:

ping 192.168.1.1

Another interesting experiment that can be performed with the setup is actually observing the connections go up and down. Firstly, we can shut down a client and observe it give back the IP address to the server. Run the following on a client of your selection:

sudo ifdown eth0

Once we do that, we will see an output similar to the following:

Listening on LPF/eth0/b8:27:eb:a8:6b:cc
Sending on   LPF/eth0/b8:27:eb:a8:6b:cc
Sending on   Socket/fallback
DHCPRELEASE on eth0 to 192.168.1.1 port 67

DHCPRELEASE is the actual statement where the IP address is handed back to the server by the client. Similarly, we restart the eth0 and observe the DHCP address being acquired. Run the following command:

sudo ifup eth0

We will see an output similar to the following:

Listening on LPF/eth0/b8:27:eb:a8:6b:cc
Sending on   LPF/eth0/b8:27:eb:a8:6b:cc
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.1.1
DHCPACK from 192.168.1.1 bound to 192.168.0.X -- renewal in 40000 seconds

In this exchange, DCHPDISCOVER, DHCPREQUEST, DHCPOFFER, and DHCPACK are of importance. They correlate with the acquisition procedure in the IP address through a DHCP server, as described before. It is left as an exercise to the reader to figure out their respective functions.

Introducing Domain Naming System (DNS)

In the previous section, we learned to add the DHCP server to our Raspberry Pi cluster. This was done mainly so that each Raspberry Pi in our cluster could be identified by a unique IP address. Now, as you can imagine, the bigger our cluster grows, the harder it is going to be to remember the IP address of each Raspberry Pi. Humans find it hard to remember long sequences of numbers, which is what the IP addresses are. But there is a way by which we can easily connect to different nodes without having to remember their IP addresses.

This method is called a Domain Name System (DNS). Its basic function is to translate IP addresses into words so that it becomes easier for us to remember. For example, the DNS server will translate the IP address 192.168.5.43 into raspberrypi.org and vice versa to make it easier to connect to. Indeed, this is what happens on the Internet. Each website has an IP address behind it.

When you type a URL into your browser, your computer first contacts the DNS server and asks for the IP address that it is associated with. The DNS server then searches its database for the name and returns the IP address to your computer. This whole process is called a DNS query.

Now, we can have multiple DNS servers in a single network. This way, when one DNS server doesn't have an address saved in its database, it can pass the query to the second DNS server, and so on. This is known as an iterative DNS query. This is what actually happens on the Internet. There are millions of websites on the Internet and having a single DNS server that holds a large database is not only unfeasible but also unreliable. So, there are millions of DNS servers that are distributed across the world and act together to resolve billions of translation requests from millions of clients.

Note

But here is an interesting problem. In a DHCP network, IP addresses are dynamic, which means that the IP address of a node might change. Think about how a DNS server might handle that situation. You can do that as an exercise.

Setting up a DNS server on the Pi

Now, we will learn about the practical part of setting up a Domain Name System server on our own cluster of Raspberry Pis so as to learn the intricacies of the system. We will set up a DNS server on the same Pi on which we set up the DHCP server earlier. Since we took care to see that it is easily identifiable from the other client Raspberry Pis, we can begin the setting-up procedure.

We use the same software, dnsmasq, which we used for the DHCP server, as it also has the capability to run a DNS server. Other than that, we don't need to install anything extra. As a sanity check, before beginning the following tutorial, try to ping the server from one of the clients. Although multiple DNS servers can be configured, for the purposes of this tutorial, we will be using only one Raspberry Pi as the server.

As the DNS server doesn't have a broadcast system like DHCP, the clients can't locate it easily. So they need to be told the IP address of the DNS server, and one way of doing it is to make the DHCP server pass the IP address to the client. This can be done at the same time as the DHCP server is allotting its own IP address. In this case, the IP address of both the DHCP server and the DNS server is the same. Open up the dnsmasq configuration file (dnsmasq.conf) for editing with the following command:

sudo nano /etc/dnsmasq.conf

The first thing we do is specify that the IP address of the DNS server and DHCP server is the same. To do this, add the following line at the end of the file:

dhcp-option=6,192.168.1.1

Now that the clients know where the DNS server is located, we need to create a lookup database that contains the IP addresses with their corresponding names. Although in actual DNS servers a more sophisticated database platform is used, for example SQL, here we will use a simple text file as a demonstration. Add the following two lines to the configuration file:

no-hosts
addn-hosts=/etc/hosts.dnsmasq

Here, the no-hosts line tells dnsmasq to ignore the default /etc/hosts file for DNS queries. And the next line specifies that our own file, /etc/hosts.dnsmasq, should be used for DNS queries.

The next step in this process is to create our hosts file. To do that, enter the following command:

sudo nano /etc/hosts.dnsmasq

Since this file that didn't exist before, we should now be editing a blank file. New entries can be added in a specific format, which is the IP Address, followed by a tab, followed by the name. For example:

192.168.1.1	server

Here, the first part is the IP address, the second part is the tab spacing, and the third part is the name associated with that IP address.

Note

We have to add a tab instead of multiple spaces for it to work.

Now, save and exit this file. Make sure that the server is the only device connected to the networking switch. Unplug all other devices before restarting the dnsmasq service. Restart the service with the following command:

sudo service dnsmasq restart

But there is one more thing. Since our server is set up with a static IP address, we also need to tell the DHCP server to use its own DNS server. We do that through a file named /etc/resolv.conf. Open it for editing by:

sudo nano /etc/resolve.conf

Change the contents of the file to:

nameserver 127.0.0.1

Now, 127.0.0.1 is a reserved IP address that is used to refer to one's own system. So, it would be the same if we put 192.168.1.1 as the IP address. However, if the server's IP address changes, we would need to change this file manually. So, we put 127.0.0.1 as the IP address of the nameserver. Exit the file and restart the networking service:

sudo service networking restart

Finally, connect all the client Raspberry Pis to the networking hub. They should start receiving their allocated IP addresses. Once all the Pis are connected to the network, you can run:

ping server

And you will start getting a response. If this is successful, it means that the ping request was first passed to the DNS server inside the server Pi and, when the hostname was resolved, a response was obtained from the IP address of the server.

Configuring the setup for a web server

Let's say, for example, one of the Raspberry Pis is configured as a web server. So, the task now will be to set up the cluster in such a way that you can type a name in a browser and have the home page of the web server load up!

By convention, web servers are supposed to have static IP addresses. This is so that DNS servers can store their hostnames without worrying too much about IP addresses changing. Since we earlier put in the entire range of IP addresses possible as the range for the DHCP server, we will modify that range so that we can reserve some static IP addresses for our web servers. For this, again edit the /etc/dnsmasq.conf file and modify the dhcp-range variable to the following:

dhcp-range=192.168.1.40,192.168.1.254,255.255.255.0,12h

So, now we have non-DHCP IP addresses from 192.168.1.2 to 192.168.1.39, which we can allot to the web servers. One of the ways to do this is to modify /etc/network/interfaces and /etc/resolve.conf on the web server itself and set it so that the web server always gets a static IP address. But, we can also identify the web server by its MAC address, which is the unique hardware address of the network interface, and give it the same IP address every time.

This would require a modification of the dnsmasq.conf file. We need to know the MAC address of our web server Pi for this. It can be easily found by executing ifconfig in a new terminal and looking for the HWaddr field ; it will be in the form b8:27:eb:a8:6b:cc. Remember that this address is unique for every device. Once we have this address, we will add the following line in the dnsmasq.conf file on the server Pi to assign a specific IP address for this MAC address:

dhcp-host=b8:27:eb:a8:6b:cc,192.168.1.5

This configures the DHCP server to always allot the 192.168.1.5 IP address for this MAC address. Now, we just need to add a name for our web server in the hosts.dnsconf file. Open it for editing with nano and just add the following line at the end of the file:

192.168.1.5	webserver

So, it finally looks like this:

Configuring the setup for a web server

Restart the dnsmasq service for the changes to take effect by:

sudo service dnsmasq restart

Finally, we have to make the web server Pi take up the new IP address so that it can be addressed by name in the DNS server. To do this, execute the following commands:

sudo ifdown eth0
sudo ifup eth0

This will make the Raspberry Pi disengage with the DHCP server; when it tries to re-acquire the IP address, the DHCP server will allot the static IP address we defined in the configuration file.

To test if the DNS server works with the web server or not, you can run the following command from any of the other client Pis:

ping webserver

If you get a response, it means a DNS server is set up correctly. If not, then you need to check whether all the steps were followed correctly.

Automating node discovery in a network

Currently, we have very few devices in our network. But, there will be a situation when there will be many nodes and managing them manually will be a difficult task. In a large cluster, there will be many nodes that are inactive or unserviceable. If we try to connect to them using a script that has the IP address of the clients hardcoded, we will meet with a lot of errors. This is why there is a need for automatic node detection that automatically detects the active nodes in a network and saves that information so that other programs can use it. One such program is MPICH, which we learned about in the previous chapter. As you might have learned, whenever we execute a program using MPICH, we have specified a filename that contains a list of active nodes that can be used for computations. However, if one of the nodes is inactive or unresponsive, the script will not work properly and will waste valuable computation resources.

For node discovery in a network, we will use a program called Nmap, which is short for network map. Nmap is a free security scanner, port discovery, and network exploration tool. Install it using the following command:

sudo apt-get install nmap

Note

Find out more about Nmap here:

https://nmap.org/.

As we learned with the IP addresses in the second section, the following IP address:

192.168.1.1

actually looks like the following:

11000000 10101000 00000001 00000001

Now that we have this information, we can move on to learn how to use the Nmap tool. The commands for scanning active IP addresses are:

nmap -sP 192.168.1.0/24
nmap -sP 192.168.1.5-100

This is what the output looks like:

Automating node discovery in a network

The preceding are two separate commands and we will learn what each of them does. The first command scans the whole range of IP addresses in a network from 192.168.1.0192.168.1.255. In this command, we specify a mask of 24 bits, which basically tells Nmap to not change the first 24 bits of the IP address, which, according to the information we learned earlier, means that the first three numbers of the IP address will remain constant and only the last number will be varied and checked for a response. Since our network will only contain IP addresses starting with 192.168.1, due to the way our DHCP server is set up, this approach is good.

The second command explicitly specifies the range of the IP addresses to scan. This is useful as you want to find active nodes in a specific range. One use case for this is to find out all the client nodes in a network.

Summary

In this chapter, we built upon the foundations laid down in the previous chapter to gain more understanding about the concepts of networking and how they are applied to a cluster of Raspberry Pis.

Specifically, we learned how to set up a DHCP server on a Raspberry Pi and learned the mechanics of how IP addresses are allocated to different clients. We also observed the exact procedure of how the allocation takes place.

As a next step, we set up a DNS server, too, that works with the DHCP server and assigns names to the IP addresses so that the nodes are easily accessible. Using the same methodology, we learned how to assign a name for a Raspberry Pi-based web server so that we can open websites on our own network.

Finally, we learned about a tool that helps us discover active nodes on the network so that we do not have to face the inconvenience of assigning computations to a non-active node that could potentially crash a program or wrong computations.

You have been reading a chapter from
Raspberry Pi: Amazing Projects from Scratch
Published in: Sep 2016
Publisher:
ISBN-13: 9781787128491
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image