(CCed to "ethereal-dev@xxxxxxxx", so the *rest* of the developers see
this as well.)
> I will save and forward on any debug output files generated by Windows 2000
> when Ethereal crashes from now on. I think it has to do with the memory,
> because I often get Virtual Memory Low warnings from Windows when I am
> working with Ethereal. Also, the machine slows to a crawl whenever I have
> Ethereal open.
If you read a Really Large Capture with a Really Large Number Of
Packets, Ethereal currently consumes a Really Large Amount Of Memory.
It could be that it's chewing up *all* your swap^H^H^H^Hpagefile space,
causing subsequent attempts to allocate memory simply to fail (as
there's neither physical memory nor pagefile space to give); Ethereal
uses GLib's memory allocator, which simply aborts if it runs out of
memory.
I have a project in progress to substantially reduce the amount of
memory it uses; however, it involves replacing the widget used to
display the list of packets, and there's currently some Ethereal display
functionality that Doesn't Work Quite Right yet with the modified
widget.
> When I open a Token Ring trace of SNA communications that uses LLC commands
> and responses to set up and maintain connections, the detailed portion of
> the decode window lists LLC as the highest protocol available in the packet,
> unless the packet contains actual SNA data. If the packet contains actual
> SNA data, that means the LLC connection has been established, so no XID,
> Test, or SABM commands will be present in the packet. Also, if it is
> carrying data, then an idle RR will not be necessary to maintain the
> connection. Ethereal displays the decode of an LLC packet with an idle RR
> like this:
>
> LLC DSAP SNA Path Control Individual, SSAP SNA Path Control Command
>
> The protocol column lists the packet as an LLC packet and the info column
> shows whether it is a command or a response, but it doesn't show the type of
> command or response like this:
>
> LLC DSAP SNA Path Control Individual, SSAP SNA Path Control Command RR
> or
> LLC DSAP SNA Path Control Individual, SSAP SNA Path Control Command XID
>
> This may seem trivial, but when I am troubleshooting a problem on a Token
> Ring network that uses LLC connections to transfer SNA data, the LLC
> commands, their origin, and whether they generate a response are extremely
> useful in determining the nature of the problem. The faster I can obtain
> the info the faster I can fix the problem. With the LLC command type
> displayed in the Info column, I can get the info faster than decoding the
> trace and navigating down to the LLC portion of the detailed decode and
> locating the LLC command type, especially if I am using the "Update Packets
> in Real Time" option of the capture menu.
OK, so it appears that, indeed, you're seeing frames without any payload
above LLC - sort of like TCP ACK-only packets.
If I get time, I'll look at improving the Info field for those packets
(but I already have a large list of things at which I'm looking, so if
*another* developer wants to look at that, they should go ahead and not
wait for me...).
