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;
On Sun, 29 Jul 2001 [email protected] 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
Hello!
> If you reboot the computer, the _first_ ping/scan attempt will not return
> icmp dest unreachable.
Hmm... how fast after reboot?
Alexey
On Tue, 31 Jul 2001 [email protected] 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
On Tue, Jul 31, 2001 at 10:33:56PM +0400, [email protected] 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
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
On Tue, Jul 31, 2001 at 11:04:06PM +0400, [email protected] wrote:
Or to remove limiting distinguishing types, which is ideal
logically.
Why do we do this anyhow?
--cw
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
On Tue, Jul 31, 2001 at 11:25:50PM +0400, [email protected] 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
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
On Tue, Jul 31, 2001 at 11:37:06PM +0400, [email protected] 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
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
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
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