final words on udp/ICMP dest unreach issue [+PATCH]

• Next message: Mark Hemment: "[PATCH] select_parent"
• Previous message: Carlos O'Donell Jr.: "Re: What does "Neighbour table overflow" message indicate?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

hi!

concerning the bug discussed in the "missing icmp errors for udp
packets"-thread on netdev a solution has been found.

here comes the bug (see net/ipv4/icmp.c):

#define XRLIM_BURST_FACTOR 6
int xrlim_allow(struct dst_entry *dst, int timeout)
{
         unsigned long now;

          now = jiffies;
          dst->rate_tokens += now - dst->rate_last;
          dst->rate_last = now;
#1: if (dst->rate_tokens > XRLIM_BURST_FACTOR*timeout)
#2: dst->rate_tokens = XRLIM_BURST_FACTOR*timeout;
#3: if (dst->rate_tokens >= timeout) {
                   dst->rate_tokens -= timeout;
                return 1;
        }
         return 0;
}

for timeout=0 rate_tokens will be reset to 0 tokens (#2), since #1 always
holds.
(icmp ping does have timeout=0, for instance)
this doesn't cause the packet to be filtered, since in #2
holds, but will cause the following packet to be filtered, if sent
before (now - dst->rate_last) < timeout.
(note: timeout is not 0 in this inequation, since it's the
timeout of the icmp type of the following packet)

a patch is attached.

thanks to all contributors, especially pekka savola, for discovering
that pinging before udp scanning will cause the troubles, and alexey
for suppling an alternative patch (for those intrested:
http://therapy.endorphin.org/alexey.patch)

alan, please take care of that.

greets, clemens

• text/plain attachment: icmp-xrlim_allow.patch

• Next message: Mark Hemment: "[PATCH] select_parent"
• Previous message: Carlos O'Donell Jr.: "Re: What does "Neighbour table overflow" message indicate?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:43 EST