I was interviewed recently by Will Backman of BSDTalk about PCS and Packet Debugger. The full interview is here:
and the BSD Talk page itself is here:
<a href=http://bsdtalk.blogspot.com/>BSDTalk Page</a>
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.
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.
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.