OpenBSD Journal

important PF diff lays the foundation for future support

Contributed by phessler on from the king-bula-commands-it dept.

Henning and McBride are working on a very important update to PF, fixing up the interface abstraction code, which requires a ton of testing. Y'all know the routine, diff is at http://marc.theaimsgroup.com/?l=openbsd-tech&m=111626198315764&w=2

(Comments are closed)

Comments

  1. By Venture37 (217.22.88.121) venture37 # hotmail com on www.geeklan.co.uk

    on which release is the testing to be done on, 3.6??

    Comments

    1. By djm@ (203.217.30.86) on

      -current of course

      Comments

      1. By Anonymous Coward (81.57.42.108) on

        By the way, http://openbsd.org/faq/current.html (former upgrade-minifaq.html) stopped to 3.7. Changes since OPENBSD_3_7 cvs tag (nearly one month ago) aren't covered.

        I've read on openbsd-cvs mailing list that there were several flag days since then.

        Would installing the snapshot from today require special precautions ?

        Comments

        1. By Nick Holland (68.43.115.33) nick@holland-consulting.net on http://www.openbsd.org/faq/

          There are (and have been) three post-unlock (i.e., 3.7-current) changes on current.html:
          # 2005/03/29 - Exception handling flag day (i386)
          # 2005/03/31 - mmap(2) flag day (vax)
          # 2005/04/13 - New user and group: _hostapd

          If you feel some have been missed, please either put together a diff, or beat on the developer who didn't keep current.html, uh, current. However, I must say, I was rather happy with how fast those three entries into current.html were made.

          As for installing a -current snapshot, no, no special issues. Snapshots should always be internally consistant, they should install and work. Upgrades can be a bit more exciting, that's what current.html is intended to help you with, actually: NOT building your system from an earlier build, but rather, what needs to be done AFTER you install a -current snapshot. If you are worried about building your compiler, don't -- you should just use a snapshot with the new compiler in it.

          Nick.

          Comments

  2. By Matt (67.105.229.98) on

    Any hint as to what Henning is talking about when he alluded to "more changes coming"? I'm not up to date on what kind of fun things they might have in mind.

    Comments

    1. By Anonymous Coward (204.209.209.129) on

      It would seem by there comment on what needs testing might hold clues to what is coming. As per the email above: important to test (besides lots of general testing) is hotplugging interfaces, and removal. load rulesets referring to not yet existant interfaces and plug em later and verify the rules work as intended and such.

    2. By dqueue (68.167.163.185) on

      Yesterday, /. linked to this KernelTrap article about the upcoming BSDCan Hackathon.

      Henning Brauer talked about his plans for this hackathon, "there is some serious cleanup to do in pf, that Ryan and myself started over the last days in Montreal already. This is a prerequisite for finally letting pf make use of the interface groups stuff I wrote a year ago. Claudio and myself will spend some time in the routing code, cleaning it up and looking for performance bottlenecks (not that we're slow now, but we believe we can do even better). We'll work on bgpd too of course, likely some v6 stuff and changes in the filter language, mainly, the ability to define a filter set and apply it later on multiple times."

      "And of course something completely unforseeable will happen," Henning continued, "and it likely will be cool. I have no idea what it will be, but it always has been the case in the past :)"

      Comments

      1. By Jason Dixon (69.174.136.18) jason@dixongroup_NO_SPAM_.net on http://www.dixongroup.net

        I can only hope that the optimizations lead to supporting runtime macro expansion for labels.

        Pleeeeaze.... :)

        -J.

    3. By Jim (198.62.124.245) on

      I would like to connect oBSD servers to mutliple switches and failover as necessary. ifstated seems like what I'm looking for but it's not in the base install... I wonder if this functionality will fall out of their work. I can hope! ;-)

      Comments

      1. By Brad (204.101.180.70) brad at comstyle dot com on

        A good ammount of work has already gone into a generic trunking pseudo interface, for a poor mans outbound only trunking of interfaces at the moment. Next on the TODO list as I've been told would be a multi interface failover, like Linux's bonding driver (mode 1) or HP's NIC teaming (Network Fault Tolerance Only with Preference Order) as examples. and of course after that the next logical step would be adding LACP support (802.3ad).

      2. By sthen (81.168.66.229) on

        > I would like to connect oBSD servers to mutliple switches and failover as necessary.

        Is it an option to bridge them and run spanning-tree?

        Comments

        1. By Jim (198.62.124.245) on

          I just spoke with our network team and they say no. We have a large network and spanning tree can take up to a minute (too long). Good idea though! Thanks.

        2. By djm@ (218.214.226.34) on

          Without rapid-spanning-tree support, this is slower than just doing CARP. Also, right now I'm pretty sure that bridge interfaces don't work quite right for failover configs.

          Comments

          1. By Jim (198.62.124.245) on

            Reading the man pages does not make it seem possible to use CARP on one machine with two interfaces. My goal was interface failover on the localhost. Is that possible with CARP?

  3. By MotleyFool (134.253.26.9) on

    Well it appears that no one has replied to Henning in regards to this PF change.

    Comments

    1. By Anonymous Coward (207.229.38.13) on

      When NAT gets fixed, I'll grab a recent snapshot+cvs and give it a shot. My home firewall isn't doing much of nothing right now..

Latest Articles

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