[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100812124813.GB4881@albatros>
Date: Thu, 12 Aug 2010 16:48:13 +0400
From: Vasiliy Kulikov <segooon@...il.com>
To: Sven Eckelmann <sven.eckelmann@....de>
Cc: Greg Kroah-Hartman <gregkh@...e.de>, Andrew Lunn <andrew@...n.ch>,
Marek Lindner <lindner_marek@...oo.de>,
Simon Wunderlich <siwu@....tu-chemnitz.de>,
devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
Linus Lüssing <linus.luessing@....de>
Subject: Re: batman-adv: design suggestions
On Mon, Aug 09, 2010 at 22:53 +0200, Sven Eckelmann wrote:
> Vasiliy Kulikov wrote:
> > 1) Some incoming packets may cause a storm of error logs, such as at
> > routing.c:862
> >
> >
> > if (icmp_packet->msg_type != ECHO_REQUEST) {
> > pr_warning("Warning - can't forward icmp packet from %pM to "
> > "%pM: ttl exceeded\n", icmp_packet->orig,
> > icmp_packet->dst);
> >
> > Any flooding bad guy is able to fill our disks with logs.
> > This should be logged only at some slow rate (e.g. 5 logs/sec) or as
> > pr_debug().
>
> Correct. So you would prefer pr_warn_ratelimited?
As I see in net/, such packets should be silently dropped with
drop_count++. Exceeded TTL is rather common situation and is not critical.
Also such buggy packets should be found out & dropped as fast as possible.
So IMO it should be debug output (if any) that does no overhead at nodebug
compilation.
3) Also there is no handler of online MTU change, at hard_if_event().
Is there any (un)official documentation/RFC/whatever of batman-adv
protocol? I found only expired RFC of batman that is using UDP at
www.open-mesh.org.
Thanks,
Vasiliy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists