objects with the same name in different sets.
Add optional manage_sets() callback to objects rewriting framework.
It is intended to implement handler for moving and swapping named
object's sets. Add ipfw_obj_manage_sets() function that implements
generic sets handler. Use new callback to implement sets support for
lookup tables.
External actions objects are global and they don't support sets.
Modify eaction_findbyname() to reflect this.
ipfw(8) now may fail to move rules or sets, because some named objects
in target set may have conflicting names.
Note that ipfw_obj_ntlv type was changed, but since lookup tables
actually didn't support sets, this change is harmless.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
It allows implementing loadable kernel modules with new actions and
without needing to modify kernel headers and ipfw(8). The module
registers its action handler and keyword string, that will be used
as action name. Using generic syntax user can add rules with this
action. Also ipfw(8) can be easily modified to extend basic syntax
for external actions, that become a part base system.
Sample modules will coming soon.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
Currently we have different table key types which can easily interfere
with each other (numbers and IPv4 address, interface names and hostnames,
flows and hostnames/addresses).
This conflicts are solved by [auto-]creating _typed_ tables, so after
table is created, only keys of given type can be inserted to that table.
ipfw(8) consults with kernel about key/value type for particular table so
it knows key/value interpretation.
However, we have 2 cases (adding entries to non-existing table and
parsing configuration file via `ipfw -n`) when kernel is unable to
provide us table info we need. Fix the latter case by partially importing
old `table_fill_xentry()` parse function responsible for guessing key type.
Sponsored by: Yandex LLC
directly in the O_FORWARD_IP6 opcode. Use getnameinfo(3) to formatting
the IPv6 addresses of such opcodes.
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
to obtain IPv4 next hop address in tablearg case.
Add `fwd tablearg' support for IPv6. ipfw(8) uses INADDR_ANY as next hop
address in O_FORWARD_IP opcode for specifying tablearg case. For IPv6 we
still use this opcode, but when packet identified as IPv6 packet, we
obtain next hop address from dedicated field nh6 in struct table_value.
Replace hopstore field in struct ip_fw_args with anonymous union and add
hopstore6 field. Use this field to copy tablearg value for IPv6.
Replace spare1 field in struct table_value with zoneid. Use it to keep
scope zone id for link-local IPv6 addresses. Since spare1 was used
internally, replace spare0 array with two variables spare0 and spare1.
Use getaddrinfo(3)/getnameinfo(3) functions for parsing and formatting
IPv6 addresses in table_value. Use zoneid field in struct table_value
to store sin6_scope_id value.
Since the kernel still uses embedded scope zone id to represent
link-local addresses, convert next_hop6 address into this form before
return from pfil processing. This also fixes in6_localip() check
for link-local addresses.
Differential Revision: https://reviews.freebsd.org/D2015
Obtained from: Yandex LLC
Sponsored by: Yandex LLC
anything until the interface is assigned an address. This fixes
ipfw_nat to do the same by using an IP of INADDR_ANY instead of
aborting the nat setup if the requested interface is not yet configured.
Differential Revision: https://reviews.freebsd.org/D1539
Reviewed by: melifaro, glebius, gnn
MFC after: 1 week
we can't easily predict (in current parsing model)
if the keyword is ipfw(8) reserved keyword or port name.
Checking proto database via getprotobyname() consumes a lot of
CPU and leads to tens of seconds for parsing large ruleset.
Use list of reserved keywords and check them as pre-requisite
before doing getprotobyname().
Obtained from: Yandex LLC
Kernel changes:
* Split kernel/userland nat structures eliminating IPFW_INTERNAL hack.
* Add IP_FW_NAT44_* codes resemblin old ones.
* Assume that instances can be named (no kernel support currently).
* Use both UH+WLOCK locks for all configuration changes.
* Provide full ABI support for old sockopts.
Userland changes:
* Use IP_FW_NAT44_* codes for nat operations.
* Remove undocumented ability to show ranges of nat "log" entries.