OpenBSD Journal

Theo Interview at on Wireless Firmware situation

Contributed by grey on from the more news from the freed firmware dept.

Thanks to Simmoril for pointing out:

Jeremy Andrews of has a feature interview with Theo de Raadt regarding the recent push from the OpenBSD community to try and get wireless chipset vendors such as Texas Instruments to open source their firmware. The full story can be found here.

It is also worth noting (and is discussed a bit in Jeremy's interview) that the ath driver was imported with a free Hardware Abstraction Layer (HAL) yesterday. Exciting progress, but what about those TI ACX cards? Bill Carney et al at TI I guess still need encouragement to get on board.

(Comments are closed)

  1. By Anthony ( on

    Is it just me or has OpenBSD gained greater acceptance with the open source community in general in the last few years?

    1. By Nate ( on

      It is not just you, OpenBSD has from my eye risen pretty well recently. A large part of that is OpenSSH, but the squable about ipf helped to draw attention to OpenBSD and brought in some people that are interested in the ideas that Open pushes as their modus operandi.

      Hell, OpenNTPd has helped too.

      1. By Anonymous Coward ( on

        What about OpenBGP?

      2. By Anthony ( on

        I think the addition of SMP helped, as a lot of people just dismissed OpenBSD because of the lack of SMP (despite the fact that virtually everyone has a UP machine).

        I think the IPF spat raised a lot of eyebrows but it's the very rapid progression of features and capabilities that's gained acceptance for PF and by extension OpenBSD. It went from being a pet project of Theo because he was (percieved as) being a prick to being included by default on all the BSDs, with talk of all of them moving towards it as the default. Also, I read somewhere that the Linux Netfilter people wanted to bring Netfilter up to OpenBSD 3.3 PF equivilant capabilities by 2006 or so, and PF has hardly been sitting still in that time.

        I don't know about the security... Linux people are pretty happy with their security capabilities, such as they are.

        1. By Anonymous Coward ( on

          The way I see things, *personally*...

          I believe Theo himself has a big and great part of it all. For one, he's the leader just as Linus is to Linux and that's a big needed thing, a leader, and he's a damn good one at that too!

          FreeBSD and NetBSD, I've never hear of such one person other than maybe JKH?

          In a sense or two, Theo is '[re]defining' standards, security and setting those standards for all other OSS projects as a whole, including proprietary vendors such as Cisco, MS, etc. Some people might think he's an asshole, but he's got a great vision and he sticks to his guns! He deserves a hell of a lot more attention and a shitload more credit - for what he's doing, what he's done and what he will continue to do for us all.

          One thing I really like that he said was:

          One guy at Intel claims that Mandrake Linux has "signed" this contract. In the past I might have found that fascinating, but increasingly I am not surprised because the corporate ways of Linux vendors are starting to override the Linux idealism.

          That's one of the nice things about OpenBSD - OpenBSD *is* FREE. IMHO, too many corporations are destorying the original Linux idealism where'as OpenBSD will remain, OpenBSD.

          Don't want to start a war... I might be drunk right now, but I'm just contributing my personal thoughts and opinions here.

        2. By Charles Hill ( on

          Also, I read somewhere that the Linux Netfilter people wanted to bring Netfilter up to OpenBSD 3.3 PF equivilant capabilities by 2006 or so, and PF has hardly been sitting still in that time.

          Care to back that up, or at least point out a credible source?

          Reading through Daniel Hartmeier's Design and Performance of the OpenBSD Stateful Packet Filter (pf) over at shows iptables beating pf in every measure: less loss, greater thruput, lower latency, higher maximum packet handling. I believe this document is almost 2 years old, though.

          I was looking for a decent comparison of features and wasn't able to find one thru Google. The best I got were anecdotal opinions along the lines of "pf has better syntax but iptables is faster".

          While we are moving into winter in the Northern Hemisphere, I haven't heard any reports of hell freezing over so I seriously doubt the Netfilter people said anything along the lines of "we'll catch up to where pf is today sometime around 2006". If so, drug tests would be in order.

          Does anyone have a feature comparison list of pf and iptables/netfilter? I am curious as to which does what and why, etc.


          1. By baldusi ( on

            Have you ever used both?!?!
            Speed with 1.0 pf version versus a relativelly mature ipchains is not a fair comparison. But even if it was, speed is not what ipchains was lagging behind. It's features and correctness. So you can't really compare since the statefullness of Linux is not 100% but fuzzily "good enough". The syntax is awful. The nat and routing are not integrated. Bandhwidth shaping is not integrated nor as feature rich. There's nothing like tags. There's no CARP. There's a lot of things that are not there. Plaing and simple. Go read each documentation and see what I mean.

          2. By sthen ( on

            One big thing that pf does, and many other pieces of firewall software don't, is to perform strict checking on TCP sequence numbers (to make sure they're in a reasonable window from the established connection before they're let through).

            Of course there's options like packet scrubbing, TCP state modulation (to protect firewalled hosts with poor sequence randomisation), authpf, filtering by uid, filtering by host OS (e.g. 'greylist all port 25 coming from windows but leave Unix alone'), etc. Automatic ruleset optimisation, in more recent versions, too.

            I find having the bandwidth management and NAT integrated into the firewall ruleset, with sane syntax, very helpful, too.

          3. By Anthony ( on

            You'll note that the speeds at which it matters which filter you're using are well outside what you'll reach with any internet connection you're likely to have access to, and that's on a Pentium Classic 166 mhz. Also, from the paper: "Iptables has not been included in this benchmark because it does not do stateful filtering comparable to pf and IPFilter. The version of iptables that we tested employs connection tracking without any sequence number analysis for packets outside of the initial TCP handshake. While this is unsurprisingly faster, it would be an unfair performance comparison. There is a patch for iptables that adds sequence number checking, but it is still beta and is not included in the GNU/Linux distribution used for testing." This version of iptables lacked capabilities, and could not be used in several of the tests. If it had the capabilities, it would be slower than the results presented in that paper.

          4. By Matt Van Mater ( on

            One small point that you fail to mention is that document you referenced is significantly out of date. If you actually read through it, it becomes clear that it was written for the original release of pf in openbsd 3.0 (it makes a few references to 'new' features which were implemented in openbsd 3.1). Yes, that means that this document is about 3 years old.

            I think that there have been significant improvements in the past few years for both iptables as well as pf so this comparison doesn't mean crap. (unless you're running openbsd 3.0, which I hope you're not)

            1. By Charles Hill ( on

              Read my comment again. Paragraph 2 ends with a sentence saying my source was about 2 (or so) years out of date. That's why I was asking for pointers to more recent info.

              1. By Matt Van Mater ( on

                oops my bad, I didn't see that part of your post. Why would you bother making a comparison like that knowing how old it was and that it was likely to be severely outdated?

                One thing you will see on the mailing lists is that there aren't benchmarks because what really matters is how the solution works in your environment with your setup. I know that sounds like a copout, but it makes sense.

                You'd need to have a standard procedure for how to generate the traffic, what kind of rules to make (and then you get into semantics of whether rules are identical), how to log the traffic statistics, and most importantly how to interpret the results and identify the causes of the results like Daniel did. You could take it a step further than Daniel took and discuss the hardware involved (ie performance of intel fxp drivers vs realtek rl drivers: there will be a difference between them). Then if you really want to follow good scientific method, every step needs to be documented fully so others can reproduce the tests in their own environment to duplicate the results and verify the analyst's claims.

                I personally don't have the time or desire to benchmark PF against a firewalling program that I have no intention of using regardless of the performance results. I think most PF users would agree with me on that point, so I don't think you're going to get a nice writeup like that from someone who actually knows what they're talking about (like Daniel, Henning or Cedric).

                1. By Charles Hill ( on

                  No prob.

                  Actually, I used that one because it was the only real in-depth document I could find in 15-20 minutes of googling.

                  I'm not really interested in performance comparisons. I am interested in feature comparisons -- what one does that the other doesn't, etc.

                  I think I'm just going to have to go through the docs of both and create my own chart.


                  1. By Anthony ( on

                    If you turn up some really good docs for the Linux side can you please post a link here?

                    All I've ever found has been HOWTOs. They tell you hwo to do X for a small set of common X, but I never found anything resembling a comprehensive manual.

                2. By M.Raju ( on

                  Certainly, I really don't care what IPTables has to offer. PF does all and more than any commercial offerings. Why really bother?

            2. By codguy ( on

              unless you're running openbsd 3.0, which I hope you're not

              Well, I'm still running v3.1 on a 24/7 connected machine that runs as a simple firewall and serves a bit of static web content. Yes, I've kept my patching up-to-date, but as you can imagine it's getting harder and harder since even v3.4 is now EOL'ed...

              I guess that's a testimony to how robust and well-designed OBSD is, but hey, I'm probably preaching to the choir with this.

              Yeah, yeah, yeah, I know there are many reasons to upgrade, and I'll probably make some time in the near future to move the machine to v3.6. But it's sure great to be able to connect a machine 24/7, and not worry about it for several years except for some basic patching. Again, probably preaching to the choir with this...


    2. By Anonymous Coward ( on

      Who wouldn't accept it? It lives for security, has features like no other, is audited rigorously, it isn't MS based, and its free!

      1. By Anthony ( on

        "Who wouldn't accept it? It lives for security, has features like no other, is audited rigorously, it isn't MS based, and its free!"

        Great. Zealotry.

        The fact is that some people don't accept it. It doesn't matter if it makes sense or not because it's the factual truth.

  2. By psyops4 ( on

    it would be nice to have realtek, and broadcomm, and the others on board with the cheapo(less popular) wireless chipsets..

    1. By tedu ( on

      realktek support is coming. broadcom sucks.

      1. By psyops4 ( on

        agreed.. they definitely sux

  3. By baldusi ( on

    I've recieved an "automated message the the TI guy had flown to Europe". Three days after sending the mail. But just in time to save face from having lied to Theo about going to Europe. Go figure.

    1. By Anonymous Coward ( on

      But isn't shipping code that hasn't been audited by anyone in the OBSD community a bad idea?

      1. By baldusi ( on

        It's software that goes into the WiFi _CARD_. You can't go around auditing the BIOS, the VGA BIOS, the SCSI firmware etc.

        1. By grey ( on

          As a total tangent to the issue at hand: actually projects like LinuxBIOS are conceivably auditable. And back in the days/world of LISP machines, savvy users would even make optimizations to microcode (albeit, their reference with respect to the terminology microcode may have been different than our perceptions today). That said, in today's vendor environment, that level of access such a rarity as to make your point accurate on a practical level, if not a wholely factual one.

          The increasing availablity of LinuxBIOS from motherboard vendors (Tyan is noteworthy) is laudable, and in a similar way, one might wish to support hardware vendors who cooperate with F/OSS as much as possible; assuming you get the required functionality from such products.

  4. By Anonymous Coward ( on

    I think Theo is a big pussy.

    1. By Anonymous Coward ( on

      yeah! and big one.

    2. By psyops4 ( on

      or NOT!!

    3. By Anonymous Coward ( on

      WOW you got the lowest mod rating ever ;) ... I think theo is a strong leader ... and he can also admit errors ("Perhaps we were a bit ahead of the game with caring about licenses so, er, fanatically.")

      1. By Anonymous Coward ( on

        Theo is all about love and charisma.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]