Howto

At work they just gave everyone a UPS for their office: APC BK650-AS. It comes with a cable that plugs into a USB port on your computer allowing the status of the UPS to be used to trigger a shutdown (or other actions) of your computer. Also included was a free version of the APCs PowerChute software for Windows and MAC. Supposedely there is a Linux version of PowerChute, but a quick search reveals apcupsd provides all necessary features for Linux.

Heres what I did to configure apcupsd after plugging in the cable.

1. Install the software:
   

   > sudo apt-get install apcupsd
   

2. Configure the daemon by editing /etc/apcupsd/apcupsd.conf:
   

   UPSNAME SteveUPS
   UPSCABLE usb
   UPSTYPE usb
   # DEVICE
   

3. Allow access on localhost by editing /etc/hosts.allow:
   

   apcupsd: 127.0.0.0/255.0.0.0
   

4. You can check that the UPS is detected by looking at system messages:
   

   > tail /var/log/messages
   Aug 26 12:49:24 ginger kernel: [ 3456.772911] generic-usb 0003:051D:0002.0005: 
   hiddev96,hidraw0: USB HID v1.10 Device [American Power Conversion Back-UPS CS 650 
   FW:817.v6.I USB FW:v6] on usb-0000:00:1d.0-1/input0
   

5. Restart the daemon:
   

   > sudo /etc/init.d/apcupsd restart
   

6. Check the status:
   

   > apcaccess status
   

Here is a quick guide for demonstrating the impact of delay and jitter on streaming video across a network. I used this as a demo in ITS323 and ITS413.

Requirements

You need to two computers, with at least one running Ubuntu (or other Linux-based operating system). VLC must be installed on both computers - it is is as the video streaming server and video player at the client. To introduce extra delay/jitter into the path from server to client, tc is used. This is available in Linux - it can be installed from repositories using apt-get. I'm not sure of an equivalent free application in Windows operating systems, hence the reason that one computer must run Ubuntu. The two computers must be connected together via some network. To avoid problems with firewalls and NAT, and achieve reasonable speed, I suggest using a direct connection (Ethernet cross over cable or adhoc wireless LAN) or LAN (Ethernet or wireless LAN). Finally, I assume you have a video file to stream, e.g. an AVI encoded using XViD.

VLC as the Video Player on the Client

