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. -- 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
