2001-06-08 06:27:16 +00:00
|
|
|
/* reassemble.c
|
|
|
|
* Routines for {fragment,segment} reassembly
|
|
|
|
*
|
2004-07-18 00:24:25 +00:00
|
|
|
* $Id$
|
2001-06-08 06:27:16 +00:00
|
|
|
*
|
2006-05-21 05:12:17 +00:00
|
|
|
* Wireshark - Network traffic analyzer
|
|
|
|
* By Gerald Combs <gerald@wireshark.org>
|
2001-06-08 06:27:16 +00:00
|
|
|
* Copyright 1998 Gerald Combs
|
2002-08-28 21:04:11 +00:00
|
|
|
*
|
2001-06-08 06:27:16 +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.
|
2002-08-28 21:04:11 +00:00
|
|
|
*
|
2001-06-08 06:27:16 +00:00
|
|
|
* 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.
|
2002-08-28 21:04:11 +00:00
|
|
|
*
|
2001-06-08 06:27:16 +00:00
|
|
|
* 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
|
|
|
|
|
2001-06-28 19:15:11 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
2002-01-21 07:37:49 +00:00
|
|
|
#include <epan/packet.h>
|
2001-06-08 06:27:16 +00:00
|
|
|
|
2005-02-09 23:38:00 +00:00
|
|
|
#include <epan/reassemble.h>
|
2001-06-08 06:27:16 +00:00
|
|
|
|
2005-08-14 01:26:34 +00:00
|
|
|
#include <epan/emem.h>
|
|
|
|
|
2004-07-18 18:06:47 +00:00
|
|
|
#include <epan/dissectors/packet-dcerpc.h>
|
2002-06-05 11:21:49 +00:00
|
|
|
|
2001-06-08 06:27:16 +00:00
|
|
|
typedef struct _fragment_key {
|
|
|
|
address src;
|
|
|
|
address dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
guint32 id;
|
2001-06-08 06:27:16 +00:00
|
|
|
} fragment_key;
|
|
|
|
|
2004-06-24 07:43:24 +00:00
|
|
|
typedef struct _dcerpc_fragment_key {
|
2005-07-24 17:48:10 +00:00
|
|
|
address src;
|
|
|
|
address dst;
|
|
|
|
guint32 id;
|
|
|
|
e_uuid_t act_id;
|
2004-06-24 07:43:24 +00:00
|
|
|
} dcerpc_fragment_key;
|
|
|
|
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
#else
|
2001-06-08 06:27:16 +00:00
|
|
|
static GMemChunk *fragment_key_chunk = NULL;
|
|
|
|
static GMemChunk *fragment_data_chunk = NULL;
|
2009-10-18 19:46:46 +00:00
|
|
|
static GMemChunk *dcerpc_key_chunk = NULL;
|
2001-06-08 06:27:16 +00:00
|
|
|
static int fragment_init_count = 200;
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
2001-06-08 06:27:16 +00:00
|
|
|
|
2007-11-10 16:08:14 +00:00
|
|
|
static void LINK_FRAG(fragment_data *fd_head,fragment_data *fd)
|
2009-08-12 19:32:54 +00:00
|
|
|
{
|
2007-11-10 16:08:14 +00:00
|
|
|
fragment_data *fd_i;
|
|
|
|
|
|
|
|
/* add fragment to list, keep list sorted */
|
|
|
|
for(fd_i= fd_head; fd_i->next;fd_i=fd_i->next) {
|
|
|
|
if (fd->offset < fd_i->next->offset )
|
|
|
|
break;
|
2001-06-08 06:27:16 +00:00
|
|
|
}
|
2007-11-10 16:08:14 +00:00
|
|
|
fd->next=fd_i->next;
|
|
|
|
fd_i->next=fd;
|
|
|
|
}
|
2001-06-08 06:27:16 +00:00
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
/* copy a fragment key to heap store to insert in the hash */
|
|
|
|
static void *fragment_key_copy(const void *k)
|
|
|
|
{
|
|
|
|
const fragment_key* key = (const fragment_key*) k;
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
fragment_key *new_key = g_slice_new(fragment_key);
|
|
|
|
#else
|
2007-02-21 06:19:03 +00:00
|
|
|
fragment_key *new_key = g_mem_chunk_alloc(fragment_key_chunk);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
2007-02-21 06:19:03 +00:00
|
|
|
|
|
|
|
COPY_ADDRESS(&new_key->src, &key->src);
|
|
|
|
COPY_ADDRESS(&new_key->dst, &key->dst);
|
|
|
|
new_key->id = key->id;
|
|
|
|
return new_key;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* copy a dcerpc fragment key to heap store to insert in the hash */
|
|
|
|
static void *dcerpc_fragment_key_copy(const void *k)
|
|
|
|
{
|
|
|
|
const dcerpc_fragment_key* key = (const dcerpc_fragment_key*) k;
|
2009-10-18 19:46:46 +00:00
|
|
|
|
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
dcerpc_fragment_key *new_key = g_slice_new(dcerpc_fragment_key);
|
|
|
|
#else
|
|
|
|
dcerpc_fragment_key *new_key = g_mem_chunk_alloc(dcerpc_fragment_key_chunk);
|
|
|
|
#endif
|
2007-02-21 06:19:03 +00:00
|
|
|
|
|
|
|
COPY_ADDRESS(&new_key->src, &key->src);
|
|
|
|
COPY_ADDRESS(&new_key->dst, &key->dst);
|
|
|
|
new_key->id = key->id;
|
|
|
|
new_key->act_id = key->act_id;
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
return new_key;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2001-06-08 06:27:16 +00:00
|
|
|
static gint
|
|
|
|
fragment_equal(gconstpointer k1, gconstpointer k2)
|
|
|
|
{
|
2002-12-02 23:43:30 +00:00
|
|
|
const fragment_key* key1 = (const fragment_key*) k1;
|
|
|
|
const fragment_key* key2 = (const fragment_key*) k2;
|
2001-06-08 06:27:16 +00:00
|
|
|
|
2001-09-13 07:56:53 +00:00
|
|
|
/*key.id is the first item to compare since item is most
|
|
|
|
likely to differ between sessions, thus shortcircuiting
|
|
|
|
the comparasion of addresses.
|
|
|
|
*/
|
2009-08-12 19:32:54 +00:00
|
|
|
return ( ( (key1->id == key2->id) &&
|
2001-09-13 07:56:53 +00:00
|
|
|
(ADDRESSES_EQUAL(&key1->src, &key2->src)) &&
|
|
|
|
(ADDRESSES_EQUAL(&key1->dst, &key2->dst))
|
2001-06-08 06:27:16 +00:00
|
|
|
) ?
|
|
|
|
TRUE : FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static guint
|
|
|
|
fragment_hash(gconstpointer k)
|
|
|
|
{
|
2002-12-02 23:43:30 +00:00
|
|
|
const fragment_key* key = (const fragment_key*) k;
|
2001-06-08 06:27:16 +00:00
|
|
|
guint hash_val;
|
2001-11-21 01:21:08 +00:00
|
|
|
/*
|
2001-06-08 06:27:16 +00:00
|
|
|
int i;
|
2001-11-21 01:21:08 +00:00
|
|
|
*/
|
2001-06-08 06:27:16 +00:00
|
|
|
|
|
|
|
hash_val = 0;
|
2001-09-13 07:56:53 +00:00
|
|
|
|
2009-08-12 19:32:54 +00:00
|
|
|
/* More than likely: in most captures src and dst addresses are the
|
2001-09-13 07:56:53 +00:00
|
|
|
same, and would hash the same.
|
|
|
|
We only use id as the hash as an optimization.
|
|
|
|
|
2001-06-08 06:27:16 +00:00
|
|
|
for (i = 0; i < key->src.len; i++)
|
|
|
|
hash_val += key->src.data[i];
|
|
|
|
for (i = 0; i < key->dst.len; i++)
|
|
|
|
hash_val += key->dst.data[i];
|
2001-09-13 07:56:53 +00:00
|
|
|
*/
|
|
|
|
|
2001-06-08 06:27:16 +00:00
|
|
|
hash_val += key->id;
|
|
|
|
|
|
|
|
return hash_val;
|
|
|
|
}
|
|
|
|
|
2004-06-24 07:43:24 +00:00
|
|
|
static gint
|
|
|
|
dcerpc_fragment_equal(gconstpointer k1, gconstpointer k2)
|
|
|
|
{
|
2005-07-24 17:48:10 +00:00
|
|
|
const dcerpc_fragment_key* key1 = (const dcerpc_fragment_key*) k1;
|
|
|
|
const dcerpc_fragment_key* key2 = (const dcerpc_fragment_key*) k2;
|
|
|
|
|
|
|
|
/*key.id is the first item to compare since item is most
|
|
|
|
likely to differ between sessions, thus shortcircuiting
|
2009-07-27 13:59:53 +00:00
|
|
|
the comparison of addresses.
|
2005-07-24 17:48:10 +00:00
|
|
|
*/
|
|
|
|
return (((key1->id == key2->id)
|
2009-08-12 19:32:54 +00:00
|
|
|
&& (ADDRESSES_EQUAL(&key1->src, &key2->src))
|
|
|
|
&& (ADDRESSES_EQUAL(&key1->dst, &key2->dst))
|
|
|
|
&& (memcmp (&key1->act_id, &key2->act_id, sizeof (e_uuid_t)) == 0))
|
|
|
|
? TRUE : FALSE);
|
2004-06-24 07:43:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static guint
|
|
|
|
dcerpc_fragment_hash(gconstpointer k)
|
|
|
|
{
|
2005-07-24 17:48:10 +00:00
|
|
|
const dcerpc_fragment_key* key = (const dcerpc_fragment_key*) k;
|
|
|
|
guint hash_val;
|
2004-06-24 07:43:24 +00:00
|
|
|
|
2005-07-24 17:48:10 +00:00
|
|
|
hash_val = 0;
|
2004-06-24 07:43:24 +00:00
|
|
|
|
2005-07-24 17:48:10 +00:00
|
|
|
hash_val += key->id;
|
|
|
|
hash_val += key->act_id.Data1;
|
|
|
|
hash_val += key->act_id.Data2 << 16;
|
|
|
|
hash_val += key->act_id.Data3;
|
2004-06-24 07:43:24 +00:00
|
|
|
|
2005-07-24 17:48:10 +00:00
|
|
|
return hash_val;
|
2004-06-24 07:43:24 +00:00
|
|
|
}
|
|
|
|
|
2003-06-04 05:41:37 +00:00
|
|
|
typedef struct _reassembled_key {
|
2009-08-12 19:32:54 +00:00
|
|
|
guint32 id;
|
2003-06-04 05:41:37 +00:00
|
|
|
guint32 frame;
|
|
|
|
} reassembled_key;
|
|
|
|
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
static gint
|
|
|
|
reassembled_equal(gconstpointer k1, gconstpointer k2)
|
|
|
|
{
|
2003-06-04 05:41:37 +00:00
|
|
|
const reassembled_key* key1 = (const reassembled_key*) k1;
|
|
|
|
const reassembled_key* key2 = (const reassembled_key*) k2;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We assume that the frame numbers are unlikely to be equal,
|
|
|
|
* so we check them first.
|
|
|
|
*/
|
|
|
|
return key1->frame == key2->frame && key1->id == key2->id;
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static guint
|
|
|
|
reassembled_hash(gconstpointer k)
|
|
|
|
{
|
2003-06-04 05:41:37 +00:00
|
|
|
const reassembled_key* key = (const reassembled_key*) k;
|
|
|
|
|
|
|
|
return key->frame;
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
}
|
|
|
|
|
2001-06-08 06:27:16 +00:00
|
|
|
/*
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
* For a fragment hash table entry, free the address data to which the key
|
|
|
|
* refers and the fragment data to which the value refers.
|
2009-09-06 18:25:23 +00:00
|
|
|
* (The actual key and value structures get freed by "reassemble_cleanup()".)
|
2001-06-08 06:27:16 +00:00
|
|
|
*/
|
|
|
|
static gboolean
|
2002-03-31 21:05:47 +00:00
|
|
|
free_all_fragments(gpointer key_arg, gpointer value, gpointer user_data _U_)
|
2001-06-08 06:27:16 +00:00
|
|
|
{
|
|
|
|
fragment_key *key = key_arg;
|
|
|
|
fragment_data *fd_head;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Grr. I guess the theory here is that freeing
|
|
|
|
* something sure as heck modifies it, so you
|
|
|
|
* want to ban attempts to free it, but, alas,
|
|
|
|
* if we make the "data" field of an "address"
|
|
|
|
* structure not a "const", the compiler whines if
|
|
|
|
* we try to make it point into the data for a packet,
|
|
|
|
* as that's a "const" array (and should be, as dissectors
|
|
|
|
* shouldn't trash it).
|
|
|
|
*
|
|
|
|
* So we cast the complaint into oblivion, and rely on
|
|
|
|
* the fact that these addresses are known to have had
|
|
|
|
* their data mallocated, i.e. they don't point into,
|
|
|
|
* say, the middle of the data for a packet.
|
|
|
|
*/
|
|
|
|
g_free((gpointer)key->src.data);
|
|
|
|
g_free((gpointer)key->dst.data);
|
|
|
|
|
|
|
|
for (fd_head = value; fd_head != NULL; fd_head = fd_head->next) {
|
2002-02-03 23:28:38 +00:00
|
|
|
if(fd_head->data && !(fd_head->flags&FD_NOT_MALLOCED))
|
2001-06-08 06:27:16 +00:00
|
|
|
g_free(fd_head->data);
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2007-11-10 16:08:14 +00:00
|
|
|
/* ------------------------- */
|
|
|
|
static fragment_data *new_head(guint32 flags)
|
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
2008-05-07 17:57:45 +00:00
|
|
|
/* If head/first structure in list only holds no other data than
|
2009-08-12 19:32:54 +00:00
|
|
|
* 'datalen' then we don't have to change the head of the list
|
|
|
|
* even if we want to keep it sorted
|
|
|
|
*/
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
fd_head=g_slice_new0(fragment_data);
|
|
|
|
#else
|
|
|
|
fd_head=g_mem_chunk_alloc0(fragment_data_chunk);
|
|
|
|
#endif
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-11-10 16:08:14 +00:00
|
|
|
fd_head->flags=flags;
|
|
|
|
return fd_head;
|
|
|
|
}
|
|
|
|
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
/*
|
|
|
|
* For a reassembled-packet hash table entry, free the fragment data
|
|
|
|
* to which the value refers.
|
2009-09-06 18:25:23 +00:00
|
|
|
* (The actual value structures get freed by "reassemble_cleanup()".)
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*/
|
|
|
|
static gboolean
|
|
|
|
free_all_reassembled_fragments(gpointer key_arg _U_, gpointer value,
|
2009-08-12 19:32:54 +00:00
|
|
|
gpointer user_data _U_)
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
|
|
|
|
|
|
|
for (fd_head = value; fd_head != NULL; fd_head = fd_head->next) {
|
2003-04-20 08:40:45 +00:00
|
|
|
if(fd_head->data && !(fd_head->flags&FD_NOT_MALLOCED)) {
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
g_free(fd_head->data);
|
2003-04-20 08:40:45 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* A reassembled packet is inserted into the
|
|
|
|
* hash table once for every frame that made
|
|
|
|
* up the reassembled packet; clear the data
|
|
|
|
* pointer so that we only free the data the
|
|
|
|
* first time we see it.
|
|
|
|
*/
|
|
|
|
fd_head->data = NULL;
|
|
|
|
}
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2001-06-08 06:27:16 +00:00
|
|
|
/*
|
|
|
|
* Initialize a fragment table.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
fragment_table_init(GHashTable **fragment_table)
|
|
|
|
{
|
|
|
|
if (*fragment_table != NULL) {
|
|
|
|
/*
|
|
|
|
* The fragment hash table exists.
|
2002-08-28 21:04:11 +00:00
|
|
|
*
|
2001-06-08 06:27:16 +00:00
|
|
|
* Remove all entries and free fragment data for
|
2009-08-12 19:32:54 +00:00
|
|
|
* each entry. (The key and value data is freed
|
2009-09-06 18:25:23 +00:00
|
|
|
* by "reassemble_cleanup()".)
|
2001-06-08 06:27:16 +00:00
|
|
|
*/
|
|
|
|
g_hash_table_foreach_remove(*fragment_table,
|
|
|
|
free_all_fragments, NULL);
|
|
|
|
} else {
|
|
|
|
/* The fragment table does not exist. Create it */
|
|
|
|
*fragment_table = g_hash_table_new(fragment_hash,
|
|
|
|
fragment_equal);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-06-24 07:43:24 +00:00
|
|
|
void
|
|
|
|
dcerpc_fragment_table_init(GHashTable **fragment_table)
|
|
|
|
{
|
2009-08-12 19:32:54 +00:00
|
|
|
if (*fragment_table != NULL) {
|
|
|
|
/*
|
|
|
|
* The fragment hash table exists.
|
|
|
|
*
|
|
|
|
* Remove all entries and free fragment data for
|
|
|
|
* each entry. (The key and value data is freed
|
2009-09-06 18:25:23 +00:00
|
|
|
* by "reassemble_cleanup()".)
|
2009-08-12 19:32:54 +00:00
|
|
|
*/
|
|
|
|
g_hash_table_foreach_remove(*fragment_table,
|
|
|
|
free_all_fragments, NULL);
|
|
|
|
} else {
|
|
|
|
/* The fragment table does not exist. Create it */
|
|
|
|
*fragment_table = g_hash_table_new(dcerpc_fragment_hash,
|
|
|
|
dcerpc_fragment_equal);
|
|
|
|
}
|
2004-06-24 07:43:24 +00:00
|
|
|
}
|
|
|
|
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
/*
|
|
|
|
* Initialize a reassembled-packet table.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
reassembled_table_init(GHashTable **reassembled_table)
|
|
|
|
{
|
|
|
|
if (*reassembled_table != NULL) {
|
|
|
|
/*
|
|
|
|
* The reassembled-packet hash table exists.
|
2002-08-28 21:04:11 +00:00
|
|
|
*
|
2003-06-04 05:41:37 +00:00
|
|
|
* Remove all entries and free reassembled packet
|
|
|
|
* data for each entry. (The key data is freed
|
2009-09-06 18:25:23 +00:00
|
|
|
* by "reassemble_cleanup()".)
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*/
|
|
|
|
g_hash_table_foreach_remove(*reassembled_table,
|
|
|
|
free_all_reassembled_fragments, NULL);
|
|
|
|
} else {
|
|
|
|
/* The fragment table does not exist. Create it */
|
|
|
|
*reassembled_table = g_hash_table_new(reassembled_hash,
|
|
|
|
reassembled_equal);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-06-08 06:27:16 +00:00
|
|
|
/*
|
2003-06-04 05:41:37 +00:00
|
|
|
* Free up all space allocated for fragment keys and data and
|
|
|
|
* reassembled keys.
|
2001-06-08 06:27:16 +00:00
|
|
|
*/
|
|
|
|
void
|
2009-09-06 18:25:23 +00:00
|
|
|
reassemble_cleanup(void)
|
2001-06-08 06:27:16 +00:00
|
|
|
{
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
#else
|
2001-06-08 06:27:16 +00:00
|
|
|
if (fragment_key_chunk != NULL)
|
|
|
|
g_mem_chunk_destroy(fragment_key_chunk);
|
|
|
|
if (fragment_data_chunk != NULL)
|
|
|
|
g_mem_chunk_destroy(fragment_data_chunk);
|
2009-08-16 04:54:33 +00:00
|
|
|
|
2009-09-06 18:25:23 +00:00
|
|
|
fragment_key_chunk = NULL;
|
|
|
|
fragment_data_chunk = NULL;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
reassemble_init(void)
|
|
|
|
{
|
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
#else
|
2001-06-08 06:27:16 +00:00
|
|
|
fragment_key_chunk = g_mem_chunk_new("fragment_key_chunk",
|
2009-08-12 19:32:54 +00:00
|
|
|
sizeof(fragment_key),
|
|
|
|
fragment_init_count * sizeof(fragment_key),
|
|
|
|
G_ALLOC_AND_FREE);
|
2001-06-08 06:27:16 +00:00
|
|
|
fragment_data_chunk = g_mem_chunk_new("fragment_data_chunk",
|
2009-08-12 19:32:54 +00:00
|
|
|
sizeof(fragment_data),
|
|
|
|
fragment_init_count * sizeof(fragment_data),
|
|
|
|
G_ALLOC_ONLY);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
2001-06-08 06:27:16 +00:00
|
|
|
}
|
|
|
|
|
2001-11-24 09:36:40 +00:00
|
|
|
/* This function cleans up the stored state and removes the reassembly data and
|
|
|
|
* (with one exception) all allocated memory for matching reassembly.
|
2002-08-28 21:04:11 +00:00
|
|
|
*
|
2001-11-24 09:36:40 +00:00
|
|
|
* The exception is :
|
2002-08-28 21:04:11 +00:00
|
|
|
* If the PDU was already completely reassembled, then the buffer containing the
|
2001-11-24 09:36:40 +00:00
|
|
|
* reassembled data WILL NOT be free()d, and the pointer to that buffer will be
|
|
|
|
* returned.
|
|
|
|
* Othervise the function will return NULL.
|
|
|
|
*
|
2002-08-28 21:04:11 +00:00
|
|
|
* So, if you call fragment_delete and it returns non-NULL, YOU are responsible to
|
2001-11-24 09:36:40 +00:00
|
|
|
* g_free() that buffer.
|
|
|
|
*/
|
|
|
|
unsigned char *
|
|
|
|
fragment_delete(packet_info *pinfo, guint32 id, GHashTable *fragment_table)
|
|
|
|
{
|
|
|
|
fragment_data *fd_head, *fd;
|
|
|
|
fragment_key key;
|
|
|
|
unsigned char *data=NULL;
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
2001-11-24 09:36:40 +00:00
|
|
|
|
|
|
|
fd_head = g_hash_table_lookup(fragment_table, &key);
|
|
|
|
|
|
|
|
if(fd_head==NULL){
|
2008-05-07 17:57:45 +00:00
|
|
|
/* We do not recognize this as a PDU we have seen before. return */
|
2001-11-24 09:36:40 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
data=fd_head->data;
|
|
|
|
/* loop over all partial fragments and free any buffers */
|
|
|
|
for(fd=fd_head->next;fd;){
|
|
|
|
fragment_data *tmp_fd;
|
|
|
|
tmp_fd=fd->next;
|
|
|
|
|
2002-02-03 23:28:38 +00:00
|
|
|
if( !(fd->flags&FD_NOT_MALLOCED) )
|
|
|
|
g_free(fd->data);
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
g_slice_free(fragment_data, fd);
|
|
|
|
#else
|
2001-11-24 09:36:40 +00:00
|
|
|
g_mem_chunk_free(fragment_data_chunk, fd);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
2001-11-24 09:36:40 +00:00
|
|
|
fd=tmp_fd;
|
|
|
|
}
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
g_slice_free(fragment_data, fd_head);
|
|
|
|
#else
|
2001-11-24 09:36:40 +00:00
|
|
|
g_mem_chunk_free(fragment_data_chunk, fd_head);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
2001-11-24 09:36:40 +00:00
|
|
|
g_hash_table_remove(fragment_table, &key);
|
|
|
|
|
|
|
|
return data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This function is used to check if there is partial or completed reassembly state
|
2008-05-07 17:57:45 +00:00
|
|
|
* matching this packet. I.e. Is there reassembly going on or not for this packet?
|
2001-11-24 09:36:40 +00:00
|
|
|
*/
|
|
|
|
fragment_data *
|
|
|
|
fragment_get(packet_info *pinfo, guint32 id, GHashTable *fragment_table)
|
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
|
|
|
fragment_key key;
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
2001-11-24 09:36:40 +00:00
|
|
|
|
|
|
|
fd_head = g_hash_table_lookup(fragment_table, &key);
|
2002-08-28 21:04:11 +00:00
|
|
|
|
2001-11-24 09:36:40 +00:00
|
|
|
return fd_head;
|
|
|
|
}
|
|
|
|
|
2006-01-22 16:47:16 +00:00
|
|
|
/* id *must* be the frame number for this to work! */
|
2005-09-12 00:16:57 +00:00
|
|
|
fragment_data *
|
2007-02-19 15:30:06 +00:00
|
|
|
fragment_get_reassembled(packet_info *pinfo _U_, guint32 id, GHashTable *reassembled_table)
|
2005-09-12 00:16:57 +00:00
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
|
|
|
reassembled_key key;
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.frame = id;
|
|
|
|
key.id = id;
|
|
|
|
fd_head = g_hash_table_lookup(reassembled_table, &key);
|
|
|
|
|
|
|
|
return fd_head;
|
|
|
|
}
|
|
|
|
|
2006-01-22 16:47:16 +00:00
|
|
|
fragment_data *
|
|
|
|
fragment_get_reassembled_id(packet_info *pinfo, guint32 id, GHashTable *reassembled_table)
|
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
|
|
|
reassembled_key key;
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.frame = pinfo->fd->num;
|
|
|
|
key.id = id;
|
|
|
|
fd_head = g_hash_table_lookup(reassembled_table, &key);
|
|
|
|
|
|
|
|
return fd_head;
|
|
|
|
}
|
|
|
|
|
2008-05-07 17:57:45 +00:00
|
|
|
/* This function can be used to explicitly set the total length (if known)
|
2001-11-24 09:36:40 +00:00
|
|
|
* for reassembly of a PDU.
|
|
|
|
* This is useful for reassembly of PDUs where one may have the total length specified
|
|
|
|
* in the first fragment instead of as for, say, IPv4 where a flag indicates which
|
|
|
|
* is the last fragment.
|
|
|
|
*
|
|
|
|
* Such protocols might fragment_add with a more_frags==TRUE for every fragment
|
|
|
|
* and just tell the reassembly engine the expected total length of the reassembled data
|
|
|
|
* using fragment_set_tot_len immediately after doing fragment_add for the first packet.
|
2001-12-15 05:40:32 +00:00
|
|
|
*
|
2008-05-07 17:57:45 +00:00
|
|
|
* Note that for FD_BLOCKSEQUENCE tot_len is the index for the tail fragment.
|
2002-08-28 21:04:11 +00:00
|
|
|
* i.e. since the block numbers start at 0, if we specify tot_len==2, that
|
2001-12-15 05:40:32 +00:00
|
|
|
* actually means we want to defragment 3 blocks, block 0, 1 and 2.
|
2001-11-24 09:36:40 +00:00
|
|
|
*/
|
|
|
|
void
|
2002-08-28 21:04:11 +00:00
|
|
|
fragment_set_tot_len(packet_info *pinfo, guint32 id, GHashTable *fragment_table,
|
2009-08-12 19:32:54 +00:00
|
|
|
guint32 tot_len)
|
2001-11-24 09:36:40 +00:00
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
|
|
|
fragment_key key;
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
2001-11-24 09:36:40 +00:00
|
|
|
|
|
|
|
fd_head = g_hash_table_lookup(fragment_table, &key);
|
|
|
|
|
|
|
|
if(fd_head){
|
|
|
|
fd_head->datalen = tot_len;
|
2007-02-21 06:19:03 +00:00
|
|
|
fd_head->flags |= FD_DATALEN_SET;
|
2001-11-24 09:36:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2002-05-24 11:51:14 +00:00
|
|
|
guint32
|
|
|
|
fragment_get_tot_len(packet_info *pinfo, guint32 id, GHashTable *fragment_table)
|
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
|
|
|
fragment_key key;
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
2002-05-24 11:51:14 +00:00
|
|
|
|
|
|
|
fd_head = g_hash_table_lookup(fragment_table, &key);
|
|
|
|
|
|
|
|
if(fd_head){
|
|
|
|
return fd_head->datalen;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2002-02-03 23:28:38 +00:00
|
|
|
|
|
|
|
/* This function will set the partial reassembly flag for a fh.
|
|
|
|
When this function is called, the fh MUST already exist, i.e.
|
|
|
|
the fh MUST be created by the initial call to fragment_add() before
|
|
|
|
this function is called.
|
2002-08-28 21:04:11 +00:00
|
|
|
Also note that this function MUST be called to indicate a fh will be
|
2002-02-03 23:28:38 +00:00
|
|
|
extended (increase the already stored data)
|
|
|
|
*/
|
|
|
|
|
|
|
|
void
|
|
|
|
fragment_set_partial_reassembly(packet_info *pinfo, guint32 id, GHashTable *fragment_table)
|
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
|
|
|
fragment_key key;
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
2002-02-03 23:28:38 +00:00
|
|
|
|
|
|
|
fd_head = g_hash_table_lookup(fragment_table, &key);
|
|
|
|
|
2005-07-29 07:14:32 +00:00
|
|
|
/*
|
|
|
|
* XXX - why not do all the stuff done early in "fragment_add_work()",
|
|
|
|
* turning off FD_DEFRAGMENTED and pointing the fragments' data
|
|
|
|
* pointers to the appropriate part of the already-reassembled
|
|
|
|
* data, and clearing the data length and "reassembled in" frame
|
|
|
|
* number, here? We currently have a hack in the TCP dissector
|
|
|
|
* not to set the "reassembled in" value if the "partial reassembly"
|
|
|
|
* flag is set, so that in the first pass through the packets
|
|
|
|
* we don't falsely set a packet as reassembled in that packet
|
|
|
|
* if the dissector decided that even more reassembly was needed.
|
|
|
|
*/
|
2002-02-03 23:28:38 +00:00
|
|
|
if(fd_head){
|
|
|
|
fd_head->flags |= FD_PARTIAL_REASSEMBLY;
|
|
|
|
}
|
|
|
|
}
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
/*
|
|
|
|
* This function gets rid of an entry from a fragment table, given
|
|
|
|
* a pointer to the key for that entry; it also frees up the key
|
|
|
|
* and the addresses in it.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
fragment_unhash(GHashTable *fragment_table, fragment_key *key)
|
|
|
|
{
|
|
|
|
/*
|
2005-04-15 20:15:03 +00:00
|
|
|
* Remove the entry from the fragment table.
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
*/
|
2005-04-15 20:15:03 +00:00
|
|
|
g_hash_table_remove(fragment_table, key);
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
|
|
|
|
/*
|
2005-04-15 20:15:03 +00:00
|
|
|
* Free up the copies of the addresses from the old key.
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
*/
|
2005-04-15 20:15:03 +00:00
|
|
|
g_free((gpointer)key->src.data);
|
|
|
|
g_free((gpointer)key->dst.data);
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Free the key itself.
|
|
|
|
*/
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
g_slice_free(fragment_key, key);
|
|
|
|
#else
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
g_mem_chunk_free(fragment_key_chunk, key);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function adds fragment_data structure to a reassembled-packet
|
2003-04-20 08:40:45 +00:00
|
|
|
* hash table, using the frame numbers of each of the frames from
|
2003-04-20 11:36:16 +00:00
|
|
|
* which it was reassembled as keys, and sets the "reassembled_in"
|
|
|
|
* frame number.
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
*/
|
2003-06-04 05:41:37 +00:00
|
|
|
static void
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
fragment_reassembled(fragment_data *fd_head, packet_info *pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
GHashTable *reassembled_table, guint32 id)
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
{
|
2003-06-04 05:41:37 +00:00
|
|
|
reassembled_key *new_key;
|
2003-04-20 08:40:45 +00:00
|
|
|
fragment_data *fd;
|
|
|
|
|
2003-04-20 11:36:16 +00:00
|
|
|
if (fd_head->next == NULL) {
|
|
|
|
/*
|
|
|
|
* This was not fragmented, so there's no fragment
|
|
|
|
* table; just hash it using the current frame number.
|
|
|
|
*/
|
2005-08-14 01:26:34 +00:00
|
|
|
new_key = se_alloc(sizeof(reassembled_key));
|
2003-06-04 05:41:37 +00:00
|
|
|
new_key->frame = pinfo->fd->num;
|
|
|
|
new_key->id = id;
|
|
|
|
g_hash_table_insert(reassembled_table, new_key, fd_head);
|
2003-04-20 11:36:16 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Hash it with the frame numbers for all the frames.
|
|
|
|
*/
|
|
|
|
for (fd = fd_head->next; fd != NULL; fd = fd->next){
|
2005-08-14 01:26:34 +00:00
|
|
|
new_key = se_alloc(sizeof(reassembled_key));
|
2003-06-04 05:41:37 +00:00
|
|
|
new_key->frame = fd->frame;
|
|
|
|
new_key->id = id;
|
|
|
|
g_hash_table_insert(reassembled_table, new_key,
|
2009-08-12 19:32:54 +00:00
|
|
|
fd_head);
|
2003-04-20 11:36:16 +00:00
|
|
|
}
|
2003-04-20 08:40:45 +00:00
|
|
|
}
|
2003-07-31 21:55:22 +00:00
|
|
|
fd_head->flags |= FD_DEFRAGMENTED;
|
2003-04-20 11:36:16 +00:00
|
|
|
fd_head->reassembled_in = pinfo->fd->num;
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
}
|
|
|
|
|
2001-06-08 06:27:16 +00:00
|
|
|
/*
|
|
|
|
* This function adds a new fragment to the fragment hash table.
|
|
|
|
* If this is the first fragment seen for this datagram, a new entry
|
|
|
|
* is created in the hash table, otherwise this fragment is just added
|
|
|
|
* to the linked list of fragments for this packet.
|
|
|
|
* The list of fragments for a specific datagram is kept sorted for
|
|
|
|
* easier handling.
|
|
|
|
*
|
|
|
|
* Returns a pointer to the head of the fragment data list if we have all the
|
|
|
|
* fragments, NULL otherwise.
|
2001-11-24 09:36:40 +00:00
|
|
|
*
|
2001-12-15 05:40:32 +00:00
|
|
|
* This function assumes frag_offset being a byte offset into the defragment
|
|
|
|
* packet.
|
2002-02-03 23:28:38 +00:00
|
|
|
*
|
|
|
|
* 01-2002
|
|
|
|
* Once the fh is defragmented (= FD_DEFRAGMENTED set), it can be
|
2002-08-28 21:04:11 +00:00
|
|
|
* extended using the FD_PARTIAL_REASSEMBLY flag. This flag should be set
|
2002-02-03 23:28:38 +00:00
|
|
|
* using fragment_set_partial_reassembly() before calling fragment_add
|
|
|
|
* with the new fragment. FD_TOOLONGFRAGMENT and FD_MULTIPLETAILS flags
|
|
|
|
* are lowered when a new extension process is started.
|
2001-06-08 06:27:16 +00:00
|
|
|
*/
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
static gboolean
|
|
|
|
fragment_add_work(fragment_data *fd_head, tvbuff_t *tvb, int offset,
|
2009-08-12 19:32:54 +00:00
|
|
|
packet_info *pinfo, guint32 frag_offset,
|
|
|
|
guint32 frag_data_len, gboolean more_frags)
|
2001-06-08 06:27:16 +00:00
|
|
|
{
|
|
|
|
fragment_data *fd;
|
|
|
|
fragment_data *fd_i;
|
|
|
|
guint32 max, dfpos;
|
2002-02-03 23:28:38 +00:00
|
|
|
unsigned char *old_data;
|
2001-06-08 06:27:16 +00:00
|
|
|
|
|
|
|
/* create new fd describing this fragment */
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
fd = g_slice_new(fragment_data);
|
|
|
|
#else
|
2001-06-08 06:27:16 +00:00
|
|
|
fd = g_mem_chunk_alloc(fragment_data_chunk);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
2001-06-08 06:27:16 +00:00
|
|
|
fd->next = NULL;
|
|
|
|
fd->flags = 0;
|
|
|
|
fd->frame = pinfo->fd->num;
|
2007-11-10 16:08:14 +00:00
|
|
|
if (fd->frame > fd_head->frame)
|
2009-08-12 19:32:54 +00:00
|
|
|
fd_head->frame = fd->frame;
|
2001-06-08 06:27:16 +00:00
|
|
|
fd->offset = frag_offset;
|
|
|
|
fd->len = frag_data_len;
|
|
|
|
fd->data = NULL;
|
|
|
|
|
2002-02-03 23:28:38 +00:00
|
|
|
/*
|
|
|
|
* If it was already defragmented and this new fragment goes beyond
|
|
|
|
* data limits, set flag in already empty fds & point old fds to malloc'ed data.
|
2009-08-12 19:32:54 +00:00
|
|
|
*/
|
2002-02-03 23:28:38 +00:00
|
|
|
if(fd_head->flags & FD_DEFRAGMENTED && (frag_offset+frag_data_len) >= fd_head->datalen &&
|
|
|
|
fd_head->flags & FD_PARTIAL_REASSEMBLY){
|
|
|
|
for(fd_i=fd_head->next; fd_i; fd_i=fd_i->next){
|
|
|
|
if( !fd_i->data ) {
|
|
|
|
fd_i->data = fd_head->data + fd_i->offset;
|
|
|
|
fd_i->flags |= FD_NOT_MALLOCED;
|
|
|
|
}
|
|
|
|
fd_i->flags &= (~FD_TOOLONGFRAGMENT) & (~FD_MULTIPLETAILS);
|
|
|
|
}
|
2007-02-21 06:19:03 +00:00
|
|
|
fd_head->flags &= ~(FD_DEFRAGMENTED|FD_PARTIAL_REASSEMBLY|FD_DATALEN_SET);
|
2002-02-03 23:28:38 +00:00
|
|
|
fd_head->flags &= (~FD_TOOLONGFRAGMENT) & (~FD_MULTIPLETAILS);
|
|
|
|
fd_head->datalen=0;
|
2005-07-29 07:14:32 +00:00
|
|
|
fd_head->reassembled_in=0;
|
2002-02-03 23:28:38 +00:00
|
|
|
}
|
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
if (!more_frags) {
|
2001-06-08 06:27:16 +00:00
|
|
|
/*
|
|
|
|
* This is the tail fragment in the sequence.
|
|
|
|
*/
|
2007-02-21 06:19:03 +00:00
|
|
|
if (fd_head->flags & FD_DATALEN_SET) {
|
2001-06-08 06:27:16 +00:00
|
|
|
/* ok we have already seen other tails for this packet
|
|
|
|
* it might be a duplicate.
|
|
|
|
*/
|
|
|
|
if (fd_head->datalen != (fd->offset + fd->len) ){
|
|
|
|
/* Oops, this tail indicates a different packet
|
2008-05-07 17:57:45 +00:00
|
|
|
* len than the previous ones. Something's wrong.
|
2001-06-08 06:27:16 +00:00
|
|
|
*/
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_MULTIPLETAILS;
|
2001-06-08 06:27:16 +00:00
|
|
|
fd_head->flags |= FD_MULTIPLETAILS;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* this was the first tail fragment, now we know the
|
|
|
|
* length of the packet
|
|
|
|
*/
|
|
|
|
fd_head->datalen = fd->offset + fd->len;
|
2007-02-21 06:19:03 +00:00
|
|
|
fd_head->flags |= FD_DATALEN_SET;
|
2001-06-08 06:27:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* If the packet is already defragmented, this MUST be an overlap.
|
2008-05-07 17:57:45 +00:00
|
|
|
* The entire defragmented packet is in fd_head->data.
|
|
|
|
* Even if we have previously defragmented this packet, we still
|
2001-06-08 06:27:16 +00:00
|
|
|
* check it. Someone might play overlap and TTL games.
|
2008-05-07 17:57:45 +00:00
|
|
|
*/
|
2001-06-08 06:27:16 +00:00
|
|
|
if (fd_head->flags & FD_DEFRAGMENTED) {
|
2009-07-16 22:25:06 +00:00
|
|
|
guint32 end_offset = fd->offset + fd->len;
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_OVERLAP;
|
2001-06-08 06:27:16 +00:00
|
|
|
fd_head->flags |= FD_OVERLAP;
|
2008-05-07 17:57:45 +00:00
|
|
|
/* make sure it's not too long */
|
2009-07-16 22:25:06 +00:00
|
|
|
if (end_offset > fd_head->datalen || end_offset < fd->offset || end_offset < fd->len) {
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_TOOLONGFRAGMENT;
|
2001-06-08 06:27:16 +00:00
|
|
|
fd_head->flags |= FD_TOOLONGFRAGMENT;
|
|
|
|
}
|
2008-05-07 17:57:45 +00:00
|
|
|
/* make sure it doesn't conflict with previous data */
|
2007-11-10 16:08:14 +00:00
|
|
|
else if ( memcmp(fd_head->data+fd->offset,
|
2001-06-08 06:27:16 +00:00
|
|
|
tvb_get_ptr(tvb,offset,fd->len),fd->len) ){
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_OVERLAPCONFLICT;
|
2001-06-08 06:27:16 +00:00
|
|
|
fd_head->flags |= FD_OVERLAPCONFLICT;
|
|
|
|
}
|
|
|
|
/* it was just an overlap, link it and return */
|
|
|
|
LINK_FRAG(fd_head,fd);
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
return TRUE;
|
2001-06-08 06:27:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* If we have reached this point, the packet is not defragmented yet.
|
2009-08-12 19:32:54 +00:00
|
|
|
* Save all payload in a buffer until we can defragment.
|
2001-06-08 06:27:16 +00:00
|
|
|
* XXX - what if we didn't capture the entire fragment due
|
|
|
|
* to a too-short snapshot length?
|
|
|
|
*/
|
|
|
|
fd->data = g_malloc(fd->len);
|
|
|
|
tvb_memcpy(tvb, fd->data, offset, fd->len);
|
|
|
|
LINK_FRAG(fd_head,fd);
|
|
|
|
|
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
if( !(fd_head->flags & FD_DATALEN_SET) ){
|
2001-06-08 06:27:16 +00:00
|
|
|
/* if we dont know the datalen, there are still missing
|
|
|
|
* packets. Cheaper than the check below.
|
|
|
|
*/
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
return FALSE;
|
2001-06-08 06:27:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
/*
|
|
|
|
* Check if we have received the entire fragment.
|
|
|
|
* This is easy since the list is sorted and the head is faked.
|
|
|
|
*
|
|
|
|
* First, we compute the amount of contiguous data that's
|
|
|
|
* available. (The check for fd_i->offset <= max rules out
|
|
|
|
* fragments that don't start before or at the end of the
|
|
|
|
* previous fragment, i.e. fragments that have a gap between
|
|
|
|
* them and the previous fragment.)
|
2001-06-08 06:27:16 +00:00
|
|
|
*/
|
|
|
|
max = 0;
|
|
|
|
for (fd_i=fd_head->next;fd_i;fd_i=fd_i->next) {
|
2002-08-28 21:04:11 +00:00
|
|
|
if ( ((fd_i->offset)<=max) &&
|
2009-08-12 19:32:54 +00:00
|
|
|
((fd_i->offset+fd_i->len)>max) ){
|
2001-06-08 06:27:16 +00:00
|
|
|
max = fd_i->offset+fd_i->len;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (max < (fd_head->datalen)) {
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
/*
|
|
|
|
* The amount of contiguous data we have is less than the
|
|
|
|
* amount of data we're trying to reassemble, so we haven't
|
|
|
|
* received all packets yet.
|
|
|
|
*/
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
return FALSE;
|
2001-06-08 06:27:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (max > (fd_head->datalen)) {
|
2002-02-03 23:28:38 +00:00
|
|
|
/*XXX not sure if current fd was the TOOLONG*/
|
|
|
|
/*XXX is it fair to flag current fd*/
|
2001-06-08 06:27:16 +00:00
|
|
|
/* oops, too long fragment detected */
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_TOOLONGFRAGMENT;
|
2001-06-08 06:27:16 +00:00
|
|
|
fd_head->flags |= FD_TOOLONGFRAGMENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* we have received an entire packet, defragment it and
|
2009-08-12 19:32:54 +00:00
|
|
|
* free all fragments
|
|
|
|
*/
|
2002-02-03 23:28:38 +00:00
|
|
|
/* store old data just in case */
|
|
|
|
old_data=fd_head->data;
|
2001-06-08 06:27:16 +00:00
|
|
|
fd_head->data = g_malloc(max);
|
|
|
|
|
|
|
|
/* add all data fragments */
|
|
|
|
for (dfpos=0,fd_i=fd_head;fd_i;fd_i=fd_i->next) {
|
|
|
|
if (fd_i->len) {
|
2002-02-03 23:28:38 +00:00
|
|
|
/* dfpos is always >= than fd_i->offset */
|
|
|
|
/* No gaps can exist here, max_loop(above) does this */
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
/* XXX - true? Can we get fd_i->offset+fd-i->len */
|
|
|
|
/* overflowing, for example? */
|
2009-08-12 19:32:54 +00:00
|
|
|
/* Actually: there is at least one pathological case wherein there can be fragments
|
|
|
|
on the list which are for offsets greater than max (i.e.: following a gap after max).
|
|
|
|
(Apparently a "DESEGMENT_UNTIL_FIN" was involved wherein the FIN packet had an offset
|
|
|
|
less than the highest fragment offset seen. [Seen from a fuzz-test: bug #2470]).
|
|
|
|
Note that the "overlap" compare must only be done for fragments with (offset+len) <= max
|
|
|
|
and thus within the newly g_malloc'd buffer.
|
2008-05-21 16:53:07 +00:00
|
|
|
*/
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2008-05-21 16:53:07 +00:00
|
|
|
if ( fd_i->offset+fd_i->len > dfpos ) {
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
if (fd_i->offset+fd_i->len > max)
|
|
|
|
g_warning("Reassemble error in frame %u: offset %u + len %u > max %u",
|
2009-08-12 19:32:54 +00:00
|
|
|
pinfo->fd->num, fd_i->offset,
|
|
|
|
fd_i->len, max);
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
else if (dfpos < fd_i->offset)
|
|
|
|
g_warning("Reassemble error in frame %u: dfpos %u < offset %u",
|
2009-08-12 19:32:54 +00:00
|
|
|
pinfo->fd->num, dfpos, fd_i->offset);
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
else if (dfpos-fd_i->offset > fd_i->len)
|
|
|
|
g_warning("Reassemble error in frame %u: dfpos %u - offset %u > len %u",
|
2009-08-12 19:32:54 +00:00
|
|
|
pinfo->fd->num, dfpos, fd_i->offset,
|
|
|
|
fd_i->len);
|
2008-05-21 16:53:07 +00:00
|
|
|
else {
|
|
|
|
if (fd_i->offset < dfpos) {
|
|
|
|
fd_i->flags |= FD_OVERLAP;
|
|
|
|
fd_head->flags |= FD_OVERLAP;
|
|
|
|
if ( memcmp(fd_head->data+fd_i->offset,
|
2009-08-12 19:32:54 +00:00
|
|
|
fd_i->data,
|
|
|
|
MIN(fd_i->len,(dfpos-fd_i->offset))
|
|
|
|
) ) {
|
2008-05-21 16:53:07 +00:00
|
|
|
fd_i->flags |= FD_OVERLAPCONFLICT;
|
|
|
|
fd_head->flags |= FD_OVERLAPCONFLICT;
|
|
|
|
}
|
|
|
|
}
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
memcpy(fd_head->data+dfpos,
|
2009-08-12 19:32:54 +00:00
|
|
|
fd_i->data+(dfpos-fd_i->offset),
|
|
|
|
fd_i->len-(dfpos-fd_i->offset));
|
2008-05-21 16:53:07 +00:00
|
|
|
}
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
} else {
|
|
|
|
if (fd_i->offset+fd_i->len < fd_i->offset)
|
|
|
|
g_warning("Reassemble error in frame %u: offset %u + len %u < offset",
|
2009-08-12 19:32:54 +00:00
|
|
|
pinfo->fd->num, fd_i->offset,
|
|
|
|
fd_i->len);
|
When reassembling a packet, all data, including data with
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
2005-07-25 18:03:19 +00:00
|
|
|
}
|
|
|
|
if( fd_i->flags & FD_NOT_MALLOCED )
|
|
|
|
fd_i->flags &= ~FD_NOT_MALLOCED;
|
|
|
|
else
|
|
|
|
g_free(fd_i->data);
|
2001-06-08 06:27:16 +00:00
|
|
|
fd_i->data=NULL;
|
|
|
|
|
|
|
|
dfpos=MAX(dfpos,(fd_i->offset+fd_i->len));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-03-13 22:06:48 +00:00
|
|
|
g_free(old_data);
|
2001-06-08 06:27:16 +00:00
|
|
|
/* mark this packet as defragmented.
|
2009-08-12 19:32:54 +00:00
|
|
|
allows us to skip any trailing fragments */
|
2001-06-08 06:27:16 +00:00
|
|
|
fd_head->flags |= FD_DEFRAGMENTED;
|
2003-04-09 09:04:08 +00:00
|
|
|
fd_head->reassembled_in=pinfo->fd->num;
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2005-07-24 17:48:10 +00:00
|
|
|
static fragment_data *
|
2003-04-20 00:27:29 +00:00
|
|
|
fragment_add_common(tvbuff_t *tvb, int offset, packet_info *pinfo, guint32 id,
|
2009-08-12 19:32:54 +00:00
|
|
|
GHashTable *fragment_table, guint32 frag_offset,
|
|
|
|
guint32 frag_data_len, gboolean more_frags,
|
|
|
|
gboolean check_already_added)
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
{
|
|
|
|
fragment_key key, *new_key;
|
|
|
|
fragment_data *fd_head;
|
|
|
|
fragment_data *fd_item;
|
|
|
|
gboolean already_added=pinfo->fd->flags.visited;
|
|
|
|
|
2006-01-22 16:47:16 +00:00
|
|
|
|
2006-11-21 21:49:58 +00:00
|
|
|
/* dissector shouldn't give us garbage tvb info */
|
|
|
|
DISSECTOR_ASSERT(tvb_bytes_exist(tvb, offset, frag_data_len));
|
2006-01-22 16:47:16 +00:00
|
|
|
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
|
|
|
|
fd_head = g_hash_table_lookup(fragment_table, &key);
|
|
|
|
|
2005-09-10 15:11:21 +00:00
|
|
|
#if 0
|
|
|
|
/* debug output of associated fragments. */
|
|
|
|
/* leave it here for future debugging sessions */
|
|
|
|
if(strcmp(pinfo->current_proto, "DCERPC") == 0) {
|
2009-08-12 19:32:54 +00:00
|
|
|
printf("proto:%s num:%u id:%u offset:%u len:%u more:%u visited:%u\n",
|
2005-09-10 15:11:21 +00:00
|
|
|
pinfo->current_proto, pinfo->fd->num, id, frag_offset, frag_data_len, more_frags, pinfo->fd->flags.visited);
|
|
|
|
if(fd_head != NULL) {
|
|
|
|
for(fd_item=fd_head->next;fd_item;fd_item=fd_item->next){
|
2009-08-12 19:32:54 +00:00
|
|
|
printf("fd_frame:%u fd_offset:%u len:%u datalen:%u\n",
|
2005-09-10 15:11:21 +00:00
|
|
|
fd_item->frame, fd_item->offset, fd_item->len, fd_item->datalen);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
/*
|
|
|
|
* "already_added" is true if "pinfo->fd->flags.visited" is true;
|
|
|
|
* if "pinfo->fd->flags.visited", this isn't the first pass, so
|
|
|
|
* we've already done all the reassembly and added all the
|
|
|
|
* fragments.
|
|
|
|
*
|
2003-04-20 00:27:29 +00:00
|
|
|
* If it's not true, but "check_already_added" is true, just check
|
|
|
|
* if we have seen this fragment before, i.e., if we have already
|
|
|
|
* added it to reassembly.
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
* That can be true even if "pinfo->fd->flags.visited" is false
|
|
|
|
* since we sometimes might call a subdissector multiple times.
|
2009-08-12 19:32:54 +00:00
|
|
|
* As an additional check, just make sure we have not already added
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
* this frame to the reassembly list, if there is a reassembly list;
|
|
|
|
* note that the first item in the reassembly list is not a
|
|
|
|
* fragment, it's a data structure for the reassembled packet.
|
|
|
|
* We don't check it because its "frame" member isn't initialized
|
|
|
|
* to anything, and because it doesn't count in any case.
|
2005-09-10 15:11:21 +00:00
|
|
|
*
|
|
|
|
* And as another additional check, make sure the fragment offsets are
|
|
|
|
* the same, as otherwise we get into trouble if multiple fragments
|
|
|
|
* are in one PDU.
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
*/
|
2003-04-20 00:27:29 +00:00
|
|
|
if (!already_added && check_already_added && fd_head != NULL) {
|
2007-11-10 16:08:14 +00:00
|
|
|
if (pinfo->fd->num <= fd_head->frame) {
|
|
|
|
for(fd_item=fd_head->next;fd_item;fd_item=fd_item->next){
|
|
|
|
if(pinfo->fd->num==fd_item->frame && frag_offset==fd_item->offset){
|
|
|
|
already_added=TRUE;
|
|
|
|
}
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* have we already added this frame ?*/
|
|
|
|
if (already_added) {
|
|
|
|
if (fd_head != NULL && fd_head->flags & FD_DEFRAGMENTED) {
|
|
|
|
return fd_head;
|
|
|
|
} else {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fd_head==NULL){
|
|
|
|
/* not found, this must be the first snooped fragment for this
|
2009-08-12 19:32:54 +00:00
|
|
|
* packet. Create list-head.
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
*/
|
2007-11-10 16:08:14 +00:00
|
|
|
fd_head = new_head(0);
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We're going to use the key to insert the fragment,
|
|
|
|
* so allocate a structure for it, and copy the
|
|
|
|
* addresses, allocating new buffers for the address
|
|
|
|
* data.
|
|
|
|
*/
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
new_key = g_slice_new(fragment_key);
|
|
|
|
#else
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
new_key = g_mem_chunk_alloc(fragment_key_chunk);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
COPY_ADDRESS(&new_key->src, &key.src);
|
|
|
|
COPY_ADDRESS(&new_key->dst, &key.dst);
|
|
|
|
new_key->id = key.id;
|
|
|
|
g_hash_table_insert(fragment_table, new_key, fd_head);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fragment_add_work(fd_head, tvb, offset, pinfo, frag_offset,
|
2009-08-12 19:32:54 +00:00
|
|
|
frag_data_len, more_frags)) {
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
/*
|
|
|
|
* Reassembly is complete.
|
|
|
|
*/
|
|
|
|
return fd_head;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Reassembly isn't complete.
|
|
|
|
*/
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-04-20 00:27:29 +00:00
|
|
|
fragment_data *
|
|
|
|
fragment_add(tvbuff_t *tvb, int offset, packet_info *pinfo, guint32 id,
|
2009-08-12 19:32:54 +00:00
|
|
|
GHashTable *fragment_table, guint32 frag_offset,
|
|
|
|
guint32 frag_data_len, gboolean more_frags)
|
2003-04-20 00:27:29 +00:00
|
|
|
{
|
|
|
|
return fragment_add_common(tvb, offset, pinfo, id, fragment_table,
|
2009-08-12 19:32:54 +00:00
|
|
|
frag_offset, frag_data_len, more_frags, TRUE);
|
2003-04-20 00:27:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For use when you can have multiple fragments in the same frame added
|
|
|
|
* to the same reassembled PDU, e.g. with ONC RPC-over-TCP.
|
|
|
|
*/
|
|
|
|
fragment_data *
|
|
|
|
fragment_add_multiple_ok(tvbuff_t *tvb, int offset, packet_info *pinfo,
|
|
|
|
guint32 id, GHashTable *fragment_table,
|
|
|
|
guint32 frag_offset, guint32 frag_data_len,
|
|
|
|
gboolean more_frags)
|
|
|
|
{
|
|
|
|
return fragment_add_common(tvb, offset, pinfo, id, fragment_table,
|
2009-08-12 19:32:54 +00:00
|
|
|
frag_offset, frag_data_len, more_frags, FALSE);
|
2003-04-20 00:27:29 +00:00
|
|
|
}
|
|
|
|
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
fragment_data *
|
|
|
|
fragment_add_check(tvbuff_t *tvb, int offset, packet_info *pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
guint32 id, GHashTable *fragment_table,
|
|
|
|
GHashTable *reassembled_table, guint32 frag_offset,
|
|
|
|
guint32 frag_data_len, gboolean more_frags)
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
{
|
2003-06-04 05:41:37 +00:00
|
|
|
reassembled_key reass_key;
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
fragment_key key, *new_key, *old_key;
|
|
|
|
gpointer orig_key, value;
|
|
|
|
fragment_data *fd_head;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this isn't the first pass, look for this frame in the table
|
|
|
|
* of reassembled packets.
|
|
|
|
*/
|
2003-06-04 05:41:37 +00:00
|
|
|
if (pinfo->fd->flags.visited) {
|
|
|
|
reass_key.frame = pinfo->fd->num;
|
|
|
|
reass_key.id = id;
|
|
|
|
return g_hash_table_lookup(reassembled_table, &reass_key);
|
|
|
|
}
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
|
|
|
|
if (!g_hash_table_lookup_extended(fragment_table, &key,
|
|
|
|
&orig_key, &value)) {
|
|
|
|
/* not found, this must be the first snooped fragment for this
|
2009-08-12 19:32:54 +00:00
|
|
|
* packet. Create list-head.
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
*/
|
2007-11-10 16:08:14 +00:00
|
|
|
fd_head = new_head(0);
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We're going to use the key to insert the fragment,
|
|
|
|
* so allocate a structure for it, and copy the
|
|
|
|
* addresses, allocating new buffers for the address
|
|
|
|
* data.
|
|
|
|
*/
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
new_key = g_slice_new(fragment_key);
|
|
|
|
#else
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
new_key = g_mem_chunk_alloc(fragment_key_chunk);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
COPY_ADDRESS(&new_key->src, &key.src);
|
|
|
|
COPY_ADDRESS(&new_key->dst, &key.dst);
|
|
|
|
new_key->id = key.id;
|
|
|
|
g_hash_table_insert(fragment_table, new_key, fd_head);
|
|
|
|
|
2009-08-12 19:32:54 +00:00
|
|
|
orig_key = new_key; /* for unhashing it later */
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* We found it.
|
|
|
|
*/
|
|
|
|
fd_head = value;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this is a short frame, then we can't, and don't, do
|
|
|
|
* reassembly on it. We just give up.
|
|
|
|
*/
|
|
|
|
if (tvb_reported_length(tvb) > tvb_length(tvb))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (fragment_add_work(fd_head, tvb, offset, pinfo, frag_offset,
|
2009-08-12 19:32:54 +00:00
|
|
|
frag_data_len, more_frags)) {
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
/*
|
|
|
|
* Reassembly is complete.
|
|
|
|
* Remove this from the table of in-progress
|
|
|
|
* reassemblies, add it to the table of
|
|
|
|
* reassembled packets, and return it.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove this from the table of in-progress reassemblies,
|
|
|
|
* and free up any memory used for it in that table.
|
|
|
|
*/
|
|
|
|
old_key = orig_key;
|
|
|
|
fragment_unhash(fragment_table, old_key);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add this item to the table of reassembled packets.
|
|
|
|
*/
|
2003-06-04 05:41:37 +00:00
|
|
|
fragment_reassembled(fd_head, pinfo, reassembled_table, id);
|
We can't use the frame_data structure as a key structure when looking
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
2003-04-20 00:11:28 +00:00
|
|
|
return fd_head;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Reassembly isn't complete.
|
|
|
|
*/
|
|
|
|
return NULL;
|
|
|
|
}
|
2001-06-08 06:27:16 +00:00
|
|
|
}
|
2001-12-15 05:40:32 +00:00
|
|
|
|
2007-06-24 05:14:39 +00:00
|
|
|
static void
|
|
|
|
fragment_defragment_and_free (fragment_data *fd_head, fragment_data *fd,
|
2009-08-12 19:32:54 +00:00
|
|
|
packet_info *pinfo)
|
2007-06-24 05:14:39 +00:00
|
|
|
{
|
|
|
|
fragment_data *fd_i = NULL;
|
|
|
|
fragment_data *last_fd = NULL;
|
|
|
|
guint32 dfpos = 0, size = 0;
|
|
|
|
void *old_data = NULL;
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-06-24 05:14:39 +00:00
|
|
|
for(fd_i=fd_head->next;fd_i;fd_i=fd_i->next) {
|
|
|
|
if(!last_fd || last_fd->offset!=fd_i->offset){
|
|
|
|
size+=fd_i->len;
|
|
|
|
}
|
|
|
|
last_fd=fd_i;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* store old data in case the fd_i->data pointers refer to it */
|
|
|
|
old_data=fd_head->data;
|
|
|
|
fd_head->data = g_malloc(size);
|
|
|
|
fd_head->len = size; /* record size for caller */
|
|
|
|
|
|
|
|
/* add all data fragments */
|
|
|
|
last_fd=NULL;
|
|
|
|
for (fd_i=fd_head->next;fd_i && fd_i->len + dfpos <= size;fd_i=fd_i->next) {
|
|
|
|
if (fd_i->len) {
|
|
|
|
if(!last_fd || last_fd->offset!=fd_i->offset){
|
|
|
|
memcpy(fd_head->data+dfpos,fd_i->data,fd_i->len);
|
|
|
|
dfpos += fd_i->len;
|
|
|
|
} else {
|
|
|
|
/* duplicate/retransmission/overlap */
|
|
|
|
fd_i->flags |= FD_OVERLAP;
|
|
|
|
fd_head->flags |= FD_OVERLAP;
|
|
|
|
if( (last_fd->len!=fd_i->len)
|
2009-08-12 19:32:54 +00:00
|
|
|
|| memcmp(last_fd->data, fd_i->data, last_fd->len) ) {
|
2007-06-24 05:14:39 +00:00
|
|
|
if (fd) {
|
|
|
|
fd->flags |= FD_OVERLAPCONFLICT;
|
|
|
|
}
|
|
|
|
fd_head->flags |= FD_OVERLAPCONFLICT;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
last_fd=fd_i;
|
|
|
|
}
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-06-24 05:14:39 +00:00
|
|
|
/* we have defragmented the pdu, now free all fragments*/
|
|
|
|
for (fd_i=fd_head->next;fd_i;fd_i=fd_i->next) {
|
|
|
|
if( fd_i->flags & FD_NOT_MALLOCED )
|
|
|
|
fd_i->flags &= ~FD_NOT_MALLOCED;
|
|
|
|
else
|
|
|
|
g_free(fd_i->data);
|
|
|
|
fd_i->data=NULL;
|
|
|
|
}
|
2009-03-13 22:06:48 +00:00
|
|
|
g_free(old_data);
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-06-24 05:14:39 +00:00
|
|
|
/* mark this packet as defragmented.
|
2009-08-12 19:32:54 +00:00
|
|
|
allows us to skip any trailing fragments */
|
2007-06-24 05:14:39 +00:00
|
|
|
fd_head->flags |= FD_DEFRAGMENTED;
|
|
|
|
fd_head->reassembled_in=pinfo->fd->num;
|
|
|
|
}
|
|
|
|
|
2001-12-15 05:40:32 +00:00
|
|
|
/*
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
* This function adds a new fragment to the entry for a reassembly
|
|
|
|
* operation.
|
|
|
|
*
|
2001-12-15 05:40:32 +00:00
|
|
|
* The list of fragments for a specific datagram is kept sorted for
|
|
|
|
* easier handling.
|
|
|
|
*
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
* Returns TRUE if we have all the fragments, FALSE otherwise.
|
2001-12-15 05:40:32 +00:00
|
|
|
*
|
2002-04-17 04:54:30 +00:00
|
|
|
* This function assumes frag_number being a block sequence number.
|
|
|
|
* The bsn for the first block is 0.
|
2001-12-15 05:40:32 +00:00
|
|
|
*/
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
static gboolean
|
|
|
|
fragment_add_seq_work(fragment_data *fd_head, tvbuff_t *tvb, int offset,
|
2009-08-12 19:32:54 +00:00
|
|
|
packet_info *pinfo, guint32 frag_number,
|
|
|
|
guint32 frag_data_len, gboolean more_frags,
|
|
|
|
guint32 flags _U_)
|
2001-12-15 05:40:32 +00:00
|
|
|
{
|
|
|
|
fragment_data *fd;
|
|
|
|
fragment_data *fd_i;
|
|
|
|
fragment_data *last_fd;
|
2007-06-24 05:14:39 +00:00
|
|
|
guint32 max, dfpos;
|
2007-02-21 06:19:03 +00:00
|
|
|
|
|
|
|
/* if the partial reassembly flag has been set, and we are extending
|
|
|
|
* the pdu, un-reassemble the pdu. This means pointing old fds to malloc'ed data.
|
|
|
|
*/
|
|
|
|
if(fd_head->flags & FD_DEFRAGMENTED && frag_number >= fd_head->datalen &&
|
|
|
|
fd_head->flags & FD_PARTIAL_REASSEMBLY){
|
|
|
|
guint32 lastdfpos = 0;
|
|
|
|
dfpos = 0;
|
|
|
|
for(fd_i=fd_head->next; fd_i; fd_i=fd_i->next){
|
|
|
|
if( !fd_i->data ) {
|
|
|
|
if( fd_i->flags & FD_OVERLAP ) {
|
|
|
|
/* this is a duplicate of the previous
|
|
|
|
* fragment. */
|
|
|
|
fd_i->data = fd_head->data + lastdfpos;
|
|
|
|
} else {
|
|
|
|
fd_i->data = fd_head->data + dfpos;
|
|
|
|
lastdfpos = dfpos;
|
|
|
|
dfpos += fd_i->len;
|
|
|
|
}
|
|
|
|
fd_i->flags |= FD_NOT_MALLOCED;
|
|
|
|
}
|
|
|
|
fd_i->flags &= (~FD_TOOLONGFRAGMENT) & (~FD_MULTIPLETAILS);
|
|
|
|
}
|
|
|
|
fd_head->flags &= ~(FD_DEFRAGMENTED|FD_PARTIAL_REASSEMBLY|FD_DATALEN_SET);
|
|
|
|
fd_head->flags &= (~FD_TOOLONGFRAGMENT) & (~FD_MULTIPLETAILS);
|
|
|
|
fd_head->datalen=0;
|
|
|
|
fd_head->reassembled_in=0;
|
|
|
|
}
|
|
|
|
|
2001-12-15 05:40:32 +00:00
|
|
|
|
|
|
|
/* create new fd describing this fragment */
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
fd = g_slice_new(fragment_data);
|
|
|
|
#else
|
2001-12-15 05:40:32 +00:00
|
|
|
fd = g_mem_chunk_alloc(fragment_data_chunk);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
2001-12-15 05:40:32 +00:00
|
|
|
fd->next = NULL;
|
|
|
|
fd->flags = 0;
|
|
|
|
fd->frame = pinfo->fd->num;
|
2002-04-17 04:54:30 +00:00
|
|
|
fd->offset = frag_number;
|
2001-12-15 05:40:32 +00:00
|
|
|
fd->len = frag_data_len;
|
|
|
|
fd->data = NULL;
|
|
|
|
|
2002-08-28 21:04:11 +00:00
|
|
|
if (!more_frags) {
|
2001-12-15 05:40:32 +00:00
|
|
|
/*
|
|
|
|
* This is the tail fragment in the sequence.
|
|
|
|
*/
|
2007-02-21 06:19:03 +00:00
|
|
|
if (fd_head->flags&FD_DATALEN_SET) {
|
2001-12-15 05:40:32 +00:00
|
|
|
/* ok we have already seen other tails for this packet
|
|
|
|
* it might be a duplicate.
|
|
|
|
*/
|
|
|
|
if (fd_head->datalen != fd->offset ){
|
|
|
|
/* Oops, this tail indicates a different packet
|
2008-05-07 17:57:45 +00:00
|
|
|
* len than the previous ones. Something's wrong.
|
2001-12-15 05:40:32 +00:00
|
|
|
*/
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_MULTIPLETAILS;
|
2001-12-15 05:40:32 +00:00
|
|
|
fd_head->flags |= FD_MULTIPLETAILS;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* this was the first tail fragment, now we know the
|
2003-04-30 22:13:05 +00:00
|
|
|
* sequence number of that fragment (which is NOT
|
|
|
|
* the length of the packet!)
|
2001-12-15 05:40:32 +00:00
|
|
|
*/
|
|
|
|
fd_head->datalen = fd->offset;
|
2007-02-21 06:19:03 +00:00
|
|
|
fd_head->flags |= FD_DATALEN_SET;
|
2001-12-15 05:40:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If the packet is already defragmented, this MUST be an overlap.
|
2009-08-12 19:32:54 +00:00
|
|
|
* The entire defragmented packet is in fd_head->data
|
2001-12-15 05:40:32 +00:00
|
|
|
* Even if we have previously defragmented this packet, we still check
|
|
|
|
* check it. Someone might play overlap and TTL games.
|
2009-08-12 19:32:54 +00:00
|
|
|
*/
|
2001-12-15 05:40:32 +00:00
|
|
|
if (fd_head->flags & FD_DEFRAGMENTED) {
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_OVERLAP;
|
2001-12-15 05:40:32 +00:00
|
|
|
fd_head->flags |= FD_OVERLAP;
|
|
|
|
|
2003-04-30 22:13:05 +00:00
|
|
|
/* make sure it's not past the end */
|
2001-12-15 05:40:32 +00:00
|
|
|
if (fd->offset > fd_head->datalen) {
|
2003-04-30 22:13:05 +00:00
|
|
|
/* new fragment comes after the end */
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_TOOLONGFRAGMENT;
|
2001-12-15 05:40:32 +00:00
|
|
|
fd_head->flags |= FD_TOOLONGFRAGMENT;
|
|
|
|
LINK_FRAG(fd_head,fd);
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
return TRUE;
|
2001-12-15 05:40:32 +00:00
|
|
|
}
|
2008-05-07 17:57:45 +00:00
|
|
|
/* make sure it doesn't conflict with previous data */
|
2001-12-15 05:40:32 +00:00
|
|
|
dfpos=0;
|
2002-10-17 20:51:35 +00:00
|
|
|
last_fd=NULL;
|
2006-01-15 15:01:14 +00:00
|
|
|
for (fd_i=fd_head->next;fd_i && (fd_i->offset!=fd->offset);fd_i=fd_i->next) {
|
2002-10-17 20:51:35 +00:00
|
|
|
if (!last_fd || last_fd->offset!=fd_i->offset){
|
2009-08-12 19:32:54 +00:00
|
|
|
dfpos += fd_i->len;
|
2002-10-17 20:51:35 +00:00
|
|
|
}
|
|
|
|
last_fd=fd_i;
|
2001-12-15 05:40:32 +00:00
|
|
|
}
|
2003-04-30 22:13:05 +00:00
|
|
|
if(fd_i){
|
|
|
|
/* new fragment overlaps existing fragment */
|
|
|
|
if(fd_i->len!=fd->len){
|
|
|
|
/*
|
|
|
|
* They have different lengths; this
|
|
|
|
* is definitely a conflict.
|
|
|
|
*/
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_OVERLAPCONFLICT;
|
2003-04-30 22:13:05 +00:00
|
|
|
fd_head->flags |= FD_OVERLAPCONFLICT;
|
|
|
|
LINK_FRAG(fd_head,fd);
|
|
|
|
return TRUE;
|
|
|
|
}
|
2005-03-23 00:09:12 +00:00
|
|
|
DISSECTOR_ASSERT(fd_head->len >= dfpos + fd->len);
|
2003-04-30 22:13:05 +00:00
|
|
|
if ( memcmp(fd_head->data+dfpos,
|
2009-08-12 19:32:54 +00:00
|
|
|
tvb_get_ptr(tvb,offset,fd->len),fd->len) ){
|
2003-04-30 22:13:05 +00:00
|
|
|
/*
|
|
|
|
* They have the same length, but the
|
|
|
|
* data isn't the same.
|
|
|
|
*/
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_OVERLAPCONFLICT;
|
2003-04-30 22:13:05 +00:00
|
|
|
fd_head->flags |= FD_OVERLAPCONFLICT;
|
|
|
|
LINK_FRAG(fd_head,fd);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
/* it was just an overlap, link it and return */
|
2001-12-15 05:40:32 +00:00
|
|
|
LINK_FRAG(fd_head,fd);
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
return TRUE;
|
2003-04-30 22:13:05 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* New fragment doesn't overlap an existing
|
|
|
|
* fragment - there was presumably a gap in
|
|
|
|
* the sequence number space.
|
|
|
|
*
|
|
|
|
* XXX - what should we do here? Is it always
|
|
|
|
* the case that there are no gaps, or are there
|
|
|
|
* protcols using sequence numbers where there
|
|
|
|
* can be gaps?
|
|
|
|
*
|
|
|
|
* If the former, the check below for having
|
|
|
|
* received all the fragments should check for
|
|
|
|
* holes in the sequence number space and for the
|
|
|
|
* first sequence number being 0. If we do that,
|
|
|
|
* the only way we can get here is if this fragment
|
|
|
|
* is past the end of the sequence number space -
|
|
|
|
* but the check for "fd->offset > fd_head->datalen"
|
|
|
|
* would have caught that above, so it can't happen.
|
|
|
|
*
|
|
|
|
* If the latter, we don't have a good way of
|
|
|
|
* knowing whether reassembly is complete if we
|
|
|
|
* get packet out of order such that the "last"
|
|
|
|
* fragment doesn't show up last - but, unless
|
|
|
|
* in-order reliable delivery of fragments is
|
|
|
|
* guaranteed, an implementation of the protocol
|
|
|
|
* has no way of knowing whether reassembly is
|
|
|
|
* complete, either.
|
|
|
|
*
|
|
|
|
* For now, we just link the fragment in and
|
|
|
|
* return.
|
|
|
|
*/
|
2001-12-15 05:40:32 +00:00
|
|
|
LINK_FRAG(fd_head,fd);
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
return TRUE;
|
2001-12-15 05:40:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If we have reached this point, the packet is not defragmented yet.
|
2009-08-12 19:32:54 +00:00
|
|
|
* Save all payload in a buffer until we can defragment.
|
2001-12-15 05:40:32 +00:00
|
|
|
* XXX - what if we didn't capture the entire fragment due
|
|
|
|
* to a too-short snapshot length?
|
|
|
|
*/
|
2008-05-07 17:57:45 +00:00
|
|
|
/* check len, there may be a fragment with 0 len, that is actually the tail */
|
2006-01-15 15:01:14 +00:00
|
|
|
if (fd->len) {
|
|
|
|
fd->data = g_malloc(fd->len);
|
|
|
|
tvb_memcpy(tvb, fd->data, offset, fd->len);
|
|
|
|
}
|
2001-12-15 05:40:32 +00:00
|
|
|
LINK_FRAG(fd_head,fd);
|
|
|
|
|
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
if( !(fd_head->flags & FD_DATALEN_SET) ){
|
2003-04-30 22:13:05 +00:00
|
|
|
/* if we dont know the sequence number of the last fragment,
|
|
|
|
* there are definitely still missing packets. Cheaper than
|
|
|
|
* the check below.
|
2001-12-15 05:40:32 +00:00
|
|
|
*/
|
2002-04-25 21:28:15 +00:00
|
|
|
return FALSE;
|
2001-12-15 05:40:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* check if we have received the entire fragment
|
|
|
|
* this is easy since the list is sorted and the head is faked.
|
2007-11-10 16:08:14 +00:00
|
|
|
* common case the whole list is scanned.
|
2001-12-15 05:40:32 +00:00
|
|
|
*/
|
|
|
|
max = 0;
|
|
|
|
for(fd_i=fd_head->next;fd_i;fd_i=fd_i->next) {
|
|
|
|
if ( fd_i->offset==max ){
|
2009-08-12 19:32:54 +00:00
|
|
|
max++;
|
2001-12-15 05:40:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
/* max will now be datalen+1 if all fragments have been seen */
|
|
|
|
|
|
|
|
if (max <= fd_head->datalen) {
|
|
|
|
/* we have not received all packets yet */
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
return FALSE;
|
2001-12-15 05:40:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (max > (fd_head->datalen+1)) {
|
|
|
|
/* oops, too long fragment detected */
|
2009-08-12 19:32:54 +00:00
|
|
|
fd->flags |= FD_TOOLONGFRAGMENT;
|
2001-12-15 05:40:32 +00:00
|
|
|
fd_head->flags |= FD_TOOLONGFRAGMENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* we have received an entire packet, defragment it and
|
2009-08-12 19:32:54 +00:00
|
|
|
* free all fragments
|
|
|
|
*/
|
2007-06-24 05:14:39 +00:00
|
|
|
fragment_defragment_and_free(fd_head, fd, pinfo);
|
2001-12-15 05:40:32 +00:00
|
|
|
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function adds a new fragment to the fragment hash table.
|
|
|
|
* If this is the first fragment seen for this datagram, a new entry
|
|
|
|
* is created in the hash table, otherwise this fragment is just added
|
|
|
|
* to the linked list of fragments for this packet.
|
|
|
|
*
|
|
|
|
* Returns a pointer to the head of the fragment data list if we have all the
|
|
|
|
* fragments, NULL otherwise.
|
|
|
|
*
|
|
|
|
* This function assumes frag_number being a block sequence number.
|
|
|
|
* The bsn for the first block is 0.
|
|
|
|
*/
|
|
|
|
fragment_data *
|
|
|
|
fragment_add_seq(tvbuff_t *tvb, int offset, packet_info *pinfo, guint32 id,
|
2009-08-12 19:32:54 +00:00
|
|
|
GHashTable *fragment_table, guint32 frag_number,
|
|
|
|
guint32 frag_data_len, gboolean more_frags)
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
{
|
2007-02-21 06:19:03 +00:00
|
|
|
fragment_key key;
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
return fragment_add_seq_key(tvb, offset, pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
&key, fragment_key_copy,
|
|
|
|
fragment_table, frag_number,
|
|
|
|
frag_data_len, more_frags, 0);
|
2007-02-21 06:19:03 +00:00
|
|
|
}
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
|
|
|
|
fragment_data *
|
|
|
|
fragment_add_dcerpc_dg(tvbuff_t *tvb, int offset, packet_info *pinfo, guint32 id,
|
2009-08-12 19:32:54 +00:00
|
|
|
void *v_act_id,
|
|
|
|
GHashTable *fragment_table, guint32 frag_number,
|
|
|
|
guint32 frag_data_len, gboolean more_frags)
|
2007-02-21 06:19:03 +00:00
|
|
|
{
|
|
|
|
e_uuid_t *act_id = (e_uuid_t *)v_act_id;
|
|
|
|
dcerpc_fragment_key key;
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
|
|
|
key.act_id = *act_id;
|
2007-02-21 06:19:03 +00:00
|
|
|
|
|
|
|
return fragment_add_seq_key(tvb, offset, pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
&key, dcerpc_fragment_key_copy,
|
|
|
|
fragment_table, frag_number,
|
|
|
|
frag_data_len, more_frags, 0);
|
2007-02-21 06:19:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fragment_data *
|
|
|
|
fragment_add_seq_key(tvbuff_t *tvb, int offset, packet_info *pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
void *key, fragment_key_copier key_copier,
|
|
|
|
GHashTable *fragment_table, guint32 frag_number,
|
|
|
|
guint32 frag_data_len, gboolean more_frags,
|
|
|
|
guint32 flags)
|
2007-02-21 06:19:03 +00:00
|
|
|
{
|
|
|
|
fragment_data *fd_head;
|
|
|
|
fd_head = g_hash_table_lookup(fragment_table, key);
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
|
|
|
|
/* have we already seen this frame ?*/
|
|
|
|
if (pinfo->fd->flags.visited) {
|
|
|
|
if (fd_head != NULL && fd_head->flags & FD_DEFRAGMENTED) {
|
|
|
|
return fd_head;
|
|
|
|
} else {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fd_head==NULL){
|
|
|
|
/* not found, this must be the first snooped fragment for this
|
2009-08-12 19:32:54 +00:00
|
|
|
* packet. Create list-head.
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*/
|
2007-11-10 16:08:14 +00:00
|
|
|
fd_head= new_head(FD_BLOCKSEQUENCE);
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
if((flags & (REASSEMBLE_FLAGS_NO_FRAG_NUMBER|REASSEMBLE_FLAGS_802_11_HACK))
|
|
|
|
&& !more_frags) {
|
|
|
|
/*
|
|
|
|
* This is the last fragment for this packet, and
|
|
|
|
* is the only one we've seen.
|
|
|
|
*
|
|
|
|
* Either we don't have sequence numbers, in which
|
|
|
|
* case we assume this is the first fragment for
|
|
|
|
* this packet, or we're doing special 802.11
|
|
|
|
* processing, in which case we assume it's one
|
|
|
|
* of those reassembled packets with a non-zero
|
|
|
|
* fragment number (see packet-80211.c); just
|
|
|
|
* return a pointer to the head of the list;
|
|
|
|
* fragment_add_seq_check will then add it to the table
|
|
|
|
* of reassembled packets.
|
|
|
|
*/
|
|
|
|
fd_head->reassembled_in=pinfo->fd->num;
|
|
|
|
return fd_head;
|
|
|
|
}
|
2009-08-12 19:32:54 +00:00
|
|
|
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
/*
|
|
|
|
* We're going to use the key to insert the fragment,
|
2007-02-21 06:19:03 +00:00
|
|
|
* so copy it to a long-term store.
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*/
|
2007-02-21 06:19:03 +00:00
|
|
|
if(key_copier != NULL)
|
|
|
|
key = key_copier(key);
|
|
|
|
g_hash_table_insert(fragment_table, key, fd_head);
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
/*
|
|
|
|
* If we weren't given an initial fragment number,
|
|
|
|
* make it 0.
|
|
|
|
*/
|
|
|
|
if (flags & REASSEMBLE_FLAGS_NO_FRAG_NUMBER)
|
|
|
|
frag_number = 0;
|
|
|
|
} else {
|
|
|
|
if (flags & REASSEMBLE_FLAGS_NO_FRAG_NUMBER) {
|
|
|
|
fragment_data *fd;
|
|
|
|
/*
|
|
|
|
* If we weren't given an initial fragment number,
|
|
|
|
* use the next expected fragment number as the fragment
|
|
|
|
* number for this fragment.
|
|
|
|
*/
|
|
|
|
for (fd = fd_head; fd != NULL; fd = fd->next) {
|
|
|
|
if (fd->next == NULL)
|
|
|
|
frag_number = fd->offset + 1;
|
|
|
|
}
|
|
|
|
}
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
}
|
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
/*
|
|
|
|
* XXX I've copied this over from the old separate
|
|
|
|
* fragment_add_seq_check_work, but I'm not convinced it's doing the
|
|
|
|
* right thing -- rav
|
|
|
|
*
|
|
|
|
* If we don't have all the data that is in this fragment,
|
|
|
|
* then we can't, and don't, do reassembly on it.
|
|
|
|
*
|
|
|
|
* If it's the first frame, handle it as an unfragmented packet.
|
|
|
|
* Otherwise, just handle it as a fragment.
|
|
|
|
*
|
|
|
|
* If "more_frags" isn't set, we get rid of the entry in the
|
|
|
|
* hash table for this reassembly, as we don't need it any more.
|
|
|
|
*/
|
|
|
|
if ((flags & REASSEMBLE_FLAGS_CHECK_DATA_PRESENT) &&
|
|
|
|
!tvb_bytes_exist(tvb, offset, frag_data_len)) {
|
|
|
|
if (!more_frags) {
|
|
|
|
gpointer orig_key;
|
|
|
|
/*
|
|
|
|
* Remove this from the table of in-progress
|
|
|
|
* reassemblies, and free up any memory used for
|
|
|
|
* it in that table.
|
|
|
|
*/
|
|
|
|
if (g_hash_table_lookup_extended(fragment_table, key,
|
|
|
|
&orig_key, NULL)) {
|
|
|
|
fragment_unhash(fragment_table, (fragment_key *)orig_key);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
fd_head -> flags |= FD_DATA_NOT_PRESENT;
|
|
|
|
return frag_number == 0 ? fd_head : NULL;
|
|
|
|
}
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2002-04-22 08:14:12 +00:00
|
|
|
if (fragment_add_seq_work(fd_head, tvb, offset, pinfo,
|
2007-02-21 06:19:03 +00:00
|
|
|
frag_number, frag_data_len, more_frags, flags)) {
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
/*
|
|
|
|
* Reassembly is complete.
|
|
|
|
*/
|
|
|
|
return fd_head;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Reassembly isn't complete.
|
|
|
|
*/
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2002-10-24 06:17:36 +00:00
|
|
|
* This does the work for "fragment_add_seq_check()" and
|
|
|
|
* "fragment_add_seq_next()".
|
|
|
|
*
|
|
|
|
* This function assumes frag_number being a block sequence number.
|
|
|
|
* The bsn for the first block is 0.
|
|
|
|
*
|
|
|
|
* If "no_frag_number" is TRUE, it uses the next expected fragment number
|
|
|
|
* as the fragment number if there is a reassembly in progress, otherwise
|
|
|
|
* it uses 0.
|
|
|
|
*
|
|
|
|
* If "no_frag_number" is FALSE, it uses the "frag_number" argument as
|
|
|
|
* the fragment number.
|
|
|
|
*
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
* If this is the first fragment seen for this datagram, a new
|
2007-01-19 23:27:24 +00:00
|
|
|
* "fragment_data" structure is allocated to refer to the reassembled
|
|
|
|
* packet.
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*
|
2007-01-19 23:27:24 +00:00
|
|
|
* This fragment is added to the linked list of fragments for this packet.
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*
|
2007-02-21 06:19:03 +00:00
|
|
|
* If "more_frags" is false and REASSEMBLE_FLAGS_802_11_HACK (as the name
|
|
|
|
* implies, a special hack for 802.11) or REASSEMBLE_FLAGS_NO_FRAG_NUMBER
|
|
|
|
* (implying messages must be in order since there's no sequence number) are
|
|
|
|
* set in "flags", then this (one element) list is returned.
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*
|
2003-12-20 03:21:20 +00:00
|
|
|
* If, after processing this fragment, we have all the fragments,
|
|
|
|
* "fragment_add_seq_check_work()" removes that from the fragment hash
|
|
|
|
* table if necessary and adds it to the table of reassembled fragments,
|
|
|
|
* and returns a pointer to the head of the fragment list.
|
|
|
|
*
|
|
|
|
* Otherwise, it returns NULL.
|
2005-09-20 17:23:19 +00:00
|
|
|
*
|
|
|
|
* XXX - Should we simply return NULL for zero-length fragments?
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*/
|
2003-12-20 03:21:20 +00:00
|
|
|
static fragment_data *
|
2002-10-24 06:17:36 +00:00
|
|
|
fragment_add_seq_check_work(tvbuff_t *tvb, int offset, packet_info *pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
guint32 id, GHashTable *fragment_table,
|
|
|
|
GHashTable *reassembled_table, guint32 frag_number,
|
|
|
|
guint32 frag_data_len, gboolean more_frags,
|
|
|
|
guint32 flags)
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
{
|
2003-06-04 05:41:37 +00:00
|
|
|
reassembled_key reass_key;
|
2007-02-21 06:19:03 +00:00
|
|
|
fragment_key key;
|
|
|
|
fragment_data *fd_head;
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Have we already seen this frame?
|
|
|
|
* If so, look for it in the table of reassembled packets.
|
|
|
|
*/
|
2003-06-04 05:41:37 +00:00
|
|
|
if (pinfo->fd->flags.visited) {
|
|
|
|
reass_key.frame = pinfo->fd->num;
|
|
|
|
reass_key.id = id;
|
|
|
|
return g_hash_table_lookup(reassembled_table, &reass_key);
|
|
|
|
}
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
|
2007-02-21 06:19:03 +00:00
|
|
|
fd_head = fragment_add_seq_key(tvb, offset, pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
&key, fragment_key_copy,
|
|
|
|
fragment_table, frag_number,
|
|
|
|
frag_data_len, more_frags, flags|REASSEMBLE_FLAGS_CHECK_DATA_PRESENT);
|
2007-02-21 06:19:03 +00:00
|
|
|
if (fd_head) {
|
|
|
|
gpointer orig_key;
|
|
|
|
|
|
|
|
if(fd_head->flags & FD_DATA_NOT_PRESENT) {
|
|
|
|
/* this is the first fragment of a datagram with
|
|
|
|
* truncated fragments. Don't move it to the
|
|
|
|
* reassembled table. */
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
return fd_head;
|
|
|
|
}
|
2009-08-12 19:32:54 +00:00
|
|
|
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
/*
|
|
|
|
* Reassembly is complete.
|
|
|
|
* Remove this from the table of in-progress
|
|
|
|
* reassemblies, add it to the table of
|
|
|
|
* reassembled packets, and return it.
|
|
|
|
*/
|
2007-02-21 06:19:03 +00:00
|
|
|
if (g_hash_table_lookup_extended(fragment_table, &key,
|
|
|
|
&orig_key, NULL)) {
|
|
|
|
/*
|
|
|
|
* Remove this from the table of in-progress reassemblies,
|
|
|
|
* and free up any memory used for it in that table.
|
|
|
|
*/
|
|
|
|
fragment_unhash(fragment_table, (fragment_key *)orig_key);
|
|
|
|
}
|
2002-04-17 08:57:07 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Add this item to the table of reassembled packets.
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
*/
|
2003-06-04 05:41:37 +00:00
|
|
|
fragment_reassembled(fd_head, pinfo, reassembled_table, id);
|
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key. There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.
Add a routine "fragment_add_seq_check()", which
if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;
if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;
if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.
Add reassembly support for fragmented 802.11 frames. Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).
svn path=/trunk/; revision=5177
2002-04-17 08:25:05 +00:00
|
|
|
return fd_head;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Reassembly isn't complete.
|
|
|
|
*/
|
|
|
|
return NULL;
|
|
|
|
}
|
2001-12-15 05:40:32 +00:00
|
|
|
}
|
2002-06-05 11:21:49 +00:00
|
|
|
|
2002-10-24 06:17:36 +00:00
|
|
|
fragment_data *
|
|
|
|
fragment_add_seq_check(tvbuff_t *tvb, int offset, packet_info *pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
guint32 id, GHashTable *fragment_table,
|
|
|
|
GHashTable *reassembled_table, guint32 frag_number,
|
|
|
|
guint32 frag_data_len, gboolean more_frags)
|
2002-10-24 06:17:36 +00:00
|
|
|
{
|
|
|
|
return fragment_add_seq_check_work(tvb, offset, pinfo, id,
|
2009-08-12 19:32:54 +00:00
|
|
|
fragment_table, reassembled_table, frag_number, frag_data_len,
|
|
|
|
more_frags, 0);
|
2003-12-20 03:21:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fragment_data *
|
|
|
|
fragment_add_seq_802_11(tvbuff_t *tvb, int offset, packet_info *pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
guint32 id, GHashTable *fragment_table,
|
|
|
|
GHashTable *reassembled_table, guint32 frag_number,
|
|
|
|
guint32 frag_data_len, gboolean more_frags)
|
2003-12-20 03:21:20 +00:00
|
|
|
{
|
|
|
|
return fragment_add_seq_check_work(tvb, offset, pinfo, id,
|
2009-08-12 19:32:54 +00:00
|
|
|
fragment_table, reassembled_table, frag_number, frag_data_len,
|
|
|
|
more_frags, REASSEMBLE_FLAGS_802_11_HACK);
|
2002-10-24 06:17:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fragment_data *
|
|
|
|
fragment_add_seq_next(tvbuff_t *tvb, int offset, packet_info *pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
guint32 id, GHashTable *fragment_table,
|
|
|
|
GHashTable *reassembled_table, guint32 frag_data_len,
|
|
|
|
gboolean more_frags)
|
2002-10-24 06:17:36 +00:00
|
|
|
{
|
|
|
|
return fragment_add_seq_check_work(tvb, offset, pinfo, id,
|
2009-08-12 19:32:54 +00:00
|
|
|
fragment_table, reassembled_table, 0, frag_data_len,
|
|
|
|
more_frags, REASSEMBLE_FLAGS_NO_FRAG_NUMBER);
|
2002-10-24 06:17:36 +00:00
|
|
|
}
|
2002-06-05 11:21:49 +00:00
|
|
|
|
2007-08-15 22:24:05 +00:00
|
|
|
void
|
|
|
|
fragment_start_seq_check(packet_info *pinfo, guint32 id, GHashTable *fragment_table,
|
|
|
|
guint32 tot_len)
|
|
|
|
{
|
|
|
|
fragment_key key, *new_key;
|
|
|
|
fragment_data *fd_head;
|
|
|
|
|
|
|
|
/* Have we already seen this frame ?*/
|
|
|
|
if (pinfo->fd->flags.visited) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
2007-08-15 22:24:05 +00:00
|
|
|
|
|
|
|
/* Check if fragment data exist for this key */
|
|
|
|
fd_head = g_hash_table_lookup(fragment_table, &key);
|
|
|
|
|
|
|
|
if (fd_head == NULL) {
|
|
|
|
/* Create list-head. */
|
2009-08-16 04:54:33 +00:00
|
|
|
#if GLIB_CHECK_VERSION(2,10,0)
|
|
|
|
fd_head = g_slice_new(fragment_data);
|
|
|
|
#else
|
2007-08-15 22:24:05 +00:00
|
|
|
fd_head = g_mem_chunk_alloc(fragment_data_chunk);
|
2009-08-16 04:54:33 +00:00
|
|
|
#endif
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-08-15 22:24:05 +00:00
|
|
|
fd_head->next = NULL;
|
|
|
|
fd_head->datalen = tot_len;
|
|
|
|
fd_head->offset = 0;
|
|
|
|
fd_head->len = 0;
|
2009-08-12 19:32:54 +00:00
|
|
|
fd_head->flags = FD_BLOCKSEQUENCE|FD_DATALEN_SET;
|
2007-08-15 22:24:05 +00:00
|
|
|
fd_head->data = NULL;
|
|
|
|
fd_head->reassembled_in = 0;
|
|
|
|
/*
|
|
|
|
* We're going to use the key to insert the fragment,
|
|
|
|
* so copy it to a long-term store.
|
|
|
|
*/
|
|
|
|
new_key = fragment_key_copy(&key);
|
|
|
|
g_hash_table_insert(fragment_table, new_key, fd_head);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-06-24 05:14:39 +00:00
|
|
|
fragment_data *
|
|
|
|
fragment_end_seq_next(packet_info *pinfo, guint32 id, GHashTable *fragment_table,
|
2009-08-12 19:32:54 +00:00
|
|
|
GHashTable *reassembled_table)
|
2007-06-24 05:14:39 +00:00
|
|
|
{
|
|
|
|
reassembled_key reass_key;
|
|
|
|
reassembled_key *new_key;
|
|
|
|
fragment_key key;
|
|
|
|
fragment_data *fd_head;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Have we already seen this frame?
|
|
|
|
* If so, look for it in the table of reassembled packets.
|
|
|
|
*/
|
|
|
|
if (pinfo->fd->flags.visited) {
|
|
|
|
reass_key.frame = pinfo->fd->num;
|
|
|
|
reass_key.id = id;
|
|
|
|
return g_hash_table_lookup(reassembled_table, &reass_key);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* create key to search hash with */
|
|
|
|
key.src = pinfo->src;
|
|
|
|
key.dst = pinfo->dst;
|
2009-08-12 19:32:54 +00:00
|
|
|
key.id = id;
|
2007-06-24 05:14:39 +00:00
|
|
|
|
|
|
|
fd_head = g_hash_table_lookup (fragment_table, &key);
|
|
|
|
|
|
|
|
if (fd_head) {
|
|
|
|
gpointer orig_key;
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-06-24 05:14:39 +00:00
|
|
|
if (fd_head->flags & FD_DATA_NOT_PRESENT) {
|
|
|
|
/* No data added */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
fd_head->datalen = fd_head->offset;
|
|
|
|
fd_head->flags |= FD_DATALEN_SET;
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2007-06-24 05:14:39 +00:00
|
|
|
fragment_defragment_and_free (fd_head, NULL, pinfo);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove this from the table of in-progress
|
|
|
|
* reassemblies, add it to the table of
|
|
|
|
* reassembled packets, and return it.
|
|
|
|
*/
|
|
|
|
if (g_hash_table_lookup_extended(fragment_table, &key,
|
|
|
|
&orig_key, NULL)) {
|
|
|
|
/*
|
|
|
|
* Remove this from the table of in-progress reassemblies,
|
|
|
|
* and free up any memory used for it in that table.
|
|
|
|
*/
|
|
|
|
fragment_unhash(fragment_table, (fragment_key *)orig_key);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add this item to the table of reassembled packets.
|
|
|
|
*/
|
|
|
|
fragment_reassembled(fd_head, pinfo, reassembled_table, id);
|
|
|
|
if (fd_head->next != NULL) {
|
|
|
|
new_key = se_alloc(sizeof(reassembled_key));
|
|
|
|
new_key->frame = pinfo->fd->num;
|
|
|
|
new_key->id = id;
|
|
|
|
g_hash_table_insert(reassembled_table, new_key, fd_head);
|
|
|
|
}
|
|
|
|
|
2009-08-12 19:32:54 +00:00
|
|
|
return fd_head;
|
2007-06-24 05:14:39 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Fragment data not found.
|
|
|
|
*/
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
2009-08-12 19:32:54 +00:00
|
|
|
|
2003-04-20 08:06:01 +00:00
|
|
|
/*
|
|
|
|
* Process reassembled data; if we're on the frame in which the data
|
|
|
|
* was reassembled, put the fragment information into the protocol
|
|
|
|
* tree, and construct a tvbuff with the reassembled data, otherwise
|
|
|
|
* just put a "reassembled in" item into the protocol tree.
|
|
|
|
*/
|
|
|
|
tvbuff_t *
|
2003-08-28 04:19:29 +00:00
|
|
|
process_reassembled_data(tvbuff_t *tvb, int offset, packet_info *pinfo,
|
2009-08-12 19:32:54 +00:00
|
|
|
const char *name, fragment_data *fd_head, const fragment_items *fit,
|
|
|
|
gboolean *update_col_infop, proto_tree *tree)
|
2003-04-20 08:06:01 +00:00
|
|
|
{
|
|
|
|
tvbuff_t *next_tvb;
|
2003-04-20 11:36:16 +00:00
|
|
|
gboolean update_col_info;
|
2005-07-24 22:01:14 +00:00
|
|
|
proto_item *frag_tree_item;
|
2003-04-20 08:06:01 +00:00
|
|
|
|
2003-08-28 04:19:29 +00:00
|
|
|
if (fd_head != NULL && pinfo->fd->num == fd_head->reassembled_in) {
|
2003-04-20 11:36:16 +00:00
|
|
|
/*
|
2003-08-28 04:19:29 +00:00
|
|
|
* OK, we've reassembled this.
|
|
|
|
* Is this something that's been reassembled from more
|
|
|
|
* than one fragment?
|
2003-04-20 11:36:16 +00:00
|
|
|
*/
|
2003-08-28 04:19:29 +00:00
|
|
|
if (fd_head->next != NULL) {
|
|
|
|
/*
|
|
|
|
* Yes.
|
|
|
|
* Allocate a new tvbuff, referring to the
|
|
|
|
* reassembled payload.
|
|
|
|
*/
|
|
|
|
if (fd_head->flags & FD_BLOCKSEQUENCE) {
|
|
|
|
next_tvb = tvb_new_real_data(fd_head->data,
|
2009-08-12 19:32:54 +00:00
|
|
|
fd_head->len, fd_head->len);
|
2003-08-28 04:19:29 +00:00
|
|
|
} else {
|
|
|
|
next_tvb = tvb_new_real_data(fd_head->data,
|
2009-08-12 19:32:54 +00:00
|
|
|
fd_head->datalen, fd_head->datalen);
|
2003-08-28 04:19:29 +00:00
|
|
|
}
|
2003-04-20 08:06:01 +00:00
|
|
|
|
2003-08-28 04:19:29 +00:00
|
|
|
/*
|
|
|
|
* Add the tvbuff to the list of tvbuffs to which
|
|
|
|
* the tvbuff we were handed refers, so it'll get
|
|
|
|
* cleaned up when that tvbuff is cleaned up.
|
|
|
|
*/
|
|
|
|
tvb_set_child_real_data_tvbuff(tvb, next_tvb);
|
|
|
|
|
|
|
|
/* Add the defragmented data to the data source list. */
|
2009-08-15 06:38:10 +00:00
|
|
|
packet_add_new_data_source(pinfo, tree, next_tvb, name);
|
2003-08-28 04:19:29 +00:00
|
|
|
|
|
|
|
/* show all fragments */
|
|
|
|
if (fd_head->flags & FD_BLOCKSEQUENCE) {
|
|
|
|
update_col_info = !show_fragment_seq_tree(
|
2009-08-12 19:32:54 +00:00
|
|
|
fd_head, fit, tree, pinfo, next_tvb, &frag_tree_item);
|
2003-08-28 04:19:29 +00:00
|
|
|
} else {
|
|
|
|
update_col_info = !show_fragment_tree(fd_head,
|
2009-08-12 19:32:54 +00:00
|
|
|
fit, tree, pinfo, next_tvb, &frag_tree_item);
|
2003-08-28 04:19:29 +00:00
|
|
|
}
|
2003-04-20 08:06:01 +00:00
|
|
|
} else {
|
2003-08-28 04:19:29 +00:00
|
|
|
/*
|
|
|
|
* No.
|
|
|
|
* Return a tvbuff with the payload.
|
|
|
|
*/
|
2009-08-16 12:36:22 +00:00
|
|
|
next_tvb = tvb_new_subset_remaining(tvb, offset);
|
2003-08-28 04:19:29 +00:00
|
|
|
pinfo->fragmented = FALSE; /* one-fragment packet */
|
|
|
|
update_col_info = TRUE;
|
2003-04-20 08:06:01 +00:00
|
|
|
}
|
2003-04-20 11:36:16 +00:00
|
|
|
if (update_col_infop != NULL)
|
|
|
|
*update_col_infop = update_col_info;
|
2003-04-20 08:06:01 +00:00
|
|
|
} else {
|
2003-08-28 04:46:13 +00:00
|
|
|
/*
|
|
|
|
* We don't have the complete reassembled payload, or this
|
|
|
|
* isn't the final frame of that payload.
|
|
|
|
*/
|
2003-04-20 08:06:01 +00:00
|
|
|
next_tvb = NULL;
|
2003-04-20 11:36:16 +00:00
|
|
|
|
|
|
|
/*
|
2003-08-28 04:19:29 +00:00
|
|
|
* If we know what frame this was reassembled in,
|
|
|
|
* and if there's a field to use for the number of
|
2003-04-20 11:36:16 +00:00
|
|
|
* the frame in which the packet was reassembled,
|
|
|
|
* add it to the protocol tree.
|
|
|
|
*/
|
2003-08-28 04:19:29 +00:00
|
|
|
if (fd_head != NULL && fit->hf_reassembled_in != NULL) {
|
2003-04-20 11:36:16 +00:00
|
|
|
proto_tree_add_uint(tree,
|
2009-08-12 19:32:54 +00:00
|
|
|
*(fit->hf_reassembled_in), tvb,
|
|
|
|
0, 0, fd_head->reassembled_in);
|
2003-04-20 11:36:16 +00:00
|
|
|
}
|
2003-04-20 08:06:01 +00:00
|
|
|
}
|
|
|
|
return next_tvb;
|
|
|
|
}
|
|
|
|
|
2002-06-07 10:11:41 +00:00
|
|
|
/*
|
2005-07-24 17:48:10 +00:00
|
|
|
* Show a single fragment in a fragment subtree, and put information about
|
|
|
|
* it in the top-level item for that subtree.
|
2002-06-07 10:11:41 +00:00
|
|
|
*/
|
|
|
|
static void
|
2002-10-24 06:17:36 +00:00
|
|
|
show_fragment(fragment_data *fd, int offset, const fragment_items *fit,
|
2009-08-12 19:32:54 +00:00
|
|
|
proto_tree *ft, proto_item *fi, gboolean first_frag, tvbuff_t *tvb)
|
2002-06-07 10:11:41 +00:00
|
|
|
{
|
2004-06-20 19:20:55 +00:00
|
|
|
proto_item *fei=NULL;
|
|
|
|
int hf;
|
2002-06-07 10:11:41 +00:00
|
|
|
|
2005-07-24 17:48:10 +00:00
|
|
|
if (first_frag)
|
2006-11-21 21:49:58 +00:00
|
|
|
proto_item_append_text(fi, " (%u byte%s): ", tvb_length(tvb),
|
2009-08-12 19:32:54 +00:00
|
|
|
plurality(tvb_length(tvb), "", "s"));
|
2005-07-24 17:48:10 +00:00
|
|
|
else
|
|
|
|
proto_item_append_text(fi, ", ");
|
|
|
|
proto_item_append_text(fi, "#%u(%u)", fd->frame, fd->len);
|
|
|
|
|
2004-06-20 19:20:55 +00:00
|
|
|
if (fd->flags & (FD_OVERLAPCONFLICT
|
|
|
|
|FD_MULTIPLETAILS|FD_TOOLONGFRAGMENT) ) {
|
|
|
|
hf = *(fit->hf_fragment_error);
|
|
|
|
} else {
|
|
|
|
hf = *(fit->hf_fragment);
|
|
|
|
}
|
|
|
|
if (fd->len == 0) {
|
|
|
|
fei = proto_tree_add_uint_format(ft, hf,
|
|
|
|
tvb, offset, fd->len,
|
|
|
|
fd->frame,
|
|
|
|
"Frame: %u (no data)",
|
|
|
|
fd->frame);
|
|
|
|
} else {
|
2002-12-19 11:22:38 +00:00
|
|
|
fei = proto_tree_add_uint_format(ft, hf,
|
2002-06-07 10:11:41 +00:00
|
|
|
tvb, offset, fd->len,
|
2002-12-19 11:22:38 +00:00
|
|
|
fd->frame,
|
2006-11-21 21:49:58 +00:00
|
|
|
"Frame: %u, payload: %u-%u (%u byte%s)",
|
2002-06-07 10:11:41 +00:00
|
|
|
fd->frame,
|
|
|
|
offset,
|
2004-04-24 06:46:04 +00:00
|
|
|
offset+fd->len-1,
|
2006-11-21 21:49:58 +00:00
|
|
|
fd->len,
|
|
|
|
plurality(fd->len, "", "s"));
|
2004-06-20 19:20:55 +00:00
|
|
|
}
|
|
|
|
PROTO_ITEM_SET_GENERATED(fei);
|
|
|
|
if (fd->flags & (FD_OVERLAP|FD_OVERLAPCONFLICT
|
|
|
|
|FD_MULTIPLETAILS|FD_TOOLONGFRAGMENT) ) {
|
|
|
|
/* this fragment has some flags set, create a subtree
|
|
|
|
* for it and display the flags.
|
|
|
|
*/
|
|
|
|
proto_tree *fet=NULL;
|
|
|
|
|
2002-06-07 10:11:41 +00:00
|
|
|
fet = proto_item_add_subtree(fei, *(fit->ett_fragment));
|
|
|
|
if (fd->flags&FD_OVERLAP) {
|
2004-05-14 17:34:51 +00:00
|
|
|
fei=proto_tree_add_boolean(fet,
|
2002-06-07 10:11:41 +00:00
|
|
|
*(fit->hf_fragment_overlap),
|
2002-08-28 21:04:11 +00:00
|
|
|
tvb, 0, 0,
|
2002-06-07 10:11:41 +00:00
|
|
|
TRUE);
|
2004-05-14 17:34:51 +00:00
|
|
|
PROTO_ITEM_SET_GENERATED(fei);
|
2002-06-07 10:11:41 +00:00
|
|
|
}
|
|
|
|
if (fd->flags&FD_OVERLAPCONFLICT) {
|
2004-05-14 17:34:51 +00:00
|
|
|
fei=proto_tree_add_boolean(fet,
|
2002-08-28 21:04:11 +00:00
|
|
|
*(fit->hf_fragment_overlap_conflict),
|
|
|
|
tvb, 0, 0,
|
2002-06-07 10:11:41 +00:00
|
|
|
TRUE);
|
2004-05-14 17:34:51 +00:00
|
|
|
PROTO_ITEM_SET_GENERATED(fei);
|
2002-06-07 10:11:41 +00:00
|
|
|
}
|
|
|
|
if (fd->flags&FD_MULTIPLETAILS) {
|
2004-05-14 17:34:51 +00:00
|
|
|
fei=proto_tree_add_boolean(fet,
|
2002-06-07 10:11:41 +00:00
|
|
|
*(fit->hf_fragment_multiple_tails),
|
2002-08-28 21:04:11 +00:00
|
|
|
tvb, 0, 0,
|
2002-06-07 10:11:41 +00:00
|
|
|
TRUE);
|
2004-05-14 17:34:51 +00:00
|
|
|
PROTO_ITEM_SET_GENERATED(fei);
|
2002-06-07 10:11:41 +00:00
|
|
|
}
|
|
|
|
if (fd->flags&FD_TOOLONGFRAGMENT) {
|
2004-05-14 17:34:51 +00:00
|
|
|
fei=proto_tree_add_boolean(fet,
|
2002-08-28 21:04:11 +00:00
|
|
|
*(fit->hf_fragment_too_long_fragment),
|
|
|
|
tvb, 0, 0,
|
2002-06-07 10:11:41 +00:00
|
|
|
TRUE);
|
2004-05-14 17:34:51 +00:00
|
|
|
PROTO_ITEM_SET_GENERATED(fei);
|
2002-06-07 10:11:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2002-06-07 10:17:21 +00:00
|
|
|
static gboolean
|
2002-10-24 06:17:36 +00:00
|
|
|
show_fragment_errs_in_col(fragment_data *fd_head, const fragment_items *fit,
|
2009-08-12 19:32:54 +00:00
|
|
|
packet_info *pinfo)
|
2002-06-07 10:17:21 +00:00
|
|
|
{
|
|
|
|
if (fd_head->flags & (FD_OVERLAPCONFLICT
|
|
|
|
|FD_MULTIPLETAILS|FD_TOOLONGFRAGMENT) ) {
|
|
|
|
if (check_col(pinfo->cinfo, COL_INFO)) {
|
2002-08-28 21:04:11 +00:00
|
|
|
col_add_fstr(pinfo->cinfo, COL_INFO,
|
2002-06-07 10:17:21 +00:00
|
|
|
"[Illegal %s]", fit->tag);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2002-06-07 10:11:41 +00:00
|
|
|
/* This function will build the fragment subtree; it's for fragments
|
|
|
|
reassembled with "fragment_add()".
|
2002-08-28 21:04:11 +00:00
|
|
|
|
2002-06-07 10:11:41 +00:00
|
|
|
It will return TRUE if there were fragmentation errors
|
2002-06-05 11:21:49 +00:00
|
|
|
or FALSE if fragmentation was ok.
|
|
|
|
*/
|
2002-06-07 10:11:41 +00:00
|
|
|
gboolean
|
2002-10-24 06:17:36 +00:00
|
|
|
show_fragment_tree(fragment_data *fd_head, const fragment_items *fit,
|
2009-08-12 19:32:54 +00:00
|
|
|
proto_tree *tree, packet_info *pinfo, tvbuff_t *tvb, proto_item **fi)
|
2002-06-05 11:21:49 +00:00
|
|
|
{
|
2002-06-07 10:11:41 +00:00
|
|
|
fragment_data *fd;
|
2002-10-17 21:14:17 +00:00
|
|
|
proto_tree *ft;
|
2005-07-24 17:48:10 +00:00
|
|
|
gboolean first_frag;
|
2002-06-05 11:21:49 +00:00
|
|
|
|
|
|
|
/* It's not fragmented. */
|
|
|
|
pinfo->fragmented = FALSE;
|
|
|
|
|
2005-06-02 18:52:55 +00:00
|
|
|
*fi = proto_tree_add_item(tree, *(fit->hf_fragments),
|
2009-08-12 19:32:54 +00:00
|
|
|
tvb, 0, -1, FALSE);
|
2005-06-02 18:52:55 +00:00
|
|
|
PROTO_ITEM_SET_GENERATED(*fi);
|
2004-05-14 17:34:51 +00:00
|
|
|
|
2005-06-02 18:52:55 +00:00
|
|
|
ft = proto_item_add_subtree(*fi, *(fit->ett_fragments));
|
2005-07-24 17:48:10 +00:00
|
|
|
first_frag = TRUE;
|
|
|
|
for (fd = fd_head->next; fd != NULL; fd = fd->next) {
|
|
|
|
show_fragment(fd, fd->offset, fit, ft, *fi, first_frag, tvb);
|
|
|
|
first_frag = FALSE;
|
|
|
|
}
|
2002-06-07 10:11:41 +00:00
|
|
|
|
2002-06-07 10:17:21 +00:00
|
|
|
return show_fragment_errs_in_col(fd_head, fit, pinfo);
|
2002-08-28 21:04:11 +00:00
|
|
|
}
|
2002-06-07 10:11:41 +00:00
|
|
|
|
|
|
|
/* This function will build the fragment subtree; it's for fragments
|
|
|
|
reassembled with "fragment_add_seq()" or "fragment_add_seq_check()".
|
2002-08-28 21:04:11 +00:00
|
|
|
|
2002-06-07 10:11:41 +00:00
|
|
|
It will return TRUE if there were fragmentation errors
|
|
|
|
or FALSE if fragmentation was ok.
|
|
|
|
*/
|
|
|
|
gboolean
|
2002-10-24 06:17:36 +00:00
|
|
|
show_fragment_seq_tree(fragment_data *fd_head, const fragment_items *fit,
|
2009-08-12 19:32:54 +00:00
|
|
|
proto_tree *tree, packet_info *pinfo, tvbuff_t *tvb, proto_item **fi)
|
2002-06-07 10:11:41 +00:00
|
|
|
{
|
2002-10-17 21:14:17 +00:00
|
|
|
guint32 offset, next_offset;
|
|
|
|
fragment_data *fd, *last_fd;
|
|
|
|
proto_tree *ft;
|
2005-07-24 17:48:10 +00:00
|
|
|
gboolean first_frag;
|
2002-06-07 10:11:41 +00:00
|
|
|
|
|
|
|
/* It's not fragmented. */
|
|
|
|
pinfo->fragmented = FALSE;
|
|
|
|
|
2005-06-02 20:55:58 +00:00
|
|
|
*fi = proto_tree_add_item(tree, *(fit->hf_fragments),
|
2009-08-12 19:32:54 +00:00
|
|
|
tvb, 0, -1, FALSE);
|
2005-06-02 20:55:58 +00:00
|
|
|
PROTO_ITEM_SET_GENERATED(*fi);
|
|
|
|
|
|
|
|
ft = proto_item_add_subtree(*fi, *(fit->ett_fragments));
|
2002-06-07 10:11:41 +00:00
|
|
|
offset = 0;
|
2002-10-17 21:14:17 +00:00
|
|
|
next_offset = 0;
|
|
|
|
last_fd = NULL;
|
2005-07-24 17:48:10 +00:00
|
|
|
first_frag = TRUE;
|
2002-10-17 21:14:17 +00:00
|
|
|
for (fd = fd_head->next; fd != NULL; fd = fd->next){
|
|
|
|
if (last_fd == NULL || last_fd->offset != fd->offset) {
|
|
|
|
offset = next_offset;
|
|
|
|
next_offset += fd->len;
|
|
|
|
}
|
|
|
|
last_fd = fd;
|
2005-07-24 17:48:10 +00:00
|
|
|
show_fragment(fd, offset, fit, ft, *fi, first_frag, tvb);
|
|
|
|
first_frag = FALSE;
|
2002-06-07 10:11:41 +00:00
|
|
|
}
|
|
|
|
|
2002-06-07 10:17:21 +00:00
|
|
|
return show_fragment_errs_in_col(fd_head, fit, pinfo);
|
2002-08-28 21:04:11 +00:00
|
|
|
}
|
2007-02-21 06:19:03 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Local Variables:
|
|
|
|
* c-basic-offset: 8
|
|
|
|
* indent-tabs-mode: t
|
|
|
|
* tab-width: 8
|
|
|
|
* End:
|
|
|
|
*/
|