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.
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:
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.
Â 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.
Will Backman of BSDTalk interviewed me about my work with kernel development and virtual machines. You can find the podcast here:
and you can find all the podcasts on BSDTalk here:
I’ll be adding more posts about working with virtual machines in the near future.
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:
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.