Re: missing icmp errors for udp packets

Re: missing icmp errors for udp packets

[kuznet]

Hello!

> So in conclusion:
> 
> with net.ipv4.icmp_echoreply_rate=0:

Congratulations! That's why I do not see this, forgot to ping before. :-)

The patch is enclosed.

Alexey


--- ../dust/vger3-010728/linux/net/ipv4/icmp.c	Thu Jun 14 22:49:44 2001
+++ linux/net/ipv4/icmp.c	Sun Jul 29 19:52:55 2001
@@ -240,12 +240,15 @@
 int xrlim_allow(struct dst_entry *dst, int timeout)
 {
 	unsigned long now;
+	static int burst;
 
 	now = jiffies;
 	dst->rate_tokens += now - dst->rate_last;
 	dst->rate_last = now;
-	if (dst->rate_tokens > XRLIM_BURST_FACTOR*timeout)
-		dst->rate_tokens = XRLIM_BURST_FACTOR*timeout;
+	if (burst < XRLIM_BURST_FACTOR*timeout)
+		burst = XRLIM_BURST_FACTOR*timeout;
+	if (dst->rate_tokens > burst)
+		dst->rate_tokens = burst;
 	if (dst->rate_tokens >= timeout) {
 		dst->rate_tokens -= timeout;
 		return 1;

Re: missing icmp errors for udp packets

[Pekka Savola]

On Sun, 29 Jul 2001 kuznet@ms2.inr.ac.ru wrote:

> Hello!
>
> > So in conclusion:
> >
> > with net.ipv4.icmp_echoreply_rate=0:
>
> Congratulations! That's why I do not see this, forgot to ping before. :-)
>
> The patch is enclosed.

Alexey, there is a tiny problem with your patch.

If you reboot the computer, the _first_ ping/scan attempt will not return
icmp dest unreachable.  All of the rest do.  If the network was quiet
enough, I guess there might be some circumstances where this could be
applicable again..


> --- ../dust/vger3-010728/linux/net/ipv4/icmp.c	Thu Jun 14 22:49:44 2001
> +++ linux/net/ipv4/icmp.c	Sun Jul 29 19:52:55 2001
> @@ -240,12 +240,15 @@
>  int xrlim_allow(struct dst_entry *dst, int timeout)
>  {
>  	unsigned long now;
> +	static int burst;
>
>  	now = jiffies;
>  	dst->rate_tokens += now - dst->rate_last;
>  	dst->rate_last = now;
> -	if (dst->rate_tokens > XRLIM_BURST_FACTOR*timeout)
> -		dst->rate_tokens = XRLIM_BURST_FACTOR*timeout;
> +	if (burst < XRLIM_BURST_FACTOR*timeout)
> +		burst = XRLIM_BURST_FACTOR*timeout;
> +	if (dst->rate_tokens > burst)
> +		dst->rate_tokens = burst;
>  	if (dst->rate_tokens >= timeout) {
>  		dst->rate_tokens -= timeout;
>  		return 1;
>

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

Re: missing icmp errors for udp packets

[kuznet]

Hello!

> If you reboot the computer, the _first_ ping/scan attempt will not return
> icmp dest unreachable.

Hmm... how fast after reboot?

Alexey

Re: missing icmp errors for udp packets

[Pekka Savola]

On Tue, 31 Jul 2001 kuznet@ms2.inr.ac.ru wrote:
> Hello!
>
> > If you reboot the computer, the _first_ ping/scan attempt will not return
> > icmp dest unreachable.
>
> Hmm... how fast after reboot?

Can be quite a long time.  Previously, I tested it immediately after
reboot.  Now I tried it about 6 minutes after I had typed 'reboot' with
success.

I believe it may be the first ICMP message to be sent after reboot..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

Re: missing icmp errors for udp packets

[clemens]

On Tue, Jul 31, 2001 at 10:33:56PM +0400, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> > If you reboot the computer, the _first_ ping/scan attempt will not return
> > icmp dest unreachable.
> Hmm... how fast after reboot?

your patch will not prevent the first ping to empty the token bucket,
because burst is still 0, which is larger than dst->rate_token, and since
XRLIM_BURST_FACTOR times the timeout (which is 6*0=0 in that case) is the
token maximum, it will be truncated to 0, causing the following packets (if
in time) to be dropped.

clemens

Re: missing icmp errors for udp packets

[kuznet]

Hello!

> your patch will not prevent the first ping to empty the token bucket,
> because burst is still 0, which is larger than dst->rate_token, and since
> XRLIM_BURST_FACTOR times the timeout (which is 6*0=0 in that case) is the
> token maximum, it will be truncated to 0,
> causing the following packets (if in time) to be dropped.

Argh... I see, gap is too short and not enough of tokens are accumulated.
Thank you.

Damn, I see two ways: 1. to make sysctl active function
and recalculate max/sum of rates over classes and fill bucket.

Or to remove limiting distinguishing types, which is ideal
logically.

Alexey

Re: missing icmp errors for udp packets

[Chris Wedgwood]

On Tue, Jul 31, 2001 at 11:04:06PM +0400, kuznet@ms2.inr.ac.ru wrote:

    Or to remove limiting distinguishing types, which is ideal
    logically.

Why do we do this anyhow?



  --cw

Re: missing icmp errors for udp packets

[kuznet]

Hello!

> Why do we do this anyhow?

I have no idea. This is too old facility to be remembered.

Anyway, it is clear that echos are to be limited differently of errors.

Alexey

Re: missing icmp errors for udp packets

[Chris Wedgwood]

On Tue, Jul 31, 2001 at 11:25:50PM +0400, kuznet@ms2.inr.ac.ru wrote:

    Anyway, it is clear that echos are to be limited differently of
    errors.

Even then I wonder if it is worth the code.  If you are rate-limiting,
who cares if drop the odd echo/reply?

ICMP echo/reply is a useful diagnostic tool --- but on the internet as
we have it today, its limitations need to be understood by the user :)



  --cw

Re: missing icmp errors for udp packets

[kuznet]

Hello!

> ICMP echo/reply is a useful diagnostic tool --- but on the internet as
> we have it today, its limitations need to be understood by the user :)

But what do you propose eventually? :-)

To bind all of them together? Then kernel must be shipped out
without rate-limiting enabled by default, that's problem.

Alexey

Re: missing icmp errors for udp packets

[Chris Wedgwood]

On Tue, Jul 31, 2001 at 11:37:06PM +0400, kuznet@ms2.inr.ac.ru wrote:

    To bind all of them together?

Sure... why not?

The kernel normally does one of two things

   --- multiplex hardware resources for applications

or

   --- cheap router thing

"really good ping responder" is a pointless purpose.

    Then kernel must be shipped out without rate-limiting enabled by
    default, that's problem.

I guess I missed something.  That doesn't seem like a problem to
me... and if you need to ship with a rate by default, then ship with a
very-high rate.  I've never managed to respond to more than 60,000
ICMP packets/second, so I suggest 60,001.




  --cw

Re: missing icmp errors for udp packets

[Pekka Savola]

On Wed, 1 Aug 2001, Chris Wedgwood wrote:
>    --- cheap router thing
>
> "really good ping responder" is a pointless purpose.

bad ping responder == bad PR ;-)

