Friday, February 03, 2006

Dangers of Tracking FreeBSD STABLE

Most of my FreeBSD systems track the SECURITY branch of FreeBSD. Wherever possible I try to apply binary updates for the kernel and userland with Colin Percival's freebsd-update tool. Most of my hardware is really old and I prefer not to spend a lot of time recompiling from source.

One of my systems does track the STABLE branch of FreeBSD, specifically RELENG_6. This is more or less a lab system. I like to see what might appear in the next version of FreeBSD, since 6.1 will be a version of STABLE.

Although STABLE is definitely more likely to be operational than CURRENT (which is the bleeding edge and will become FreeBSD 7.0), running STABLE is not without its hazards. Recently a commit appeared that changed part of the PCI code, shown with diffs here.

I happened to try updating to the version of FreeBSD STABLE that had src/sys/dev/pci/pci.c version, dated Mon Jan 30 18:42:10 2006 UTC. While compiling, I got this error:

/usr/src/sys/dev/pci/pci.c:1611: error: `PCI_IVAR_LATTIMER' undeclared
(first use in this function)
*** Error code 1
Stop in /usr/obj/usr/src/sys/JANNEY.
Error code 1
Stop in /usr/src.
*** Error code 1

I can see the line in pci.c the compiler doesn't like:

1612 *result = cfg->lattimer;
1613 break;

Shorly after version, dated Mon Jan 30 18:42:10 2006 UTC, appeared in STABLE, it was updated to, dated Tue Jan 31 14:42:43 2006 UTC. However, the diffs to the previous version don't appear to affect the PCI_IVAR_LATTIMER code. I'm not sure what happened, but I was able to update to STABLE after the new code was committed and therefore get the system compiled and running.

janney:/home/richard$ uname -a
FreeBSD 6.0-STABLE FreeBSD 6.0-STABLE #0: Tue Jan 31 22:17:14 EST 2006 i386
janney:/home/richard$ grep FBSDID /usr/src/sys/dev/pci/pci.c
__FBSDID("$FreeBSD: src/sys/dev/pci/pci.c,v 2006/01/31 14:42:43 imp Exp $");

As you can see, the system is now running STABLE as of late 31 Jan 06.


Chris Byrd said...

Out of curiosity, what do you think about using FreeBSD vs. OpenBSD? I've been interested in looking at BSD as an alternative (especially to learn pf, which I understand is superior to iptables). As a longtime Linux user, I'm told that FreeBSD would be the OS to try. As a security professional, OpenBSD does seem to have a great track record. Obviously you use FreeBSD, and as you are one of my most respected mentors in InfoSec (Marcus Ranum also comes to mind), I'm just curious as to why you use that over OpenBSD.

Richard Bejtlich said...

Hi Chris,

It depends on your needs. As a general-purpose server with a huge array of applications in the ports tree (14,000+), I like FreeBSD. For a single-purpose system with a high level of Internet exposure or responsibility (like a firewall), I like OpenBSD. The good news is that trying both costs zero money.

Anonymous said...

Having had my 1st exposure to PF through OpenBSD, I migrated over to FreeBSD once it became a standard part of the system as of 5.x

FBSD and the ports system make it a lot easier to maintain than OBSD.

I've deployed into production use both on custom systems for clients and as part of self contained solutions using PFSense.

Regardless of platform, PF is a joy to work on and maintain compared to iptables.


Joao Barros said...

Richard, better not having the kernel compile than not booting or deadlocks ;)

For a generic server/router I would choose FreeBSD over OpenBSD or in Chris case where you'll find FreeBSD a more welcoming enviroment for first time users.

I agree with greg, pf is way more friendly than iptables.
One thing I miss from iptables: a p2p module where you can discard or tag packets. Imagine ALTQ on it ;)

Richard Bejtlich said...

I didn't mention that at one point I couldn't get the kernel to boot... I had to recover from that as well!

Anonymous said...

Most of my hardware is really old and I prefer not to spend a lot of time recompiling from source.

Apparently you don't know the benefits of compiling from source:


Joao Barros said...


I resent the use of the Type-R logo to make fun of someone. What's wrong with my CTR? ;)

Joe said...


I use both FreeBSD and OpenBSD, similar to the way Richard does. For an all round server, FreeBSD and the various ports tools are great.

I leave firewalling and VPN'ing to my OpenBSD boxes. You can also run snort on them, but you have to do a manual install of snort and any tools you want. However, setting up a bonded interface when using taps is a piece of cake on OpenBSD. FreeBSD is a little more work.

PF rocks btw. So does having a transparent squid proxy and a chrooted bind (caching dns for internal users).

Anonymous said...


I am curious as to why you'd need an external module to packet shape p2p ?

I havent had much difficulty tagging and massaging p2p traffic using ALTQ here.


I can recommend adding

Ad blocking with Bind

to your internal dns. Speeds up surfing a lot


Chirs Byrd said...

Thanks for the comments. It sounds like FreeBSD is the best way to get started, with OpenBSD something to keep as an option where necessary. Now if I just had more free time...

Joao Barros said...

Yes it's doable but not dynamic and when you have such dynamic traffic like P2P you're not shaping/blocking everything.
Take for example ICQ: block the default ICQ ports,start a network capture and you'll see it try to go out through 21, 23, 80, 8080, 3128, etc. Identify it by packet pattern and you'll get it always (depending on protocol).
Of course as like snort a realtime packet parser is a cpu hog and depending on the scenario, mostly pps or bandwith this can be very dificult to apply.

Dave said...

You guys need ipp2p from
Sure, it's Loonix not FreeBSD, but it's an easy build, install & config on 2.6.12 or higher kernels..
(ipp2p is a kernel & iptables module that allows you to mark most P2P connections/sessions. It works "a trick" to allow you to mark, classify & ratelimit most modern P2P protocols!

I've also read of the ng_p2p netgraph module for FreeBSD, but I don't think it's anywhere near as good as ipp2p currently is..

Dave said...

Make that the ng_tag module at

ipp2p is (much) less cpu load than you'd think, even with its need for the CONNTRACK modules etal..