I'd like to re-open this discussion. I apologize for not responding sooner; I've been a bit busy. I'm also not subscribed to netfilter-devel, so this message may bounce from there. On Sat, May 23, 2009 at 6:20 AM, Jan Engelhardt<jengelh@xxxxxxxxxx> wrote: > Then again, people might be using -m limit -j DROP to simulate actual > packet loss, for whatever scientific interests they currently have. Which is precisely what happened: I was using DROP to simulate packet loss to test timeout handling in a program. The program in question does handle errors, but that wasn't the code path I wanted to exercise. I wasn't aware of netem, but DROP would be all I needed in this case (if it didn't return -EPERM). In my former life as a sysadmin, it never occurred to me to interpret DROP as "administratively prohibited"; that is what REJECT is for. I interpreted DROP as "drop the packet silently, without any response", which I think is the intuitive interpretation. An ICMP reply to a remote machine is a response, and changing the return value of a system call is also a response; neither is desirable. The current behavior produces different results on local and remote machines - programs on the remote machine time out, while programs on the local machine get an error. I think this inconsistency - or asymmetry - is undesirable. What happens when adding an INPUT DROP rule for a protocol and port bound for a socket where a daemon is listening? If we apply this interpretation consistently, then when the rule is added, those listen() calls should be interrupted and return -EPERM. I don't think that's desirable behavior either - I think the kernel should drop the packets when they arrive, and the listening daemon should never know it happened. Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > Reporting -EPERM seems to me a good practise to report user-space > applications that the kernel is explicit dropping the packet. Otherwise, > while diagnosing problems, people cannot be sure where the packet has > been lost. I don't agree. In fact, the current behavior makes this worse, because the -EPERM behavior is unexpected (I think the interpretation of DROP as silent is very common) and inconsistent (different things happen if you're dropping remotely versus locally) - so it's not like you can forget that you must check both end's firewalling rules when you're diagnosing a problem. -- Mike Acar -- 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
