Date: Fri, 16 Feb 2018 06:55:46 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 225944] ipfw table destruction exit code and -q option Message-ID: <bug-225944-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225944 Bug ID: 225944 Summary: ipfw table destruction exit code and -q option Product: Base System Version: 11.1-STABLE Hardware: Any OS: Any Status: New Keywords: feature Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: vladimir-csp@yandex.ru This command: ipfw table sometable destroy always returns 0 even if 'sometable' does not exist. This command: ipfw table sometable create type addr behaves correctly (0 on creation, 71 if table already exits) Since autocreating table when adding address is now deprecated, it would be logical if -q option would also be supported for create/destroy commands. Currently a ruleset like this would work on boot, but fail on ipfw restart: -qf flush table 10 create type addr -q table 10 add 172.17.2.1/32 add 00010 allow tcp from table(10) to me Supporting -q option on create/destroy would make this construction workabl= e: -qf flush -q table 10 create type addr -q table 10 add 172.17.2.1/32 add allow tcp from table(10) to me Another inconsistency is produced when checking the above ruleset (first variant without -q for create): # ipfw -n ipfw.rules Flushed all rules. Line 3: DEPRECATED: inserting data into non-existing table 10. (auto-created) 00010 allow tcp from table(10) to me 'ipfw -n' ignores table create line, ignores existence of table 10, makes it impossible to tell whether the ruleset would work or not. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-225944-8>