PF libpfctl: manual or examples of use

[ogogon]

Colleagues, I want to use the libpfctl library in my program.
Does anyone have even the briefest description of its use or program code from which this can be understood?

Thanks in advance,
Ogogon.

 

[Phishfry]

In absense of manual use the code.

libpfctl.c « libpfctl « lib - src - FreeBSD source tree

cgit.freebsd.org

Start with a simple status program and grow it..

#include    <sys/types.h>
#include    <err.h>
#include    <libpfctl.h>

pfctl_get_status;

 

[Phishfry]

Be advised you want to update to 0.4 as soon as the newest version hits the ports tree:

273993 – net/libpfctl: fails to build b/c of double .include

bugs.freebsd.org

 

[Phishfry]

The port commit notes provide a good background:

New port: net/libpfctl: library for interaction with pf(4)

The libpfctl port builds a shared library version of the base system
internal libpfctl library.
While the base system libpfctl API/ABI is not guaranteed to be stable
the ioctl interface is, so any version of libpfctl can be safely used.

net/libpfctl

 

[ogogon]

In absense of manual use the code.

libpfctl.c « libpfctl « lib - src - FreeBSD source tree

cgit.freebsd.org

Start with a simple status program and grow it..

#include    <sys/types.h>
#include    <err.h>
#include    <libpfctl.h>

pfctl_get_status;

"Real Programmers don't need comments -- the code is obvious."
Ed Post, Tektronix, Wilsonville

 

[zirias@]

"Real Programmers don't need comments -- the code is obvious."
Ed Post, Tektronix, Wilsonville

This is of course an overstatement ... but still true. If you need comments to explain what your code does, you're writing bad code.

Formalized comments (like e.g. for doxygen, to create API docs) aside, the key to good comments is, they should be rare and only explain why the code does something in places where this isn't obvious.

 

[Phishfry]

I should not have commented on this post. I treated it like homework.

Could somebone write libpfctl status function for me? Something like the handbook would offer. I want to learn..

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <libpfctl.h>
#include <strings.h>

    int main(int argc, char **argv)
    {
        printf(libpfctl_get_status)
};

Status seems to have several chunks. Do you need to call those? Are those the output workers?

status->running
status->since
etc...

 

[Phishfry]

Since I brought up the ports version of the library I have to ask about the path to the header file.
If you used the ports version of libpfctl would you have to point to /usr/local/lib/ version for the header?

It sound to me for portability of code use ports libpfctl. KP wrote it so I assume it is the best way.

 

[Kristof Provost]

Since I brought up the ports version of the library I have to ask about the path to the header file.
If you used the ports version of libpfctl would you have to point to /usr/local/lib/ version for the header?

It sound to me for portability of code use ports libpfctl. KP wrote it so I assume it is the best way.

The reasoning behind this is that I didn't want the in-tree libpfctl code to become a stable ABI, because that would just have moved the ABI stability problem rather than fixing it. It would have meant I still couldn't add fields to e.g. pfctl_rule for new features. As it is now the kernel still offers a stable ABI (even if it's nvlist-based for many new calls), and the ports version offers a stable ABI for ports consumers, while base can evolve more or less freely.

There's no documentation for libpfctl at the moment, but it's an extremely thin layer on top of the ioctls. If you look at either the in-tree changes (e.g. https://cgit.FreeBSD.org/src/commit/?id=6fbb9fbf7d659574512d706912e8fd0576b13573) or ports changes (e.g. https://cgit.FreeBSD.org/ports/commit/?id=a36ac4ec4f06a1d6a14f63972aaa1399035f55a6) it ought to be pretty obvious just how thin libpfctl actually is.

If you need more examples, pfctl itself is the obvious place to look.