rfc: DROP returns error

rfc: DROP returns error

[Jan Engelhardt]

Time and again I notice users complaining about DROP returning an error 
when used in the OUTPUT chain:

root@nuqneh:~# iptables -A OUTPUT -o lo -p icmp -j DROP
root@nuqneh:~# ping -c1 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
--- localhost ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

I am wondering whether we should either add a new verdict to
accomodate for this, or do the following:

diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index b16cd79..2de3772 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -185,7 +185,6 @@ next_hook:
                goto unlock;
        } else if (verdict == NF_DROP) {
                kfree_skb(skb);
-               ret = -EPERM;
        } else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
                if (!nf_queue(skb, elem, pf, hook, indev, outdev, okfn,
                              verdict >> NF_VERDICT_BITS))

Re: rfc: DROP returns error

[Patrick McHardy]

Jan Engelhardt wrote:
> Time and again I notice users complaining about DROP returning an error 
> when used in the OUTPUT chain:
> 
> root@nuqneh:~# iptables -A OUTPUT -o lo -p icmp -j DROP
> root@nuqneh:~# ping -c1 localhost
> PING localhost (127.0.0.1) 56(84) bytes of data.
> ping: sendmsg: Operation not permitted
> --- localhost ping statistics ---
> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
> 
> I am wondering whether we should either add a new verdict to
> accomodate for this, or do the following:

I've been thinking about this myself. EPERM for packets dropped by
an explicit DROP seems fine in general. There are other cases where
this is not correct though, for example when rerouting in mangle
and we don't have a route anymore.

I think what we should do instead of adding new verdicts is something
similar to how NF_QUEUE works, encode the error code in the upper 16
bits and return it from nf_hook_slow.