How to Configure a Cisco Frame Relay Switch - Part 1

Today I am going to explain how to create a Frame Relay switch using the most basic configuration possible. As I searched the Internet in search of instructions on how to setup a Frame Relay switch for use in my own lab, I was somewhat frustrated because the procedures I found were confusing in how they were written, mainly because they tried to implement too many concepts and principals at once. Their diagrams, if any, were also not all that great either.

So in this lab, I am going to create a single PVC between two routers using a single Frame Relay switch in between. Because I’m a visually oriented person, I also created this Visio drawing of the Frame Relay circuit. Here is a logical/physical diagram of how the routers are connected together:

DLCI 100 is the address for the link or connection between R1 and the Frame Relay switch’s serial 1/0 interface.  DLCI 200 is the address for the link or connection between R2 and the Frame Relay switch’s serial 1/1 interface.

Here is what my Frame Relay switch looks like:

Procedure:
The Physical Connections

1. Connect the DTE end of a serial cable to router R1’s serial interface 0/0 and the DCE end of the cable to serial interface 1/0 of the router that I am using for my Frame Relay switch.
2. Connect the DTE end of a serial cable to router R2’s serial interface 0/0 and the DCE end of the cable to serial interface 1/1 of the Frame Relay switch.

Configure the Frame Relay Switch
Leave R1 and R2 turned off for now. Just turn on the Frame Relay switch and configure it. The very first thing that you do on the switch is enable Frame Relay switching with the global mode command:

• Frame-relay switching

Next, configure the switch’s serial interfaces with the following interface mode commands:

• clock rate number
• encapsulation frame-relay
• frame-relay intf-type dce
• frame-relay route incoming-DLCI interface exit-interface exit-DLCI
• no shutdown

In this lab we are using the following default Frame Relay settings for Cisco routers:

• Frame Relay encapsulation is “Cisco” and not “IETF”.
• Inverse-ARP is being used.

Also, it doesn’t matter what the clock speed is. I picked 64kbps for grins and giggles. Show here are the commands as I entered them into the Frame Relay switch:

FR-SW(config)#frame-relay switching
FR-SW(config)#interface serial 1/0
FR-SW(config-if)#clock rate 64000
FR-SW(config-if)#encapsulation frame-relay
FR-SW(config-if)#frame-relay intf-type dce
FR-SW(config-if)#frame-relay route 100 interface serial 1/1 200
FR-SW(config-if)#no shutdown
FR-SW(config-if)#interface serial 1/1
FR-SW(config-if)#clock rate 64000
FR-SW(config-if)#encapsulation frame-relay
FR-SW(config-if)#frame-relay intf-type dce
FR-SW(config-if)#frame-relay route 200 interface serial 1/0 100
FR-SW(config-if)#no shutdown

What the Frame Relay route command on serial 1/0 is basically doing is this:

• Assigning the DLCI of 100 to the link or connection connected to the serial 1/0 interface.
• Assigning the DLCI of 200 to the link connected to the serial 1/1 interface.
• Directing traffic coming in on serial 1/0 and sending it out serial 1/1.

Now let’s look at the status of the PVC that we just created:

FR-SW #show frame-relay pvc

PVC Statistics for interface Serial1/0 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       0            1            0            0
  Unused         0            0            0            0

DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = INACTIVE, INTERFACE = Serial1/0

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0       out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  switched pkts 0
  Detailed packet drop counters:
  no out intf 0            out intf down 0          no out PVC 0
  in PVC down 0            out PVC down 0           pkt too big 0
  shaping Q full 0         pkt above DE 0           policing drop 0
  pvc create time 00:03:45, last time pvc status changed 00:03:45

PVC Statistics for interface Serial1/1 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       0            1            0            0
  Unused         0            0            0            0

DLCI = 200, DLCI USAGE = SWITCHED, PVC STATUS = INACTIVE, INTERFACE = Serial1/1

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0       out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  switched pkts 0
  Detailed packet drop counters:
  no out intf 0            out intf down 0          no out PVC 0
  in PVC down 0            out PVC down 0           pkt too big 0
  shaping Q full 0         pkt above DE 0           policing drop 0
  pvc create time 00:01:13, last time pvc status changed 00:01:13
FR-SW #show frame-relay route
Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial1/0       100             Serial1/1       200             inactive
Serial1/1       200             Serial1/0       100             inactive
FR-SW#

Note the output of the “show frame-relay pvc” command for both serial interfaces:

