iptables: fix longopt reecognition and workaround getopt(3) behavior
* On the first call to getopt, opts was NULL, so long options would
not be recognized until a match/target was loaded.
Whacky getopt behavior:
* If the longopts parameter is NULL, getopt fails to recognize unknown
options, such that `iptables-multi main --append` will print a garbage
help message ("main needs an argument").
* If the longopts parameter is NULL on the first call, but not on
subsequent calls, it completely screws up option parsing, taking
the --dport in `iptables-multi main -A INPUT -p tcp --dport 1000`
as --destination instead, but not accepting "--destination 1.2.3.4"
either.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
diff --git a/ip6tables.c b/ip6tables.c
index 150893d..8318f91 100644
--- a/ip6tables.c
+++ b/ip6tables.c
@@ -147,6 +147,7 @@
struct xtables_globals ip6tables_globals = {
.option_offset = 0,
.program_version = IPTABLES_VERSION,
+ .opts = original_opts,
.orig_opts = original_opts,
.exit_err = ip6tables_exit_error,
};