[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1321548319.2751.70.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date: Thu, 17 Nov 2011 17:45:19 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Flavio Leitner <fbl@...hat.com>
Cc: David Miller <davem@...emloft.net>,
Ivan Zahariev <famzah@...soft.com>, netdev@...r.kernel.org,
Vasiliy Kulikov <segoon@...nwall.com>
Subject: Re: Unable to flush ICMP redirect routes in kernel 3.0+
Le jeudi 17 novembre 2011 à 14:40 -0200, Flavio Leitner a écrit :
> On Thu, 17 Nov 2011 17:31:50 +0100
> Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> > Le jeudi 17 novembre 2011 à 13:37 -0200, Flavio Leitner a écrit :
> > > On Thu, 17 Nov 2011 15:40:20 +0100
> > > Eric Dumazet <eric.dumazet@...il.com> wrote:
> > >
> > > > [PATCH] ping: dont increment ICMP_MIB_INERRORS
> > > >
> > > > ping module incorrectly increments ICMP_MIB_INERRORS if feeded
> > > > with a frame not belonging to its own sockets.
> > > >
> > > > RFC 2011 states that ICMP_MIB_INERRORS should count "the number of
> > > > ICMP messages which the entiry received but determined as having
> > > > ICMP-specific errors (bad ICMP checksums, bad length, etc.)."
> > > >
> > > > Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
> > > > CC: Vasiliy Kulikov <segoon@...nwall.com>
> > >
> > > Yeah, they aren't ICMP specific errors and the callers already
> > > checked for checksum, lengths, and etc.. increasing that counter
> > > when necessary.
> > >
> > > Acked-by: Flavio Leitner <fbl@...hat.com>
> >
> > Thanks
> >
> > By the way, redirects dont work at all in net-next
>
> Could you be more specific? It seems to be working here.
>
> > Probably coming from your commit 7cc9150ebe8ec0
> > (route: fix ICMP redirect validation)
> >
> > Since calling __ip_route_output_key() will create the route with s =
> > 0, l = 0 (forcing saddr and dev->ifindex) selectors...
> >
> > We have to add a 'create' parameter to __ip_route_output_key() so that
> > ip_rt_redirect() doesnt create a route, only find the existing one in
> > cache ?
>
> It should receive redirect after sending a packet, so the route
> should be ready at this point.
I receive the redirect, but the rt->peer is updated on a different route
than the one used by my ping command.
Its updated on the specific route (source address forced, output device
forced), not on the wildcarded route my ping is using.
So next packets are still sent on old gateway...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists