| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit da8ecc62dd765b15df84c3aa6b83dcb7a81d4ffa.
The patch's original intention is not entirely clear anymore. If it was
to reduce delays involved by calling getprotobynumber() though, commit
b6196c7504d4d ("xshared: Prefer xtables_chain_protos lookup over
getprotoent") avoids those if --numeric flag was given already. Also,
this numeric protocol output did not cover iptables-save which is a more
relevant candidate for such optimizations anyway.
Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1729
Signed-off-by: Phil Sutter <phil@nwl.cc>
|
| |
|
|
|
|
|
|
|
|
| |
This is much trickier than expected: On one hand, proto_to_name() is
used to lookup protocol extensions so must resolve despite FMT_NUMERIC
being set. On the other, --verbose implies --numeric but changing the
output there is probably a bad idea. Luckily the latter situation is
identified by FMT_NOTABLE bit.
Signed-off-by: Phil Sutter <phil@nwl.cc>
|
|
|
Lookahead buffer used for cache requirements estimate in restore
--noflush separates individual lines with nul-chars. Two consecutive
nul-chars are interpreted as end of buffer and remaining buffer content
is skipped.
Sadly, reading an empty line (i.e., one containing a newline character
only) caused double nul-chars to appear in buffer as well, leading to
premature stop when reading cached lines from buffer.
To fix that, make use of xtables_restore_parse_line() skipping empty
lines without calling strtok() and just leave the newline character in
place. A more intuitive approach, namely skipping empty lines while
buffering, is deliberately not chosen as that would cause wrong values
in 'line' variable.
Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1400
Fixes: 09cb517949e69 ("xtables-restore: Improve performance of --noflush operation")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Arturo Borrero Gonzalez <arturo@netfilter.org>
|
