OpenBSD Journal

PF and AltQ merged

Contributed by jose on from the merge dept.

Rick Wash writes :
"Today, the packet filter PF was merged with the bandwidth control system AltQ to form a new PF that can limit bandwidth and do all kinds of fancy stuff. Still no documentation for it, but it is in the -current tree. Very cool stuff

Checkin: http://marc.theaimsgroup.com/?l=openbsd-cvs&m=103765983111026&w=2 "

Note that, as stated in the CVS commit message, it's still pretty experimental and poorly documented. However, this is a lot closer to the integration of PF and altq some of us have been wishing for. Now we need better altq docs.

(Comments are closed)


Comments
  1. By click46 () click46@operamail.com on mailto:click46@operamail.com

    AltQ is in all three BSD branches; so is it safe to assume that this merge of AltQ and PF will make it to Net and, more importantly [to me :D] FreeBSD?

    Comments
    1. By d () on

      well, since it's merged with pf I'd say your only chance is if pf is ported to FreeBSD. I'm sure ALTQ will continue to prosper in stand alone form on NetBSD and FreeBSD, you just won't have the benifits of a merged packet filter :)

    2. By Anonymous Coward () on

      I doubt it will make it to either until they go with pf and drop IPF(Net)/IPFW(Free).

    3. By db () on http://www.nipsi.de

      I don't think that they import and maintain a third packetfilter.

    4. By db () on http://www.nipsi.de

      but maybe we can start a project to port it.

      Comments
      1. By Jedi/Sector One () j@pureftpd.org on http://www.pureftpd.org/

        What for?

        If you need PF+AltQ on hardware that OpenBSD and MicroBSD don't support, go for NetBSD (PF has been ported) .

        Comments
        1. By jolan () on

          I've seen two ports. One is out of date and the other is incomplete.

      2. By click46 () click46@operamail.com on mailto:click46@operamail.com

        its not a matter of using PF on FreeBSD, its a matter of easy rate limiting in FreeBSD. AltQ is worse than sendmail when it comes to configuring and it'd be nice to have IPFW2 rules that combine both, rather than maintaining two different files.

        pf is ipf is ipfw...it doesnt matter much to me since, at the moment, I'm "stuck" with FreeBSD.

        Comments
        1. By Anonymous Coward () on

          pf is ipf is ipfw
          Really?!

        2. By Brad () brad@comstyle.com on mailto:brad@comstyle.com

          >pf is ipf is ipfw

          That couldn't be further from the truth.

          Comments
          1. By click46 () click46@operamail.com on mailto:click46@operamail.com

            oi oi oi ....no no, I wasnt proclaiming my ignorance here, I was merely pointing out that to me and my naivete, they might as well be the same!

            in anyevent dummynet is clunky and was not designed to do what I want.

        3. By Anonymous Coward () on

          IPFW has dummy net. Use that instead of altq

  2. By psygnosis () on

    cool, gotta grab -current to my devel machine

  3. By Sacha () on http://www.ligthert.net

    Everytime I asked Daniel about some feature or functionality I got the usual answer from Daniel: "We don't do features!"

    And this is a feature, it should've been: "We don't do YOUR features!" (Typo)

    Then again. Nice meeting you again at the Con ;)

    Comments
    1. By Peter Hessler () spambox@theapt.org on http://phessler.sfobug.org

      What Daniel means, is they don't ask for requests. They add features that are relevant to the piece of software. Why should there be two different pieces of software that affect how networking happens? Them not doing features allows them to do things correctly, as opposed to being pressured to do things right now.

      Out of curiosity, what features/functionality did you ask for?

      Comments
      1. By RC () on

        Well, mine was a bug report, not a reature request, that said when a hard drive was put into standby with atactl that it would spin up again, momentarily. Theo responded that it was not a bug, that the OS constanly wanted to access the hard drive (despite no running programs), so it was doing just as it should.

        So, pretty much every OS on the planet can put an otherwise idle hard drive into standby, except OpenBSD. Nice to know that it's not a bug, but a feature.

        Comments
        1. By William () on

          UNIX assumes that hard disks are always available so as I understand it, you can still use atactl to put disks into standby mode but it is pointless because it would require more power to have the disk spin down only to have it spin up again. It is requires less power to leave it just spin. Not a bug and not a feature it is just how it is.

          Comments
          1. By RC () on

            *Ahem*. No, in OpenBSD it is pointless... In just about any other operating system, as long as no running program is accessing the hard drive, you can spin it down and it will stay in standby until it is needed again.

            I had a workstation runing Linux, which I set to spindown the hard drive after 15 minutes of no use. The hard drive would remain in standby for hours at a time. Obviously that *is* saving power, reducing heat, etc. I've done the same on Windows, Mac, etc.

            It is a bug IMHO. If you have a command that spins down the hard drive, it *should* also send whatever signals required to tell the OS not to continually read it, needlessly.

            You're right, OpenBSD does assume the disks are always available. You don't seem to see that it is causing a problem/conflict.

            Comments
            1. By William () on

              I wasn't entirely disagreeing with you. I'm just saying that I understand why OpenBSD handles it this way.

              Comments
              1. By William () on

                Oh, same thing happens on NetBSD too so it is not just OpenBSD. There is a way to make it work as expected on NetBSD that should work on OpenBSD too.

                Comments
                1. By William () on

                  Well, it probably won't work on OpenBSD, but if you can get them to implement the nodevmtime mount option from NetBSD it may work.

                  Comments
                  1. By RC () on

                    Okay... I'll be sure to look into it. But the point was merely to illustrate the attitude of the OpenBSD developers to bug reports/feature requests/etc.

      2. By Sacha () on

        Actually: non at all.
        Henning Bauer interrepted and everybody was making jokes again.

  4. By Dries Schellekens () on

    pb@ provided a nice example on the pf mailing list: Re: altq and pf

  5. By Anonymous Coward () on

    has there been any improvements as to the bandwidth limiting? ie., limit a 100mbit interface to say 300kbit?

    Comments
    1. By W () on

      Isn't that what ALQ does? But you can only limit outgoing data (of course). :-)

      Comments
      1. By R3bus () on

        ALTQ does not handle correctly shaping of very small bandwidth.

        Comments
      2. By Dan () on

        It's possible to limit your download rate with AltQ too.. Just have to do a little magic, like I did.. :D

Credits

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 deadly.org 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.]