And anyway, who is anyone to judge what the system should be used for?

I want a system to respond to ping without limitations; it's good for
debugging, diagnostics, etc.  If I want, I can just filter the requests
out, or rate-limit the responses.

However, ICMP error messages cannot be effectively filtered; they may
happen due to TTL=0 when forwarding, legit or illegit UDP connection etc.;
only way to effectively limit them is by rate-limiting.  If rate-limiting
with informational and error types are the same, we have an inflexible
situation here.

>     Then kernel must be shipped out without rate-limiting enabled by
>     default, that's problem.
>
> I guess I missed something.  That doesn't seem like a problem to
> me... and if you need to ship with a rate by default, then ship with a
> very-high rate.  I've never managed to respond to more than 60,000
> ICMP packets/second, so I suggest 60,001.

Yes you did.  60,000 responses/sec is effectively no protection at all,
and most people would appeaciate protection for the error messages, which
are crucial to the working of TCP/IP; not so with informational ICMP
messages.

And by the way, rate-limiting ICMP error messages is a MUST item for IPv6.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

Re: missing icmp errors for udp packets

[Chris Wedgwood]

On Tue, Jul 31, 2001 at 10:59:39PM +0300, Pekka Savola wrote:

    bad ping responder == bad PR ;-)

    And anyway, who is anyone to judge what the system should be used
    for?

    I want a system to respond to ping without limitations; it's good
    for debugging, diagnostics, etc.  If I want, I can just filter the
    requests out, or rate-limit the responses.