• DLCI USAGE = SWITCHED
• PVC STATUS = INACTIVE

Configure R1 and R2.
Now power on R1 and R2. On the serial interfaces for R1 and R2, you enter the following interface mode commands:

• ip address address subnet-mask
• encapsulation frame-relay
• no shutdown

R1(config)#interface serial 0/0/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#ip address 10.1.1.1 255.255.255.252
R1(config-if)#no shutdown

R2(config)#interface serial 0/0
R2(config-if)#ip address 10.1.1.2 255.255.255.252
R2(config-if)#encapsulation frame-relay
R2(config-if)#no shutdown

Verify Frame Relay Connectivity
On R2, enter the “show frame-relay pvc” command:

R2#show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 200, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 1             output pkts 0            in bytes 34
  out bytes 0              dropped pkts 0           in pkts dropped 0
  out pkts dropped 0       out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:00:36, last time pvc status changed 00:00:26
R2#

Note the output of the “show frame-relay pvc” command as shown above. The DLCI usage is “LOCAL” instead of “SWITCHED” and the PVC status is “ACTIVE”. So, if you ever come across a situation in which the PVC is “INACTIVE”, you know that it means that one of the sides of the connection is not configured or turned on.

Now ping R1 from R2. The frame relay switch is working.

Installing the TFTP Server in OpenSuse 12.3

OBJECTIVE:

In this lab I would like to install a TFTP server in OpenSuse Linux, and then try to copy files from a Cisco router toe the server.

REQUIRED MATERIALS:

• 1 x Cisco Router
• 1 x Switch
• 1 x PC with OpenSuse Linux 12.3 already installed
• 2 x Ethernet cables to connect the equipment to the switch

PRE-REQUISITES:

A basic understanding of:

• Ethernet networking
• The Linux Operating System
• Cisco Console and Command Line Interface

REFERENCES:

• tftp(1) - Linux Man Page
• tftp(8) - Linux Man Page

PROCEDURE:

This procedure consists of basically three parts:

1. Installing the TFTP Server in OpenSuse
2. Configuring the TFTP Server After Installing It
3. Copying Files from a Cisco Device to the TFTP Server

Installing the TFTP Server in OpenSuse

Step 1.
To install a TFTP server in OpenSuse Linux, start the YaST Control Center. Click on “Software Management” in the right pane, as shown below.

Figure 1. YaST Control Center

Step 2.
Enter tftp in the search dialog box and click the “Search” button next to it.

Step 3.
The pane immediately to the right shows the results of the search. Mark the checkboxes next to “tftp” and “yast2-tftp-server” as shown in Figure 2. Click the “Accept” button on the bottom right of the window to start the installation process.

Figure 2. Yast Software Installation Dialog Box

Configuring the TFTP Server After Installing It

Step 1.
After the software has been installed, startup YaST again. Click on “Network Services” in the left pane. Click on “TFTP Server” in the right pane as shown in Figure 3.

Figure 3. Starting the TFTP Server Configuration Utility

Step 2.
This will cause the “TFTP Server Configuration” dialog window to pop up as shown in Figure 4 below. Click the “Enable” radio button.

Step 3.
The dialog box entitled “Boot Image Directory” is where the files that are uploaded to and downloaded from the TFTP server are stored. Accept the default or change it by clicking the “Browse” button.

Step 4.
Mark the checkbox next to “Open Port in Firewall”. Click “OK”.

Figure 4. TFTP Configuration Dialog Box

Step 5.
Open a file and directory management program such as Dolphin. Right click on the folder “/srv/tftpboot”, or, if you selected another folder for the Boot Image Directory, right click on that.
Shown in Figure 5 below are the default permission settings for the directory.

Figure 5. Default TFTP Permissions

Step 6.
For the TFTP server to work properly, we need to change the default settings to match those shown in the next screen shot shown below in Figure 6. Basically we need to:

• Change “Others” from “Forbidden” to “Can View & Modify Content”.
• Change group ownership from “tftp” to “users”.

Click “OK”.

Figure 6. Modified TFTP Permissions

Step 7.
Next we need to change the configuration file. Using your favorite text editor (l like to use KWrite), open “/etc/xinetd.d/tftp”. Look for the line that shows:

• server_args = -u tftp -s /srv/tftpboot

Step 8.
In your text editor:

• Delete “-u tftp”
• Add “-c”
• If you selected a different Boot Imaging Directory above, that should be displayed in the line instead of “/srv/tftpboot”.

NOTE: There MUST be a space between the switches “-s” and the “-c” and the path, otherwise, the TFTP server will not work.

In order for a file to be copied to that directory, a zero sized file must be created first in that directory. What the “-c” switch does is that it allows the TFTP server to automatically create the zero sized file before the actual copy process begins so that you don’t have to create the zero sized file manually before copying the actual file. The configuration should like the one shown below:

service tftp
{
    socket_type     = dgram
    protocol        = udp
    wait            = yes
    flags           = IPv6 IPv4
    user            = root
    server          = /usr/sbin/in.tftpd
    server_args     = -s –c /srv/tftpboot
#   per_source      = 11
#   cps             = 100 2
    disable         = no
}

Copying Files from a Cisco Device to the TFTP Server

Something that you need to know when copying files from a Cisco device to the TFTP server is that when you enter the URL of the TFTP server, you do NOT need to enter the full path to the storage folder because the Linux configuration file takes care of that for you. For example, to copy the “startup-config” file to the TFTP server with an IP address of 192.168.1.10, I would enter the command:

#copy startup-config tftp://192.168.1.10/startup-config

Notice that I did NOT enter the command:

#copy startup-config tftp://192.168.1.10/srv/tftpboot/startup-config

Troubleshooting

1.    Verify that the Cisco device and the TFTP server can ping one another.
2.    Verify that your firewall is not blocking TFTP traffic.
3.    Open the “TFTP Server Configuration” dialog box, and click on “View Log” (Figure 4) for clues as to why things are not working.

If you see a message that says :
Unknown option: ‘-‘
Or,
Too many -s directories

That means that you need to insert a space between the switches in the configuration file or that there is some other typographical error.

If you get a message that says:
Cannot set groups for user tftp

Then you need to remove the “-u” and “tftp” from the “server_args” line of the configuration file. Verify that the line looks exactly like the one shown above.

Additional Comments:

Some people may think that it is a security risk setting the permissions of the Boot Image Directory like I did. So did I. So I tried every possible combination of configurations and nothing else worked. So, I would suggest that immediately after doing your file copy to or from the TFTP server, you move the files from the Boot Image Directory to another directory with stricter permissions.

Thoughts about the CCENT Test

Well, I passed the CCENT test on February 11th, 2014. It is the first of 5 that I need to take on my path to renew my CCNP.

I am REALLY upset at Cisco though. They claim that their test contains 50 questions. That statement is a BOLD FACED LIE pure and simple.

Why do I say that? I say that because some of their so called "single questions" contain an additional 3-4 questions, each with their own set of multiple choice answers. There were about two or three of these on the test. So, in reality, the test has around 60 questions, give or take a few. I was sailing along thinking I was doing real good with lots of time time left, until I ran into several of these, and so I had to rush through them, because I didn't know how many more there would be before the 90 minute timer expired. In doing so, I sure I made a few mistakes lowering my score significantly.

I knew that they had these types of scenarios that contained multiple questions, but I assumed that each individual question was considered part of the 50. Not so. The whole scenario counts as a single question.

Next test though, now that I know their little trick, I hope to do better, unless of course they have some other trick to pull on me.

Bad Documentation – The Bane of My Existence

The problem with most open source and many commercial software packages is that the documentation sucks rocks. The two biggest reasons their creators often site for their oversight are:

1.    The project is a hobby and that they don’t have time to write decent documentation.
2.    Anybody that has any knowledge of computer programming should be able to figure it out. If you don’t have a Ph.D. in Computer Science, you shouldn’t be in the IT industry.

My response to that is this:

1.    If they had planned and organized their project from the very beginning like they teach you to do in college, the documentation would have been written before they ever wrote a single line of code. Should it come as a surprise then that their project is so buggy from the get-go? Poor planning and poor documentation is the sure sign of an amateur. Period.

2.    What is the point of creating software for someone to use if nobody can figure out how to use it? I have better things to do with my time than reverse engineering their project even if I was a code-head. It would be easier and more cost effective to purchase a retail version that is well planned and well documented. Heck, it might even be more cost effective to write it myself or pay someone else to write it!

3.    Everyone in the IT industry does not have Ph.D.s in Computer Science. In all the places I’ve worked in my 30 year career, less than one-third of the people I worked with had any extensive formal computer programming training and experience.

4.    If your program, like syslog-ng for example, is “written by programmers for programmers” not everyone that knows how to program know how to program in C# or whatever language your program is supposed to emulate.

