Bug 232396 - net/miniupnpd: ipfw support does not compile, likely API change
Summary: net/miniupnpd: ipfw support does not compile, likely API change
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Depends on: 251822
  Show dependency treegraph
Reported: 2018-10-18 17:42 UTC by Jeremy Cooper
Modified: 2021-07-23 21:52 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (squat)

Full build log (after config step) (9.38 KB, text/plain)
2018-10-18 17:42 UTC, Jeremy Cooper
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Cooper 2018-10-18 17:42:37 UTC
Created attachment 198311 [details]
Full build log (after config step)


At a glance, miniupnpd appears to have support for all three of FreeBSD's firewall types: pf, ipfilter, and ipfw. But ipfw support does not compile, and the fix to make it compile does not look very simple; ipfw may have undergone an API re-write in the time since ipfw support was included in miniupnpd.


FreeBSD: 11.2-RELEASE r335510
Ports: Not sure, probably vanilla version from 11.2-RELEASE
net/miniupnpd: 1.9.20160113


The code in question will not be configured at compile time unless the host system has enabled ipfw in /etc/rc.conf. (This is done in genconfig.sh in the miniupnpd distribution):

1. Add firewall_enable="YES" to /etc/rc.conf before attempting to build the port.

2. Change directories to the miniupnpd port: cd /usr/ports/net/miniupnpd/

3. Configure the port: make config, accept the default, which is only "IPv6 protocol support"

4. Make

5. The build process should fail when compiling ipfw/ipfwrdr.c:

  cc -O2 -pipe  -I/usr/include -fstack-protector -fno-strict-aliasing -Wall -W Wstrict-prototypes -fno-common -c -o ipfw/ipfwrdr.o ipfw/ipfwrdr.c ipfw/ipfwrdr.c:176:7: error: no member named 'version' in 'struct ip_fw'
          rule.version = IP_FW_CURRENT_API_VERSION;
          ~~~~ ^


The code appears to include <netinet/ip_fw.h> for its main kernel interface. The members of the structures currently defined in this file, however, bear little resemblance to the members being used by the code. For instance, the very first compilation error above implies that there is a "version" member in the "ip_fw" structure. There is no such member in the current code. Likewise, the symbol "IP_FW_CURRENT_API_VERSION" doesn't exist at all in any header file under /usr/include.
Comment 1 Daniel Engberg 2020-12-12 00:36:08 UTC
Is this still an issue?
Comment 2 Jeremy Cooper 2020-12-13 20:05:50 UTC
I'll upgrade my ports tree and give it a whirl.
Comment 3 Jeremy Cooper 2020-12-13 20:52:06 UTC
I can't fully test whether ipfw support has been improved; another issue blocks me. I've opened it separately: bug #251822.
Comment 4 Jeremy Cooper 2020-12-13 20:57:12 UTC
Adding bug #251822 as blocker for this issue.
Comment 5 Jeremy Cooper 2020-12-13 23:51:42 UTC
Changing bug title to be a little clearer. (Compile issue due to API change instead of "completely broken").
Comment 6 Dan Mahoney 2021-07-23 21:52:38 UTC
ipfw support has not been improved.  It seems to be the opinion of the developers that the world has moved on to pf.  (https://miniupnp.tuxfamily.org/forum/viewtopic.php?p=3987) I disagree.

It looks like the original ipfw support was based on the ipfw that was in OSX.  Their 'man 4 ipfw' page can be seen here:


It documents a complete API with applications designed to be written against it.

FreeBSD's "man 4 ipfw" makes no such mention.

You can compare Apple's and FreeBSD's /usr/include/netinet/ip_fw.h

I see two ways forward:

1) Someone with some good kernel knowledge rewrites the ipfw support for a modern FreeBSD with ipfw2.

2) Someone rewrites this as something that can do a system() call to a helper app (same as most ddns, let's encrype, and dhclient programs do.

Jeremy, if you still would like an upstream pull, I can make a port for the new version and submit it for update.  It will not help the ipfw situation.