People who want to do strange stuff can tweak via sysctl.

    However, ICMP error messages cannot be effectively filtered; they
    may happen due to TTL=0 when forwarding, legit or illegit UDP
    connection etc.; only way to effectively limit them is by
    rate-limiting.  If rate-limiting with informational and error
    types are the same, we have an inflexible situation here.

Networks are lossy, you can spill the odd packet anyhow.

It was just a suggestion that we merge all ICMP rate-limiting for
simplicity, I don't see it being an issue for the majority of users.

Perhaps I am wrong, in which case DaveM and Alexey will ignore me :)

I really don't see the need to continue to discuss this further on the
list, but by all means flame me in private!





  --cw

Re: missing icmp errors for udp packets

[Pekka Savola]

On Wed, 1 Aug 2001, Chris Wedgwood wrote:
> I really don't see the need to continue to discuss this further on the
> list, but by all means flame me in private!

I can perform the flaming if you bring the bananas. :-)

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

Re: missing icmp errors for udp packets

[Pekka Savola]

On Mon, 30 Jul 2001, Pekka Savola wrote:

> On Sun, 29 Jul 2001 kuznet@ms2.inr.ac.ru wrote:
>
> > Hello!
> >
> > > So in conclusion:
> > >
> > > with net.ipv4.icmp_echoreply_rate=0:
> >
> > Congratulations! That's why I do not see this, forgot to ping before. :-)
> >
> > The patch is enclosed.
>
> Alexey, there is a tiny problem with your patch.
>
> If you reboot the computer, the _first_ ping/scan attempt will not return
> icmp dest unreachable.  All of the rest do.  If the network was quiet
> enough, I guess there might be some circumstances where this could be
> applicable again..

As this happening is rather rare, would there be resistance for adding
this as an intermediate fix, to be replaced later with a bigger overhaul
if that is to be decided?

For 99.9% of cases, this works rather well and the 0.1% is the same as
before (== acceptable).  Returning ICMP unreachables after being pinged is
IMO rather important.


