In the unfortunate event that the kernel crashes during config save, both config.xml and the last backup might be broken. Let's try to find the last functional config when unable to init()
usage: pluginctl [-h] -[c] [-s] [arguments]
optional arguments:
-h show this help text and exit
-c configure mode (default), executes plugin [_configure] hook
-s service mode (e.g. myservice restart)
without arguments, a list of plugins of the requested type is shown
Currently the direction of the traffic can only be chosen in floating rules, but in some scenario's it's much easier to create outbound rules (only inbound is supported now).
When using a lot of interfaces, which should all be allowed to access devices on one specific interface, this would save quite some rules and is easier to track for the administrator.
This feature adds direction as on option and while already changing these pages, also allow to create "non quick" rules on interfaces.
Functionally the "regular" rules would be more aligned with the "floating" rules as we have now, with the exception that you can't add multiple interfaces in a normal rule due to the inability to reorder a single rule in multiple rulesets (rules are positional).
Policy based routing on outbound rules is not supported on the interface rules for now, since it would probably lead to confusion.
The old configuration defaults still apply, when writing an entry, both quick and direction are saved as well (default quick + in).
DHCP-relay service will fail with the following error if DHCP server IP is know in static route:
dhcrelay: Can't attach interface {ifname} to bpf device /dev/bpf0: Device not configured
This is the only place where get_real_interface( ) isn't used
Our current generated ruleset creates two count rules to match incoming and outgoing traffic to and from the client for accounting purposes. Since ipfw doesn't support table stats, the options are limited to know the amount of traffic processed and last accessed times.
This patch basically replaces the accounting section with seperate blocks, which are jumped to using the exising table (which contains address + rulenumber now), logically this would lower the time needed to parse the accounting section (since only the count rules for the specif ip's are evaulated now).
In terms of ruleset, this will generate 3 rules per address (count from, count to and jump to end of ruleset), like:
```
30001 342 27744 count ip from xxx.xxx.xxx.xxx to any
30001 1194 225783 count ip from any to xxx.xxx.xxx.xxx
30001 1536 253527 skipto 60000 ip from any to any [ <--- NEW ]
```
Since we need the address to collect rules, we can't simply this count to one rule (IPFW.list_accounting_info() parses the address from the ruleset).
Our per zone "skipto" section, uses a tablearg in stead of static rule number now:
```
03001 2362 386004 skipto tablearg ip from table(1) to any via em2
03001 5701 4761746 skipto tablearg ip from any to table(1) via em2
```
