2000-08-19 23:06:51 +00:00
|
|
|
/* packet-smtp.c
|
2000-08-20 02:16:23 +00:00
|
|
|
* Routines for SMTP packet disassembly
|
2000-08-19 23:06:51 +00:00
|
|
|
*
|
2004-07-18 00:24:25 +00:00
|
|
|
* $Id$
|
2000-08-19 23:06:51 +00:00
|
|
|
*
|
|
|
|
* Copyright (c) 2000 by Richard Sharpe <rsharpe@ns.aus.com>
|
|
|
|
*
|
2006-05-21 04:49:01 +00:00
|
|
|
* Wireshark - Network traffic analyzer
|
|
|
|
* By Gerald Combs <gerald@wireshark.org>
|
2000-08-19 23:06:51 +00:00
|
|
|
* Copyright 1999 Gerald Combs
|
2001-12-03 04:00:26 +00:00
|
|
|
*
|
2000-08-19 23:06:51 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
#include "config.h"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <ctype.h>
|
|
|
|
#include <time.h>
|
|
|
|
#include <glib.h>
|
|
|
|
#include <string.h>
|
2002-01-21 07:37:49 +00:00
|
|
|
#include <epan/packet.h>
|
|
|
|
#include <epan/conversation.h>
|
2004-08-06 19:57:49 +00:00
|
|
|
#include <epan/addr_resolv.h>
|
2004-09-27 22:55:15 +00:00
|
|
|
#include <epan/prefs.h>
|
2002-01-21 07:37:49 +00:00
|
|
|
#include <epan/strutil.h>
|
2005-08-12 10:03:17 +00:00
|
|
|
#include <epan/emem.h>
|
2007-07-04 16:16:32 +00:00
|
|
|
#include <epan/reassemble.h>
|
2000-08-19 23:06:51 +00:00
|
|
|
|
strcasecmp(), strncasecmp(), g_strcasecmp(), and g_strncasecmp() delenda
est. Use g_ascii_strcasecmp() and g_ascii_strncasecmp(), and supply our
own versions if they're missing from GLib (as is the case with GLib
1.x).
In the code to build the list of named fields for Diameter, don't use
g_strdown(); do our own g_ascii_-style upper-case to lower-case mapping
in the hash function and use g_ascii_strcasecmp() in the compare
function.
We do this because there is no guarantee that toupper(), tolower(), and
functions that use them will, for example, map between "I" and "i" in
all locales; in Turkish locales, for example, there are, in both
upper case and lower case, versions of "i" with and without a dot, and
the upper-case version of "i" is "I"-with-a-dot and the lower-case
version of "I" is "i"-without-a-dot. This causes strings that should
match not to match.
This finishes fixing bug 2010 - an earlier checkin prevented the crash
(as there are other ways to produce the same crash, e.g. a bogus
dictionary.xml file), but didn't fix the case-insensitive string matching.
svn path=/trunk/; revision=23623
2007-11-27 18:52:51 +00:00
|
|
|
#ifdef NEED_G_ASCII_STRCASECMP_H
|
|
|
|
#include "g_ascii_strcasecmp.h"
|
|
|
|
#endif
|
|
|
|
|
2007-12-28 09:09:09 +00:00
|
|
|
/* RFC 2821 */
|
2000-08-19 23:06:51 +00:00
|
|
|
#define TCP_PORT_SMTP 25
|
|
|
|
|
2007-12-28 09:09:09 +00:00
|
|
|
/* RFC 4409 */
|
|
|
|
#define TCP_PORT_SUBMISSION 587
|
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
static int proto_smtp = -1;
|
|
|
|
|
|
|
|
static int hf_smtp_req = -1;
|
|
|
|
static int hf_smtp_rsp = -1;
|
2002-07-14 00:40:07 +00:00
|
|
|
static int hf_smtp_req_command = -1;
|
|
|
|
static int hf_smtp_req_parameter = -1;
|
|
|
|
static int hf_smtp_rsp_code = -1;
|
|
|
|
static int hf_smtp_rsp_parameter = -1;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
static int hf_smtp_data_fragments = -1;
|
|
|
|
static int hf_smtp_data_fragment = -1;
|
|
|
|
static int hf_smtp_data_fragment_overlap = -1;
|
|
|
|
static int hf_smtp_data_fragment_overlap_conflicts = -1;
|
|
|
|
static int hf_smtp_data_fragment_multiple_tails = -1;
|
|
|
|
static int hf_smtp_data_fragment_too_long_fragment = -1;
|
|
|
|
static int hf_smtp_data_fragment_error = -1;
|
|
|
|
static int hf_smtp_data_reassembled_in = -1;
|
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
static int ett_smtp = -1;
|
2003-06-11 18:22:12 +00:00
|
|
|
static int ett_smtp_cmdresp = -1;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
static gint ett_smtp_data_fragment = -1;
|
|
|
|
static gint ett_smtp_data_fragments = -1;
|
|
|
|
|
2002-07-17 06:55:29 +00:00
|
|
|
/* desegmentation of SMTP command and response lines */
|
|
|
|
static gboolean smtp_desegment = TRUE;
|
2007-07-04 16:16:32 +00:00
|
|
|
static gboolean smtp_data_desegment = TRUE;
|
|
|
|
|
|
|
|
static GHashTable *smtp_data_segment_table = NULL;
|
|
|
|
static GHashTable *smtp_data_reassembled_table = NULL;
|
|
|
|
|
|
|
|
static const fragment_items smtp_data_frag_items = {
|
|
|
|
/* Fragment subtrees */
|
|
|
|
&ett_smtp_data_fragment,
|
|
|
|
&ett_smtp_data_fragments,
|
|
|
|
/* Fragment fields */
|
|
|
|
&hf_smtp_data_fragments,
|
|
|
|
&hf_smtp_data_fragment,
|
|
|
|
&hf_smtp_data_fragment_overlap,
|
|
|
|
&hf_smtp_data_fragment_overlap_conflicts,
|
|
|
|
&hf_smtp_data_fragment_multiple_tails,
|
|
|
|
&hf_smtp_data_fragment_too_long_fragment,
|
|
|
|
&hf_smtp_data_fragment_error,
|
|
|
|
/* Reassembled in field */
|
|
|
|
&hf_smtp_data_reassembled_in,
|
|
|
|
/* Tag */
|
|
|
|
"DATA fragments"
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Define media_type/Content type table */
|
|
|
|
static dissector_table_t media_type_dissector_table;
|
|
|
|
|
|
|
|
|
|
|
|
static dissector_handle_t imf_handle = NULL;
|
2002-07-17 06:55:29 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
/*
|
|
|
|
* A CMD is an SMTP command, MESSAGE is the message portion, and EOM is the
|
|
|
|
* last part of a message
|
|
|
|
*/
|
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
#define SMTP_PDU_CMD 0
|
2000-08-24 11:32:09 +00:00
|
|
|
#define SMTP_PDU_MESSAGE 1
|
|
|
|
#define SMTP_PDU_EOM 2
|
|
|
|
|
|
|
|
struct smtp_proto_data {
|
|
|
|
guint16 pdu_type;
|
2007-07-04 16:16:32 +00:00
|
|
|
guint16 conversation_id;
|
2007-08-15 22:29:58 +00:00
|
|
|
gboolean more_frags;
|
2000-08-24 11:32:09 +00:00
|
|
|
};
|
|
|
|
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
/*
|
|
|
|
* State information stored with a conversation.
|
|
|
|
*/
|
2000-08-24 11:32:09 +00:00
|
|
|
struct smtp_request_val {
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
gboolean reading_data; /* Reading message data, not commands */
|
2007-08-15 22:29:58 +00:00
|
|
|
gboolean crlf_seen; /* Have we seen a CRLF on the end of a packet */
|
|
|
|
gboolean data_seen; /* Have we seen a DATA command yet */
|
|
|
|
guint32 msg_read_len; /* Length of BDAT message read so far */
|
|
|
|
guint32 msg_tot_len; /* Total length of BDAT message */
|
|
|
|
gboolean msg_last; /* Is this the last BDAT chunk */
|
2000-08-24 11:32:09 +00:00
|
|
|
};
|
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
|
|
|
|
static void dissect_smtp_data(tvbuff_t *tvb, int offset, proto_tree *smtp_tree)
|
|
|
|
{
|
|
|
|
gint next_offset;
|
|
|
|
|
|
|
|
while (tvb_offset_exists(tvb, offset)) {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the end of the line.
|
|
|
|
*/
|
|
|
|
tvb_find_line_end(tvb, offset, -1, &next_offset, FALSE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Put this line.
|
|
|
|
*/
|
|
|
|
proto_tree_add_text(smtp_tree, tvb, offset, next_offset - offset,
|
|
|
|
"Message: %s",
|
|
|
|
tvb_format_text(tvb, offset, next_offset - offset));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Step to the next line.
|
|
|
|
*/
|
|
|
|
offset = next_offset;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
static void
|
|
|
|
dissect_smtp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
|
|
|
|
{
|
2000-08-24 11:32:09 +00:00
|
|
|
struct smtp_proto_data *frame_data;
|
2000-11-12 02:29:20 +00:00
|
|
|
proto_tree *smtp_tree;
|
2003-06-11 18:22:12 +00:00
|
|
|
proto_tree *cmdresp_tree;
|
2000-11-12 02:29:20 +00:00
|
|
|
proto_item *ti;
|
|
|
|
int offset = 0;
|
2000-08-24 11:32:09 +00:00
|
|
|
int request = 0;
|
|
|
|
conversation_t *conversation;
|
|
|
|
struct smtp_request_val *request_val;
|
2002-08-02 23:36:07 +00:00
|
|
|
const guchar *line;
|
2002-07-15 09:40:20 +00:00
|
|
|
guint32 code;
|
2000-11-12 02:29:20 +00:00
|
|
|
int linelen;
|
2003-06-10 05:45:33 +00:00
|
|
|
gint length_remaining;
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
gboolean eom_seen = FALSE;
|
2000-11-12 02:29:20 +00:00
|
|
|
gint next_offset;
|
|
|
|
gboolean is_continuation_line;
|
|
|
|
int cmdlen;
|
2007-07-04 16:16:32 +00:00
|
|
|
fragment_data *frag_msg = NULL;
|
|
|
|
tvbuff_t *next_tvb;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
/* As there is no guarantee that we will only see frames in the
|
|
|
|
* the SMTP conversation once, and that we will see them in
|
2006-05-21 04:49:01 +00:00
|
|
|
* order - in Wireshark, the user could randomly click on frames
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
* in the conversation in any order in which they choose - we
|
|
|
|
* have to store information with each frame indicating whether
|
|
|
|
* it contains commands or data or an EOM indication.
|
|
|
|
*
|
|
|
|
* XXX - what about frames that contain *both*? TCP is a
|
|
|
|
* byte-stream protocol, and there are no guarantees that
|
|
|
|
* TCP segment boundaries will correspond to SMTP commands
|
|
|
|
* or EOM indications.
|
|
|
|
*
|
|
|
|
* We only need that for the client->server stream; responses
|
2000-08-24 11:32:09 +00:00
|
|
|
* are easy to manage.
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
*
|
2002-08-28 21:04:11 +00:00
|
|
|
* If we have per frame data, use that, else, we must be on the first
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
* pass, so we figure it out on the first pass.
|
2000-08-24 11:32:09 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* Find out what conversation this packet is part of ... but only
|
2002-08-28 21:04:11 +00:00
|
|
|
* if we have no information on this packet, so find the per-frame
|
2000-08-24 11:32:09 +00:00
|
|
|
* info first.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* SMTP messages have a simple format ... */
|
|
|
|
|
Remove more "CHECK_DISPLAY_AS_DATA()" calls and "pinfo->current_proto ="
statements.
Move the setting of the Protocol column in various dissectors before
anything is fetched from the packet, and also clear the Info column at
that point in those and some other dissectors, so that if an exception
is thrown, the columns don't reflect the previous protocol.
"Tvbuffify" the Mobile IP dissector (it took old-style arguments, and
then converted them into tvbuff arguments, so there wasn't much to do,
other than to fix references to "fd" to refer to "pinfo->fd").
In the SCTP dissector, refer to the port type and source and destination
ports through "pinfo" rather than through the global "pi", as it's a
tvbuffified dissector.
In the SMTP and Time Protocol dissectors, use "pinfo->match_port" rather
than "TCP_PORT_SMTP" when checking whether the packet is a request or
reply, just in case somebody makes a non-standard port be dissected as
SMTP or Time. (Also, remove a bogus comment from the Time dissector; it
was probably cut-and-pasted from the TFTP dissector.)
svn path=/trunk/; revision=2938
2001-01-25 06:14:14 +00:00
|
|
|
request = pinfo -> destport == pinfo -> match_port;
|
2000-11-12 02:29:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the first line from the buffer.
|
Remove more "CHECK_DISPLAY_AS_DATA()" calls and "pinfo->current_proto ="
statements.
Move the setting of the Protocol column in various dissectors before
anything is fetched from the packet, and also clear the Info column at
that point in those and some other dissectors, so that if an exception
is thrown, the columns don't reflect the previous protocol.
"Tvbuffify" the Mobile IP dissector (it took old-style arguments, and
then converted them into tvbuff arguments, so there wasn't much to do,
other than to fix references to "fd" to refer to "pinfo->fd").
In the SCTP dissector, refer to the port type and source and destination
ports through "pinfo" rather than through the global "pi", as it's a
tvbuffified dissector.
In the SMTP and Time Protocol dissectors, use "pinfo->match_port" rather
than "TCP_PORT_SMTP" when checking whether the packet is a request or
reply, just in case somebody makes a non-standard port be dissected as
SMTP or Time. (Also, remove a bogus comment from the Time dissector; it
was probably cut-and-pasted from the TFTP dissector.)
svn path=/trunk/; revision=2938
2001-01-25 06:14:14 +00:00
|
|
|
*
|
2002-07-17 06:55:29 +00:00
|
|
|
* Note that "tvb_find_line_end()" will, if it doesn't return
|
|
|
|
* -1, return a value that is not longer than what's in the buffer,
|
|
|
|
* and "tvb_find_line_end()" will always return a value that is not
|
|
|
|
* longer than what's in the buffer, so the "tvb_get_ptr()" call
|
|
|
|
* won't throw an exception.
|
2000-11-12 02:29:20 +00:00
|
|
|
*/
|
2002-07-17 06:55:29 +00:00
|
|
|
linelen = tvb_find_line_end(tvb, offset, -1, &next_offset,
|
|
|
|
smtp_desegment && pinfo->can_desegment);
|
|
|
|
if (linelen == -1) {
|
|
|
|
/*
|
|
|
|
* We didn't find a line ending, and we're doing desegmentation;
|
|
|
|
* tell the TCP dissector where the data for this message starts
|
|
|
|
* in the data it handed us, and tell it we need one more byte
|
|
|
|
* (we may need more, but we'll try again if what we get next
|
|
|
|
* isn't enough), and return.
|
|
|
|
*/
|
|
|
|
pinfo->desegment_offset = offset;
|
|
|
|
pinfo->desegment_len = 1;
|
|
|
|
return;
|
|
|
|
}
|
2000-11-12 02:29:20 +00:00
|
|
|
line = tvb_get_ptr(tvb, offset, linelen);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-20 02:16:23 +00:00
|
|
|
frame_data = p_get_proto_data(pinfo->fd, proto_smtp);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
if (!frame_data) {
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2005-02-02 20:07:03 +00:00
|
|
|
conversation = find_conversation(pinfo->fd->num, &pinfo->src, &pinfo->dst, pinfo->ptype,
|
2000-10-21 05:52:28 +00:00
|
|
|
pinfo->srcport, pinfo->destport, 0);
|
2000-08-24 11:32:09 +00:00
|
|
|
if (conversation == NULL) { /* No conversation, create one */
|
2005-02-02 20:07:03 +00:00
|
|
|
conversation = conversation_new(pinfo->fd->num, &pinfo->src, &pinfo->dst, pinfo->ptype,
|
2001-09-03 10:33:12 +00:00
|
|
|
pinfo->srcport, pinfo->destport, 0);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2001-11-13 04:34:38 +00:00
|
|
|
/*
|
|
|
|
* Is there a request structure attached to this conversation?
|
2000-08-24 11:32:09 +00:00
|
|
|
*/
|
2001-11-13 04:34:38 +00:00
|
|
|
request_val = conversation_get_proto_data(conversation, proto_smtp);
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2001-11-13 04:34:38 +00:00
|
|
|
if (!request_val) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2001-11-13 04:34:38 +00:00
|
|
|
/*
|
|
|
|
* No - create one and attach it.
|
|
|
|
*/
|
2005-08-12 10:03:17 +00:00
|
|
|
request_val = se_alloc(sizeof(struct smtp_request_val));
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
request_val->reading_data = FALSE;
|
2007-08-15 22:29:58 +00:00
|
|
|
request_val->crlf_seen = FALSE;
|
|
|
|
request_val->data_seen = FALSE;
|
|
|
|
request_val->msg_read_len = 0;
|
|
|
|
request_val->msg_tot_len = 0;
|
|
|
|
request_val->msg_last = TRUE;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2001-11-13 04:34:38 +00:00
|
|
|
conversation_add_proto_data(conversation, proto_smtp, request_val);
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
/*
|
2000-08-24 11:32:09 +00:00
|
|
|
* Check whether or not this packet is an end of message packet
|
|
|
|
* We should look for CRLF.CRLF and they may be split.
|
|
|
|
* We have to keep in mind that we may see what we want on
|
|
|
|
* two passes through here ...
|
|
|
|
*/
|
|
|
|
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
if (request_val->reading_data) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The order of these is important ... We want to avoid
|
2002-08-28 21:04:11 +00:00
|
|
|
* cases where there is a CRLF at the end of a packet and a
|
2000-08-24 11:32:09 +00:00
|
|
|
* .CRLF at the begining of the same packet.
|
|
|
|
*/
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
if ((request_val->crlf_seen && tvb_strneql(tvb, offset, ".\r\n", 3) == 0) ||
|
|
|
|
tvb_strneql(tvb, offset, "\r\n.\r\n", 5) == 0) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
eom_seen = TRUE;
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
2003-06-10 05:45:33 +00:00
|
|
|
length_remaining = tvb_length_remaining(tvb, offset);
|
|
|
|
if (length_remaining == tvb_reported_length_remaining(tvb, offset) &&
|
|
|
|
tvb_strneql(tvb, offset + length_remaining - 2, "\r\n", 2) == 0) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2007-08-15 22:29:58 +00:00
|
|
|
request_val->crlf_seen = TRUE;
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
|
2007-08-15 22:29:58 +00:00
|
|
|
request_val->crlf_seen = FALSE;
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2002-08-28 21:04:11 +00:00
|
|
|
* OK, Check if we have seen a DATA request. We do it here for
|
2000-08-24 11:32:09 +00:00
|
|
|
* simplicity, but we have to be careful below.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (request) {
|
|
|
|
|
2005-08-12 10:03:17 +00:00
|
|
|
frame_data = se_alloc(sizeof(struct smtp_proto_data));
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
frame_data->conversation_id = conversation->index;
|
2007-08-15 22:29:58 +00:00
|
|
|
frame_data->more_frags = TRUE;
|
2007-07-04 16:16:32 +00:00
|
|
|
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
if (request_val->reading_data) {
|
|
|
|
/*
|
|
|
|
* This is message data.
|
|
|
|
*/
|
|
|
|
if (eom_seen) { /* Seen the EOM */
|
|
|
|
/*
|
|
|
|
* EOM.
|
|
|
|
* Everything that comes after it is commands.
|
|
|
|
*
|
|
|
|
* XXX - what if the EOM isn't at the beginning of
|
|
|
|
* the TCP segment? It can occur anywhere....
|
|
|
|
*/
|
|
|
|
frame_data->pdu_type = SMTP_PDU_EOM;
|
|
|
|
request_val->reading_data = FALSE;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Message data with no EOM.
|
|
|
|
*/
|
2000-08-24 11:32:09 +00:00
|
|
|
frame_data->pdu_type = SMTP_PDU_MESSAGE;
|
2007-08-15 22:29:58 +00:00
|
|
|
|
|
|
|
if (request_val->msg_tot_len > 0) {
|
|
|
|
/*
|
|
|
|
* We are handling a BDAT message.
|
|
|
|
* Check if we have reached end of the data chunk.
|
|
|
|
*/
|
|
|
|
request_val->msg_read_len += tvb_length_remaining(tvb, offset);
|
|
|
|
|
|
|
|
if (request_val->msg_read_len == request_val->msg_tot_len) {
|
|
|
|
/*
|
|
|
|
* We have reached end of BDAT data chunk.
|
|
|
|
* Everything that comes after this is commands.
|
|
|
|
*/
|
|
|
|
request_val->reading_data = FALSE;
|
|
|
|
|
|
|
|
if (request_val->msg_last) {
|
|
|
|
/*
|
|
|
|
* We have found the LAST data chunk.
|
|
|
|
* The message can now be reassembled.
|
|
|
|
*/
|
|
|
|
frame_data->more_frags = FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/*
|
2000-11-12 02:29:20 +00:00
|
|
|
* This is commands - unless the capture started in the
|
|
|
|
* middle of a session, and we're in the middle of data.
|
|
|
|
* To quote RFC 821, "Command codes are four alphabetic
|
|
|
|
* characters"; if we don't see four alphabetic characters
|
|
|
|
* and, if there's anything else in the line, a space, we
|
|
|
|
* assume it's not a command.
|
|
|
|
* (We treat only A-Z and a-z as alphabetic.)
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
*/
|
2000-11-12 02:29:20 +00:00
|
|
|
#define ISALPHA(c) (((c) >= 'A' && (c) <= 'Z') || \
|
|
|
|
((c) >= 'a' && (c) <= 'z'))
|
|
|
|
if (linelen >= 4 && ISALPHA(line[0]) && ISALPHA(line[1]) &&
|
|
|
|
ISALPHA(line[2]) && ISALPHA(line[3]) &&
|
|
|
|
(linelen == 4 || line[4] == ' ')) {
|
strcasecmp(), strncasecmp(), g_strcasecmp(), and g_strncasecmp() delenda
est. Use g_ascii_strcasecmp() and g_ascii_strncasecmp(), and supply our
own versions if they're missing from GLib (as is the case with GLib
1.x).
In the code to build the list of named fields for Diameter, don't use
g_strdown(); do our own g_ascii_-style upper-case to lower-case mapping
in the hash function and use g_ascii_strcasecmp() in the compare
function.
We do this because there is no guarantee that toupper(), tolower(), and
functions that use them will, for example, map between "I" and "i" in
all locales; in Turkish locales, for example, there are, in both
upper case and lower case, versions of "i" with and without a dot, and
the upper-case version of "i" is "I"-with-a-dot and the lower-case
version of "I" is "i"-without-a-dot. This causes strings that should
match not to match.
This finishes fixing bug 2010 - an earlier checkin prevented the crash
(as there are other ways to produce the same crash, e.g. a bogus
dictionary.xml file), but didn't fix the case-insensitive string matching.
svn path=/trunk/; revision=23623
2007-11-27 18:52:51 +00:00
|
|
|
if (g_ascii_strncasecmp(line, "DATA", 4) == 0) {
|
2000-11-12 02:29:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DATA command.
|
|
|
|
* This is a command, but everything that comes after it,
|
|
|
|
* until an EOM, is data.
|
|
|
|
*/
|
|
|
|
frame_data->pdu_type = SMTP_PDU_CMD;
|
|
|
|
request_val->reading_data = TRUE;
|
2007-07-04 16:16:32 +00:00
|
|
|
request_val->data_seen = TRUE;
|
2000-11-12 02:29:20 +00:00
|
|
|
|
strcasecmp(), strncasecmp(), g_strcasecmp(), and g_strncasecmp() delenda
est. Use g_ascii_strcasecmp() and g_ascii_strncasecmp(), and supply our
own versions if they're missing from GLib (as is the case with GLib
1.x).
In the code to build the list of named fields for Diameter, don't use
g_strdown(); do our own g_ascii_-style upper-case to lower-case mapping
in the hash function and use g_ascii_strcasecmp() in the compare
function.
We do this because there is no guarantee that toupper(), tolower(), and
functions that use them will, for example, map between "I" and "i" in
all locales; in Turkish locales, for example, there are, in both
upper case and lower case, versions of "i" with and without a dot, and
the upper-case version of "i" is "I"-with-a-dot and the lower-case
version of "I" is "i"-without-a-dot. This causes strings that should
match not to match.
This finishes fixing bug 2010 - an earlier checkin prevented the crash
(as there are other ways to produce the same crash, e.g. a bogus
dictionary.xml file), but didn't fix the case-insensitive string matching.
svn path=/trunk/; revision=23623
2007-11-27 18:52:51 +00:00
|
|
|
} else if (g_ascii_strncasecmp(line, "BDAT", 4) == 0) {
|
2007-08-15 22:29:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* BDAT command.
|
|
|
|
* This is a command, but everything that comes after it,
|
|
|
|
* until given length is received, is data.
|
|
|
|
*/
|
|
|
|
guint32 msg_len;
|
|
|
|
|
|
|
|
msg_len = strtoul (line+5, NULL, 10);
|
|
|
|
|
|
|
|
frame_data->pdu_type = SMTP_PDU_CMD;
|
|
|
|
request_val->data_seen = TRUE;
|
|
|
|
request_val->msg_tot_len += msg_len;
|
|
|
|
|
|
|
|
if (msg_len == 0) {
|
|
|
|
/* No data to read, next will be a command */
|
|
|
|
request_val->reading_data = FALSE;
|
|
|
|
} else {
|
|
|
|
request_val->reading_data = TRUE;
|
|
|
|
}
|
|
|
|
|
strcasecmp(), strncasecmp(), g_strcasecmp(), and g_strncasecmp() delenda
est. Use g_ascii_strcasecmp() and g_ascii_strncasecmp(), and supply our
own versions if they're missing from GLib (as is the case with GLib
1.x).
In the code to build the list of named fields for Diameter, don't use
g_strdown(); do our own g_ascii_-style upper-case to lower-case mapping
in the hash function and use g_ascii_strcasecmp() in the compare
function.
We do this because there is no guarantee that toupper(), tolower(), and
functions that use them will, for example, map between "I" and "i" in
all locales; in Turkish locales, for example, there are, in both
upper case and lower case, versions of "i" with and without a dot, and
the upper-case version of "i" is "I"-with-a-dot and the lower-case
version of "I" is "i"-without-a-dot. This causes strings that should
match not to match.
This finishes fixing bug 2010 - an earlier checkin prevented the crash
(as there are other ways to produce the same crash, e.g. a bogus
dictionary.xml file), but didn't fix the case-insensitive string matching.
svn path=/trunk/; revision=23623
2007-11-27 18:52:51 +00:00
|
|
|
if (g_ascii_strncasecmp(line+linelen-4, "LAST", 4) == 0) {
|
2007-08-15 22:29:58 +00:00
|
|
|
/*
|
|
|
|
* This is the last data chunk.
|
|
|
|
*/
|
|
|
|
request_val->msg_last = TRUE;
|
|
|
|
|
|
|
|
if (msg_len == 0) {
|
|
|
|
/*
|
|
|
|
* No more data to expect.
|
|
|
|
* The message can now be reassembled.
|
|
|
|
*/
|
|
|
|
frame_data->more_frags = FALSE;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
request_val->msg_last = FALSE;
|
|
|
|
}
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
} else {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Regular command.
|
|
|
|
*/
|
|
|
|
frame_data->pdu_type = SMTP_PDU_CMD;
|
|
|
|
|
|
|
|
}
|
|
|
|
} else {
|
strcasecmp(), strncasecmp(), g_strcasecmp(), and g_strncasecmp() delenda
est. Use g_ascii_strcasecmp() and g_ascii_strncasecmp(), and supply our
own versions if they're missing from GLib (as is the case with GLib
1.x).
In the code to build the list of named fields for Diameter, don't use
g_strdown(); do our own g_ascii_-style upper-case to lower-case mapping
in the hash function and use g_ascii_strcasecmp() in the compare
function.
We do this because there is no guarantee that toupper(), tolower(), and
functions that use them will, for example, map between "I" and "i" in
all locales; in Turkish locales, for example, there are, in both
upper case and lower case, versions of "i" with and without a dot, and
the upper-case version of "i" is "I"-with-a-dot and the lower-case
version of "I" is "i"-without-a-dot. This causes strings that should
match not to match.
This finishes fixing bug 2010 - an earlier checkin prevented the crash
(as there are other ways to produce the same crash, e.g. a bogus
dictionary.xml file), but didn't fix the case-insensitive string matching.
svn path=/trunk/; revision=23623
2007-11-27 18:52:51 +00:00
|
|
|
if ((linelen >= 7) && line[0] == 'X' && ( (g_ascii_strncasecmp(line, "X-EXPS ", 7) == 0) ||
|
|
|
|
((linelen >=13) && (g_ascii_strncasecmp(line, "X-LINK2STATE ", 13) == 0)) ||
|
|
|
|
((linelen >= 8) && (g_ascii_strncasecmp(line, "XEXCH50 ", 8) == 0)) ))
|
2004-05-16 18:50:40 +00:00
|
|
|
frame_data->pdu_type = SMTP_PDU_CMD;
|
|
|
|
else
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
/*
|
2000-11-12 02:29:20 +00:00
|
|
|
* Assume it's message data.
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
*/
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
|
|
|
|
frame_data->pdu_type = request_val->data_seen ? SMTP_PDU_MESSAGE : SMTP_PDU_CMD;
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
}
|
Simplify the state machine:
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
2000-11-11 07:48:30 +00:00
|
|
|
|
|
|
|
p_add_proto_data(pinfo->fd, proto_smtp, frame_data);
|
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
/*
|
|
|
|
* From here, we simply add items to the tree and info to the info
|
2000-08-24 11:32:09 +00:00
|
|
|
* fields ...
|
|
|
|
*/
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
if (check_col(pinfo->cinfo, COL_PROTOCOL))
|
|
|
|
col_set_str(pinfo->cinfo, COL_PROTOCOL, "SMTP");
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
if (check_col(pinfo->cinfo, COL_INFO)) { /* Add the appropriate type here */
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
/*
|
|
|
|
* If it is a request, we have to look things up, otherwise, just
|
2002-08-28 21:04:11 +00:00
|
|
|
* display the right things
|
2000-08-24 11:32:09 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
if (request) {
|
|
|
|
|
|
|
|
/* We must have frame_data here ... */
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
switch (frame_data->pdu_type) {
|
|
|
|
case SMTP_PDU_MESSAGE:
|
|
|
|
|
2007-08-15 22:29:58 +00:00
|
|
|
length_remaining = tvb_length_remaining(tvb, offset);
|
2007-07-04 16:16:32 +00:00
|
|
|
col_set_str(pinfo->cinfo, COL_INFO, smtp_data_desegment ? "DATA fragment" : "Message Body");
|
2007-08-15 22:29:58 +00:00
|
|
|
col_append_fstr(pinfo->cinfo, COL_INFO, ", %d byte%s", length_remaining,
|
|
|
|
plurality (length_remaining, "", "s"));
|
2000-08-24 11:32:09 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SMTP_PDU_EOM:
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
col_add_fstr(pinfo->cinfo, COL_INFO, "EOM: %s",
|
2000-11-12 02:29:20 +00:00
|
|
|
format_text(line, linelen));
|
2000-08-24 11:32:09 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SMTP_PDU_CMD:
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
col_add_fstr(pinfo->cinfo, COL_INFO, "Command: %s",
|
2000-11-12 02:29:20 +00:00
|
|
|
format_text(line, linelen));
|
|
|
|
break;
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
|
2001-12-10 00:26:21 +00:00
|
|
|
col_add_fstr(pinfo->cinfo, COL_INFO, "Response: %s",
|
2000-11-12 02:29:20 +00:00
|
|
|
format_text(line, linelen));
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (tree) { /* Build the tree info ... */
|
|
|
|
|
2002-01-24 09:20:54 +00:00
|
|
|
ti = proto_tree_add_item(tree, proto_smtp, tvb, offset, -1, FALSE);
|
2000-08-19 23:06:51 +00:00
|
|
|
smtp_tree = proto_item_add_subtree(ti, ett_smtp);
|
|
|
|
if (request) {
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
/*
|
2000-08-24 11:32:09 +00:00
|
|
|
* Check out whether or not we can see a command in there ...
|
|
|
|
* What we are looking for is not data_seen and the word DATA
|
|
|
|
* and not eom_seen.
|
|
|
|
*
|
|
|
|
* We will see DATA and request_val->data_seen when we process the
|
|
|
|
* tree view after we have seen a DATA packet when processing
|
|
|
|
* the packet list pane.
|
|
|
|
*
|
|
|
|
* On the first pass, we will not have any info on the packets
|
|
|
|
* On second and subsequent passes, we will.
|
|
|
|
*/
|
|
|
|
|
|
|
|
switch (frame_data->pdu_type) {
|
|
|
|
|
|
|
|
case SMTP_PDU_MESSAGE:
|
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
if(smtp_data_desegment) {
|
2000-11-12 02:29:20 +00:00
|
|
|
|
2007-08-15 22:29:58 +00:00
|
|
|
frag_msg = fragment_add_seq_next (tvb, 0, pinfo, frame_data->conversation_id,
|
|
|
|
smtp_data_segment_table, smtp_data_reassembled_table,
|
2007-10-23 05:50:00 +00:00
|
|
|
tvb_length(tvb), frame_data->more_frags);
|
2007-07-04 16:16:32 +00:00
|
|
|
} else {
|
2007-08-15 22:29:58 +00:00
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
2007-07-04 16:16:32 +00:00
|
|
|
* Message body.
|
|
|
|
* Put its lines into the protocol tree, a line at a time.
|
2000-11-12 02:29:20 +00:00
|
|
|
*/
|
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
dissect_smtp_data(tvb, offset, smtp_tree);
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
}
|
2000-08-24 11:32:09 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
case SMTP_PDU_EOM:
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* End-of-message-body indicator.
|
|
|
|
*
|
|
|
|
* XXX - what about stuff after the first line?
|
|
|
|
* Unlikely, as the client should wait for a response to the
|
|
|
|
* DATA command this terminates before sending another
|
|
|
|
* request, but we should probably handle it.
|
|
|
|
*/
|
2000-11-12 03:13:44 +00:00
|
|
|
proto_tree_add_text(smtp_tree, tvb, offset, linelen,
|
|
|
|
"EOM: %s", format_text(line, linelen));
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
if(smtp_data_desegment) {
|
|
|
|
|
|
|
|
/* terminate the desegmentation */
|
|
|
|
frag_msg = fragment_end_seq_next (pinfo, frame_data->conversation_id, smtp_data_segment_table,
|
|
|
|
smtp_data_reassembled_table);
|
|
|
|
}
|
|
|
|
|
2000-08-24 11:32:09 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SMTP_PDU_CMD:
|
2000-11-12 02:29:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Command.
|
|
|
|
*
|
|
|
|
* XXX - what about stuff after the first line?
|
|
|
|
* Unlikely, as the client should wait for a response to the
|
|
|
|
* previous command before sending another request, but we
|
|
|
|
* should probably handle it.
|
|
|
|
*/
|
|
|
|
if (linelen >= 4)
|
|
|
|
cmdlen = 4;
|
|
|
|
else
|
|
|
|
cmdlen = linelen;
|
2002-07-14 08:27:34 +00:00
|
|
|
proto_tree_add_boolean_hidden(smtp_tree, hf_smtp_req, tvb,
|
|
|
|
0, 0, TRUE);
|
2003-06-11 18:22:12 +00:00
|
|
|
/*
|
|
|
|
* Put the command line into the protocol tree.
|
|
|
|
*/
|
|
|
|
ti = proto_tree_add_text(smtp_tree, tvb, offset, next_offset - offset,
|
|
|
|
"Command: %s",
|
|
|
|
tvb_format_text(tvb, offset, next_offset - offset));
|
|
|
|
cmdresp_tree = proto_item_add_subtree(ti, ett_smtp_cmdresp);
|
|
|
|
|
|
|
|
proto_tree_add_item(cmdresp_tree, hf_smtp_req_command, tvb,
|
2002-07-14 00:40:07 +00:00
|
|
|
offset, cmdlen, FALSE);
|
2000-11-12 02:29:20 +00:00
|
|
|
if (linelen > 5) {
|
2003-06-11 18:22:12 +00:00
|
|
|
proto_tree_add_item(cmdresp_tree, hf_smtp_req_parameter, tvb,
|
2002-07-14 00:40:07 +00:00
|
|
|
offset + 5, linelen - 5, FALSE);
|
2000-11-12 02:29:20 +00:00
|
|
|
}
|
2000-08-24 11:32:09 +00:00
|
|
|
|
2007-08-15 22:29:58 +00:00
|
|
|
if (smtp_data_desegment && !frame_data->more_frags) {
|
|
|
|
|
|
|
|
/* terminate the desegmentation */
|
|
|
|
frag_msg = fragment_end_seq_next (pinfo, frame_data->conversation_id, smtp_data_segment_table,
|
|
|
|
smtp_data_reassembled_table);
|
|
|
|
}
|
2000-08-24 11:32:09 +00:00
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2007-08-15 22:29:58 +00:00
|
|
|
if (smtp_data_desegment) {
|
|
|
|
next_tvb = process_reassembled_data (tvb, offset, pinfo, "Reassembled DATA",
|
|
|
|
frag_msg, &smtp_data_frag_items, NULL, smtp_tree);
|
|
|
|
if (next_tvb) {
|
|
|
|
/* XXX: this is presumptious - we may have negotiated something else */
|
|
|
|
if(imf_handle) {
|
|
|
|
call_dissector(imf_handle, next_tvb, pinfo, tree);
|
|
|
|
} else {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Message body.
|
|
|
|
* Put its lines into the protocol tree, a line at a time.
|
|
|
|
*/
|
|
|
|
|
|
|
|
dissect_smtp_data(tvb, offset, smtp_tree);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
pinfo->fragmented = FALSE;
|
|
|
|
} else {
|
|
|
|
pinfo->fragmented = TRUE;
|
|
|
|
}
|
|
|
|
}
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* Process the response, a line at a time, until we hit a line
|
|
|
|
* that doesn't have a continuation indication on it.
|
|
|
|
*/
|
2002-07-14 08:27:34 +00:00
|
|
|
proto_tree_add_boolean_hidden(smtp_tree, hf_smtp_rsp, tvb,
|
|
|
|
0, 0, TRUE);
|
2000-11-12 02:29:20 +00:00
|
|
|
|
2000-11-13 08:58:17 +00:00
|
|
|
while (tvb_offset_exists(tvb, offset)) {
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* Find the end of the line.
|
|
|
|
*/
|
2002-07-17 06:55:29 +00:00
|
|
|
linelen = tvb_find_line_end(tvb, offset, -1, &next_offset, FALSE);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2003-06-11 18:22:12 +00:00
|
|
|
/*
|
|
|
|
* Put it into the protocol tree.
|
|
|
|
*/
|
|
|
|
ti = proto_tree_add_text(smtp_tree, tvb, offset,
|
|
|
|
next_offset - offset, "Response: %s",
|
|
|
|
tvb_format_text(tvb, offset,
|
|
|
|
next_offset - offset));
|
|
|
|
cmdresp_tree = proto_item_add_subtree(ti, ett_smtp_cmdresp);
|
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* Is it a continuation line?
|
|
|
|
*/
|
|
|
|
is_continuation_line =
|
|
|
|
(linelen >= 4 && tvb_get_guint8(tvb, offset + 3) == '-');
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
2003-06-11 18:22:12 +00:00
|
|
|
* Put the response code and parameters into the protocol tree.
|
2000-11-12 02:29:20 +00:00
|
|
|
*/
|
2002-07-14 00:40:07 +00:00
|
|
|
line = tvb_get_ptr(tvb, offset, linelen);
|
|
|
|
if (linelen >= 3 && isdigit(line[0]) && isdigit(line[1])
|
|
|
|
&& isdigit(line[2])) {
|
|
|
|
/*
|
|
|
|
* We have a 3-digit response code.
|
|
|
|
*/
|
|
|
|
code = (line[0] - '0')*100 + (line[1] - '0')*10 + (line[2] - '0');
|
2003-06-11 18:22:12 +00:00
|
|
|
proto_tree_add_uint(cmdresp_tree, hf_smtp_rsp_code, tvb, offset, 3,
|
2002-07-14 00:40:07 +00:00
|
|
|
code);
|
|
|
|
|
|
|
|
if (linelen >= 4) {
|
2003-06-11 18:22:12 +00:00
|
|
|
proto_tree_add_item(cmdresp_tree, hf_smtp_rsp_parameter, tvb,
|
2002-07-14 00:40:07 +00:00
|
|
|
offset + 4, linelen - 4, FALSE);
|
|
|
|
}
|
2000-11-12 02:29:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Step past this line.
|
|
|
|
*/
|
|
|
|
offset = next_offset;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2000-11-12 02:29:20 +00:00
|
|
|
/*
|
|
|
|
* If it's not a continuation line, quit.
|
|
|
|
*/
|
|
|
|
if (!is_continuation_line)
|
|
|
|
break;
|
|
|
|
|
|
|
|
}
|
2002-08-28 21:04:11 +00:00
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-07-04 16:16:32 +00:00
|
|
|
static void smtp_data_reassemble_init (void)
|
|
|
|
{
|
|
|
|
fragment_table_init (&smtp_data_segment_table);
|
|
|
|
reassembled_table_init (&smtp_data_reassembled_table);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
/* Register all the bits needed by the filtering engine */
|
|
|
|
|
|
|
|
void
|
|
|
|
proto_register_smtp(void)
|
|
|
|
{
|
|
|
|
static hf_register_info hf[] = {
|
|
|
|
{ &hf_smtp_req,
|
2001-06-18 02:18:27 +00:00
|
|
|
{ "Request", "smtp.req", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "", HFILL }},
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
{ &hf_smtp_rsp,
|
2001-06-18 02:18:27 +00:00
|
|
|
{ "Response", "smtp.rsp", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "", HFILL }},
|
2002-07-14 00:40:07 +00:00
|
|
|
|
|
|
|
{ &hf_smtp_req_command,
|
|
|
|
{ "Command", "smtp.req.command", FT_STRING, BASE_NONE, NULL, 0x0,
|
|
|
|
"", HFILL }},
|
|
|
|
|
|
|
|
{ &hf_smtp_req_parameter,
|
|
|
|
{ "Request parameter", "smtp.req.parameter", FT_STRING, BASE_NONE, NULL, 0x0,
|
|
|
|
"", HFILL }},
|
|
|
|
|
|
|
|
{ &hf_smtp_rsp_code,
|
2002-07-15 09:40:20 +00:00
|
|
|
{ "Response code", "smtp.response.code", FT_UINT32, BASE_DEC, NULL, 0x0,
|
2002-07-14 00:40:07 +00:00
|
|
|
"", HFILL }},
|
|
|
|
|
|
|
|
{ &hf_smtp_rsp_parameter,
|
|
|
|
{ "Response parameter", "smtp.rsp.parameter", FT_STRING, BASE_NONE, NULL, 0x0,
|
2007-07-04 16:16:32 +00:00
|
|
|
"", HFILL }},
|
|
|
|
|
|
|
|
/* Fragment entries */
|
|
|
|
{ &hf_smtp_data_fragments,
|
|
|
|
{ "DATA fragments", "smtp.data.fragments", FT_NONE, BASE_NONE,
|
|
|
|
NULL, 0x00, "Message fragments", HFILL } },
|
|
|
|
{ &hf_smtp_data_fragment,
|
|
|
|
{ "DATA fragment", "smtp.data.fragment", FT_FRAMENUM, BASE_NONE,
|
|
|
|
NULL, 0x00, "Message fragment", HFILL } },
|
|
|
|
{ &hf_smtp_data_fragment_overlap,
|
|
|
|
{ "DATA fragment overlap", "smtp.data.fragment.overlap", FT_BOOLEAN,
|
|
|
|
BASE_NONE, NULL, 0x00, "Message fragment overlap", HFILL } },
|
|
|
|
{ &hf_smtp_data_fragment_overlap_conflicts,
|
|
|
|
{ "DATA fragment overlapping with conflicting data",
|
|
|
|
"smtp.data.fragment.overlap.conflicts", FT_BOOLEAN, BASE_NONE, NULL,
|
|
|
|
0x00, "Message fragment overlapping with conflicting data", HFILL } },
|
|
|
|
{ &hf_smtp_data_fragment_multiple_tails,
|
|
|
|
{ "DATA has multiple tail fragments",
|
|
|
|
"smtp.data.fragment.multiple_tails", FT_BOOLEAN, BASE_NONE,
|
|
|
|
NULL, 0x00, "Message has multiple tail fragments", HFILL } },
|
|
|
|
{ &hf_smtp_data_fragment_too_long_fragment,
|
|
|
|
{ "DATA fragment too long", "smtp.data.fragment.too_long_fragment",
|
|
|
|
FT_BOOLEAN, BASE_NONE, NULL, 0x00, "Message fragment too long",
|
|
|
|
HFILL } },
|
|
|
|
{ &hf_smtp_data_fragment_error,
|
|
|
|
{ "DATA defragmentation error", "smtp.data.fragment.error", FT_FRAMENUM,
|
|
|
|
BASE_NONE, NULL, 0x00, "Message defragmentation error", HFILL } },
|
|
|
|
{ &hf_smtp_data_reassembled_in,
|
|
|
|
{ "Reassembled DATA in frame", "smtp.data.reassembled.in", FT_FRAMENUM, BASE_NONE,
|
|
|
|
NULL, 0x00, "This DATA fragment is reassembled in this frame", HFILL } },
|
2000-08-19 23:06:51 +00:00
|
|
|
};
|
|
|
|
static gint *ett[] = {
|
2003-06-11 18:22:12 +00:00
|
|
|
&ett_smtp,
|
|
|
|
&ett_smtp_cmdresp,
|
2007-07-04 16:16:32 +00:00
|
|
|
&ett_smtp_data_fragment,
|
|
|
|
&ett_smtp_data_fragments,
|
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
};
|
2002-07-17 06:55:29 +00:00
|
|
|
module_t *smtp_module;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
|
2001-01-03 06:56:03 +00:00
|
|
|
proto_smtp = proto_register_protocol("Simple Mail Transfer Protocol",
|
|
|
|
"SMTP", "smtp");
|
2000-08-19 23:06:51 +00:00
|
|
|
|
|
|
|
proto_register_field_array(proto_smtp, hf, array_length(hf));
|
|
|
|
proto_register_subtree_array(ett, array_length(ett));
|
2007-07-04 16:16:32 +00:00
|
|
|
register_init_routine (&smtp_data_reassemble_init);
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2006-10-25 16:46:27 +00:00
|
|
|
/* Allow dissector to find be found by name. */
|
|
|
|
register_dissector("smtp", dissect_smtp, proto_smtp);
|
|
|
|
|
|
|
|
/* Preferences */
|
2002-07-17 06:55:29 +00:00
|
|
|
smtp_module = prefs_register_protocol(proto_smtp, NULL);
|
|
|
|
prefs_register_bool_preference(smtp_module, "desegment_lines",
|
2004-08-21 09:02:52 +00:00
|
|
|
"Reassemble SMTP command and response lines\nspanning multiple TCP segments",
|
|
|
|
"Whether the SMTP dissector should reassemble command and response lines spanning multiple TCP segments."
|
|
|
|
" To use this option, you must also enable \"Allow subdissectors to reassemble TCP streams\" in the TCP protocol settings.",
|
2002-07-17 06:55:29 +00:00
|
|
|
&smtp_desegment);
|
2007-07-04 16:16:32 +00:00
|
|
|
|
|
|
|
prefs_register_bool_preference(smtp_module, "desegment_data",
|
|
|
|
"Reassemble SMTP DATA commands spanning multiple TCP segments",
|
|
|
|
"Whether the SMTP dissector should reassemble DATA command and lines spanning multiple TCP segments."
|
|
|
|
" To use this option, you must also enable \"Allow subdissectors to reassemble TCP streams\" in the TCP protocol settings.",
|
|
|
|
&smtp_data_desegment);
|
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* The registration hand-off routine */
|
|
|
|
void
|
|
|
|
proto_reg_handoff_smtp(void)
|
|
|
|
{
|
2003-09-16 17:42:01 +00:00
|
|
|
dissector_handle_t smtp_handle;
|
2000-08-19 23:06:51 +00:00
|
|
|
|
2003-09-16 17:42:01 +00:00
|
|
|
smtp_handle = create_dissector_handle(dissect_smtp, proto_smtp);
|
|
|
|
dissector_add("tcp.port", TCP_PORT_SMTP, smtp_handle);
|
2007-12-28 09:09:09 +00:00
|
|
|
dissector_add("tcp.port", TCP_PORT_SUBMISSION, smtp_handle);
|
2007-07-04 16:16:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the content type and Internet media type table
|
|
|
|
*/
|
|
|
|
media_type_dissector_table = find_dissector_table("media_type");
|
|
|
|
|
|
|
|
/* find the IMF dissector */
|
|
|
|
imf_handle = find_dissector("imf");
|
|
|
|
|
2000-08-19 23:06:51 +00:00
|
|
|
}
|