[Bug 37] icmp match defaults to --icmp-type icmp-echo-reply
bugzilla-daemon@netfilter.org
bugzilla-daemon@netfilter.org
Mon, 03 Feb 2003 16:52:56 +0100
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=37
laforge@netfilter.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Additional Comments From laforge@netfilter.org 2003-02-03 16:52 -------
Incompatible solutions:
1) have a special value meaning "no icmp type specified", for example -1 (0xFF)
would mean "any"
2) create a possibility to match a range of icmp types, and initialize the
range to [0,max_icmp_type]
3) use a bitmask instead of a range where each bit would mean a specific
icmp type
Option 1) could be implemented without changing the size of the match
struct, the other two would involve changing the size of the match struct.
I've checked the kernel source, specifying -1 for old kernels would mean
'match nothing', thus our beloved compatibility equations would be like
this:
1) old kernel - new iptables
when ANY icmp type is specified, no packets would be matched, this is
different from the current behaviour when icmp type 0 is matched (PONG).
when a usual icmp type is specified everything works correctly.
2) new kernel - old iptables
no problem.
The question is whether we can live with the incompatibility of matching
nothing instead of PONG when no --icmp-type is specified.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.