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
Archive for the 'Uncategorized' Category
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:
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.
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