VLC is a great media player supporting many different codecs and available for a variety of operating systems. On the client computer (you could use Windows OS, but I'll give instructions for Ubuntu) VLC will be used to play the received video. You have two options to open the network stream:

1. Via the command line, run:
   

   vlc udp://@CLIENTIP:1234
   

   where CLIENTIP is the IP address of this client computer. You can find it using the ifconfig command.

2. Open VLC and from the Media menu select Open Network Stream then specify the protocol as UDP and the IP address as your computers address. Port 1234 is chosen by default. Then press play.

As the server hasn't started, nothing will be displayed yet.

Streaming Server

In addition to being a media player, VLC can act as a streaming server. A command line interface (with no GUI) is available using cvlc. Your server computer should be running Ubuntu. Assuming the video file you want to stream is video.avi start streaming it:

cvlc -vvv video.avi --sout '#std{access=udp,mux=ts,dst=CLIENTIP:1234}'

Again, CLIENTIP is the IP address of the client computer that is going to receive the stream. The '-vvv' option gives verbose output on the terminal. The 'access' option specifies UDP is to be used as the streaming protocol. The 'mux' option specifies the format to encode the data. 'dst' specifies the destination host and port number. Note that as an alternative to the command line, you can start a streaming server via the Media->Streaming... menu in the VLC GUI.

Now on the client you should see the video playing.

Adding Delay/Jitter using tc

In Linux, tc is a traffic control application. It allows you to control packets being sent by your computer. We will use it on the server computer to introduce additional delay/jitter/loss into the path from server to client. You need to be an administrator to make changes with tc, i.e. use sudo in Ubuntu. Without explaining how tc works, here are some example commands you can use.

To add a random delay of between 90 and 110ms (average 100ms) to every packet your computer sends do this (assumes you are using your Ethernet interface eth0):

tc qdisc add dev eth0 root netem delay 100ms 10ms

To remove this delay, use the del option, i.e.:

tc qdisc del dev eth0 root netem delay 100ms 10ms

To change the jitter, simple change the 2nd time interval (10ms above). You can also drop, for example 1% of the packets (randomly):

tc qdisc add dev eth0 root netem loss 1%

And again you can remove it by replacing add with del. Also you can change existing commands by using change instead of add and del.

With tc you can now vary the additional delay/jitter/loss in the network path and investigate how that effects the quality of the streaming video.

At work we have a new Canon LBP3370 laser printer. Most of our other printers have been HP, and printing from Ubuntu Linux has been relatively straightforward. HP have very good support for printing in Linux through the HPLIP software. My HP multi function printer (including scanning) at home works fine with Ubuntu. However I had some problems with the Canon printer, especially printing PDF. Below is the original configuration in Ubuntu of using the Canon driver, and then the way I fixed the problems by using a HP driver.

Using the Canon Driver

When adding a printer in Ubuntu 9.10, I followed the steps of selecting 'Canon' and then 'LBP-3360' (the LBP-3370 is not listed) which gives the option of four drivers:

Canon LBP-3360 Foomatic/pxlmono [en] (recommended)
Canon LBP-3360 Foomatic/lj4dith [en]
Canon LBP-3360 Foomatic/ljet4 [en]
Canon LBP-3360 Foomatic/ljet4d [en]

As was suggested, I choose the pxlmono driver. Note that the LBP-3370 uses direct sockets printing (the device URI is 'socket://IP'). Unfortunately I had several problems when printing (mostly PDF - not sure if it also applied to other formats). Firstly, sometimes the first page of the PDF would print and then an error message would be printed (on the paper):

PCL XL Error
  SubSystem: IMAGE
  Error: MissingData
  Operator: ReadImage
  Position: 8644

And then some documents were taking a loooong time to print (5-10 minutes per page).

Fixing with the HP Driver

A quick search at OpenPrinting indicated that the driver I selected may not be reliable. It suggested using the hpijis-pcl5e driver instead (surprise, surprise - a HPLIP driver). So I downloaded the driver directly, saved it in /etc/cups/ppd/ and selected it from the printer Properties (under "Make and Model" select "Change" and then "Provide PPD file"). The result is shown below (note the "Make and Model").

For the past few weeks printing to the Canon printer using the HP driver has been trouble free. Nice job HP!

When introducing data communications concepts and protocols to students I think it is beneficial to demonstrate, and more importantly, allow students to play with real protocols. In the lab I teach (ITS332), as well as assignments for some lecture courses, we use Wireshark to capture traffic generated by several Internet applications (e.g. ping, Secure Shell, web browsing, iperf). This allows students to see the actual packets being sent across a network, and start to understand the protocol rules and formats used.

Unfortunately sometimes what we see in Wireshark is not what we expect. One case in which this occurs is when TCP/IP operations are offloaded by the operating system to the Network Interface Card (NIC). Common operations for offloading are segmentation and checksum calculations. That is, instead of the OS using the CPU to segment TCP packets, it allows the NIC to use its own processor to perform the segmentation. This saves on the CPU and importantly cuts down on the bus communications to/from the NIC. However offloading doesn't change what is sent over the network. In other words, offloading to the NIC can produce performance gains inside your computer, but not across the network.

How does this affect what Wireshark captures? Consider the figure below illustrating the normal flow of data through a TCP/IP stack without offloading. Lets assume the application data is 7,300 Bytes. TCP breaks this into five segments. Why five? The Maximum Transmission Unit (MTU) of Ethernet is 1500 Bytes. If we subtract the 20 Byte IP header and 20 Byte TCP header there is 1460 Bytes remaining for data in a TCP segment (this is the TCP Maximum Segment Size (MSS)). 7,300 Bytes can be conveniently segmented into five maximum sized TCP segments.

After IP adds a header to the TCP segments the resulting IP datagrams are sent one-by-one to the "Ethernet layer". Note that TCP/IP are part of operating system, while most functionality of Ethernet is implemented on the NIC. However network drivers (lets consider them part of the OS) also perform some of the Ethernet functionality. The network driver creates/receives Ethernet frames. So in the above example, assuming segmentation offloading is not used, the 7,300 Bytes of application data is segmented into 5 TCP/IP packets containing 1460 Bytes of data each. The network driver encapsulates each IP datagram in an Ethernet frame and sends the frames to the NIC. It is these Ethernet frames that Wireshark (and other packet capture software, like tcpdump) captures. The NIC then sends the frames, one-by-one, over the network.

Now consider when segmentation offloading is used (as in the figure below). The OS does not segment the application data, but instead creates one large TCP/IP packet and sends that to the driver. The TCP and IP headers are in fact template headers. The driver creates a single Ethernet frame (which is captured by Wireshark) and sends it to the NIC. Now the NIC performs the segmentation. It uses the template headers to create 5 Ethernet frames with real TCP/IP/Ethernet headers. The 5 frames are then sent over the network

The result: although the same 5 Ethernet frames are sent over the network, Wireshark captures different data depending on the use of segmentation offloading. When not used, the 5 Ethernet frames are captured. When offloading is used, Wireshark only captures the single, large frame (containing 7,300 bytes of data).

To further illustrate segmentation offloading, and how to control it in Linux, consider the following tests performed on two Ubuntu computers, basil and ginger, connected on an Ethernet LAN. On basil (which has IP address 10.10.1.22) netcat in server mode is used to receive data:

sgordon@basil$ nc -l 5001

On ginger netcat in client mode is used to send 10,000 Bytes of data (stored in a file) to the server.

sgordon@ginger$ nc -p 5002 10.10.1.22 5001 < 10000bytes.txt 

tcpdump is used to see the captured IP packets, and in particular the size of the TCP segments. I could have used Wireshark, but the text output of tcpdump> is easier to include in this page. ethtool is used to view and change the status of segmentation offloading (in this example, generic segmentation offload or GSO).

First note that ethtool shows us that generic segmentation offload is on.

sgordon@ginger$ sudo ethtool -k eth0
Offload parameters for eth0:
Cannot get device flags: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: on
large receive offload: off

Now, after running the netcat client, lets see the output from tcpdump (for clarity I have omitted the option fields from selected TCP segments):

sgordon@ginger$ sudo tcpdump -i eth0 -n 'not port 22'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:30:24.899687 IP 192.168.1.2.5002 > 10.10.1.22.5001: S 679249855:679249855(0) win 5840 
18:30:24.900583 IP 10.10.1.22.5001 > 192.168.1.2.5002: S 1420594303:1420594303(0) ack 679249856 win 5792 
18:30:24.900612 IP 192.168.1.2.5002 > 10.10.1.22.5001: . ack 1 win 92
18:30:24.900713 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 1:2897(2896) ack 1 win 92
18:30:24.900735 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 2897:4345(1448) ack 1 win 92 
18:30:24.902575 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 1449 win 68 
18:30:24.902591 IP 192.168.1.2.5002 > 10.10.1.22.5001: P 4345:7241(2896) ack 1 win 92 
18:30:24.903597 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 2897 win 91 
18:30:24.903607 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 7241:8689(1448) ack 1 win 92 
18:30:24.903613 IP 192.168.1.2.5002 > 10.10.1.22.5001: P 8689:10001(1312) ack 1 win 92 
18:30:24.903617 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 4345 win 114 
18:30:24.905573 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 5793 win 136 
18:30:24.905587 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 7241 win 159 
18:30:24.906628 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 8689 win 181 
18:30:24.906637 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 10001 win 204 

Each line is showing a captured packet. The TCP segments containing data can be identified by the sequence numbers (I've made them bold). The number in parentheses indicates the number of bytes in this TCP segment. We can see from the capture that our 10,000 Bytes of data is broken into 5 segments containing: 2896, 1448, 2896, 1448, 1312 Bytes each. But wait ... 2896 Bytes in a TCP segment when the MSS is 1460? (in fact, with TCP header options, like SACK and timestamp, the MSS in this capture is 1448). This is Generic Segmentation Offloading going to work: the OS is sending large segments, as captured above, and letting the NIC do the real segmentation.

So now lets turn Generic Segmentation Offloading off using ethtool:

sgordon@ginger$ sudo ethtool -K eth0 gso off

And run the netcat transfer again and look at the tcpdump output this time:

sgordon@ginger$ sudo tcpdump -i eth0 -n 'not port 22'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:33:02.644356 IP 192.168.1.2.5002 > 10.10.1.22.5001: S 3144010294:3144010294(0) win 5840 
18:33:02.645427 IP 10.10.1.22.5001 > 192.168.1.2.5002: S 3901655238:3901655238(0) ack 3144010295 win 5792 
18:33:02.645471 IP 192.168.1.2.5002 > 10.10.1.22.5001: . ack 1 win 92 
18:33:02.645542 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 1:1449(1448) ack 1 win 92 
18:33:02.645558 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 1449:2897(1448) ack 1 win 92 
18:33:02.645567 IP 192.168.1.2.5002 > 10.10.1.22.5001: P 2897:4345(1448) ack 1 win 92 
18:33:02.647415 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 1449 win 68 
18:33:02.647433 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 4345:5793(1448) ack 1 win 92 
18:33:02.647439 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 5793:7241(1448) ack 1 win 92 
18:33:02.648437 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 2897 win 91 
18:33:02.648446 IP 192.168.1.2.5002 > 10.10.1.22.5001: . 7241:8689(1448) ack 1 win 92 
18:33:02.648451 IP 192.168.1.2.5002 > 10.10.1.22.5001: P 8689:10001(1312) ack 1 win 92 
18:33:02.648460 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 4345 win 114 
18:33:02.650414 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 5793 win 136 
18:33:02.650428 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 7241 win 159 
18:33:02.651469 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 8689 win 181 
18:33:02.651476 IP 10.10.1.22.5001 > 192.168.1.2.5002: . ack 10001 win 204

Now this is what we expect to see - 7 TCP segments each no larger than 1448 Bytes.

Whats the conclusion of all this? What is taught in lectures and textbooks is not always what you see in practice. I suggest turning offloading optimisations off to demonstrate the basic concepts, and then turn them back on again to illustrate the practical performance optimizations applied at the expense of theoretical layering principles.

I've had a HP C3180 colour inkjet printer for more than 3 years. However I don't really use it much for printing from the computer. As a multifunction printer, its handy to make quick photocopies (scan and print without being attached to the computer). I also use the scanner to make electronic copies of important documents. Oh, and the built-in multi-card reader (SD, MMC, CF) has been handy on occasions. However I noticed some time ago that an upgrade of Ubuntu (maybe to 9.04 - I can't remember) resulted in the scanning functionality being unaccessible. Running scanimage -L as a normal user did not detect the scanner (however running as sudo did), and using xsane resulted in an error along the lines of Failed to start scanner error during device I/O. After a bit of searching I guessed an upgrade of the HP printing software could help.

The version of hplip that comes with Ubuntu 9.04 is 3.9.2. An upgrade to the latest version (3.9.12 in Feb 2010) fixed my scanning problems. Simply download the binary from the HP Linux Imaging and Printing site, open a terminal and install:

cd Desktop
sh hplip-3.9.12.run

A number of questions are asked, the necessary Ubuntu packages installed, and the hplip software compiled and installed. To test:

scanimage -L

(run as normal user) recognizes the scanner/printer with output like

device `hpaio:/usb/Photosmart_C3100_series?serial=MY69CC540R04KV' is a Hewlett-Packard Photosmart_C3100_series all-in-one

Now when I turn my printer/scanner on, xsane starts automatically, allowing me to scan.

CPN Tools is a popular software application for creating, simulating and analysing Coloured Petri Nets. I've used it occasionally over the past 3 or 4 years, and also used its predecessor, Design/CPN, extensively during my PhD. There has always been a Linux and Windows version of CPN Tools, however the GUI in the Linux version has some bugs, and the developers have decided to concentrate only on the Windows GUI for future releases. Thats annoying for me, however all is not lost as the simulator process of CPN Tools (for simulations and state space analysis) will still run in Linux. That is, the GUI can run on one host, and it communicates via TCP/IP sockets to the simulator on another host.

With the current external version (2.2.0) I had trouble setting up the remote simulator, but after trying with the latest internal version (2.3.5) I worked it out. There are some instructions spread across different posts in the Support Maillist, but for reference I give the precise commands I used here. The instructions are for running both the GUI and simulator under Linux, but can be modified for any combination of Windows and Linux. It turns out the version of CPN Tools didn't make any difference - these instructions will work for both versions 2.2.0 and 2.3.5. (2.3.5 also provides an option in the GUI to set the remote simulator, but I didn't use that).

Install CPN Tools on both hosts, in the directory /home/user/CPNTools/. On the host that will run the simulator with example IP address 10.10.10.1, change into the install directory and run:

./cpnsim/cpnmld 7001 cpnsim/run.x86-linux

7001 is the example port number the simulator will listen on. You may choose another value (so long as it is not in use by another application. If you wanted to run the simulator under Windows, then replace run.x86-linux with run.x86-win32.exe (and of course use backslash instead of forward slash).

On the host that will run the GUI with example IP address 10.10.10.2, change into the install directory and run:

./cpntools -remote -image cpnsim/cpn.ML.x86-linux -port 7001 -host 10.10.10.1

Of course set the host IP address to the actual IP address of your simulator host and use the appropriate port number.

On the GUI host you should see output such as:

INFO: Using remote simulator (UNIX)

and the CPN Tools Gui should start. You can now open a CPN file. Once opened, on the simulator host you should see output such as:

Accepted connection from 10.10.10.2
login = cpn2000
path = ./
User login
Starting new session for user cpnsim/cpn.ML.x86-linux in ./
Starting new session
Child spawned with pid = 24935

Changing current path to ./
Executing: cpnsim/run.x86-linux @SMLload=cpnsim/cpn.ML.x86-linux @SMLcmdname=cpnsim/cpn.ML.x86-linux
GC #0.0.0.0.1.6:   (0 ms)
GC ...

and the GC output will continue as the simulator checks the syntax.

This looks, and is easy. However it took me several hours to get it working. When opening a net I would get an error in the GUI: a red popup box saying something like "Could not start the simulator. You will not be able to simulate the net". It turned out my most significant problem was the permissions of my install of CPNTools on the simulator. All files were owned by the normal user except cpn.ML.x86-linux which was owned by, and only had read permissions for root. After changing the ownership/permissions of this file to be the same as all others, everything worked. I'm not sure what lead to this situation, but hopefully now others will not make the same time-wasting mistake as me.

A simple example of sampling a sine wave at different sampling rates, and different number of levels. You can see how increasing the sampling rate and number of levels produces a digital waveform closer to the continuous sine wave. But in practice this comes at the expense of an increased required data rate to send the digital data.

Here are some of my recommendations and personal preferences for maintaining a BibTeX file for a bibliography to be used with LaTeX.

General

Paper titles do not need capital letters for the first letter of all words. Example:

title="This is the Title of a Paper on the {ABC} Protocol",

BibTeX will typically convert all but the first letter to lowercase ("This is the title of a paper on the ABC protocol"); this is ok. However you should force uppercase for acronymns or names using the braces. You should avoid using formats like (let the BibTeX style deal with the case):

title="{This is the Title of a Paper on the ABC Protocol}",

The second problem I had with my Samsung G600 was with configuring GPRS/EDGE. I use the AIS network in Thailand (brand name 1-2-Call) and tried to follow the instructions through the AIS Call Centre. The first attempt last night I told them my phone and they send me the SMS for Over-the-Air (OTA) configuration of GPRS. However when I tried to view the SMS my phone returned an error Wrong PIN ID!. I couldn't find any PIN settings relating the messages, and so I contacted the Call Centre again and they said they thought I said D600 (and sent me the configuration for the wrong phone). The said someone would call me the next day. They didn't (in all fairness, my phone ran out of credit just before our conversation ended - but they did have both my mobile number and work number to call!).

So I tried again tonight. After making it clear it was the G600, they resent the SMS but the same Wrong PIN ID! error occurred. I quick search on the Internet found all the details I needed to configure GPRS myself.

In the menu I selected: Applications -> Internet (called t-zones on my phone) -> Browser settings -> Browser Profiles and then edited a new profile with the following settings:

Profile name: AIS
Home URL: http://google.com
Bearer: GPRS Only
Proxy: Disable
GPRS Settings: 
   DNS1: 202.183.255.20
   DNS2: 202.183.255.21
   APN: internet
   Login: blank
   Password: blank
GSM Settings: I didn't change

Then Internet access worked fine. You may want to do the same GPRS settings for Messages -> Settings -> Multimedia messages -> Multimedia message profile.

I recently got a Samsung SGH-G600 mobile phone. It replaces my 5+ year old Nokia 2100. The Nokia was a great phone - it still works fine, apart from the battery that lasted about 1 day and the numbers are almost wiped off the keypad. It is nice to now have a colour screen ... and EDGE Internet access ... and a 2GB MP3 player ... and a 5 megapixel camera.

The phone works great, but I had a problem with connecting with the provided Samsung PC Studio software (which lets you organise contact, files, music etc). After plugging in the mobile to the USB cable, selecting PC Studio on the phone menu the PC Studio application on my PC shows the phone connected. However when I open the contacts or files on PC Studio it reports a problem like Another PC Studio program is performing a time-consuming operation. Please wait until its finished.. After this error occurring with every attempt I search and found a solution (posted by MillyGirl at AVForums.com):

1. Unplug the usb cable from the phone
2. Type *#52828378# into phone
3. The following menu comes up:
   • 1 Trace setting
   • 2 OTA type setting
   • 3 Serial test
   • 4 TFS reset
4. Select 3 Serial test
5. And then this menu comes up:
   • 1 PPP UP
   • 2 Serial download
   • 3 Run TCK
6. Select 2 Serial download
7. The phone will reboot and once its rebooted connect the usb cable and PC Studio will work.

It works with no problems - no data is deleted from your phone. Thanks AVForums!