gnn: Testing multicast

Published on April 23, 2008 in General. 0 Comments

TCP is the protocol that gets the most attention, and that makes some sense as it’s the one that carries your email and web pages, the two most popular applications on the net.   There are times, though, when TCP is not appropriate, like when you want to multicast data to several machines at once.

Multicasting takes advantage of the fact that LANs, such as Ethernet, are broadcast media, in which all hosts can, if they choose, see all the packets as they go by.

In order to use multicast you have to use a datagram protocol, such as UDP, for reasons that I will not get into in this posting.

One of the more important qualities to test for when building a multicast network is latency. Many people know about testing for bandwidth, i.e. how many bytes/bits per second can we shove down this pipe, but latency tests are rarer. Since such tests are rare I have written one which is now included in FreeBSD. It can be found in the src/tools/tools/mctest directory of CURRENT (8.0). An example is shown below:


Source
mctest -i em0 -s 1024 -n 100 -t 1
Sink
mctest -i em0 -s 1024 -n 100 -r

Send 100 packets of 1024 bytes, with an inter-packet gap of 1 nanosecond.

The mctest program includes both the source and the sink code, and the -r command line argument is what tells the program to be a sink (i.e. to receive packets).

The way that mctest tests for latency is that the source sends out a multicast packet and then the sink(s) send the packet right back. The sinks report statistics like the size of the gap between packets, which shows network jitter, and if any packets were lost. The source reports if packets were lost as well as the round trip latency of the packets.

Results from the test look like this on the source:

Results from client #0
sec: 0 usecs: 73
sec: 0 usecs: 44
sec: 0 usecs: 48
sec: 0 usecs: 39

which shows partial results. The results for all clients are actually output. There is also a convenient shell script mctest_run.sh which can be used to start sinks on multiple hosts. All of this is documented in the manual page as well.

Happy Testing!

gnn: Interview on BSDTalk about the new IPsec

Published on July 18, 2007 in Uncategorized. 0 Comments

I was interviewed recently by Will Backman, the host of BSD Talk, about the latest changes in IPsec in FreeBSD. The podcast can be heard here:

http://bsdtalk.blogspot.com/

http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk121.ogg

gnn: FAST_IPSEC is now IPSEC in FreeBSD

Published on July 14, 2007 in Uncategorized. 0 Comments

As of about 2 weeks ago the IPsec implementations in FreeBSD were changed such that the old, Kame, IPsec is no longer in the system, and the system that was once called FAST_IPSEC is now the official IPsec of FreeBSD.

What does this mean to you?

  •  FreeBSD IPsec is now MP Safe, which is a requirement for the 7.0 release.
  • FreeBSD IPsec supports offloading cryptographic operations to specialized hardware by default.
  •  It’s time to jump in and help test these changes!

So, now it’s time for everyone to get the latest cut of HEAD and try this code out in a wider distribution.

gnn: Keeping time in a Virtual Machine

Published on April 29, 2007 in Uncategorized. 0 Comments

 Unlike suspend/resume on a laptop the guest operating system in a Virtual Machine doesn’t know when it has gone to sleep and woken up. The best way to get it to keep time correctly is to use ntpd (see ntpd(8) and ntp.conf(5)).

In order to keep ntpd running you have to tell it not to panic when it gets a very large time offset. The ntp daemon will accept an offset of up to 1000 seconds by default, but if you suspend your machine for more than that length of time the daemon will exit. In your /etc/ntp.conf file add the following lines:

tinker panic 0

The 0 says “accept any offset” which means that if your machine is suspended for a long time, as mine often are, when it unsuspends and gets a very large offset from the server everything will be OK.

You can also decide to specify the -g flag to the ntpd daemon in the flags section in rc.conf but it’s likely better to use the configuration file since you’ll need one anyway, and then upgrading and making a mistake with mergemaster won’t kill your settings.

gnn: BSDTalk Podcast on Virtual Machines…

Published on April 29, 2007 in Uncategorized. 0 Comments

Will Backman of BSDTalk interviewed me about my work with kernel development and virtual machines. You can find the podcast here:

http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk109.mp3

and you can find all the podcasts on BSDTalk here:

http://bsdtalk.blogspot.com/

I’ll be adding more posts about working with virtual machines in the near future.

gnn: Remote GDB on VMWare

Published on March 11, 2007 in Uncategorized. 0 Comments

