Also, for all interfaces in this mode pass all ethernet frames to upper layer,
even those not addressed to our own MAC, which allows packets encapsulated
in those frames be processed with packet filters (ipfw(8) et al).
Emphatically requested by: Anton Turygin <pa3op@ukr-link.net>
Valuable suggestions by: fenner
following Julian's good suggestion: since you can specify any match
pattern as an option, rules now have the following format:
[<proto> from <src> to <dst>] [options]
i.e. the first part is now entirely optional (and left there just
for compatibility with ipfw1 rulesets).
Add a "-c" flag to show/list rules in the compact form
(i.e. without the "ip from any to any" part) when possible.
The default is to include it so that scripts processing ipfw's
canonical output will still work.
Note that as part of this cleanup (and to remove ambiguity), MAC
fields now can only be specified in the options part.
Update the manpage to reflect the syntax.
Clarify the behaviour when a match is attempted on fields which
are not present in the packet, e.g. port numbers on non TCP/UDP
packets, and the "not" operator is specified. E.g.
ipfw add allow not src-port 80
will match also ICMP packets because they do not have port numbers, so
"src-port 80" will fail and "not src-port 80" will succeed. For such
cases it is advised to insert further options to prevent undesired results
(e.g. in the case above, "ipfw add allow proto tcp not src-port 80").
We definitely need to rewrite the parser using lex and yacc!
render the syntax less ambiguous.
Now rules can be in one of these two forms
<action> <protocol> from <src> to <dst> [options]
<action> MAC dst-mac src-mac mac-type [options]
however you can now specify MAC and IP header fields as options e.g.
ipfw add allow all from any to any mac-type arp
ipfw add allow all from any to any { dst-ip me or src-ip me }
which makes complex expressions a lot easier to write and parse.
The "all from any to any" part is there just for backward compatibility.
Manpage updated accordingly.
noting that the restrictions do not apply if the user invoking the
program is also the owner of the program.
Also, capitalize a section header properly.
PR: misc/41180
Implement the M_SKIP_FIREWALL bit in m_flags to avoid loops
for firewall-generated packets (the constant has to go in sys/mbuf.h).
Better comments on keepalive generation, and enforce dyn_rst_lifetime
and dyn_fin_lifetime to be less than dyn_keepalive_period.
Enforce limits (up to 64k) on the number of dynamic buckets, and
retry allocation with smaller sizes.
Raise default number of dynamic rules to 4096.
Improved handling of set of rules -- now you can atomically
enable/disable multiple sets, move rules from one set to another,
and swap sets.
sbin/ipfw/ipfw2.c:
userland support for "noerror" pipe attribute.
userland support for sets of rules.
minor improvements on rule parsing and printing.
sbin/ipfw/ipfw.8:
more documentation on ipfw2 extensions, differences from ipfw1
(so we can use the same manpage for both), stateful rules,
and some additional examples.
Feedback and more examples needed here.
- Make getvfsbyname() take a struct xvfsconf *.
- Convert several consumers of getvfsbyname() to use struct xvfsconf.
- Correct the getvfsbyname.3 manpage.
- Create a new vfs.conflist sysctl to dump all the struct xvfsconf in the
kernel, and rewrite getvfsbyname() to use this instead of the weird
existing API.
- Convert some {set,get,end}vfsent() consumers to use the new vfs.conflist
sysctl.
- Convert a vfsload() call in nfsiod.c to kldload() and remove the useless
vfsisloadable() and endvfsent() calls.
- Add a warning printf() in vfs_sysctl() to tell people they are using
an old userland.
After these changes, it's possible to modify struct vfsconf without
breaking the binary compatibility. Please note that these changes don't
break this compatibility either.
When bp will have updated mount_smbfs(8) with the patch I sent him, there
will be no more consumers of the {set,get,end}vfsent(), vfsisloadable()
and vfsload() API, and I will promptly delete it.
with ipfw2 extensions and give examples of use of the new features.
This is just a preliminary commit, where i simply added the basic
syntax for the extensions, and clean up the page (e.g. by listing
things in alphabetical rather than random order).
I would appreciate feedback and possible corrections/extensions
by interested parties.
Still missing are a more detailed description of stateful rules
(with keepalives), interaction with of stateful rules and natd (don't do
that!), examples of use with the recently introduced rule sets.
There is an issue related to the MFC: RELENG_4 still has ipfw as a
default, and ipfw2 is optional. We have two options here: MFC this
page as ipfw(8) adding a large number of "SORRY NOT IN IPFW" notes,
or create a new ipfw2(8) manpage just for -stable users. I am all
for the first approach, but of course am listening to your comments.
The bugfix (ipfw2.c) makes the handling of port numbers with
a dash in the name, e.g. ftp-data, consistent with old ipfw:
use \\ before the - to consider it as part of the name and not
a range separator.
The new feature (all this description will go in the manpage):
each rule now belongs to one of 32 different sets, which can
be optionally specified in the following form:
ipfw add 100 set 23 allow ip from any to any
If "set N" is not specified, the rule belongs to set 0.
Individual sets can be disabled, enabled, and deleted with the commands:
ipfw disable set N
ipfw enable set N
ipfw delete set N
Enabling/disabling of a set is atomic. Rules belonging to a disabled
set are skipped during packet matching, and they are not listed
unless you use the '-S' flag in the show/list commands.
Note that dynamic rules, once created, are always active until
they expire or their parent rule is deleted.
Set 31 is reserved for the default rule and cannot be disabled.
All sets are enabled by default. The enable/disable status of the sets
can be shown with the command
ipfw show sets
Hopefully, this feature will make life easier to those who want to
have atomic ruleset addition/deletion/tests. Examples:
To add a set of rules atomically:
ipfw disable set 18
ipfw add ... set 18 ... # repeat as needed
ipfw enable set 18
To delete a set of rules atomically
ipfw disable set 18
ipfw delete set 18
ipfw enable set 18
To test a ruleset and disable it and regain control if something
goes wrong:
ipfw disable set 18
ipfw add ... set 18 ... # repeat as needed
ipfw enable set 18 ; echo "done "; sleep 30 && ipfw disable set 18
here if everything goes well, you press control-C before
the "sleep" terminates, and your ruleset will be left
active. Otherwise, e.g. if you cannot access your box,
the ruleset will be disabled after the sleep terminates.
I think there is only one more thing that one might want, namely
a command to assign all rules in set X to set Y, so one can
test a ruleset using the above mechanisms, and once it is
considered acceptable, make it part of an existing ruleset.
gcc memcpy "knows" about types that are supposed to be actually already
aligned and triggers alignment errors doing the memcpy itself.
"Fix" this by changing it to a bcopy(). In this case, we had:
struct timeval *tp;
struct timeval tv1;
memcpy(&tv1,tp,sizeof(tv1));
.. and since gcc *knows* that a pointer to a timeval is longword aligned
and that tv1 is longword aligned, then it can use an inline that assumes
alignment. The following works too:
cp = (char *)tp;
memcpy(&tv1,cp,sizeof(tv1));
Simply casting (char *)tp for the memcpy doesn't work. :-(
This affected different 64 bit platforms in different ways and depends
a lot on gcc as well. I've seen this on alpha and ia64 at least, although
alpha isn't doing it right now.
