Comment 8 for bug 67868

Package: watchdog
Version: 5.2.4-4
Followup-For: Bug #32547

I can reproduce this bug 100% of the time, although it can take a while
before it happens. In my last 5 runs I had 318, 322, 320, 46, and 38
successful pings before it finally croaked. I put abort()'s in the
check_net function to get a core when it finally fails. The core shows
that it is the return at net.c:141 that is causing the problem. I also
have a full strace, but the only thing that I can determine is that the
sendto/recvfrom near net.c:71 is happening twice for every 'got answer
from target' message. Eventually all three loops fail and check_net
returns ENETUNREACH.

This is on a fairly lightly loaded server. The IP address in question
is for my internal network and is up for the entire duration of the
test.

There is something funky going on in check_net. If you run it under a
debugger and step through the code, you will find that the for loop
runs twice, the first time through the loop, the value of the received
packet's type is still 8 (i.e. ICMP_ECHO) at net.c:127. The second
time through the value is correct (ICMP_ECHOREPLY) and the loop
terminates by returning ENOERR. The comments to the ping program
indicate this is normal behavior:

--- begin ping comments ---
 * parse_reply --
 * Print out the packet, if it came from us. This logic is necessary
 * because ALL readers of the ICMP socket get a copy of ALL ICMP packets
 * which arrive ('tis only fair). This permits multiple copies of this
 * program to be run without having intermingled output (or statistics!).
--- end ping comments

Maybe it fails all three times through the loop when another ping
program is running. Yes! I set up a 'ping -f 192.168.1.1' and the
watchdog bailed with only 2 successful pings! So check_net needs to
get reworked to keep doing recvfrom's until there are not any more,
checking each one to see if the watchdog set it.

I'll see if I can whip up a patch in the next couple weeks. Or I'll
check back and see if some beats me to it. :)

Omen Wild

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12-1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages watchdog depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii makedev 2.3.1-78 creates device files in /dev

-- no debconf information

--
I found out why my car was humming. It had forgotten the words.