Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
/* conversation.c
|
|
|
|
* Routines for building lists of packets that are part of a "conversation"
|
|
|
|
*
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
* $Id: conversation.c,v 1.5 1999/11/14 21:16:58 guy Exp $
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
*
|
|
|
|
* Ethereal - Network traffic analyzer
|
|
|
|
* By Gerald Combs <gerald@zing.org>
|
|
|
|
* Copyright 1998 Gerald Combs
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
# include "config.h"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
#ifdef HAVE_SYS_TYPES_H
|
|
|
|
# include <sys/types.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef HAVE_NETINET_IN_H
|
|
|
|
# include <netinet/in.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <string.h>
|
|
|
|
#include <glib.h>
|
|
|
|
#include "packet.h"
|
Export the data structure used to represent a conversation.
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
|
|
|
#include "conversation.h"
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
|
|
|
|
static GHashTable *conversation_hashtable = NULL;
|
|
|
|
static GMemChunk *conversation_key_chunk = NULL;
|
Export the data structure used to represent a conversation.
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
|
|
|
static GMemChunk *conversation_chunk = NULL;
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
|
|
|
|
typedef struct conversation_key {
|
|
|
|
struct conversation_key *next;
|
|
|
|
address src;
|
|
|
|
address dst;
|
|
|
|
port_type ptype;
|
|
|
|
guint16 port_src;
|
|
|
|
guint16 port_dst;
|
|
|
|
} conversation_key;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Linked list of conversation keys, so we can, before freeing them all,
|
|
|
|
* free the address data allocations associated with them.
|
|
|
|
*/
|
|
|
|
static conversation_key *conversation_keys;
|
|
|
|
|
|
|
|
static guint32 new_index;
|
|
|
|
|
|
|
|
static int conversation_init_count = 200;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compare two conversation keys.
|
|
|
|
*/
|
|
|
|
static gint
|
|
|
|
conversation_equal(gconstpointer v, gconstpointer w)
|
|
|
|
{
|
|
|
|
conversation_key *v1 = (conversation_key *)v;
|
|
|
|
conversation_key *v2 = (conversation_key *)w;
|
|
|
|
|
|
|
|
if (v1->ptype != v2->ptype)
|
|
|
|
return 0; /* different types of port */
|
|
|
|
|
1999-11-11 20:44:14 +00:00
|
|
|
/*
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
* Are the first and second source ports the same, the first and
|
|
|
|
* second destination ports the same, the first and second source
|
|
|
|
* addresses the same, and the first and second destination
|
|
|
|
* addresses the same?
|
1999-11-11 20:44:14 +00:00
|
|
|
*/
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
if (v1->port_src == v2->port_src &&
|
|
|
|
v1->port_dst == v2->port_dst &&
|
|
|
|
v1->src.type == v2->src.type &&
|
|
|
|
v1->src.len == v2->src.len &&
|
1999-11-11 20:44:14 +00:00
|
|
|
memcmp(v1->src.data, v2->src.data, v1->src.len) == 0 &&
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
v1->dst.type == v2->dst.type &&
|
1999-11-11 20:44:14 +00:00
|
|
|
v1->dst.len == v2->dst.len &&
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
memcmp(v1->dst.data, v2->dst.data, v1->dst.len) == 0) {
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
/*
|
1999-11-11 20:44:14 +00:00
|
|
|
* Yes. It's the same conversation, and the two
|
|
|
|
* address/port pairs are going in the same direction.
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
*/
|
1999-11-11 20:44:14 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
* Is the first source port the same as the second destination
|
|
|
|
* port, the first destination port the same as the first
|
|
|
|
* source port, the first source address the same as the second
|
|
|
|
* destination address, and the first destination address the
|
|
|
|
* same as the second source address?
|
1999-11-11 20:44:14 +00:00
|
|
|
*/
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
if (v1->port_src == v2->port_dst &&
|
|
|
|
v1->port_dst == v2->port_src &&
|
|
|
|
v1->src.type == v2->dst.type &&
|
|
|
|
v1->src.len == v2->dst.len &&
|
1999-11-11 20:44:14 +00:00
|
|
|
memcmp(v1->src.data, v2->dst.data, v1->src.len) == 0 &&
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
v1->dst.type == v2->src.type &&
|
1999-11-11 20:44:14 +00:00
|
|
|
v1->dst.len == v2->src.len &&
|
For ONC RPC, when constructing conversations, use a null address as the
destination address for calls and the source address of the reply - we
should't require the server address to be the same for a call and reply,
as they may not be on a multi-homed server (clients presumably check the
XID only, or perhaps the XID and the port whence the reply came,
although with TI-RPC I don't think they can check the port without
checking the address as well).
This requires that the conversation code not assume that the source and
destination addresses for a given packet in a conversation have the same
type, so, when comparing addresses for equality, it must explicitly
check the address types.
In said code, also check the port numbers before we check the addresses
- testing ports is cheaper, as they're just integers, and there's
probably a decent chance that you won't see two conversations between
different pairs of hosts and the *same* pair of ports in a capture file,
so the cheaper port tests are probably decently likely to fail first.
svn path=/trunk/; revision=1031
1999-11-14 21:16:58 +00:00
|
|
|
memcmp(v1->dst.data, v2->src.data, v1->dst.len) == 0) {
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
/*
|
1999-11-11 20:44:14 +00:00
|
|
|
* Yes. It's the same conversation, and the two
|
|
|
|
* address/port pairs are going in opposite directions.
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
*/
|
1999-11-11 20:44:14 +00:00
|
|
|
return 1;
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The addresses or the ports don't match.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compute the hash value for a given set of source and destination
|
|
|
|
* addresses and ports.
|
|
|
|
*/
|
|
|
|
static guint
|
|
|
|
conversation_hash(gconstpointer v)
|
|
|
|
{
|
|
|
|
conversation_key *key = (conversation_key *)v;
|
|
|
|
guint hash_val;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
hash_val = 0;
|
|
|
|
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];
|
|
|
|
hash_val += key->port_src + key->port_dst;
|
|
|
|
|
|
|
|
return hash_val;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize some variables every time a file is loaded or re-loaded.
|
|
|
|
* Destroy all existing conversations, and create a new hash table
|
|
|
|
* for the conversations in the new file.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
conversation_init(void)
|
|
|
|
{
|
|
|
|
conversation_key *key;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Free the addresses associated with the conversation keys.
|
|
|
|
*/
|
|
|
|
for (key = conversation_keys; key != NULL; key = key->next) {
|
|
|
|
/*
|
|
|
|
* 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);
|
|
|
|
}
|
1999-11-14 19:56:32 +00:00
|
|
|
conversation_keys = NULL;
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
if (conversation_hashtable != NULL)
|
|
|
|
g_hash_table_destroy(conversation_hashtable);
|
|
|
|
if (conversation_key_chunk != NULL)
|
|
|
|
g_mem_chunk_destroy(conversation_key_chunk);
|
Export the data structure used to represent a conversation.
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
|
|
|
if (conversation_chunk != NULL)
|
|
|
|
g_mem_chunk_destroy(conversation_chunk);
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
|
|
|
|
conversation_hashtable = g_hash_table_new(conversation_hash,
|
|
|
|
conversation_equal);
|
|
|
|
conversation_key_chunk = g_mem_chunk_new("conversation_key_chunk",
|
|
|
|
sizeof(conversation_key),
|
|
|
|
conversation_init_count * sizeof(struct conversation_key),
|
|
|
|
G_ALLOC_AND_FREE);
|
Export the data structure used to represent a conversation.
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
|
|
|
conversation_chunk = g_mem_chunk_new("conversation_chunk",
|
|
|
|
sizeof(conversation_t),
|
|
|
|
conversation_init_count * sizeof(conversation_t),
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
G_ALLOC_AND_FREE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Start the conversation indices over at 0.
|
|
|
|
*/
|
|
|
|
new_index = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copy an address, allocating a new buffer for the address data.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
copy_address(address *to, address *from)
|
|
|
|
{
|
|
|
|
guint8 *data;
|
|
|
|
|
|
|
|
to->type = from->type;
|
|
|
|
to->len = from->len;
|
|
|
|
data = g_malloc(from->len);
|
|
|
|
memcpy(data, from->data, from->len);
|
|
|
|
to->data = data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
Export the data structure used to represent a conversation.
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
|
|
|
* Given source and destination addresses and ports for a packet,
|
|
|
|
* create a new conversation to contain packets between those address/port
|
|
|
|
* pairs.
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
*/
|
Export the data structure used to represent a conversation.
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
|
|
|
conversation_t *
|
|
|
|
conversation_new(address *src, address *dst, port_type ptype,
|
|
|
|
guint16 src_port, guint16 dst_port, void *data)
|
|
|
|
{
|
|
|
|
conversation_t *conversation;
|
|
|
|
conversation_key *new_key;
|
|
|
|
|
|
|
|
new_key = g_mem_chunk_alloc(conversation_key_chunk);
|
|
|
|
new_key->next = conversation_keys;
|
|
|
|
conversation_keys = new_key;
|
|
|
|
copy_address(&new_key->src, src);
|
|
|
|
copy_address(&new_key->dst, dst);
|
|
|
|
new_key->ptype = ptype;
|
|
|
|
new_key->port_src = src_port;
|
|
|
|
new_key->port_dst = dst_port;
|
|
|
|
|
|
|
|
conversation = g_mem_chunk_alloc(conversation_chunk);
|
|
|
|
conversation->index = new_index;
|
|
|
|
conversation->data = data;
|
|
|
|
new_index++;
|
|
|
|
|
|
|
|
g_hash_table_insert(conversation_hashtable, new_key, conversation);
|
|
|
|
return conversation;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Given source and destination addresses and ports for a packet,
|
|
|
|
* search for a conversation containing packets between those address/port
|
|
|
|
* pairs. Returns NULL if not found.
|
|
|
|
*/
|
|
|
|
conversation_t *
|
|
|
|
find_conversation(address *src, address *dst, port_type ptype,
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
guint16 src_port, guint16 dst_port)
|
|
|
|
{
|
Export the data structure used to represent a conversation.
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
|
|
|
conversation_key key;
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't make a copy of the address data, we just copy the
|
|
|
|
* pointer to it, as "key" disappears when we return.
|
|
|
|
*/
|
|
|
|
key.src = *src;
|
|
|
|
key.dst = *dst;
|
|
|
|
key.ptype = ptype;
|
|
|
|
key.port_src = src_port;
|
|
|
|
key.port_dst = dst_port;
|
Export the data structure used to represent a conversation.
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
|
|
|
return g_hash_table_lookup(conversation_hashtable, &key);
|
Generalize the "ip_src" and "ip_dst" members of the "packet_info"
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
|
|
|
}
|