If a user can’t figure out how to use a piece of software without having to reverse engineer it first, what is the point of writing it in the first place?

Take for example this article I recently read entitled "Receiving Messages from a Remote System" for the rsyslog logging software installed by default on my OpenSuSE Linux PC.

1.    It says "Note that the server port address specified in $InputTCPServerRun must match the port address that the clients send messages to." In the sample configuration file that immediately follows this statement, there isn’t one single line that even contains "$InputTCPServerRun". So how am I supposed to use this statement? When? Where?

2.    The author writes that to receive logging messages from remote devices, certain plugins need to be loaded at the start of the of the configuration file and shows examples in the sample configuration file. After the sample configuration, the author states that you need to activate “listeners” and that loading the “plugins” is not sufficient.

• Are "plugins" the same as the "modules" that are loaded in the configuration file? He doesn’t say.
• Nowhere in this article, or any other article, does he specify exactly what a "listener" is, nor does he describe how to "activate" them. Is a listener the same as a filter? A ruleset? Who knows?

3.    The author mentions in a completely different article that if you want to receive messages by both the TCP and UDP protocols, you need to configure them with different port numbers. Yet in the example configuration contained within this article, he configures both TCP and UDP to use the same port 514.

4.    In another document "Storing Messages from a Remote System into a Specific File", the author writes "It is important that the rules processing the remote messages come before any rules to process local messages." He doesn’t mention that in this document anywhere.

5.    I enter the "Config Statements" shown in the document exactly as written and they don’t work.

• Error messages in the log files say that "no listeners are defined – no input will be gathered" among others. Why would anyone put a incomplete, non-working configuration example in their documentation? What is the point in doing that?
• The configuration is for TCP, but most logging programs send their log messages via UDP (including Cisco, which is what I’m trying to receive messages from). What good is a configuration that receives only TCP to me?

6.    In the configuration examples of some articles, he uses these commands:

• module (load="imtcp")
• input (type="imtcp" port="514")
• In other examples he uses "$Modload imtcp" but doesn’t explain why there is a difference.

The documentation on the rsyslog website is extensive, yet there is nothing there, that I can find, that is actually usable. It’s like trying to hunt down little bits and pieces here and there in the various different articles and then try and fit them all together like a jig-saw puzzle.  Yast’s description of rsyslog says that it is easy for novices to use.

I’d be willing to bet real money that they never actually asked a novice user to try and figure out how to use it before making that statement.

Why people say on the Internet that this logging program is better than the old syslog program is beyond my comprehension. I am going to unload rsyslog and load the old, tried and true syslog.

As far as  syslog-ng is concerned – though I do have some programming training and experience, I don’t have a Ph.D. in Computer Science. My degree is in Electronics Engineering Technology. I don’t have the time or the motivation to learn their programming language. I need something that’s KISS. I don’t need something that will clean the kitchen sink. Whatever happened to

Keep It Simple Stupid?

What about the Windows logging program called Kiwi? It doesn’t support IPv6. REALLY? With the remaining IPv4 address allotment being exhausted in a matter of months, Kiwi won’t support the newer IPv6 addresses? Who’s the genius that made that command decision?

The university I went to required engineering majors to take a class in technical writing in addition to the usual English Composition classes. Don’t all universities require engineering majors to take a course in technical writing for graduation? Sadly, apparently not.

Pi Lab 4: GPS on the Pi

OBJECTIVE:
The objective of this lab is to connect a GPS receiver to the Pi and use it to determine location and time.

REQUIRED MATERIALS:

• Raspberry Pi Micro-Controller
• 8GB SDCard with the Operating System NOOBS (Raspian – Debian Linux derivative) pre-installed.
• Power Supply, AC-DC Converter, External Plug in, Micro USB connector, 5W, 5V, 1A output.
• USB Keyboard.
• USB Mouse.
• USB Hub
• HDMI Monitor.
• HDMI Cable.
• HDMI to DVI Adpater (if your monitor only has a DVI and not a HDMI connector).
• One Ethernet cable
• Adafruit Ultimate 66 GPS Breakout with 9 pin Header and Coin Cell Battery Holder
• SMA to uFL/u.FL/IPX/IPEX RF Adapter Cable
• Adafruit External GPS Antenna, 3-5Volt,  28dB gain, 5 Meter cable with SMA Connector
• USB to TTL Serial Cable - Debug / Console Cable
• CR1220 Coin Cell Battery
• Soldering iron with solder
• Electronics cleaning solvent (available at electronics and automotive stores)

