https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293642
Bug ID: 293642
Summary: ipfw table valtype order is normalized internally but
not documented
Product: Base System
Version: 16.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
When creating a table with multiple valtype entries, ipfw may internally
normalize (reorder) them. The table add command requires values to be provided
in the internally stored order, not necessarily in the order specified during
create.
This behavior is not clearly documented. As a result, users may supply values
in the same order as given at creation time and encounter parsing errors. The
effective order can only be determined via ipfw table <name> info, which may
differ from the user-specified order.
Example
# ipfw table t create type addr valtype ipv4,fib
# ipfw table t add 1.1.1.1 2.2.2.2,3
ipfw: Unable to parse 2.2.2.2 as fib
# ipfw table t add 1.1.1.1 3,2.2.2.2
added: 1.1.1.1/32 3,2.2.2.2
# ipfw table t info
--- table(t), set(0) ---
kindex: 1, type: addr
references: 0, valtype: fib,ipv4
algorithm: addr:radix
items: 1, size: 416
Also note the following example:
# ipfw table r create type number valtype
mark,ipv6,ipv4,limit,netgraph,divert,tag,dscp,nat,fib,pipe,skipto
# ipfw table r info
--- table(r), set(0) ---
kindex: 2, type: number
references: 0, valtype:
skipto,pipe,fib,nat,dscp,tag,divert,netgraph,limit,ipv4,ipv6,ma
algorithm: number:array
items: 0, size: 296
Observe that the valtype output is truncated (ma instead of mark).
--
You are receiving this mail because:
You are the assignee for the bug.
