ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-users: Re: [Ethereal-users] large capture file hangs machine

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Wed, 18 Jul 2001 12:15:43 -0700 (PDT)
> I have a simple question.  One of my clients needed me to do a weekend
> capture at their site.  The capture is quite large, about 84.1 meg.  When I
> load it into ethereal either on my linux box or my win2k box it hangs it

That probably means that the capture includes IP addresses that, when
your machine tries to resolve them, cause your machine's
IP-address-resolution code to take a long time to do so (or causes them
to try to talk to an unresponsive DNS server, so that it takes a long
time to time out - or perhaps the attempts fail, with "no such host",
quickly, and Windows' host name resolver tries NBNS after that; NBNS
IP-address-to-hostname resolutions involve, as I remember, sending an
NBNS "Node Status Request" packet to the IP address and waiting for an
NBNS "Node Status Reply" containing NBNS names, and if that host doesn't
respond, that could take a while).

I think the Windows version of the code in Ethereal doesn't do its own
"fast timeout" to give up on those resolution attempts after a few
seconds (the mechanism used in UNIX depends on the UNIX signaling
mechanism, so it'd have to be redone for Windows), so attempts to look
up host names that aren't in DNS could take a while.

As the capture was at the client's site, I could easily imagine that
there are IP addresses in the capture that aren't in a DNS server
accessible to the outside world.

You will also get delays on Linux, but, as Linux

	1) is UNIX-compatible, and therefore can use the "fast timeout"
	   in Ethereal's lookup code;

	2) doesn't do NBNS resolution, normally (I guess somebody could
	   write an NBNS-resolution mechanism and plug it into the name
	   service switch, but I don't think anybody's done that);

the delays won't be as bad.

As such, the first thing I'd try would be to turn off IP-address-to-name
resolution when loading the capture; either run Ethereal with the "-n"
flag, or, if you're opening the file with the "File->Open" menu item
rather than specifying it on the command line, disable network name
resolution by un-selecting the "Enable network name resolution" checkbox
in Ethereal 0.8.19, or the "Enable name resolution" checkbox in older
versions.

> or makes it really slow.  I increased the virtual memory on both boxes
> (yes i know it is called something different on the linux box),

I assume that means "increased the amount of swap space available"; if
so, running out of swap space probably means that attempts to allocate
memory will fail, which won't cause Ethereal to hang, it'll cause
Ethereal to abort.  That's probably not your problem.