Ethereal-dev: Re: [Ethereal-dev] Ethereal Design Considerations.
On Thu, Apr 17, 2003 at 12:42:40AM +0100, Ole Henry Halvorsen wrote:
> Hi.
>
> theese questions could probably be answered by looking at the source code,
> which I already did, however as ethereal is a big and complex program, it's
> hard for someone outside to gain an overall view of it's design. So I
> figured my questions would be best answered by someone who works on it.
>
> 1. how does ethereal store packets internally
In a file.
> and in what form?
In the same file format tcpdump uses; the file has a header giving
information such as the link-layer type of the packets in the file,
followed by a sequence of packets in the form of a header giving a
packet arrival timestamp and packet lengths (length on the network, and
length in the file, which could be smaller than the length on the
network if a shorter "snapshot length" was specified when capturing).
It can also read other capture file formats.
> 2. Are packets dissected at capture time, or are they dissected when the
> user "views" the packet?
They're not dissected by the capture code, other than a very simplistic
dissection in order to figure out which of the counters in the capture
window to increment.
When a capture is read in (which is done when you stop the capture, if
you didn't use the "Update list of packets in real time" option, or done
as packets are written by the capture code to the capture file, if you
did use that option), the packets are dissected in order to:
1) construct the data for the columns in the topmost display
pane;
2) construct any state needed to dissect subsequent packets (not
all protocols supply enough information with a packet to
enable a network analyzer to fully dissect it - sometimes you
need to know what packets were sent before it).
If you click on a packet, the dissection is redone, so that it can
display the "protocol tree" that's shown in the middle pane.
> 3. which approaches does ethereal use to determine/detect application layer
> protocols?
What's an "application layer protocol"? Not all protocols necessarily
fit neatly into the OSI 7-layer model.
Ethereal has several mechanisms to determine protocol types, which are
used at several different protocol layers:
1) packet "type fields", where those occur in the protocol as an
indication of the next protocol (that occurs in Ethernet, for
example);
2) port/socket numbers, which are similar to packet type fields,
except that there's no *guarantee* that a given port number
implies that the traffic is for the protocol for that prot
number;
3) heuristics, where a dissector will look at data in the packet
to see whether it looks like a packet for its protocol
(that's used for SMB over several transports, and for ONC RPC
and DCE RPC as well, for example);
4) hardwired knowledge, where protocol Y is always the protocol
running atop protocol X;
and the like.
> 4. when a packet is captured, is the packet handled by it's own thread?
If you're doing an "Update list of packets in real time", there are
separate processes (not threads in the same address space) for:
capturing packets, writing them to a file, updating the capture
window counters, responding to "stop the capture" UI events, and
informing the other process that more packets have arrived;
reading packets from the file as they arrive, updating the
display, and handling other UI events.
If you're not doing an "Update list of packets in real time" capture,
it's all done in one process that doesn't have multiple threads.
> why/or why not?
Not all the platforms on which Ethereal runs support threads well
enough, and not all of them have the same thread API.
