missing icmp errors for udp packets

missing icmp errors for udp packets

Post by kuz.. » Thu, 02 Aug 2001 03:50:04



Hello!

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

Hmm... how fast after reboot?

Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

missing icmp errors for udp packets

Post by Pekka Savol » Thu, 02 Aug 2001 04:00:06



Quote:> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

missing icmp errors for udp packets

Post by kuz.. » Thu, 02 Aug 2001 04:10:10


Hello!

Quote:> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

missing icmp errors for udp packets

Post by kuz.. » Thu, 02 Aug 2001 04:30:14


Hello!

Quote:> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

missing icmp errors for udp packets

Post by kuz.. » Thu, 02 Aug 2001 04:40:07


Hello!

Quote:> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

missing icmp errors for udp packets

Post by Pekka Savol » Thu, 02 Aug 2001 05:10:07



>    --- 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.

Quote:>     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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. How to receive UDP and ICMP packet using one UDP socket, (Path MTUD)

Dear All,

Can we configure one socket to receive two different protocols packet.
Like how can we made a UDP socket to receive udp as well as icmp
messages.

Actually I am implementing Path MTUD, so for that I sent some udp
probs to destination host, now I want that the same socket at client
side must be able to receive both udp response and icmp error
messages(like host unreachable, port unreachable etc).

Another approach is that, we will use two sockets for both source and
destination, form source we will send udp probs(through udp socket)
while at destination host, after receiving that prob(through udp
socket), application will make an icmp packet and sent it back to the
source host (using ICMP socket). And here at source host, that message
and other icmp error messages will be received by icmp socket.

But this approch dosen't look efficient to me, what u people say? If
Any one has another approch plz let me know.

Eagerly waiting for some +ve pings.

2. ignore just a test

3. Kernel does not detect UDP/ICMP packets

4. Unixware 7.0 installation on dual hd sys. with primary Windows

5. Problem with capturing the icmp and udp packets

6. dual nics

7. no ICMP port unreachable for UDP packets

8. cout generates LARGE executables on Linux

9. UDP packet receive errors--wazup?

10. DHCP - UDP packet error between Win95 & Linux - need help!

11. "Got UDP packet for no socket!" error

12. make icmp.c be more verbose on broadcast icmp errors

13. ipchains - blocking outgoing ICMP/UDP