Enable on OpenBSD and FreeBSD

[alvinpeters]

trafficstars

Replaces the ioctl-sys with the ioctl macros from nix crate. The nix crate allows this library to be built on other platforms like FreeBSD.

Passes all tests until the states test, although the main branch fails as well for literally the same reasons. Tested on macOS Sonoma 14.5 on an M1 Pro MacBook. Done FreeBSD tests through cross-rs with the same result.

Pending full testing on macOS and FreeBSD.

Edit: Currently passing on macOS test runs: https://github.com/striczkof/pfctl-rs/actions/runs/9457974825. Fails anchors test on FreeBSD and OpenBSD: https://github.com/striczkof/pfctl-rs/actions/runs/9458110537.

---

This change is 

[faern]

Thanks for wanting to contribute! Can you please try to minimize changes to Cargo.lock? :pray: This PR pulls in serde_derive and does a bunch of other things it probably should not do. When I try to add nix locally it just adds bitflags and nix to Cargo.lock. We don't want unnecessary churn on the lockfile.

If this supposedly works for integrating to the FreeBSD version of PF then I think we should have CI tests for that. Does Github actions support that? If we don't have tests it will inevitably break without us noticing. Could you look into adding such tests maybe?

[faern]

Would it make sense to try to upstream FreeBSD support to ioctl-sys instead/also? They added OpenBSD support a while back, so looks like it should be possible?

[alvinpeters]

Hey, thanks for checking out my PR and apologies for not replying ASAP. I hyperfocused into trying to make this crate actually work on OpenBSD and then FreeBSD after. I just discovered that they are way too different now. (after 20 years of divergence obviously) For example; OpenBSD doesn't use pool addresses (pf_pool is just wired funny), and FreeBSD doesn't have types for port ranges. I'm changing this PR to reflect that.

I'm developing on OpenBSD 7.5 and FreeBSD 14.1. Using these man pages for reference on enabling OpenBSD and FreeBSD respectively: https://man.openbsd.org/pf https://man.freebsd.org/cgi/man.cgi?pf(4)

If anyone knows where to find pf(4) manual page for macOS Sonoma or closer please lemme know! I need it to cross-reference and Apple loves being a PITA.

Thanks for wanting to contribute! Can you please try to minimize changes to Cargo.lock? 🙏 This PR pulls in serde_derive and does a bunch of other things it probably should not do. When I try to add nix locally it just adds bitflags and nix to Cargo.lock. We don't want unnecessary churn on the lockfile.

I manually modified Cargo.toml for the exact same reason of trying to get rid of random churn (but failed). error-chain is somehow bringing other dependencies along the way. I suggest getting rid of Cargo.lock altogether like other libraries, and only using major versions in the Cargo.toml. Plus getting rid of error-chain would be a great bonus too. Perhaps this work will justify bumping this crate to 0.5? I can also try to 'pre-expand' the macros so we can drop the ioctl macro dependency altogether. I can either put that in this crate or create 'pf-sys' containing the bindings and the ioctl calls. The caveat with that is that it might be a bit hard to read/maintain and could be a non-singular point of failure.

If this supposedly works for integrating to the FreeBSD version of PF then I think we should have CI tests for that. Does Github actions support that? If we don't have tests it will inevitably break without us noticing. Could you look into adding such tests maybe?

Right now, I've added tests for the 2 BSDs using VM on ubuntu-latest. I've also modified the generate-bindings.sh to be able to generate bindings for those BSDs. Plus some initial (non-compiling) work for OpenBSD done already. (Also, sorry for the random commits lol, I'll squash them once everything's done.)

Would it make sense to try to upstream FreeBSD support to ioctl-sys instead/also? They added OpenBSD support a while back, so looks like it should be possible?

I'll try that once I'm done with this one. Judging by the last update date, I don't reckon the maintainers are active enough, plus I want a working ioctl wrapper right now.