There really is a basic difference between a packet and a frame. It has
of course been corrupted by lots of applications that give their own
definitions to these two words, but if you look at it linguistically and
etymologically, you see that these words are meant for different things.
A packet is a group of bits of data. A frame is a place to put a packet.
You can't store a frame -- it is mainly of interest to low level network
hardware. A frame is typically an interval of time. Sometimes, it is the
equivalent region along the length of a wire.
If you look at a very early use of the term "frame" this is clear. In the
RS-232 asynchronous serial line protocol, a packet (though not called
that) is typically 8 bits that represent a byte of data being sent from
one node to another. But on the wire, you have to add a start bit in
front and a stop bit in back. Adding those bits is called "framing." You
will never see the 10 bit sequence stored anywhere - the bits are added on
the fly by hardware. The start and stop bits are not part of any packet.
The time between when the receiver sees the start bit and when the
receiver sees to stop bit, not the 10 bits, is a frame.
In T1, a frame is defined by points in time alone -- no extra bits
involved at all. It's not uncommon on T1 voice lines for the packets to
end up distributed incorrectly among the frames (instead of one packet to
each frame), thus causing individual voice circuits to get messed up.
In virtual memory, a page frame is a region of real memory in which you
can place a page of virtual memory. The frame is not the contents of that
real memory -- its just the place.
I'd say ethereal can't really see frames -- it sees only packets that
layers below it extract from frames.
But I also agree that when "frame" is the well-known term for something
else in a particular protocol, ethereal should use it that way.