One of the reasons to use virtual machines is that they make kernel debugging easier. No messing about with serial cables anymore, the simulator provides you with virtual serial ports, which to the operating system look just like real serial ports. In this entry I’ll explain how to use remote GDB with VMWare virtual machines. My current setup is VMWare 5.x on Linux with FreeBSD-CURRENT (7.x) as the guest.

In order to set up remote GDB you’ll need two virtual machines, one of which you’ll be debugging from, which I call devbox, and the other is the one you’re debugging which is often called a target, and which I call dut, short for Device Under Test.

Preparing a Kernel

For the DUT you will need to prepare a kernel that has support for remote GDB. Add the following lines to your kernel configuration file and compile the kernel on devbox:


options KDB # Enable kernel debugger support.
options DDB # Support DDB.
options GDB # Support remote GDB.

Install the newly compiled kernel into your DUT virtual machine. DO NOT INSTALL IT ON DEVBOX or you will be sorry.

On the DUT you will need to add the following lines to loader.conf:

hint.sio.1.flags=0x90
boot_gdb=1

gnn: PCS and Packet Debugger on BSDTalk

Published on February 28, 2007 in General. 0 Comments

I was interviewed recently by Will Backman of BSDTalk about PCS and Packet Debugger. The full interview is here:

<a href=http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk101.mp3>Interview</a>

and the BSD Talk page itself is here:

<a href=http://bsdtalk.blogspot.com/>BSDTalk Page</a>

gnn: Announcing the Packet Debugger

Published on February 8, 2007 in General. 0 Comments

In order to facilitate the debugging of networking code I have used my library, <a href=http://pcs.sf.net>Packet Construction Set aka PCS</a> to write a program I call the <a href=http://pktdbg.sf.net>Packet Debugger (pdb)</a>. All of this is written in Python and available under a BSD license. The blurb from the pdb web page gives you the best idea of what I’m doing:

“The Packet Debugger (pdb) is a program which allows people to work with packet streams as if they were working with a source code debugger. Users can list, inspect, modify, and retransmit any packet from captured files as well as work with live packet capture.” – pdb web page

There is a twelve page manual on the web page that describes how to use the debugger as well.

gnn: Configuration Files for FreeBSD Development on Parallels

Published on February 8, 2007 in General. 0 Comments

This post points to two files, PARA, my kernel configuration file, and loader.conf which sets the kernel’s HZ back to 100. The default hz in FreeBSD CURRENT (will be 7.0) is now 1000 which is too high for Parallels to keep up with and causes it to eat about 15% of the CPU on my MacBook. With HZ set to 100 an idle virtual machine uses only 5% of the CPU, which is less than OSX’s windowserver process.

<a href=people.freebsd.org/~gnn/PARA>PARA</a>

<a href=people.freebsd.org/~gnn/loader.conf>loader.conf</a>

gnn: Parallels Desktop as a Network Development System

Published on February 8, 2007 in General. 0 Comments

 As some of you may, or may not know, I tend to do a lot of my kernel development in virtual machines, such as <a href=www.vmware.com>VMware</a> and now <a href=http://www.parallels.com/>Parallels</a> on my MacBook. I find that virtual machines make the perfect test lab because you can easily create, copy, store, backup and delete them. For a more full discussion of using virtual machines for kernel and protocol development see my presentat from the <a href=http://www.bsdcan.org/2006/papers/VirtualProtocolandKernelDev.pdf>BSDCan</a> conference in 2006.

To build a proper network test lab you not only need machines with multiple interfaces but a way to hook those interfaces to each other. Until the most recent versions of Parallels, around December of 2006, this was not possible, and so I had to stick with VMware, on Linux. Now with the advent of 3 types of networking on Parallels, bridged, shared and host only, it is possible to have 3 interfaces independently active for use in testing.

At home my typical setup is that ed0 is a bridged network, which connects to the outside world, and ed1 is shared, and then ed2 is host only. Testing occurs on ed1 and ed2 in order for there to be a “quiet” network on which to do tests.

The next step that Parallels needs to take to make this truly work is to provide the equivalent of a hub per network, much like private networks in VMware, at which point all this messing about with different types of network interfaces can cease and I can safely continue to do testing wherever I like.

For those of you who want to do this kind of work I will be uploading my kernel configuration and other files in another post.