> > --- ../dust/vger3-010728/linux/net/ipv4/icmp.c	Thu Jun 14 22:49:44 2001
> > +++ linux/net/ipv4/icmp.c	Sun Jul 29 19:52:55 2001
> > @@ -240,12 +240,15 @@
> >  int xrlim_allow(struct dst_entry *dst, int timeout)
> >  {
> >  	unsigned long now;
> > +	static int burst;
> >
> >  	now = jiffies;
> >  	dst->rate_tokens += now - dst->rate_last;
> >  	dst->rate_last = now;
> > -	if (dst->rate_tokens > XRLIM_BURST_FACTOR*timeout)
> > -		dst->rate_tokens = XRLIM_BURST_FACTOR*timeout;
> > +	if (burst < XRLIM_BURST_FACTOR*timeout)
> > +		burst = XRLIM_BURST_FACTOR*timeout;
> > +	if (dst->rate_tokens > burst)
> > +		dst->rate_tokens = burst;
> >  	if (dst->rate_tokens >= timeout) {
> >  		dst->rate_tokens -= timeout;
> >  		return 1;
> >
>
>

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

Re: missing icmp errors for udp packets

[David S. Miller]

Pekka Savola writes:
 > As this happening is rather rare, would there be resistance for adding
 > this as an intermediate fix, to be replaced later with a bigger overhaul
 > if that is to be decided?
 > 
 > For 99.9% of cases, this works rather well and the 0.1% is the same as
 > before (== acceptable).  Returning ICMP unreachables after being pinged is
 > IMO rather important.

Please people, just make some decision and send me the final
patch :-)

Later,
David S. Miller
davem@redhat.com

Re: missing icmp errors for udp packets

[clemens]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Tue, Jul 31, 2001 at 10:57:34PM +0400, kuznet@ms2.inr.ac.ru wrote:
> > consequently since there is only one token bucket, there can only be one
> > icmp rate limit. we can add a icmp type mask to enable/disable rate limiting 
> > for certain types.
> Yes. Logically this is 100% right. Also, see below.
> 

please give this draft-like patch a try.
here at my box it does correct limiting and omits limiting for unfiltered
types like echo-reply.

clemens

[-- Attachment #2: icmp-global-rate.patch --]
[-- Type: text/plain, Size: 8380 bytes --]

diff -u linux-sane/net/ipv4/icmp.c linux/net/ipv4/icmp.c
--- linux-sane/net/ipv4/icmp.c	Thu Jun 21 06:00:55 2001
+++ linux/net/ipv4/icmp.c	Tue Jul 31 22:01:13 2001
@@ -16,6 +16,9 @@
  *	Other than that this module is a complete rewrite.
  *
  *	Fixes:
+ *	Clemens Fruhwirth	:	introduce global icmp rate limiting
+ *					with filter mask ability instead
+ *					of unclean mixed icmp timeouts.
  *		Mike Shaver	:	RFC1122 checks.
  *		Alan Cox	:	Multicast ping reply as self.
  *		Alan Cox	:	Fix atomicity lockup in ip_build_xmit 
@@ -145,6 +148,20 @@
 /* Control parameter - ignore bogus broadcast responses? */
 int sysctl_icmp_ignore_bogus_error_responses;
 
+/* 
+ * 	Configurable rate limits.
+ *	Someone should check if these default values are correct.
+ *	Note that these values interact with the routing cache GC timeout.
+ *	If you chose them too high they won't take effect, because the
+ *	dst_entry gets expired too early. The same should happen when
+ *	the cache grows too big.
+ */
+//int sysctl_icmp_destunreach_time = 1*HZ;
+//int sysctl_icmp_timeexceed_time = 1*HZ;
+//int sysctl_icmp_paramprob_time = 1*HZ;
+//int sysctl_icmp_echoreply_time; /* don't limit it per default. */
+int sysctl_icmp_ratelimit = 1*HZ;
+
 /*
  *	ICMP control array. This specifies what to do with each ICMP.
  */
@@ -155,7 +172,7 @@
 	unsigned long *input;		/* Address to increment on input */
 	void (*handler)(struct sk_buff *skb);
 	short	error;		/* This ICMP is classed as an error message */
-	int *timeout; /* Rate limit */
+//	int *timeout; /* Rate limit */
 };
 
 static struct icmp_control icmp_pointers[NR_ICMP_TYPES+1];
@@ -257,7 +270,7 @@
 {
 	struct dst_entry *dst = &rt->u.dst; 
 
-	if (type > NR_ICMP_TYPES || !icmp_pointers[type].timeout)
+	if (type > NR_ICMP_TYPES)
 		return 1;
 
 	/* Don't limit PMTU discovery. */
@@ -272,7 +285,15 @@
 	if (dst->dev && (dst->dev->flags&IFF_LOOPBACK))
  		return 1;
 
-	return xrlim_allow(dst, *(icmp_pointers[type].timeout));
+#define sysctl_icmp_filtermask 0x1818
+
+// filters destunreach (0x03), source quench (0x04)
+// time exceed (0x11), paraprob (0x12)
+
+	if((1 << type) & sysctl_icmp_filtermask)
+	 return xrlim_allow(dst,sysctl_icmp_ratelimit);
+	else
+	 return 1;
 }
 
 /*
@@ -929,18 +950,7 @@
 }
 
 
-/* 
- * 	Configurable rate limits.
- *	Someone should check if these default values are correct.
- *	Note that these values interact with the routing cache GC timeout.
- *	If you chose them too high they won't take effect, because the
- *	dst_entry gets expired too early. The same should happen when
- *	the cache grows too big.
- */
-int sysctl_icmp_destunreach_time = 1*HZ;
-int sysctl_icmp_timeexceed_time = 1*HZ;
-int sysctl_icmp_paramprob_time = 1*HZ;
-int sysctl_icmp_echoreply_time; /* don't limit it per default. */
+
 
 /*
  *	This table is the definition of how we handle ICMP.
@@ -948,37 +958,37 @@
  
 static struct icmp_control icmp_pointers[NR_ICMP_TYPES+1] = {
 /* ECHO REPLY (0) */
- { &icmp_statistics[0].IcmpOutEchoReps, &icmp_statistics[0].IcmpInEchoReps, icmp_discard, 0, &sysctl_icmp_echoreply_time},
- { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1, },
- { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1, },
+ { &icmp_statistics[0].IcmpOutEchoReps, &icmp_statistics[0].IcmpInEchoReps, icmp_discard, 0 },
+ { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1 },
+ { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1 },
 /* DEST UNREACH (3) */
- { &icmp_statistics[0].IcmpOutDestUnreachs, &icmp_statistics[0].IcmpInDestUnreachs, icmp_unreach, 1, &sysctl_icmp_destunreach_time },
+ { &icmp_statistics[0].IcmpOutDestUnreachs, &icmp_statistics[0].IcmpInDestUnreachs, icmp_unreach, 1 },
 /* SOURCE QUENCH (4) */
- { &icmp_statistics[0].IcmpOutSrcQuenchs, &icmp_statistics[0].IcmpInSrcQuenchs, icmp_unreach, 1, },
+ { &icmp_statistics[0].IcmpOutSrcQuenchs, &icmp_statistics[0].IcmpInSrcQuenchs, icmp_unreach, 1 },
 /* REDIRECT (5) */
- { &icmp_statistics[0].IcmpOutRedirects, &icmp_statistics[0].IcmpInRedirects, icmp_redirect, 1, },
- { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1, },
- { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1, },
+ { &icmp_statistics[0].IcmpOutRedirects, &icmp_statistics[0].IcmpInRedirects, icmp_redirect, 1 },
+ { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1 },
+ { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1 },
 /* ECHO (8) */
- { &icmp_statistics[0].IcmpOutEchos, &icmp_statistics[0].IcmpInEchos, icmp_echo, 0, },
- { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1, },
- { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1, },
+ { &icmp_statistics[0].IcmpOutEchos, &icmp_statistics[0].IcmpInEchos, icmp_echo, 0 },
+ { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1 },
+ { &icmp_statistics[0].dummy, &icmp_statistics[0].IcmpInErrors, icmp_discard, 1 },
 /* TIME EXCEEDED (11) */
- { &icmp_statistics[0].IcmpOutTimeExcds, &icmp_statistics[0].IcmpInTimeExcds, icmp_unreach, 1, &sysctl_icmp_timeexceed_time },
+ { &icmp_statistics[0].IcmpOutTimeExcds, &icmp_statistics[0].IcmpInTimeExcds, icmp_unreach, 1 },
 /* PARAMETER PROBLEM (12) */
- { &icmp_statistics[0].IcmpOutParmProbs, &icmp_statistics[0].IcmpInParmProbs, icmp_unreach, 1, &sysctl_icmp_paramprob_time },
+ { &icmp_statistics[0].IcmpOutParmProbs, &icmp_statistics[0].IcmpInParmProbs, icmp_unreach, 1 },
 /* TIMESTAMP (13) */
- { &icmp_statistics[0].IcmpOutTimestamps, &icmp_statistics[0].IcmpInTimestamps, icmp_timestamp, 0,  },
+ { &icmp_statistics[0].IcmpOutTimestamps, &icmp_statistics[0].IcmpInTimestamps, icmp_timestamp, 0 },
 /* TIMESTAMP REPLY (14) */
- { &icmp_statistics[0].IcmpOutTimestampReps, &icmp_statistics[0].IcmpInTimestampReps, icmp_discard, 0, },
+ { &icmp_statistics[0].IcmpOutTimestampReps, &icmp_statistics[0].IcmpInTimestampReps, icmp_discard, 0 },
 /* INFO (15) */
- { &icmp_statistics[0].dummy, &icmp_statistics[0].dummy, icmp_discard, 0, },
+ { &icmp_statistics[0].dummy, &icmp_statistics[0].dummy, icmp_discard, 0 },
 /* INFO REPLY (16) */
- { &icmp_statistics[0].dummy, &icmp_statistics[0].dummy, icmp_discard, 0, },
+ { &icmp_statistics[0].dummy, &icmp_statistics[0].dummy, icmp_discard, 0 },
 /* ADDR MASK (17) */
- { &icmp_statistics[0].IcmpOutAddrMasks, &icmp_statistics[0].IcmpInAddrMasks, icmp_address, 0,  },
+ { &icmp_statistics[0].IcmpOutAddrMasks, &icmp_statistics[0].IcmpInAddrMasks, icmp_address, 0 },
 /* ADDR MASK REPLY (18) */
- { &icmp_statistics[0].IcmpOutAddrMaskReps, &icmp_statistics[0].IcmpInAddrMaskReps, icmp_address_reply, 0, }
+ { &icmp_statistics[0].IcmpOutAddrMaskReps, &icmp_statistics[0].IcmpInAddrMaskReps, icmp_address_reply, 0 }
 };
 
 void __init icmp_init(struct net_proto_family *ops)
