Re: rfc: DROP returns error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux