Bug 232396 - net/miniupnpd: ipfw support does not compile, likely API change
Summary: net/miniupnpd: ipfw support does not compile, likely API change
Status: Closed Overcome By Events
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)
URL:
Keywords:
Depends on: 251822
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-18 17:42 UTC by Jeremy Cooper
Modified: 2024-01-09 10:02 UTC (History)
9 users (show)

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


Attachments
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)

SUMMARY

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.

VERSIONS

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

STEPS TO REPRODUCE

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;
          ~~~~ ^

FURTHER DETAILS

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 freebsd_committer freebsd_triage 2020-12-12 00:36:08 UTC
Hi,
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:

https://www.manpagez.com/man/4/ipfirewall/

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.

-Dan
Comment 7 PwrSurge 2021-12-20 15:14:05 UTC
Apple did in fact implement an API in their fork of ipfw which is the interface being used by miniupnpd to dynamically add or remove port forwarding rules to ipfw on the fly.

As API support was never backported to FreeBSD's IPFW, backporting Apple's IPFW API support to FreeBSD would most likely allow miniupnpd to work with IPFW in FreeBSD.
Comment 9 Jeremy Cooper 2022-01-02 22:05:31 UTC
(In reply to Dan Mahoney from comment #6)

Thanks, Dan. It's been three years. I've really lost track on this one. Out of frustration I started working on retooling miniupnpd to support an entirely different integration option: external executable / shell script. My main idea was to add code such that one could integrate with just about any firewall imaginable by having the code call out to external executables for every action.

Then I moved on to other things.
Comment 10 Thomas Bernard 2022-02-19 22:12:39 UTC
(In reply to Dan Mahoney from comment #6)

ipfw support in miniupnpd was contributed by Jardel Weyrich
 in 2009/2010 and has not been updated since.
it was meant to work with OS X up to 10.6 Snow Leopard.
Apple switched to pf since OS X 10.7.

Nobody has never contributed anything for supporting the FreeBSD version of ipfw.

looking at the ip_fw.h file of FreeBSD, I see that the API is quite different that the one from OS X, so a ipfw FreeBSD backend for miniupnpd would probably a totally new one.

As a side note, I will not merge upstream any generic backend using system() calls, as miniupnpd was designed specifically to replace UPnP IGD implementations working this way.
Comment 11 Robert Clausecker freebsd_committer freebsd_triage 2023-06-25 21:13:24 UTC
This will be addressed by bug #271732, which removes ipfw support from the port.
Comment 12 Sandi Rash 2024-01-09 10:02:43 UTC
MARKED AS SPAM