Common subdirectories: linux-sane/net/ipv4/netfilter and linux/net/ipv4/netfilter
diff -u linux-sane/net/ipv4/sysctl_net_ipv4.c linux/net/ipv4/sysctl_net_ipv4.c
--- linux-sane/net/ipv4/sysctl_net_ipv4.c	Mon Mar 26 04:14:25 2001
+++ linux/net/ipv4/sysctl_net_ipv4.c	Tue Jul 31 21:44:56 2001
@@ -32,10 +32,14 @@
 extern int sysctl_ip_dynaddr;
 
 /* From icmp.c */
+/*
 extern int sysctl_icmp_destunreach_time;
 extern int sysctl_icmp_timeexceed_time;
 extern int sysctl_icmp_paramprob_time;
 extern int sysctl_icmp_echoreply_time;
+*/
+extern int sysctl_icmp_ratelimit;
+extern int sysctl_icmp_filtermask;
 
 /* From igmp.c */
 extern int sysctl_igmp_max_memberships;
@@ -178,6 +182,7 @@
 	{NET_IPV4_ICMP_IGNORE_BOGUS_ERROR_RESPONSES, "icmp_ignore_bogus_error_responses",
 	 &sysctl_icmp_ignore_bogus_error_responses, sizeof(int), 0644, NULL,
 	 &proc_dointvec},
+/*
 	{NET_IPV4_ICMP_DESTUNREACH_RATE, "icmp_destunreach_rate",
 	 &sysctl_icmp_destunreach_time, sizeof(int), 0644, NULL, &proc_dointvec},
 	{NET_IPV4_ICMP_TIMEEXCEED_RATE, "icmp_timeexceed_rate",
@@ -187,6 +192,7 @@
 	{NET_IPV4_ICMP_ECHOREPLY_RATE, "icmp_echoreply_rate",
 	 &sysctl_icmp_echoreply_time, sizeof(int), 0644, NULL, &proc_dointvec},
 	{NET_IPV4_ROUTE, "route", NULL, 0, 0555, ipv4_route_table},
+*/
 #ifdef CONFIG_IP_MULTICAST
 	{NET_IPV4_IGMP_MAX_MEMBERSHIPS, "igmp_max_memberships",
 	 &sysctl_igmp_max_memberships, sizeof(int), 0644, NULL, &proc_dointvec},