Message ID | 1294917210.3570.48.camel@edumazet-laptop |
---|---|
State | Not Applicable, archived |
Delegated to: | David Miller |
Headers | show |
Hi Eric, On 13/01/11 12:13, Eric Dumazet wrote: > ipt_CLUSTERIP users might hit this annoying printk, if they forgot an > "iptables -I INPUT -m state --state INVALID -j DROP" before CLUSTERIP > rule. We could use net_ratelimit() here, or not log the message at all. > I chose to log it once per config. I think that this should be converted to pr_debug() instead, there's also another reference to "unknown protocol" that should be converted as well. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13.01.2011 12:23, Pablo Neira Ayuso wrote: > Hi Eric, > > On 13/01/11 12:13, Eric Dumazet wrote: >> ipt_CLUSTERIP users might hit this annoying printk, if they forgot an >> "iptables -I INPUT -m state --state INVALID -j DROP" before CLUSTERIP >> rule. We could use net_ratelimit() here, or not log the message at all. >> I chose to log it once per config. > > I think that this should be converted to pr_debug() instead, there's > also another reference to "unknown protocol" that should be converted as > well. I think the FIXME could also be removed, we *do* drop invalid packets in CLUSTERIP. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 13/01/11 12:28, Patrick McHardy wrote: > On 13.01.2011 12:23, Pablo Neira Ayuso wrote: >> Hi Eric, >> >> On 13/01/11 12:13, Eric Dumazet wrote: >>> ipt_CLUSTERIP users might hit this annoying printk, if they forgot an >>> "iptables -I INPUT -m state --state INVALID -j DROP" before CLUSTERIP >>> rule. We could use net_ratelimit() here, or not log the message at all. >>> I chose to log it once per config. >> >> I think that this should be converted to pr_debug() instead, there's >> also another reference to "unknown protocol" that should be converted as >> well. > > I think the FIXME could also be removed, we *do* drop invalid > packets in CLUSTERIP. Hey! You're back! :-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c index 1e26a48..bac8739 100644 --- a/net/ipv4/netfilter/ipt_CLUSTERIP.c +++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c @@ -47,6 +47,7 @@ struct clusterip_config { u_int8_t clustermac[ETH_ALEN]; /* the MAC address */ struct net_device *dev; /* device */ u_int16_t num_total_nodes; /* total number of nodes */ + bool warned_no_conntrack; unsigned long local_nodes; /* node number array */ #ifdef CONFIG_PROC_FS @@ -301,10 +302,14 @@ clusterip_tg(struct sk_buff *skb, const struct xt_action_param *par) ct = nf_ct_get(skb, &ctinfo); if (ct == NULL) { - pr_info("no conntrack!\n"); - /* FIXME: need to drop invalid ones, since replies - * to outgoing connections of other nodes will be - * marked as INVALID */ + if (unlikely(!cipinfo->config->warned_no_conntrack)) { + cipinfo->config->warned_no_conntrack = true; + pr_info("no conntrack!\n"); + } + /* FIXME: need to drop invalid ones, since replies + * to outgoing connections of other nodes will be + * marked as INVALID + */ return NF_DROP; }
ipt_CLUSTERIP users might hit this annoying printk, if they forgot an "iptables -I INPUT -m state --state INVALID -j DROP" before CLUSTERIP rule. We could use net_ratelimit() here, or not log the message at all. I chose to log it once per config. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> CC: Patrick McHardy <kaber@trash.net> --- net/ipv4/netfilter/ipt_CLUSTERIP.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html