6 Replies Latest reply: Nov 30, 2012 9:50 AM by powercore
powercore Level 1 Level 1 (10 points)



I've a problem with the "pf" Packet Filter on Mac OS X 10.7.5. If I using rules with "route-to" and any of this rules

match's this leads to a Kernel Panic and the System reboots. Has anybody expirience with this behaviour or eaqul




Shortly a User Story to understand what I'am doing:


There are two dedicated Networks with two Routers (networks holding the Internet connections).

I want to make a load balancing over both lines for that "pf" offers the possiblity to using a rule with "route-to" and a

"round-robin" packet distribution.


Example Rule:


pass in on en0 route-to { (vlan0, (vlan1 } round-robin from (en0:network) to !


If now this rule matches the system reboot's with a Kernel Panic. I'am sure this is still a Bug in the operating System self.





Mac mini, Mac OS X (10.7.5), OS X Server
  • Linc Davis Level 10 Level 10 (177,955 points)

    Although pf should be able to do that, the OS X version is compiled without the necessary facility.

  • powercore Level 1 Level 1 (10 points)

    Hi Linc,


    thanks for your reply. Its strang to belive that because I'am able to load and activate the rule into the 'pf' Engine of the Kernel. That requires that the pfctl Tool and the Kernel Engine self parse and accept the rule.


    Also I quickly check the pfvar.h on Apples Open Source tree.







    Also the operation is still defined there.

    Could you please explain your assumption?


    Thanks and regards,


  • etresoft Level 7 Level 7 (27,135 points)

    I looked into this briefly and couldn't find any reports of missing capability in the packet filter or associated kernel panics. However, routing is not an area that I know very well.


    Source code is different. Like you, I peeked at the kernel source and didn't see anything explicit. I did see a number of places where it manually issues a panic. Those include a short message. Do you have error messages in your panics that could be traced back to the offending kernel source? If so, I could help track that down. Unfortunately, much to the chagrin of Chrome users, I'm not an expert in kernel panics either. The only one I've had in past few years was caused by trying to automount MacFUSE in Mountain Lion.

  • powercore Level 1 Level 1 (10 points)

    Hi Linc, thanks for your replay. I believe the ALTQ functionality is not related to this problem.

    Because this is more or less a traffic shaper functionallity. Also from the "pf" engine point of view this is differnet code. All rules related to ALTQ Classes using the option "queue" in the syntax of a rule where the general definition for a interface is using "altq" command instead of "pass" or "block".


    • altq on - enables queueing on an interface, defines which scheduler to use, and creates the root queue
    • queue - defines the properties of a child queue


    Also you will got a error if you try to load any kind of ALTQ related rules into the "pf" engine.





  • powercore Level 1 Level 1 (10 points)

    Hi etresoft,


    thanks for sharing you're efforts as well! Unfortunately the crash reports provides no details which are helpful because its only related to "kernel_thread" as issuer. Btw I create a problem ticket (bug report) and Apples Engineering Team also ask for that and I provide the more or less insufficient stuff. Lets see if I got a response about the problem may more details etc. to this topic. The "pf" gift from OpenBSD is a very nice feature and a very powerful implementation. There are still much more bugs which I found by using this engine on MacOSX (leads not to a crash but freeze the system). But yes, step by step lets see what the engineering team telling us.