PRE-REQUISITES:

• An operating system must be installed onto the Raspberry Pi (see Pi Lab – Initial Setup)
• The Pi must have Internet connectivity.

A basic understanding of:

• Ethernet networking.
• Connector types such as HDMI, DVI, USB, RJ-45 (Ethernet), etc…
• The Linux Operating System

REFERENCES:
Raspberry Pi Help

• http://www.raspberrypi.org/phpBB3
• http://learn.adafruit.com/adafruit-ultimate-gps-on-the-raspberry-pi
• http://blog.retep.org/2012/06/18/getting-gps-to-work-on-a-raspberry-pi/

GPS

• http://gpsd.berlios.de/gpsd.html
• http://catb.org/gpsd/
• http://gpsd.berlios.de/client-howto.html

PROCEDURE:
Parts Assembly   
1.    Place the battery holder onto the back side of the circuit board using the outline that is printed on the circuit board as a guide. Solder the ears of the battery holder onto the solder pads of the circuit board.
2.    The header that came with my GPS Breakout module had more than 9 pins on it. If yours does too, then break off the extra pins so that you header has 9 pins.
3.    Insert the short pins into the holes of the GPS Breakout circuit board and solder them into the circuit board. The longer pins should be pointing away from the circuit board. Whether they are on the top of the circuit board or the bottom, it doesn’t really matter. I soldered mine with the pins pointing down so that I can stick them into a breadboard with the circuitry facing up if I want to at some future date.
4.    Clean the flux residue off of the circuit board using a brush and circuit board cleaner.
5.    Insert the battery into the clip on the backside of the circuit board with the positive terminal facing away from the board.
6.    Screw the smaller connector of the white antenna adapter cable to the connector on the circuit board as shown below.
7.    Screw the GPS SMA connector on the black antenna cable onto the larger (SMA) connector on the white adapter cable.
8.    Take the four wires of the USB to TTL adapter and connect them to the header pins on the GPS circuit board as follows:

• The white wire goes to the header pin labeled “TX”.
• The black wire goes to “GND”.
• The red wire goes to “VIN”.
• The green wire goes to “RX”.

9.    Because there are only two USB ports on the Pi, and three USB connectors that you need to plug into the Pi, you will need to connect the USB hub to the Pi and then connect the keyboard, mouse and GPS Breakout board to the hub.
10.    Power on the switch and connect the Pi to the Ethernet switch with the straight through Ethernet cable.
11.    Place the GPS antenna (the big black square block) on a window sill.
12.    Connect the monitor to the Pi and turn it on.
13.    Apply power to the Pi.

Installing the “gpsd” Program On the Pi
1.    Assuming you have booted up the Pi while being connected to the Internet, your Pi should have the current UTC time. Execute the “date” command to verify (remember that your local time might be several hours different than UTC time) or if you booted to the GUI, the time is displayed in the bottom right corner of the screen. Move your mouse over the time to view the date.

pi@raspberrypi ~ $ date
Wed Oct 16 16:38:38 CDT 2013

2.    Verify that the GPS module connected to the USB port is being recognized. The Adafruit GPS module is highlighted in yellow. Enter the following commands:

pi@raspberrypi ~ $ ls /dev/ttyUSB*
/dev/ttyUSB0
pi@raspberrypi ~ $ sudo lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 058f:9254 Alcor Micro Corp. Hub
Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 006: ID 04d9:1702 Holtek Semiconductor, Inc.
Bus 001 Device 007: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse

3. Verify that the GPS module is sending data to the Pi. Enter the following command and watch the streaming data scroll down your screen. Press “ctrl-c” to exit the data flow and return to the command prompt.

pi@raspberrypi ~ $ sudo cat /dev/ttyUSB0
$GPGGA,221016.000,3531.7468,N,09735.5017,W,2,8,1.02,382.5,M,-25.2,M,0000,0000*66
$GPGSA,A,3,18,02,05,25,29,21,26,15,,,,,1.83,1.02,1.52*0C
$GPRMC,221016.000,A,3531.7468,N,09735.5017,W,0.02,332.89,161013,,,D*78
$GPVTG,332.89,T,,M,0.02,N,0.05,K,D*3C
$GPGGA,221016.000,3531.7468,N,09735.5017,W,2,8,1.02,382.5,M,-25.2,M,0000,0000*66
<output omitted>

