|
|
 When planning a WiFi network that is supposed to support a high number of users, like in a big office, a mall or a school, it becomes important to account for several pieces of information that are not directly related to the network itself.
These are pieces of information that affect the way the network can be used, and that are often under-evaluated.
The network engineer should in fact take into account not just the direct network needs, like the number of subscribers, the throughput for each subscriber, and the percentage of subscribers that will simultaneously try to access the WiFi network.
The network engineer needs also to take into account floor plans, coverage areas, building and wall materials.
This additional information will allow the calculation of the correct number of access points (AP) and their topological distribution, preventing the overlapping of different channels in the same area, which would negatively affect the connectivity of the various devices to the WiFi network, due to the competition of multiple AP for the same device.
From the topological perspective, additional attention needs to be given also to the WiFi protocol being used. For example, the use of 802.11b/g/n favors a distribution of AP that only use channels 1, 6 and 11, and those AP have to be distributed in sort of square cells distributed in a grid where the cells are half shifted, to avoid channel overlapping.
On the other end, the use of 802.11a/h, which also work on a different frequency band, favors a distribution where the cells are of hexagonal shape. In addition, the topology also affects which channels should be used with such protocol, since different channels may have different bandwidth and might have overlapping frequencies.
I just created a new web site that will be dedicated to the spreading of knowledge about electronics engineering.
The site will also be associated with a YouTube channel of the same name.
Please visit the site and subscribe to the YouTube channel. The videos will start coming very soon.
This article is the continuation of the series “Using the Raspberry Pi as a Server for the Home Network” and describes a quick procedure to install and configure a DNS server on the RPi.
Remember that for best results you should first install the RPi server as described in my previous articles. This achieves the goal of long life of the server, thanks to the usage of a real hard disk in place of the majority of the micro SD card used by the RPi (which tends to die faster than a real HD when many read/write cycles are done on it).
First , from any computer in the home network, ssh to the RPi server and login as root.
If you have a linux computer, you can just use the ssh command to do so.
If you have a MS Windows computer, you can still install a third party free application, like PuTTY, and use that to ssh to the RPi.
Once you have a window logged in as root into the RPi, you can go through the procedure I’m about to describe.
- install all the packages necessary for handling the DNS server by executing in sequence the following commands:
apt-get update
apt-get upgrade
apt-get install bind9 dnsutils bind9-doc
- the above sequence will install the DNS service and make it start right away. You can check that the service is running by issuing the following command:
service bind9 status
Here is an example of its output:
root@rasp1:~# service bind9 status
[ ok ] bind9 is running.
- A more detailed status of the service can also be obtained with the rndc command:
root@rasp1:~# rndc status
version: 9.8.4-rpz2+rl005.12-P1
CPUs found: 4
worker threads: 4
number of zones: 20
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
- In order to make the bind9 service start every time the RPi reboots, run the following command:
update-rc.d bind9 defaults
- Now you need to stop the service to adjust its configuration the way you need it:
service bind9 stop
- Make the appropriate changes to file named.conf.local, located in the directory /etc/bind. As an example, here are the contents I used in my home network:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "myhome.westell.com." {
type master;
file "/etc/bind/myhome.zone";
};
zone "myhome.org." {
type master;
file "/etc/bind/myhome.org.zone";
};
Note that there are 2 zones defined in my configuration file.
The first zone, myhome.westell.com, represents the domain name of my home network. You can choose whatever you like for your local network, as long as it is isolated from the external network by the router (possibly using NAT service), and as long as it is in the dotted form “domain.name“.
The second zone represents the domain name of my home WEB server, that is used only inside the home network by the whole family.
You will have to declare each zone as “master“, and will have to specify the file where the details for that zone are defined.
- Create the configuration files for the zones you have defined in the previous file. In my case they are myhome.zone and myhome.org.zone, located in the same directory /etc/bind.
Here is an example of the file contents:
$TTL 24H
@ IN SOA myhome.westell.com. hostmaster.myhome.westell.com. (
2015073001 ; serial
86400 ; refresh
3600 ; retry
604800 ; expire
10800 ; minimum
)
; Name servers
IN NS ns1.myhome.westell.com.
;Public servers
ns1 IN A 192.168.1.131
bind IN A 192.168.1.131
squid IN A 192.168.1.151
router IN A 192.168.1.1
ap IN A 192.168.1.70
; Private clients on the LAN
einstein IN A 192.168.1.49
dragon IN A 192.168.1.50
rasp1 IN A 192.168.1.51
rasp2 IN A 192.168.1.52
laserjet IN A 192.168.1.99
The first section of the file is a header that contains a number of information. You can leave everything as it is and it will work for most of the case. Otherwise, please read the bind documentation to learn how to make changes on those parameters.However, you will have to change one of the parameters in the header every time you make a change to this file. That is the serial number of the file, which is the first of the numeric fields. Every time you make a change to this file, do not forget to increment the serial number, otherwise the change will not be applied. You can use whatever rule to define the number. To easily keep track of the time when I make the changes, I use to set the serial number as the date of the day followed by a 2 digit progressive number, in case I make more than one change the same day. In this case I set the date putting first the year, then the month and lastly the day, so that the number always keeps increasing.The Name servers section is actually the name of the dns server itself, comprehensive of the domain name.The public servers section lists the name of all the other services in the network, which should have a fixed IP address. Only the names are listed, without the domain.The private clients section lists all the other elements in the network (laptops, tablets, phones, servers, …) that have a fixed IP address. Elements that do not have a fixed IP address cannot be listed in the file.Remember that all the spaces you see in the file are actually TABs. Make sure you use those and not the spaces. Also make sure that there are no tabs or spaces after the last character on each line.
- Modify the file /etc/resolv.conf. Here is the content of my file:
search myhome.westell.com
nameserver 127.0.0.1
Note that the first line describes the local domain of the home network. The second line represents the internal IP address of the server. Leave it exactly the same.
- Modify the file named.conf.options in the directory /etc/bind to set the DNS cache to the directory /etc/bind/cache, which should be on the hard drive, based on the installation instructions provided in the past articles. The directory information should be right at the beginning of the file. Do not modify anything else in it, unless you really know what you are doing.
- Copy the contents of /var/cache/bind (residing on the SD card) into /etc/bind/cache (residing on the HD).
- Now reboot you RPi. This will automatically start the DNS server with the configuration information you have provided.
At this point the DNS service should be happily running with your changes. You can test if it is working correctly by querying some of the IP addresses in your home network through the command line. For example, to find the IP address of the computer dragon in the home network, type:
nslookup dragon
and you should see a response similar to the following:
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: dragon.myhome.westell.com
Address: 192.168.1.50
The address provided in the last line is the actual IP address of dragon.
Let me know if this procedure works for you. Was it useful? Clear enough to follow?
Next time we will talk about proxy servers, what they are and how they are used. Then we will learn how to install one on the Raspberry Pi.
|
DZgameEngine Repository
on GitHub
|
|
