Don't assume that we start out getting commands from the client - the
capture may have started in the middle of a transaction, and we may be
getting a message body from the client instead. Only treat stuff as
commands if it consists of four alphabetic characters followed either by
an end-of-line or a space.
Commands in SMTP are case-insensitive; when looking for "DATA", do a
case-insensitive comparison.
If the packet contains the message body, just put "Message Body" in the
summary, don't put any of the message body itself in there. If it's a
command, put "Command:" in the summary before the first line of the
command.
When putting the message body into the protocol tree, give each line its
own entry, rather than putting the entire body in as one entry.
Don't put an entry into the protocol tree for a command parameter if
there is no command parameter.
svn path=/trunk/; revision=2614
you're either reading commands, or you're reading message data;
if you're reading commands, and you see a DATA command, you
start reading data;
if you're reading data, and you see an EOM, you start reading
commands.
Also, *always* fill in the per-frame data you allocate for a frame, and
*always* attach it to the packet.
The old state machine assumed it was done with the SMTP conversation
once it saw an EOM, and the dissector wouldn't fill in the per-frame
data it'd allocated and attach it to the packet if it thought it was
done with the SMTP conversation. This meant that:
1) the per-frame data allocated for frames following the EOM
(e.g., a QUIT command) would contain random junk for data
such as the packet type;
2) that per-frame data would be re-allocated every time the
frame was looked at, as it wouldn't be attached to the frame,
so you might well get *different* random junk each time the
frame was looked at.
This caused Tethereal and Ethereal to sometimes fail to recognize
commands following the EOM - but it wouldn't *always* fail to do so,
sometimes it'd work and sometimes it wouldn't.
Fix a comment; conversations are *not* removed during filter operations,
and the visited flag is *not* cleared during a filter operation - that's
only true on a *redissection* operation. In any case, given that frames
can, after the initial sequential scan through the capture, be visited
in any order, and visited repeatedly, it's irrelevant whether
conversations are removed or not - we have to associate with each frame
information telling us how to process it.
svn path=/trunk/; revision=2608
beginning.
Pass "pinfo->fd", not "fd", to "p_get_proto_data()", so that it'll
continue to work even when tvbuffified.
Use "strchr()", not "index()" - "strchr()" is in the ANSI C standard,
and may be in some systems that don't have "index()", whereas those
systems that had "index()" but not "strchr()" got with the ANSI C
program a while ago.
Use "old_dissector_add()" and "old_dissector_delete()" to register and
unregister the SMTP dissector, as it's not yet been tvbuffified.
svn path=/trunk/; revision=2303
Guy Harris