[Sorry for the late answer; I'm still travelling] I think just turning the ratelimit sysctls into boolean that turn on/off if the ICMP is checked against a single ratelimit per dst_entry would be fin
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 bu
Or to remove limiting distinguishing types, which is ideal logically. Why do we do this anyhow? --cw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message
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
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 p
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, e
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 work
hi folks! assertation: 2.4.7 omits icmp port unreachable errors for unbound udp ports on non-local interfaces. sounds strange? here are my observations: linux host guardian linux host ghanima [sessio
ghanima:~$ cat /proc/sys/net/ipv4/icmp_destunreach_rate 100 i want to thank you, for being the first one recognizing this bug report at all, but please do read my description a little bit more carefu
I did a little bit of investigation, and I think the reason for this can seen. Not from the dump though: [problem; generated by nmap but no response sent]: 07:34:52.126018 193.94.160.1.5000 > 193.166
probably there is a bug in the icmp reply throttling code? without pinging first, there are icmp replies. with pinging first, there are no icmp replies. with pinging and heavy udp scanning, there are
Loopback is not subject to these restrictions, net/ipv4/icmp.c:icmpv4_xrlim_allow : /* No rate limit on loopback */ if (dst->dev && (dst->dev->flags&IFF_LOOPBACK)) return 1; -- Pekka Savola "Tell me
Alas, I do not believe to any results, obtained with kdb. I believe to plain logic more. :-) Particularly, I do not believe to this at all. 99% - the problem is with rate limiting. Loopback is speci
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
don't be polemic. wrong, i've found 3 lo/!lo conditionals at the first look. anyway, it is the rate limiting. i disabled icmpv4_xrlim_allow, and now every udp packets get it's proper icmp error. now,
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,
Ratelimit checks are simply skipped for it, they apply only to icmps, which are going to be sent to network. Source of the problem was that icmp holds single variable for rate, but still pretends to