* Re: missing icmp errors for udp packets
[not found] <Pine.LNX.4.33.0107290739370.2081-100000@netcore.fi>
@ 2001-07-29 15:59 ` kuznet
2001-07-30 13:03 ` Pekka Savola
0 siblings, 1 reply; 17+ messages in thread
From: kuznet @ 2001-07-29 15:59 UTC (permalink / raw)
To: Pekka Savola; +Cc: therapy, netdev, linux-kernel, Dave Miller
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;
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-29 15:59 ` missing icmp errors for udp packets kuznet
@ 2001-07-30 13:03 ` Pekka Savola
2001-07-31 18:33 ` kuznet
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Pekka Savola @ 2001-07-30 13:03 UTC (permalink / raw)
To: kuznet; +Cc: therapy, netdev, linux-kernel, Dave Miller
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-30 13:03 ` Pekka Savola
@ 2001-07-31 18:33 ` kuznet
2001-07-31 18:47 ` Pekka Savola
2001-07-31 18:51 ` clemens
2001-08-02 19:31 ` Pekka Savola
2001-08-03 8:58 ` David S. Miller
2 siblings, 2 replies; 17+ messages in thread
From: kuznet @ 2001-07-31 18:33 UTC (permalink / raw)
To: Pekka Savola; +Cc: therapy, netdev, linux-kernel, davem
Hello!
> If you reboot the computer, the _first_ ping/scan attempt will not return
> icmp dest unreachable.
Hmm... how fast after reboot?
Alexey
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 18:33 ` kuznet
@ 2001-07-31 18:47 ` Pekka Savola
2001-07-31 18:51 ` clemens
1 sibling, 0 replies; 17+ messages in thread
From: Pekka Savola @ 2001-07-31 18:47 UTC (permalink / raw)
To: kuznet; +Cc: therapy, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 18:33 ` kuznet
2001-07-31 18:47 ` Pekka Savola
@ 2001-07-31 18:51 ` clemens
2001-07-31 19:04 ` kuznet
1 sibling, 1 reply; 17+ messages in thread
From: clemens @ 2001-07-31 18:51 UTC (permalink / raw)
To: kuznet; +Cc: Pekka Savola, therapy, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 18:51 ` clemens
@ 2001-07-31 19:04 ` kuznet
2001-07-31 19:23 ` Chris Wedgwood
0 siblings, 1 reply; 17+ messages in thread
From: kuznet @ 2001-07-31 19:04 UTC (permalink / raw)
To: clemens; +Cc: pekkas, therapy, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 19:04 ` kuznet
@ 2001-07-31 19:23 ` Chris Wedgwood
2001-07-31 19:25 ` kuznet
0 siblings, 1 reply; 17+ messages in thread
From: Chris Wedgwood @ 2001-07-31 19:23 UTC (permalink / raw)
To: kuznet; +Cc: clemens, pekkas, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 19:23 ` Chris Wedgwood
@ 2001-07-31 19:25 ` kuznet
2001-07-31 19:34 ` Chris Wedgwood
0 siblings, 1 reply; 17+ messages in thread
From: kuznet @ 2001-07-31 19:25 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: therapy, pekkas, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 19:25 ` kuznet
@ 2001-07-31 19:34 ` Chris Wedgwood
2001-07-31 19:37 ` kuznet
0 siblings, 1 reply; 17+ messages in thread
From: Chris Wedgwood @ 2001-07-31 19:34 UTC (permalink / raw)
To: kuznet; +Cc: therapy, pekkas, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 19:34 ` Chris Wedgwood
@ 2001-07-31 19:37 ` kuznet
2001-07-31 19:41 ` Chris Wedgwood
0 siblings, 1 reply; 17+ messages in thread
From: kuznet @ 2001-07-31 19:37 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: therapy, pekkas, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 19:37 ` kuznet
@ 2001-07-31 19:41 ` Chris Wedgwood
2001-07-31 19:59 ` Pekka Savola
0 siblings, 1 reply; 17+ messages in thread
From: Chris Wedgwood @ 2001-07-31 19:41 UTC (permalink / raw)
To: kuznet; +Cc: therapy, pekkas, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 19:41 ` Chris Wedgwood
@ 2001-07-31 19:59 ` Pekka Savola
2001-07-31 20:53 ` Chris Wedgwood
0 siblings, 1 reply; 17+ messages in thread
From: Pekka Savola @ 2001-07-31 19:59 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: kuznet, therapy, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 19:59 ` Pekka Savola
@ 2001-07-31 20:53 ` Chris Wedgwood
2001-07-31 20:57 ` Pekka Savola
0 siblings, 1 reply; 17+ messages in thread
From: Chris Wedgwood @ 2001-07-31 20:53 UTC (permalink / raw)
To: Pekka Savola; +Cc: kuznet, therapy, netdev, linux-kernel, davem
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-31 20:53 ` Chris Wedgwood
@ 2001-07-31 20:57 ` Pekka Savola
0 siblings, 0 replies; 17+ messages in thread
From: Pekka Savola @ 2001-07-31 20:57 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: netdev, linux-kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-30 13:03 ` Pekka Savola
2001-07-31 18:33 ` kuznet
@ 2001-08-02 19:31 ` Pekka Savola
2001-08-03 8:58 ` David S. Miller
2 siblings, 0 replies; 17+ messages in thread
From: Pekka Savola @ 2001-08-02 19:31 UTC (permalink / raw)
To: kuznet; +Cc: netdev, linux-kernel, Dave Miller
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
2001-07-30 13:03 ` Pekka Savola
2001-07-31 18:33 ` kuznet
2001-08-02 19:31 ` Pekka Savola
@ 2001-08-03 8:58 ` David S. Miller
2 siblings, 0 replies; 17+ messages in thread
From: David S. Miller @ 2001-08-03 8:58 UTC (permalink / raw)
To: Pekka Savola; +Cc: kuznet, netdev, linux-kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: missing icmp errors for udp packets
[not found] <200107311857.WAA10162@ms2.inr.ac.ru>
@ 2001-07-31 20:16 ` clemens
0 siblings, 0 replies; 17+ messages in thread
From: clemens @ 2001-07-31 20:16 UTC (permalink / raw)
To: kuznet; +Cc: pekkas, cw, netdev, linux-kernel
[-- 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},
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2001-08-03 8:59 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.33.0107290739370.2081-100000@netcore.fi>
2001-07-29 15:59 ` missing icmp errors for udp packets kuznet
2001-07-30 13:03 ` Pekka Savola
2001-07-31 18:33 ` kuznet
2001-07-31 18:47 ` Pekka Savola
2001-07-31 18:51 ` clemens
2001-07-31 19:04 ` kuznet
2001-07-31 19:23 ` Chris Wedgwood
2001-07-31 19:25 ` kuznet
2001-07-31 19:34 ` Chris Wedgwood
2001-07-31 19:37 ` kuznet
2001-07-31 19:41 ` Chris Wedgwood
2001-07-31 19:59 ` Pekka Savola
2001-07-31 20:53 ` Chris Wedgwood
2001-07-31 20:57 ` Pekka Savola
2001-08-02 19:31 ` Pekka Savola
2001-08-03 8:58 ` David S. Miller
[not found] <200107311857.WAA10162@ms2.inr.ac.ru>
2001-07-31 20:16 ` clemens
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).