On 06/17/2016 07:22 AM, Pablo Neira Ayuso wrote: > On Wed, Jun 15, 2016 at 03:13:15PM +0000, Lubashev, Igor wrote: >> Vish, Pablo, >> >> I wonder about the value of sending more data than a client is >> willing to consume (setting aside the important fact that the client >> code crashes due to the extra data). >> >> It seems that we should either drop the nflog-range parameter from >> nflog altogether (and just use the len from the client) or allow >> nflog-range to further *restrict* the number of bytes sent to the >> client. >> >> The "further restrict" logic would make it easier to build iptables >> rules that vary nflog-range based on some match conditions, so a >> single client would get different packet length depending on what >> rules matched. > > Now I understand your usecase. Restricting the size based on match > conditions sound reasonable to me. > > Why don't you add a new userspace option, eg. --nflog-size, that > specifies this "further restrict" logic? > > What I'm proposing is: > > 1) If --nflog-range is used, print a message telling: "--nflog-range > has never worked, ignoring this option." > > 2) If --nflog-size is used, set the size in the structure that is > passed to the kernel, and apply this "further restrict" logic. > > 3) Add the flag to the kernel that I suggested. This flag is only set > via --nflog-size. > > Just to clarify: What I'm trying to avoid is breaking the thing for > users that are using this --nflog-range (even if it doesn't work) and > then change the behaviour for them. > > With the new option, we really validate that the user is exactly > asking for this "further restrict" logic that you need. > > let me know, thanks. > Sounds good to me, yes it will definitely change the behavior for users who are using that parameter (whether intentional or not). I'm OK with adding a new parameter instead of using --nflog-range. I will send a patch with these changes. -- 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
