Intro (2nd edition intro probably okay).
How you establish the support infrastructure for your network is as important
as what type of equipment you use. Unlike wired connections, problems with
a wireless network are often invisible, and can require more skill and more
time to diagnose and remedy. Interference, wind, and new physical obstruc-
tions can cause a long-running network to fail. This chapter details a series
of strategies to help you build a team that can support your network effec-
tively. We also describe some standard troubleshooting techniques that have proven successful in solving problems in networks in general.
Every village, company or family has individuals who are intrigued by tech-
nology. They are the ones found splicing the television cable, re-wiring a bro-
ken television or welding a new piece to a bicycle. These people will take
interest in your network and want to learn as much about it as possible.
Though these people are invaluable resources, you must avoid imparting all
of the specialized knowledge of wireless networking to only one person. If
your only specialist loses interest or finds better paying work somewhere
else, they take the knowledge with them when they go.
There may also be many young and ambitious teenagers or young adults
who will be interested and have the time to listen, help, and learn about the
network. Again, they are very helpful and will learn quickly, but the project
team must focus their attention on those who are best placed to support the
network in the coming months and years. Young adults and teenagers will go
off to university or find employment, especially the ambitious youth who tend
to want to be involved. These youth also have little influence in the commu-
nity, where an older individual is likely to be more capable of making deci-
sions that positively affect the network as a whole. Even though these individuals might have less time to learn and might appear to be less interested,
their involvement and proper education about the system can be critical.
Therefore, a key strategy in building a support team is to balance and to dis-
tribute the knowledge among those who are best placed to support the net-
work for the long term. You should involve the youth, but do not let them
monopolize use or knowledge of these systems. Find people who are commit-
ted to the community, who have roots in the community, who can be moti-
vated, and teach them. A complementary strategy is to compartmentalize
functions and duties, and to document all methodology and procedures. In
this way, people can be trained easily, and substituted with little effort.
For example, in one project site the training team selected a bright young
university graduate who had returned to his village. He was very motivated
and learned quickly. Because he learned so quickly, he was taught more than
had been foreseen, and he was able to deal with a variety of problems, from
fixing a PC to rewiring Ethernet cable. Unfortunately, two months after the
project launch he was offered a government job and left the community. Even
a better salary could not keep him, since the prospect of a stable government
job was too appealing. All of the knowledge about the network and how to
support it left with him. The training team had to return and begin the training
again, this time with local people who were known to be remaining in the village.
Although this retraining took much longer, the community could be assured that the
knowledge and skills would remain in the village for a longer time.
It is often best to find a local partner organization or a local manager, and work with them to find the right technical team. Values, history, local politics, and many other factors will be
important to them, while remaining completely unfathomable to people who
are not from that community. The best approach is to coach your local partner, to provide them sound criteria, make sure that they understand that criteria, and to set firm boundaries. Such boundaries should include rules about nepotism and patronage, considering, of course, your own local situation. It may be impossible to say that you cannot hire kin, but it is best to pro-
vide a means of checks and balances. Where a candidate is kin, there
should be clear criteria and a second authority in deciding upon their candidacy. It is also important that the local partner is given this authority and is not undermined by the project organizers, thus compromising their ability to manage. They will be best able to judge who will work best with them. If they are well educated in this process, then your requirements should be satisfied.
Troubleshooting and support of technology is an abstract art. The first time you
look at an abstract painting, it may just look to you like a bunch of random paint
splatters. After reflecting on the composition for a time, you may come to ap-
preciate the work as a whole, and the “invisible” coherence becomes very real.
The neophyte looking at a wireless network may see the antennas and wires
and computers, but it can take a while for them to appreciate the point of the
“invisible” network. In rural areas, it can often take a huge leap of understand-
ing before locals will appreciate an invisible network that is simply dropped into
their village. Therefore, a phased approach is needed to ease people into
supporting technology systems. The best method is involvement. Once the
participants are chosen and committed to the project, involve them as much as
possible. Let them "drive". Give them the cable crimper or keyboard and show
them how to do the work. Even if you do not have time to explain every detail
and even if it will take longer, they need to be involved physically and see not
only what has been done, but how much work was done.
The scientific method is taught in virtually all western schools. Many people
learn about it by the time they reach high-school science class. Simply put, answers are achieved and problems solved by taking a set of possibilities, then slowly eliminating them through binary tests until you are left with one or only a few possibilities. With those pos-
sibilities in mind, you complete the experiment. You then test to see if the ex-
periment yields something similar to the expected result. If it did not, you re-
calculate your expected result and try again. The typical agrarian villager may
have been introduced to the concept, but likely will not have had the opportu-
nity to troubleshoot complex problems. Even if they are familiar with the scien-
tific method, they might not think to apply it to resolving real problems.
This method is very effective, although time consuming. It can be sped up by
making logical assumptions. For example, if a long-running access point
suddenly stops working after a storm, you might suspect a power supply re-
lated problem and thus skip most of the procedure. People charged with
supporting technology should be taught how to troubleshoot using this
method, as there will be times when the problem is neither known nor evi-
dent. Simple decision trees or flow charts can be made that test these vari-
ables, and try to eliminate the variables to isolate the problem. Of course,
these charts should not be followed blindly.
It is often easier to teach this method using a non technological problem first.
For example, have your student develop a problem resolution procedure on
something simple and familiar, like a battery powered television. Start by
sabotaging the television. Give them a battery that is not charged. Discon-
nect the aerial. Insert a broken fuse. Test the student, making it clear that
each problem will show specific symptoms, and point the way as to how to
proceed. Once they have fixed the television, have them apply this proce-
dure to a more complicated problem. In a network, you can change an IP
address, switch or damage cables, use the wrong SSID, or orient the an-
tenna in the wrong direction. It is important that they develop a methodology
and procedure to resolve these problems.
No troubleshooting methodology can completely cover all problems you will encounter when working with wireless networks. But often, problems come down to one of a few common mistakes. Here are a few simple points to keep in mind that can get your troubleshooting effort working in the right direction.
• Dont panic. If you are troubleshooting a system, that means that it was
working at one time, probably very recently. Before jumping in and mak-
ing changes, survey the scene and assess exactly what is broken. If you
have historical logs or statistics to work from, all the better. If others were using it before it started having problems, ask them to help you by having them tell you what was happening before it stopped working. Be thorough, but don't make it sound like you are accusing them of breaking it. They may have important information that will help you fix things and you want them to be on your side. Be sure to collect information first, so you can make an informed decision before making changes.
• Make a backup. This applies before you notice problems, as well as after.
If you make a complicated software change to a system, having a backup
means that you can quickly restore it to the previous settings and start
again. When troubleshooting very complex problems, having a configura-
tion that “sort-of” works can be much better than having a mess that
doesnt work at all (and that you cant easily restore from memory). Even in a broken configuration, make a backup copy of the parts of the system you will changing before
you try to make significant changes. If your changes result in an even worse state than when you first started working on it, you will at least have a known situation to go back to.
• Is it plugged in? This step is often overlooked until many other avenues
are explored. Plugs can be accidentally (or intentionally) unplugged very
easily. Is the lead connected to a good power source? Is the other end
connected to your device? Is the power light on? It may sound silly, but
you will feel even sillier if you spend a lot of time checking out an antenna
feed line only to realize that the AP was unplugged the entire time. Trust
me, it happens more often than most of us would care to admit.
• What was the last thing changed? If you are the only person with ac-
cess to the system, what is the last change you made? If others have ac-
cess to it, what is the last change they made and when? When was the
last time the system worked? Often, system changes have unintended
consequences that may not be immediately noticed. Roll back that change
and see what effect it has on the problem.
• The known good. This idea applies to hardware, as well as software. A
known good is any component that you can replace in a complex system to
verify that its counterpart is in good, working condition. For example, you
may carry a tested Ethernet cable in a tool kit. If you suspect problems with
a cable in the field, you can easily swap out the suspect cable with the
known good and see if things improve. This is much faster and less error-
prone than re-crimping a cable, and immediately tells you if the change fixes
the problem. Likewise, you may also pack a backup battery, antenna cable,
or a CD-ROM with a known good configuration for the system. When fixing
complicated problems, saving your work at a given point lets you return to it
as a known good, even if the problem is not yet completely solved.
Determine what still works. This will help you "put a fence around the problem". While complex systems like a wireless network can be made up of many different components, it is likely that the problems is only with a very small number of them. If, for example, somebody in a lab complains they can't access the Internet, check to see if others in the same lab are experiencing the same problem. Is there connectivity in another lab or elsewhere in the building ? If the problem is just with one user or within one room, you would want to concentrate your efforts on the equipment in just that one space. If the outage were more widespread, perhaps looking at the equipment where your outside connections comes in is more appropriate.
Do no harm. If you don't fully understand how a system works, don't be afraid to call in an expert. If you are not sure if a particular change will damage another part of the system, then either find someone with more experience to help you or devise a way to test your change without doing damage. Putting a penny in place of a fuse may solve the immediate problem, but it may also burn down the building.
Your troubleshooting team will need to have good troubleshooting skills, but may not be competent enough to configure a router from scratch or crimp a piece of LMR-400. It is
often much more efficient to have a number of backup components on-hand,
and train your team to be able to swap out the entire broken part. This could
mean having an access point or router pre-configured and sitting in a locked
cabinet, plainly labeled and stored with backup cables and power supplies.
Your team can swap out the failed component, and either send the broken
part to an expert for repair, or arrange to have another backup sent in. As-
suming that the backups are kept secure and are replaced when used, this can save a lot of time for everyone.
<Section about Common Network Problems should go here>
A user may start several simultaneous downloads, or download large files
such as 650MB ISO images. In this way, a single user can use up most of
the bandwidth. The solutions to this kind of problem lie in training, offline
downloading, and monitoring (including real-time monitoring, as outlined in
chapter six). Offline downloading can be implemented in at least two ways:
• At the University of Moratuwa, a system was implemented using URL redi-
rection. Users accessing ftp:// URLs are served a directory listing in which
each file has two links: one for normal downloading, and the other for
offline downloading. If the offline link is selected, the specified file is
queued for later download and the user notified by email when the down-
load is complete. The system keeps a cache of recently downloaded files,
and retrieves such files immediately when requested again. The download
queue is sorted by file size. Therefore, small files are downloaded first. As
some bandwidth is allocated to this system even during peak hours, users
requesting small files may receive them within minutes, sometimes even
faster than an online download.
• Another approach would be to create a web interface where users enter
the URL of the file they want to download. This is then downloaded over-
night using a cron job or scheduled task. This system would only work for
users who are not impatient, and are familiar with what file sizes would be
problematic for download during the working day.
When users need to transfer large files to collaborators elsewhere on the
Internet, they should be shown how to schedule the upload. In Windows, an
upload to a remote FTP server can be done using an FTP script file, which is
a text file containing FTP commands, similar to the following (saved as
c:\ftpscript.txt):
open ftp.ed.ac.uk
gventer
mysecretword
delete data.zip
binary
put data.zip
quit
To execute, type this from the command prompt:
ftp -s:c:\ftpscript.txt
On Windows XP and earlier computers , the command can be saved into a
file such as transfer.cmd, and scheduled to run at night using the Sched-
uled Tasks (Start->Settings->Control Panel->Scheduled Tasks). In Unix,
the same can be achieved by using at or cron.
(Need how to do this under Vista/7)
Users sending each other files
Users often need to send each other large files. It is a waste of bandwidth to
send these via the Internet if the recipient is local. A file share should be cre-
ated on the local Windows / Samba /web Novell server, where a user can put
the large file for others to access.
Alternatively, a web front-end can be used for a local web server to accept
a large file and place it in a download area. After uploading it to the web
server, the user receives a URL for the file. He can then give that URL to his
local or international collaborators, and when they access that URL they can
download it. This is what the University of Bristol has done with their FLUFF
system. The University offers a facility for the upload of large files (FLUFF)
available from http://www.bris.ac.uk/it-services/applications/fluff/. There are also tools like SparkleShare(http://sparkleshare.org/) and LipSync(https://github.com/philcryer/lipsync) which are Open Source packages that you can install and set up yourself to do much the same thing.
Consider using rsync ( http://www.rsync.org ) for those users who need to send each other the same/similar large files on a regular basis. The Rsync protocol is a synchronization rather than a straightforward file transfer protocol. Rather than simply send a file from start to end, it checks with an rsync server on the destination host to see if the file being sent already exists. If it does, both sides compare their copies and the sender transmits over only the differences to the destination. For example, if a 10 MB database of research data only has 23 KB of new data vs. the last version, only the 23 KB of changes will be transmitted. Rsync can also use the SSH protocol, providing a secure transport layer for sync actions.
There has been error in communication with booki server. Not sure right now where is the problem.
You should refresh this page.