On Saturday 2009-05-23 13:43, Pablo Neira Ayuso wrote: >>> Returning >>> -EPERM seems to me quite sane to note that the kernel is explicit (via >>> iptables, for example) not allowing permission to send(). >> >> Yeah but DROP is perceived by users to be "silently ignore it", >> while the "you don't have permission" is REJECT's job. > >But the DROP and REJECT behaviours refer to the packet logic, ie. with >DROP nothing is done, with REJECT we send some explicit packet (like an >ICMP administratively prohibited). That still applies to user-space. -EPERM is an "administrative prohibited" for userspace, just like a returned ICMP packet. Here, functions overlap. >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. Then again, people might be using -m limit -j DROP to simulate actual packet loss, for whatever scientific interests they currently have. So just wanting to know - are people supposed to use xt_STEAL instead if they really want it silently dropped? >I'm more like in favour of forcing people to fix their applications, >they are doing a broken error handling. Think UDP :) -- 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
