OpenBSD Journal

pfctl improvements - 'set...' options no longer sticky

Contributed by grey on from the subtle changes and improved documenation dept.

We would like to thank Ryan McBride for writing in to let us know about the following pftctl change. The commit message may be found here.

Ryan provided us with an additional description as follows:

With this change, if you do:
       set optimization aggressive
and then later comment it out:
       #set optimization aggressive
The timeouts go back to the defaults; the same applies for:

set limit
set timeout
set hostid
set loginterface
set fingerprints
set debug

The same behaviour will come to 'set skip' as well soon.

(Comments are closed)

  1. By Anonymous Coward ( on


  2. By Anonymous Coward ( on

    Was that "merge" option done in part to make Linux iptables users feel more at home (i.e., one-rule-per-command-invocation in a shell script)? :-)

    1. By Peter Hessler ( on

      no, it was done so people could disable options w/o having to flush the changes out. I've been bitten by this before in the past, and I'm very happy to see it added.

    2. By Anonymous Coward ( on

      OK, OK, as a Linux iptables user, I have to admit that was pretty good. :-)

      I am learning OpenBSD as well; it looks like it's got a lot to offer. I'm definitely looking forward to playing with this CARP redundancy; that looks like a really cool, highly useful hack.

  3. By Anonymous Coward ( on

    I don't like it: comments should be treated as such (and they are at most places), that is, no meaning. This new feature is leading to confussion, and breaks the intuitive interface of pf.

    1. By Otto Moerbeek ( on

      You seems to confuse things. To clarify this a bit:

      A commented out set should return the value to its default. This only comes into effect on the next pf.conf reload.

      If you specify:

      set bla ...
      followed by
      #set bla ... 
      In the same file, the first given value of bla still applies, of course.

      So to repeat, this new feature only applies if you load a new ruleset which does not have values specified for some settings. These will be reset to default values.

      1. By Anonymous Coward ( on

        OK, that amkes sense. Thanks for the lucid explanation.

    2. By Anonymous Coward ( on

      wouldn't it be cleaner to use something like:

      set optimization aggressive
      # and later:
      set optimization default

    1. By Michael Knudsen ( on

      Exactly what do you want credit for? You asked if a certain behaviour was intended without explaining why you think it is bad, and as far as I can se, you didn't provide any patches either.

      Good work, Ed.

    2. By Anonymous Coward ( on

      so you are saying you wrote it and somebody comitted it with no credit?

      1. By Ed White ( on

        I don't write patch for OpenBSD anymore since they don't give credits. Every time I report a strange/weird problem they fix it without giving credits.

        1. By Anonymous Coward ( on

          can you say specifically what patch of yours has been commited with no credit given to you?

        2. By Kevin ( on

          "Every time I report" ... "they fix it without giving credits.". It sounds like you haven't actually submitted any patches. You report a problem and they fix it for you. They're doing *you* a favor, and you want credit for *their* work, just for asking for the fix? And you have the nerve to say "OpenBSD developers keep forgetting to give credits to people." Unreal.

        3. By Anonymous Coward ( on

          > Every time I report a strange/weird problem THEY FIX it without giving credits.

          If you didn't fix it, why do you want credit for the fix?

          If you're comparing finding a "strange/weird problem" to finding a remote exploit as the same class and you're demanding the same acknowledgement, then hopefully these proverbs will help.

          "Climbing a mountain, one should not give up when difficulties accumulate. Accumulating merit, one should not complain about fate." Proverb

          "Climbing a mountain, one should not give up when difficulties accumulate. Accumulating merit, one should not [climb a mountain.]" Proverb

          "A samurai may be distressed by his own lack of ability, but never by the failure of others to recognize his merits." Proverb

        4. By Luiz Gustavo ( on

          I'm reporting bugs and another strange behaviours since 2001 or something and always had a good touch.

          Perhaps you should stop seeking fame and glory paying attention only to be really happy of just having a clue to finding bugs, having good ideas or simply writing good code.

          If you are to browse around cvs history you will end up seeing loads of credits being given, maybe it is just a developer a bit lazy early in the morning. (;

    3. By Anonymous Coward ( on

      No, they don't forget at all. Simply reporting a bug doesn't get you credits in the source code. Actually writing code to fix it and submitting said code--now, that's another matter, and they do rightfully give credit there.

      1. By Ed White ( on

        This is not how it works. Some developers do it right, some don't. It's just a personal choice.

        1. By Anonymous Coward ( on

          you sure sound like someone to judge developers!
          somebody who has not produced shit!

        2. By Ben Lindstrom ( on

          It isn't? Then I expect a lot more credit to be given me from my younger years when my C skills were lets say "not up to par." Maybe I should piss and moan to Lesstif and about 20 other projects I helped port to Linux, Interactive UNIX and HP/UX.

          Frankly, I really dislike people that go "I want XX credit for suggestion ZZ.. I want ZZ copyright placed at the top of the file because of my PDQ patch..." Code comes and goes. I'm sure that code I've written or helped QC back in the mid-1990 has been long since replaced. And not getting a copyright or CVS plug doesn't bother me.

          Why? I know what I have done. There isn't a need to broadcast such stuff to the whole world. It wouldn't gain me any more respect, love or money than I'm making now. And it doesn't boost my self-esteem which was very well established when I was younger.

          - Ben

  5. By Ed White ( on

    Look at the URL. There are multiple ways to give credits and multiple ways to help. Bugs are "found by camield@", "reported by kos(at)bastard(dot)net", "analyzed by Pyun YongHyeon", "Reported by adm at celeritystorm dot com", "Reported by Bernhard Schmidt", "Report and test data by Srebrenko Sehic". Every type of help should get its credits, even if only in a commit log.

    1. By Anonymous Coward ( on

      they are not "credits" but links to people for future refernce
      in case same issue shows up again or the same code has to be modified
      and testing needs to be done again for the same problem.

      what is the value of a bug report w/ no fix supplied to be credited for?
      _you_ are supposed to credit whoever fixed your problem for you with
      generous offer of beer.

    2. By Anonymous Coward ( on

      How pathetic.

    3. By djm@ ( on

      Why can't you just be happy that the issue is fixed for you? Surely that is is the important thing...

      1. By Ed White ( on

        Damien, I'm happy for the fix. My first comment was very simple. Not a flame.

        1. By Anonymous Coward ( on

          now not only fixing but also reporting for your problems
          you prefer to be done by somebody else.... way to go!

    4. By jtorin ( on

      Isn't it ironic that any goodwill you could possibly receive from the credit of this idea/fix... is nullified by you whining here?

      1. By Ed White ( on


        1. By Brad ( brad at comstyle dot com on

          Ed, get real. You're not going to get credit for REQUESTING a FEATURE ADDITION. There is a difference between a BUG FIX and a FEATURE ADDITION.


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