On Wed, 21 Jul 2004, Guy Harris wrote:
> Are you doing an "update list of packets in real time" capture?
>
> If so, is network-layer name resolution turned on, or off?
>
> If it's turned on, try turning it off - Ethereal might be blocking trying
> to convert an IP address in one of the packets to a host name, if it's
> trying to talk to a DNS server that's not responding (from the "futex" and
> "eth0" references I assume you're using Linux, so this probably isn't a
> NetBIOS name resolution problem). It will *eventually* unblock, but that
> could take a while.
Sorry - I'm afraid, my original report was "suboptimal" ;-)
(as is probably true for most people, I usually only use ethereal when
trying to solve some other serious problem) Here some things I left out:
All this is happening on a Linux system (based on Suse 9.1) running under
Kernel 2.6.8-rc1 (same is happening with other 2.6.x Kernels; I think, the
first time I saw it was still with 2.4.x, but I'm not sure about this) with
glibc-2.3.3.
You are right, it indeed is a problem with DNS lookups. According to
the backtrace, it simply gets stuck in a call to "gethostbyaddr"
(host_name_lookup at resolv.c:382 in 0.10.5). In this case, it might
not even be a problem with ethereal, but more likely a change in the C
library.
Shouldn't the gethostbyaddr function return an errror if there was no
answer within a certain time interval (I thought, it was that way, but
the manpage dosn't mention any timeout)? I have seen programs
seemingly hang for 30 seconds trying to resove an address, but in the
case of ethereal, after an hour it is still blocked, so chances are it
would stay this way unil the next power failure...
My immediate problem could be solved by rebuilding ethereal with GNU
adns. I still would be curious if somebody could enlighten me :-)
Regards,
Peter Daum