#2 ipfw IPv6 FreeBSD7

[David Horn]

When used with IPv6, the program "/sbin/ip6fw" no longer exists. The ip6fw(8) packet filter has been removed in FreeBSD 7. Since ipfw(4) has gained IPv6 support, it should be used instead.

Of course the fix is fairly simple (in src/fwalls/ipfw.c, update the appropriate lines to ipfw instead of ip6fw

Unfortunately, it looks like this issue (in ipfw.c) still exists in sshguard 1.2, and in SVN source.

I have attached my proposed patch to ipfw.c and configure.ac (tested on 1.1 and 1.2) I also fixed an issue of exceeding the command length for ipfw (60 total bytes is not enough with IPv6, so I upped it to 90 since the IPv6 addr alone can be 39 bytes as a string)

patch <patch
autoconf
./configure -with-firewall=ipfw
make

configure will autodetect if ip6fw exists, and if it does not, will use ipfw for IPv6 instead.

[David Horn]

Patch for IPv6 ipfw FreeBSD7

[Mij]

Thanks for your update. Mac OS X still relies on ip6fw, how do you propose to address this, in a easy-to-use manner?
E.g., I'd not separate the backends; rather, we might let autoconf define a variable if we have ip6fw, and let the backend ipfw.c deal with this (at compile time).

[David Horn]

This is exactly how it is done in my patch. Configure.ac has a line that looks for ip6fw. If it exists, it is used, otherwise it uses ipfw. I also added some AC_MSG_NOTICE to tell the user at compile time what is going on. ipfw.c looks for ip6fwpath != null to determine usage. I did some tests with and without ip6fw existing to make sure it works.

+ AC_CHECK_PROG(ip6fwpath, ip6fw, `which ipfw | xargs dirname`, "")
+ if test x$ip6fwpath = x
+ then
+ ip6fwpath=null
+ AC_MSG_NOTICE([ip6fw program not in path. Using ipfw instead for IPv6])
+ else
+ AC_MSG_NOTICE([ip6fw found. Using ip6fw for IPv6 blocking])
+ fi

[Mij]

committed in the SCM, thanks