4. Install the gps daemon. Enter the command:

pi@raspberrypi ~ $ sudo apt-get install gpsd gpsd-clients python-gps
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following extra packages will be installed:
  libgps20 python-cairo python-gobject-2 python-gtk2
Suggested packages:
  python-gobject-2-dbg python-gtk2-doc
The following NEW packages will be installed:
  gpsd gpsd-clients libgps20 python-cairo python-gobject-2 python-gps
  python-gtk2
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,605 kB of archives.
After this operation, 8,113 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main libgps20 armhf 3.6-4+deb7u1 [233 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian/ wheezy/main gpsd armhf 3.6-4+deb7u1 [110 kB]
Get:3 http://mirrordirector.raspbian.org/raspbian/ wheezy/main python-gps armhf 3.6-4+deb7u1 [124 kB]
Get:4 http://mirrordirector.raspbian.org/raspbian/ wheezy/main python-cairo armhf 1.8.8-1 [68.6 kB]
Get:5 http://mirrordirector.raspbian.org/raspbian/ wheezy/main python-gobject-2 armhf 2.28.6-10 [475 kB]
Get:6 http://mirrordirector.raspbian.org/raspbian/ wheezy/main python-gtk2 armhf 2.24.0-3 [1,450 kB]
Get:7 http://mirrordirector.raspbian.org/raspbian/ wheezy/main gpsd-clients armhf 3.6-4+deb7u1 [144 kB]
Fetched 2,605 kB in 22s (116 kB/s)                                            
Preconfiguring packages ...
Selecting previously unselected package libgps20:armhf.
(Reading database ... 62275 files and directories currently installed.)
Unpacking libgps20:armhf (from .../libgps20_3.6-4+deb7u1_armhf.deb) ...
Selecting previously unselected package gpsd.
Unpacking gpsd (from .../gpsd_3.6-4+deb7u1_armhf.deb) ...
Selecting previously unselected package python-gps.
Unpacking python-gps (from .../python-gps_3.6-4+deb7u1_armhf.deb) ...
Selecting previously unselected package python-cairo.
Unpacking python-cairo (from .../python-cairo_1.8.8-1_armhf.deb) ...
Selecting previously unselected package python-gobject-2.
Unpacking python-gobject-2 (from .../python-gobject-2_2.28.6-10_armhf.deb) ...
Selecting previously unselected package python-gtk2.
Unpacking python-gtk2 (from .../python-gtk2_2.24.0-3_armhf.deb) ...
Selecting previously unselected package gpsd-clients.
Unpacking gpsd-clients (from .../gpsd-clients_3.6-4+deb7u1_armhf.deb) ...
Processing triggers for man-db ...
Processing triggers for menu ...
Setting up libgps20:armhf (3.6-4+deb7u1) ...
Setting up gpsd (3.6-4+deb7u1) ...
Setting up python-gps (3.6-4+deb7u1) ...
Setting up python-cairo (1.8.8-1) ...
Setting up python-gobject-2 (2.28.6-10) ...
Setting up python-gtk2 (2.24.0-3) ...
Setting up gpsd-clients (3.6-4+deb7u1) ...
Processing triggers for python-support ...
Processing triggers for menu ...
pi@raspberrypi ~ $

5. Now I will start up the gps daemon and instruct it to acquire its data from the Adafruit Ultimate GPS device that is connected to the the USB to TTY adapter cable. The Adafruit procedure omits the “-n” switch, but I am going to use it.

pi@raspberrypi ~ $ sudo gpsd /dev/ttyUSB0 -n -F /var/run/gpsd.sock

If the Adafruit is locked onto some satellites and tracking them, and the gpsd has opened up the appropriate socket (it may require you to wait a minute or so), you should be able to display the resulting stream of GPS data that we saw earlier. To see if “gpsd” is working properly, execute the command:

pi@raspberrypi ~ $ cgps -s

Press “ctrl-c” to exit and return to the command prompt. If you desire a fancier graphical display, enter the command:

pi@raspberrypi ~ $ xcgps

 

Your display should have a valid number for latitude and longitude. I scrambled the latitude and longitude in the pictures so you won’t come hunt me down and kill me if your gps doesn’t work like mine.

TROUBLESHOOTING:
1. Something that I encountered after I powered off my Pi for the night and then powered it back on the next day was that for some reason “cgps” and “xgps” did not work anymore!  No data was displayed! So I opened up "/var/log/syslog" with the Leafpad text editor and found the following output:

Oct 16 23:15:20 raspberrypi gpsd[1988]: gpsd:ERROR: can't bind to IPv4 port gpsd, Address already in use
Oct 16 23:15:20 raspberrypi gpsd[1988]: gpsd:ERROR: maybe gpsd is already running!
Oct 16 23:15:20 raspberrypi gpsd[1988]: gpsd:ERROR: can't create IPv6 socket

2. Apparently multiple instances of gpsd are trying to access the same resources. So I terminated all instances of gpsd running by executing the command:

pi@raspberrypi ~ $ sudo killall gpsd

3. Then I restarted gpsd:

pi@raspberrypi ~ $ sudo gpsd /dev/ttyUSB0 -n -F /var/run/gps.sock

4. Then I tried “cgps -s” again, and lo and behold, it was working properly.

Change the gpsd Startup Parameters
1. So, what I did next is change the startup parameters of gpsd using the “dpkg-reconfigure” program so that the next time the Pi reboots, it won't try to load gpsd multiple times.

pi@raspberrypi ~ $ sudo dpkg-reconfigure gpsd

2. Select YES to start gpsd automatically.

3. Do NOT let gpsd handle attached USB GPS receivers automatically. Select NO!

4. Enter "/dev/ttyUSB0" if isn't entered already, then select "Ok".

5. Enter the "-n" switch and select "Ok".

6. "/var/run/gpsd.sock" should be entered. If not, enter and then select "Ok". The program should exit at this point and return you to the command prompt.

7. Now that you have reconfigured the startup parameters of gpsd, I reboot your Pi, wait for a few minutes for the GPS to acquire a satellite fix and then try to run “cgps -s”. It should work every time you boot up the Pi now.

Pi Lab 3 – NTP Server Pools

OBJECTIVE:
The objective of this lab is to learn how to configure NTP services on the Pi by changing the NTP configuration file and change the Pi’s time sources.

REQUIRED MATERIALS:

• Raspberry Pi Micro-Controller
• 8GB SDCard with the Operating System NOOBS (Raspian – Debian Linux derivative) pre-installed.
• Power Supply, AC-DC Converter, External Plug in, Micro USB connector, 5W, 5V, 1A output.
• USB Keyboard.
• USB Mouse.
• HDMI Monitor.
• HDMI Cable.
• HDMI to DVI Adpater (if your monitor only has a DVI and not a HDMI connector).
• Two straight through Ethernet cables
• Home router\switch connected to a cable modem or DSL modem
• A personal computer

PRE-REQUISITES:

• An operating system must be installed onto the Raspberry Pi (see Pi Lab – Initial Setup)
• The Pi must have Internet connectivity.

A basic understanding of:

• Ethernet networking.
• Connector types such as HDMI, DVI, USB, RJ-45 (Ethernet), etc…
• The Linux Operating System
• The Network Time Protocol (NTP) Protocol

REFERENCES:
Raspberry Pi Help

• http://www.raspberrypi.org/phpBB3

Linux NTP Man Pages

• ntpd
• ntp.conf
• ntpq
• ntpdc
• ntpdate
• ntp_mon
• ntp_acc
• ntp_clock
• ntp_misc

The NTP Protocol

• http://www.pool.ntp.org/en/use.html
• http://www.ntp.org/
• http://tf.nist.gov/tf-cgi/servers.cgi
• http://www.eecis.udel.edu/~mills/ntp.html
• http://www.eecis.udel.edu/~mills/ntp/html/
• http://support.ntp.org/bin/view/Main/WebHome

PRELIMINARY READING:
To change the operating parameters of the ntp daemon, you need to make changes to the configuration file “/etc/ntp.conf”.

On a fresh install of Raspbian on a Raspberry Pi, NTP is configured to get its time from a pool of low-stratum NTP servers on the Internet. Because these servers are located all over the world, the accuracy of the time updates may not be as accurate as your needs might warrant. According to the NTP Pool Project (http://www.pool.ntp.org), you will get better results getting your time from servers located closer to home, so to speak. So they have organized server pools by continent, and even by country in some instances. Each pool named in your “ntp.conf” file points to a random set of servers that changes every hour. The closer the time servers are to you, the better. You can measure a specific server’s distance from you by using the traceroute or ping utilities.

If you happen to know of a time server run by an organization that is close to you and that is available to the public (such as your ISP, a local business, or a university perhaps), you should use that instead of the pool. You can even use a combination of local servers and pool servers. Because I live in Oklahoma, smack dab in the middle of the United States, I am going to configure my Pi to use the US Zone that is a subset of the North America Zone and some servers that are closer to where I live and not half way around the world.

PROCEDURE:
Experiment 1
Change the server pool.
1.   Make a backup of the ntp.conf
2.   In the GUI, right click the icon of the computer screen entitled “LXTerminal” and then left click “Open”. This opens a CLI.
3.   Make a backup of the “ntp.conf” file. In the terminal window, enter the command “sudo cp /etc/ntp.conf /etc/ntp.conf.bak”.
4.   Open the ntp configuration file for editing by entering the command: “sudo leafpad /etc/ntp.conf”.
The reason I opened the Leafpad text editor from the CLI using “sudo” is because by default the Pi logs you into the GUI as the user “pi” and not as “root”. If you want to save any changes made to the configuration file, you must edit it as the “root” user. If you open Leafpad by clicking on the icon and then open the configuration file, you will not be able to save any changes made to it because you doing so as the user “pi”.
5.   In your “ntp.conf” file, examine the section that looks like this:

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# 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>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

6.   In front of each “server” statement, type a hash symbol (#) in a manner similar to the statements above. This turns the line of text into a comment and prevents it from being executed.
I copied and pasted the following text from “http://www.pool.ntp.org/zone/us” and then added the “iburst” option:

server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst
server 3.us.pool.ntp.org iburst

By adding the “iburst” option, when a time server is unreachable, the Pi will send 8 request packets to the server spaced 2 seconds apart (a burst of packets). According to the “ntp.conf” Man Page, this is a recommended option.

7.   In Leafpad, click “File”, then “Save”.
8.   Restart the ntp daemon by executing the command: “sudo service ntp restart”.
9.   After waiting a few minutes for the Pi to sync with the Internet servers, check to see if the Pi is synchronizing with the servers. This is done by executing the command: “ntpq –p”. The resulting display should look something like this:

pi@raspberrypi ~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*paladin.latt.ne 204.123.2.72     2 u    2   64    1   55.435   -2.688   9.286
 int42.org       128.4.1.1        2 u    2   64    1   14.762   -1.008   1.069
 mirror          164.244.221.197  2 u    -   64    1   35.037    2.539   9.179
 tock.usshc.com  .GPS.            1 u    1   64    1   48.938   -0.541   1.574
pi@raspberrypi ~ $

Under the “remote” column you will see listed the names or IP addresses of the servers being synched to. The “refid” is the reference ID and can be an IP address, or a name that you specifically assign to it. The “st” refers to the server’s stratum. The “when” refers to the time elapsed in seconds since the server was last heard from. The “poll” column is the polling interval in seconds. The “jitter” column refers to changes in the rate packets arrive from the same flow of data. The values under “offset” and “delay” should not be zero, and the “jitter” should be less than 100. If they all are zero, then there is a problem with NTP synching with anything.

The asterisk (*) shown in the left margins indicates the currently selected peer, in other words, the server that the Pi is synching up to at that point in time. If there is no asterisk, then the Pi is not synching with anything.

Experiment 2   
Getting time from specific servers and not through a pool.
1.   Edit the “ntp.conf” file by executing the command “sudo leafpad /etc/ntp.conf”.
2.   Comment out the lines specifying the server pools by inserting the # symbol at the start of line.
Type the following lines into the configuration file as follows:

# This is a stratum 1 time server from NIST
# located in Carrollton, Texas.
server 96.226.242.9 iburst

# This is a time server from the U.S. Naval
# Observatory located at Oklahoma State
# University in Stillwater, Oklahoma.
server ntp.okstate.edu iburst

3.   In Leafpad, click “File”, then “Save”.
4.   In the CLI, restart ntp by entering the commands “sudo leafpad /etc/ntp.conf”.
5.   Next, check the status of NTP by executing the command “ntpq –p”. Here is the resulting output:

pi@raspberrypi ~ $ sudo leafpad /etc/ntp.conf
pi@raspberrypi ~ $ sudo service ntp restart
[ ok ] Stopping NTP server: ntpd.
[ ok ] Starting NTP server: ntpd.
pi@raspberrypi ~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*static-96-226-2 .ACTS.           1 u    -   64    1   86.985   -0.661   1.913
+ntp.okstate.edu .GPS.            1 u    1   64    1   44.818   -1.801   4.675
pi@raspberrypi ~ $