Bug 153155 - [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on start if nat enabled
Summary: [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on start if nat enabled
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 8.2-BETA1
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2010-12-14 19:50 UTC by Thomas Sandford
Modified: 2020-07-11 16:17 UTC (History)
1 user (show)

See Also:

file.diff (334 bytes, patch)
2010-12-14 19:50 UTC, Thomas Sandford
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Sandford 2010-12-14 19:50:08 UTC
/etc/rc.d/ipfw fails to load the ipdivert module when natd is enabled.

This causes the divert rules that /etc/rc.firewall adds in this case to fail on system boot, with the following error message displayed during ipfw rule load:
ipfw: getsockopt(IP_FW_ADD): Invalid argument

Restarting ipfw works around the problem as /etc/rc.d/natd (which is run _after_ ipfw is intialised) DOES load ipdivert.

Fix: Apply the attached patch.

This is verified to fix the problem in 8.2-BETA1, also 8.1-RELEASE. The patched file is identical in HEAD (against which the patch has been created) and 8.2-BETA1.

Patch attached with submission follows:
How-To-Repeat: In /etc/rc.conf

Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-12-14 20:26:08 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-ipfw

Over to maintainer(s).
Comment 2 Hiroki Sato freebsd_committer 2011-01-05 01:06:05 UTC
Responsible Changed
From-To: freebsd-ipfw->hrs

Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:05 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 4 Tom Jones freebsd_committer 2020-07-11 16:17:13 UTC
I am going to close this issue as it is nearly 10 years old. If this bug still exists on supported FreeBSD please feel free to reopen.