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"
|
|
|
|
*
|
2004-07-18 00:24:25 +00:00
|
|
|
* $Id$
|
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
|
2001-06-04 06:46:07 +00:00
|
|
|
* By Gerald Combs <gerald@ethereal.com>
|
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
|
|
|
* Copyright 1998 Gerald Combs
|
2002-08-28 20:41:00 +00:00
|
|
|
*
|
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
|
|
|
* 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 20:41:00 +00:00
|
|
|
*
|
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
|
|
|
* 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 20:41:00 +00:00
|
|
|
*
|
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
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
# include "config.h"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
#include <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
|
|
|
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
|
|
|
* Hash table for conversations with no wildcards.
|
|
|
|
*/
|
|
|
|
static GHashTable *conversation_hashtable_exact = NULL;
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Hash table for conversations with one wildcard address.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
static GHashTable *conversation_hashtable_no_addr2 = NULL;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Hash table for conversations with one wildcard port.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
static GHashTable *conversation_hashtable_no_port2 = NULL;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Hash table for conversations with one wildcard address and port.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
static GHashTable *conversation_hashtable_no_addr2_or_port2 = NULL;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
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 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
|
|
|
|
2002-08-28 20:41:00 +00:00
|
|
|
#ifdef __NOT_USED__
|
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;
|
2001-06-10 09:50:20 +00:00
|
|
|
address addr1;
|
|
|
|
address addr2;
|
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
|
|
|
port_type ptype;
|
2001-06-10 09:50:20 +00:00
|
|
|
guint32 port1;
|
|
|
|
guint32 port2;
|
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_key;
|
2000-10-21 05:52:28 +00:00
|
|
|
#endif
|
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
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
|
2001-09-03 10:33:12 +00:00
|
|
|
/*
|
|
|
|
* Protocol-specific data attached to a conversation_t structure - protocol
|
|
|
|
* index and opaque pointer.
|
|
|
|
*/
|
|
|
|
typedef struct _conv_proto_data {
|
|
|
|
int proto;
|
|
|
|
void *proto_data;
|
|
|
|
} conv_proto_data;
|
|
|
|
|
|
|
|
static GMemChunk *conv_proto_data_area = 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
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Compute the hash value for two given address/port pairs if the match
|
|
|
|
* is to be exact.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2002-08-28 20:41:00 +00:00
|
|
|
static guint
|
2000-10-21 09:54:12 +00:00
|
|
|
conversation_hash_exact(gconstpointer v)
|
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conversation_key *key = (const conversation_key *)v;
|
2000-10-21 09:54:12 +00:00
|
|
|
guint hash_val;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
hash_val = 0;
|
2001-06-10 09:50:20 +00:00
|
|
|
for (i = 0; i < key->addr1.len; i++)
|
|
|
|
hash_val += key->addr1.data[i];
|
2000-10-21 09:54:12 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
hash_val += key->port1;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
for (i = 0; i < key->addr2.len; i++)
|
|
|
|
hash_val += key->addr2.data[i];
|
2000-10-21 09:54:12 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
hash_val += key->port2;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
|
|
|
return hash_val;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compare two conversation keys for an exact match.
|
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 gint
|
2000-10-21 09:54:12 +00:00
|
|
|
conversation_match_exact(gconstpointer v, gconstpointer w)
|
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
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conversation_key *v1 = (const conversation_key *)v;
|
|
|
|
const conversation_key *v2 = (const conversation_key *)w;
|
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 (v1->ptype != v2->ptype)
|
|
|
|
return 0; /* different types of port */
|
|
|
|
|
1999-11-11 20:44:14 +00:00
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Are the first and second port 1 values the same, the first and
|
|
|
|
* second port 2 values the same, the first and second address
|
|
|
|
* 1 values the same, and the first and second address 2 values
|
|
|
|
* the same?
|
1999-11-11 20:44:14 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
if (v1->port1 == v2->port1 &&
|
|
|
|
v1->port2 == v2->port2 &&
|
|
|
|
ADDRESSES_EQUAL(&v1->addr1, &v2->addr1) &&
|
|
|
|
ADDRESSES_EQUAL(&v1->addr2, &v2->addr2)) {
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Is the first port 2 the same as the second port 1, the first
|
|
|
|
* port 1 the same as the second port 2, the first address 2
|
|
|
|
* the same as the second address 1, and the first address 1
|
|
|
|
* the same as the second address 2?
|
1999-11-11 20:44:14 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
if (v1->port2 == v2->port1 &&
|
|
|
|
v1->port1 == v2->port2 &&
|
|
|
|
ADDRESSES_EQUAL(&v1->addr2, &v2->addr1) &&
|
|
|
|
ADDRESSES_EQUAL(&v1->addr1, &v2->addr2)) {
|
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.
|
2002-08-28 20:41:00 +00:00
|
|
|
*/
|
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
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Compute the hash value for two given address/port pairs if the match
|
|
|
|
* has a wildcard address 2.
|
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
|
|
|
*/
|
2002-08-28 20:41:00 +00:00
|
|
|
static guint
|
2001-06-10 09:50:20 +00:00
|
|
|
conversation_hash_no_addr2(gconstpointer v)
|
2000-10-21 09:54:12 +00:00
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conversation_key *key = (const conversation_key *)v;
|
2000-10-21 09:54:12 +00:00
|
|
|
guint hash_val;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
hash_val = 0;
|
2001-06-10 09:50:20 +00:00
|
|
|
for (i = 0; i < key->addr1.len; i++)
|
|
|
|
hash_val += key->addr1.data[i];
|
2000-10-21 09:54:12 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
hash_val += key->port1;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
hash_val += key->port2;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
|
|
|
return hash_val;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Compare two conversation keys, except for the address 2 value.
|
2000-10-21 09:54:12 +00:00
|
|
|
* We don't check both directions of the conversation - the routine
|
|
|
|
* doing the hash lookup has to do two searches, as the hash key
|
|
|
|
* will be different for the two directions.
|
|
|
|
*/
|
|
|
|
static gint
|
2001-06-10 09:50:20 +00:00
|
|
|
conversation_match_no_addr2(gconstpointer v, gconstpointer w)
|
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
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conversation_key *v1 = (const conversation_key *)v;
|
|
|
|
const conversation_key *v2 = (const conversation_key *)w;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
|
|
|
if (v1->ptype != v2->ptype)
|
|
|
|
return 0; /* different types of port */
|
2000-10-21 05:52:28 +00:00
|
|
|
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Are the first and second port 1 values the same, the first and
|
|
|
|
* second port 2 valuess the same, and the first and second
|
|
|
|
* address 1 values the same?
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
if (v1->port1 == v2->port1 &&
|
|
|
|
v1->port2 == v2->port2 &&
|
|
|
|
ADDRESSES_EQUAL(&v1->addr1, &v2->addr1)) {
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
|
|
|
* Yes. It's the same conversation, and the two
|
|
|
|
* address/port pairs are going in the same direction.
|
|
|
|
*/
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The addresses or the ports don't match.
|
2002-08-28 20:41:00 +00:00
|
|
|
*/
|
2000-10-21 09:54:12 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Compute the hash value for two given address/port pairs if the match
|
|
|
|
* has a wildcard port 2.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2002-08-28 20:41:00 +00:00
|
|
|
static guint
|
2001-06-10 09:50:20 +00:00
|
|
|
conversation_hash_no_port2(gconstpointer v)
|
2000-10-21 09:54:12 +00:00
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conversation_key *key = (const conversation_key *)v;
|
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
|
|
|
guint hash_val;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
hash_val = 0;
|
2001-06-10 09:50:20 +00:00
|
|
|
for (i = 0; i < key->addr1.len; i++)
|
|
|
|
hash_val += key->addr1.data[i];
|
2000-10-21 05:52:28 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
hash_val += key->port1;
|
2000-10-21 05:52:28 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
for (i = 0; i < key->addr2.len; i++)
|
|
|
|
hash_val += key->addr2.data[i];
|
2000-10-21 05:52:28 +00:00
|
|
|
|
2000-10-21 09:54:12 +00:00
|
|
|
return hash_val;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Compare two conversation keys, except for the port 2 value.
|
2000-10-21 09:54:12 +00:00
|
|
|
* We don't check both directions of the conversation - the routine
|
|
|
|
* doing the hash lookup has to do two searches, as the hash key
|
|
|
|
* will be different for the two directions.
|
|
|
|
*/
|
|
|
|
static gint
|
2001-06-10 09:50:20 +00:00
|
|
|
conversation_match_no_port2(gconstpointer v, gconstpointer w)
|
2000-10-21 09:54:12 +00:00
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conversation_key *v1 = (const conversation_key *)v;
|
|
|
|
const conversation_key *v2 = (const conversation_key *)w;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
|
|
|
if (v1->ptype != v2->ptype)
|
|
|
|
return 0; /* different types of port */
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Are the first and second port 1 values the same, the first and
|
|
|
|
* second address 1 values the same, and the first and second
|
|
|
|
* address 2 values the same?
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
if (v1->port1 == v2->port1 &&
|
|
|
|
ADDRESSES_EQUAL(&v1->addr1, &v2->addr1) &&
|
|
|
|
ADDRESSES_EQUAL(&v1->addr2, &v2->addr2)) {
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
|
|
|
* Yes. It's the same conversation, and the two
|
|
|
|
* address/port pairs are going in the same direction.
|
|
|
|
*/
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The addresses or the ports don't match.
|
2002-08-28 20:41:00 +00:00
|
|
|
*/
|
2000-10-21 09:54:12 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Compute the hash value for two given address/port pairs if the match
|
|
|
|
* has a wildcard address 2 and port 2.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2002-08-28 20:41:00 +00:00
|
|
|
static guint
|
2001-06-10 09:50:20 +00:00
|
|
|
conversation_hash_no_addr2_or_port2(gconstpointer v)
|
2000-10-21 09:54:12 +00:00
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conversation_key *key = (const conversation_key *)v;
|
2000-10-21 09:54:12 +00:00
|
|
|
guint hash_val;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
hash_val = 0;
|
2001-06-10 09:50:20 +00:00
|
|
|
for (i = 0; i < key->addr1.len; i++)
|
|
|
|
hash_val += key->addr1.data[i];
|
2000-10-21 09:54:12 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
hash_val += key->port1;
|
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
|
|
|
|
|
|
|
return hash_val;
|
|
|
|
}
|
|
|
|
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Compare the address 1 and port 1 in the two conversation keys.
|
2000-10-21 09:54:12 +00:00
|
|
|
* We don't check both directions of the conversation - the routine
|
|
|
|
* doing the hash lookup has to do two searches, as the hash key
|
|
|
|
* will be different for the two directions.
|
|
|
|
*/
|
|
|
|
static gint
|
2001-06-10 09:50:20 +00:00
|
|
|
conversation_match_no_addr2_or_port2(gconstpointer v, gconstpointer w)
|
2000-10-21 09:54:12 +00:00
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conversation_key *v1 = (const conversation_key *)v;
|
|
|
|
const conversation_key *v2 = (const conversation_key *)w;
|
2000-10-21 09:54:12 +00:00
|
|
|
|
|
|
|
if (v1->ptype != v2->ptype)
|
|
|
|
return 0; /* different types of port */
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Are the first and second port 1 values the same and the first
|
|
|
|
* and second address 1 values the same?
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
if (v1->port1 == v2->port1 &&
|
|
|
|
ADDRESSES_EQUAL(&v1->addr1, &v2->addr1)) {
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
|
|
|
* Yes. It's the same conversation, and the two
|
|
|
|
* address/port pairs are going in the same direction.
|
|
|
|
*/
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The addresses or the ports don't match.
|
2002-08-28 20:41:00 +00:00
|
|
|
*/
|
2000-10-21 09:54:12 +00:00
|
|
|
return 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
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
g_free((gpointer)key->addr1.data);
|
|
|
|
g_free((gpointer)key->addr2.data);
|
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-14 19:56:32 +00:00
|
|
|
conversation_keys = NULL;
|
2000-10-21 09:54:12 +00:00
|
|
|
if (conversation_hashtable_exact != NULL)
|
|
|
|
g_hash_table_destroy(conversation_hashtable_exact);
|
2001-06-10 09:50:20 +00:00
|
|
|
if (conversation_hashtable_no_addr2 != NULL)
|
|
|
|
g_hash_table_destroy(conversation_hashtable_no_addr2);
|
|
|
|
if (conversation_hashtable_no_port2 != NULL)
|
|
|
|
g_hash_table_destroy(conversation_hashtable_no_port2);
|
|
|
|
if (conversation_hashtable_no_addr2_or_port2 != NULL)
|
|
|
|
g_hash_table_destroy(conversation_hashtable_no_addr2_or_port2);
|
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_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
|
|
|
|
2001-09-03 10:33:12 +00:00
|
|
|
/*
|
|
|
|
* Free up any space allocated for conversation protocol data
|
|
|
|
* areas.
|
|
|
|
*
|
|
|
|
* We can free the space, as the structures it contains are
|
|
|
|
* pointed to by conversation data structures that were freed
|
|
|
|
* above.
|
|
|
|
*/
|
|
|
|
if (conv_proto_data_area != NULL)
|
|
|
|
g_mem_chunk_destroy(conv_proto_data_area);
|
|
|
|
|
2000-10-21 09:54:12 +00:00
|
|
|
conversation_hashtable_exact =
|
|
|
|
g_hash_table_new(conversation_hash_exact,
|
|
|
|
conversation_match_exact);
|
2001-06-10 09:50:20 +00:00
|
|
|
conversation_hashtable_no_addr2 =
|
|
|
|
g_hash_table_new(conversation_hash_no_addr2,
|
|
|
|
conversation_match_no_addr2);
|
|
|
|
conversation_hashtable_no_port2 =
|
|
|
|
g_hash_table_new(conversation_hash_no_port2,
|
|
|
|
conversation_match_no_port2);
|
|
|
|
conversation_hashtable_no_addr2_or_port2 =
|
|
|
|
g_hash_table_new(conversation_hash_no_addr2_or_port2,
|
|
|
|
conversation_match_no_addr2_or_port2);
|
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_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);
|
|
|
|
|
2001-09-03 10:33:12 +00:00
|
|
|
/*
|
|
|
|
* Allocate a new area for conversation protocol data items.
|
|
|
|
*/
|
|
|
|
conv_proto_data_area = g_mem_chunk_new("conv_proto_data_area",
|
|
|
|
sizeof(conv_proto_data), 20 * sizeof(conv_proto_data), /* FIXME*/
|
|
|
|
G_ALLOC_ONLY);
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Start the conversation indices over at 0.
|
|
|
|
*/
|
|
|
|
new_index = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Given two address/port pairs for a packet, create a new conversation
|
|
|
|
* to contain packets between those address/port pairs.
|
|
|
|
*
|
|
|
|
* The options field is used to specify whether the address 2 value
|
|
|
|
* and/or port 2 value are not given and any value is acceptable
|
|
|
|
* when searching for this conversation.
|
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 *
|
2001-06-10 09:50:20 +00:00
|
|
|
conversation_new(address *addr1, address *addr2, port_type ptype,
|
2001-09-03 10:33:12 +00:00
|
|
|
guint32 port1, guint32 port2, guint options)
|
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;
|
|
|
|
conversation_key *new_key;
|
|
|
|
|
|
|
|
new_key = g_mem_chunk_alloc(conversation_key_chunk);
|
|
|
|
new_key->next = conversation_keys;
|
|
|
|
conversation_keys = new_key;
|
2001-06-10 09:50:20 +00:00
|
|
|
COPY_ADDRESS(&new_key->addr1, addr1);
|
|
|
|
COPY_ADDRESS(&new_key->addr2, addr2);
|
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
|
|
|
new_key->ptype = ptype;
|
2001-06-10 09:50:20 +00:00
|
|
|
new_key->port1 = port1;
|
|
|
|
new_key->port2 = port2;
|
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 = g_mem_chunk_alloc(conversation_chunk);
|
|
|
|
conversation->index = new_index;
|
2001-09-03 10:33:12 +00:00
|
|
|
conversation->data_list = NULL;
|
2000-04-12 22:53:16 +00:00
|
|
|
|
2001-11-27 07:13:32 +00:00
|
|
|
/* clear dissector handle */
|
|
|
|
conversation->dissector_handle = NULL;
|
2000-04-12 22:53:16 +00:00
|
|
|
|
2000-10-21 09:54:12 +00:00
|
|
|
/* set the options and key pointer */
|
|
|
|
conversation->options = options;
|
2000-10-21 05:52:28 +00:00
|
|
|
conversation->key_ptr = new_key;
|
|
|
|
|
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
|
|
|
new_index++;
|
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
if (options & NO_ADDR2) {
|
2004-07-06 19:01:32 +00:00
|
|
|
if (options & (NO_PORT2|NO_PORT2_FORCE)) {
|
2001-06-10 09:50:20 +00:00
|
|
|
g_hash_table_insert(conversation_hashtable_no_addr2_or_port2,
|
2000-10-21 09:54:12 +00:00
|
|
|
new_key, conversation);
|
|
|
|
} else {
|
2001-06-10 09:50:20 +00:00
|
|
|
g_hash_table_insert(conversation_hashtable_no_addr2,
|
2000-10-21 09:54:12 +00:00
|
|
|
new_key, conversation);
|
|
|
|
}
|
|
|
|
} else {
|
2004-07-06 19:01:32 +00:00
|
|
|
if (options & (NO_PORT2|NO_PORT2_FORCE)) {
|
2001-06-10 09:50:20 +00:00
|
|
|
g_hash_table_insert(conversation_hashtable_no_port2,
|
2000-10-21 09:54:12 +00:00
|
|
|
new_key, conversation);
|
|
|
|
} else {
|
|
|
|
g_hash_table_insert(conversation_hashtable_exact,
|
|
|
|
new_key, conversation);
|
|
|
|
}
|
|
|
|
}
|
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 conversation;
|
|
|
|
}
|
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
/*
|
|
|
|
* Set the port 2 value in a key. Remove the original from table,
|
|
|
|
* update the options and port values, insert the updated key.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
conversation_set_port2(conversation_t *conv, guint32 port)
|
|
|
|
{
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
2004-01-09 00:57:48 +00:00
|
|
|
* If the port 2 value is not wildcarded, don't set it.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2004-07-06 19:01:32 +00:00
|
|
|
if ((!(conv->options & NO_PORT2)) || (conv->options & NO_PORT2_FORCE))
|
2000-10-21 09:54:12 +00:00
|
|
|
return;
|
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
if (conv->options & NO_ADDR2) {
|
|
|
|
g_hash_table_remove(conversation_hashtable_no_addr2_or_port2,
|
2000-10-21 09:54:12 +00:00
|
|
|
conv->key_ptr);
|
|
|
|
} else {
|
2001-06-10 09:50:20 +00:00
|
|
|
g_hash_table_remove(conversation_hashtable_no_port2,
|
2000-10-21 09:54:12 +00:00
|
|
|
conv->key_ptr);
|
|
|
|
}
|
2001-06-10 09:50:20 +00:00
|
|
|
conv->options &= ~NO_PORT2;
|
|
|
|
conv->key_ptr->port2 = port;
|
|
|
|
if (conv->options & NO_ADDR2) {
|
|
|
|
g_hash_table_insert(conversation_hashtable_no_addr2,
|
2000-10-21 09:54:12 +00:00
|
|
|
conv->key_ptr, conv);
|
|
|
|
} else {
|
|
|
|
g_hash_table_insert(conversation_hashtable_exact,
|
|
|
|
conv->key_ptr, conv);
|
|
|
|
}
|
2002-08-28 20:41:00 +00:00
|
|
|
}
|
2000-10-21 05:52:28 +00:00
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
/*
|
|
|
|
* Set the address 2 value in a key. Remove the original from
|
|
|
|
* table, update the options and port values, insert the updated key.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
conversation_set_addr2(conversation_t *conv, address *addr)
|
|
|
|
{
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
2004-01-09 00:57:48 +00:00
|
|
|
* If the address 2 value is not wildcarded, don't set it.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
if (!(conv->options & NO_ADDR2))
|
2000-10-21 09:54:12 +00:00
|
|
|
return;
|
|
|
|
|
2001-06-10 09:50:20 +00:00
|
|
|
if (conv->options & NO_PORT2) {
|
|
|
|
g_hash_table_remove(conversation_hashtable_no_addr2_or_port2,
|
2000-10-21 09:54:12 +00:00
|
|
|
conv->key_ptr);
|
|
|
|
} else {
|
2001-06-10 09:50:20 +00:00
|
|
|
g_hash_table_remove(conversation_hashtable_no_addr2,
|
2000-10-21 09:54:12 +00:00
|
|
|
conv->key_ptr);
|
|
|
|
}
|
2001-06-10 09:50:20 +00:00
|
|
|
conv->options &= ~NO_ADDR2;
|
|
|
|
COPY_ADDRESS(&conv->key_ptr->addr2, addr);
|
|
|
|
if (conv->options & NO_PORT2) {
|
|
|
|
g_hash_table_insert(conversation_hashtable_no_port2,
|
2000-10-21 09:54:12 +00:00
|
|
|
conv->key_ptr, conv);
|
|
|
|
} else {
|
|
|
|
g_hash_table_insert(conversation_hashtable_exact,
|
|
|
|
conv->key_ptr, conv);
|
|
|
|
}
|
2000-10-21 05:52:28 +00:00
|
|
|
}
|
2000-10-21 09:54:12 +00:00
|
|
|
|
2001-09-03 00:26:31 +00:00
|
|
|
/*
|
|
|
|
* Search a particular hash table for a conversaton with the specified
|
|
|
|
* addr1, port1, addr2, and port2.
|
|
|
|
*/
|
2000-10-21 09:54:12 +00:00
|
|
|
static conversation_t *
|
2001-09-03 00:26:31 +00:00
|
|
|
conversation_lookup_hashtable(GHashTable *hashtable, address *addr1, address *addr2,
|
2001-06-10 09:50:20 +00:00
|
|
|
port_type ptype, guint32 port1, guint32 port2)
|
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_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.
|
|
|
|
*/
|
2001-06-10 09:50:20 +00:00
|
|
|
key.addr1 = *addr1;
|
|
|
|
key.addr2 = *addr2;
|
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
|
|
|
key.ptype = ptype;
|
2001-06-10 09:50:20 +00:00
|
|
|
key.port1 = port1;
|
|
|
|
key.port2 = port2;
|
2000-10-21 09:54:12 +00:00
|
|
|
return g_hash_table_lookup(hashtable, &key);
|
|
|
|
}
|
2002-08-28 20:41:00 +00:00
|
|
|
|
2001-09-03 00:26:31 +00:00
|
|
|
|
2000-10-21 09:54:12 +00:00
|
|
|
/*
|
2001-06-10 09:50:20 +00:00
|
|
|
* Given two address/port pairs for a packet, search for a conversation
|
|
|
|
* containing packets between those address/port pairs. Returns NULL if
|
2001-09-03 00:26:31 +00:00
|
|
|
* not found.
|
|
|
|
*
|
|
|
|
* We try to find the most exact match that we can, and then proceed to
|
|
|
|
* try wildcard matches on the "addr_b" and/or "port_b" argument if a more
|
|
|
|
* exact match failed.
|
|
|
|
*
|
|
|
|
* Either or both of the "addr_b" and "port_b" arguments may be specified as
|
|
|
|
* a wildcard by setting the NO_ADDR_B or NO_PORT_B flags in the "options"
|
|
|
|
* argument. We do only wildcard matches on addresses and ports specified
|
|
|
|
* as wildcards.
|
|
|
|
*
|
|
|
|
* I.e.:
|
|
|
|
*
|
|
|
|
* if neither "addr_b" nor "port_b" were specified as wildcards, we
|
|
|
|
* do an exact match (addr_a/port_a and addr_b/port_b) and, if that
|
|
|
|
* succeeds, we return a pointer to the matched conversation;
|
|
|
|
*
|
|
|
|
* otherwise, if "port_b" wasn't specified as a wildcard, we try to
|
|
|
|
* match any address 2 with the specified port 2 (addr_a/port_a and
|
|
|
|
* {any}/addr_b) and, if that succeeds, we return a pointer to the
|
|
|
|
* matched conversation;
|
|
|
|
*
|
|
|
|
* otherwise, if "addr_b" wasn't specified as a wildcard, we try to
|
|
|
|
* match any port 2 with the specified address 2 (addr_a/port_a and
|
|
|
|
* addr_b/{any}) and, if that succeeds, we return a pointer to the
|
|
|
|
* matched conversation;
|
|
|
|
*
|
|
|
|
* otherwise, we try to match any address 2 and any port 2
|
|
|
|
* (addr_a/port_a and {any}/{any}) and, if that succeeds, we return
|
|
|
|
* a pointer to the matched conversation;
|
|
|
|
*
|
|
|
|
* otherwise, we found no matching conversation, and return NULL.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
|
|
|
conversation_t *
|
2001-06-10 09:50:20 +00:00
|
|
|
find_conversation(address *addr_a, address *addr_b, port_type ptype,
|
|
|
|
guint32 port_a, guint32 port_b, guint options)
|
2000-10-21 09:54:12 +00:00
|
|
|
{
|
|
|
|
conversation_t *conversation;
|
|
|
|
|
2001-09-03 07:31:20 +00:00
|
|
|
/*
|
|
|
|
* First try an exact match, if we have two addresses and ports.
|
|
|
|
*/
|
2001-09-03 00:26:31 +00:00
|
|
|
if (!(options & (NO_ADDR_B|NO_PORT_B))) {
|
|
|
|
/*
|
2001-09-03 07:31:20 +00:00
|
|
|
* Neither search address B nor search port B are wildcarded,
|
|
|
|
* start out with an exact match.
|
2001-09-03 00:26:31 +00:00
|
|
|
* Exact matches check both directions.
|
|
|
|
*/
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_exact,
|
2002-12-08 02:32:36 +00:00
|
|
|
addr_a, addr_b, ptype,
|
|
|
|
port_a, port_b);
|
|
|
|
if ((conversation == NULL) && (addr_a->type == AT_FC)) {
|
|
|
|
/* In Fibre channel, OXID & RXID are never swapped as
|
|
|
|
* TCP/UDP ports are in TCP/IP.
|
|
|
|
*/
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_exact,
|
|
|
|
addr_b, addr_a, ptype,
|
|
|
|
port_a, port_b);
|
|
|
|
}
|
2001-09-03 00:26:31 +00:00
|
|
|
if (conversation != NULL)
|
|
|
|
return conversation;
|
|
|
|
}
|
|
|
|
|
2001-09-03 07:31:20 +00:00
|
|
|
/*
|
|
|
|
* Well, that didn't find anything. Try matches that wildcard
|
|
|
|
* one of the addresses, if we have two ports.
|
|
|
|
*/
|
2001-09-03 00:26:31 +00:00
|
|
|
if (!(options & NO_PORT_B)) {
|
|
|
|
/*
|
2001-09-03 07:31:20 +00:00
|
|
|
* Search port B isn't wildcarded.
|
2001-09-03 00:26:31 +00:00
|
|
|
*
|
|
|
|
* First try looking for a conversation with the specified
|
2001-09-03 07:31:20 +00:00
|
|
|
* address A and port A as the first address and port, and
|
|
|
|
* with any address and the specified port B as the second
|
|
|
|
* address and port.
|
|
|
|
* ("addr_b" doesn't take part in this lookup.)
|
2001-09-03 00:26:31 +00:00
|
|
|
*/
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_addr2,
|
|
|
|
addr_a, addr_b, ptype, port_a, port_b);
|
2002-12-08 02:32:36 +00:00
|
|
|
if ((conversation == NULL) && (addr_a->type == AT_FC)) {
|
|
|
|
/* In Fibre channel, OXID & RXID are never swapped as
|
|
|
|
* TCP/UDP ports are in TCP/IP.
|
|
|
|
*/
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_addr2,
|
|
|
|
addr_b, addr_a, ptype,
|
|
|
|
port_a, port_b);
|
|
|
|
}
|
2001-09-03 07:31:20 +00:00
|
|
|
if (conversation != NULL) {
|
|
|
|
/*
|
|
|
|
* If search address B isn't wildcarded, and this
|
|
|
|
* is for a connection-oriented protocol, set the
|
|
|
|
* second address for this conversation to address
|
|
|
|
* B, as that's the address that matched the
|
|
|
|
* wildcarded second address for this conversation.
|
|
|
|
*
|
|
|
|
* (XXX - this assumes that, for all connection-
|
|
|
|
* oriented protocols, the endpoints of a connection
|
|
|
|
* have only one address each, i.e. you don't get
|
|
|
|
* packets in a given direction coming from more than
|
2002-08-28 20:41:00 +00:00
|
|
|
* one address.)
|
2001-09-03 07:31:20 +00:00
|
|
|
*/
|
|
|
|
if (!(options & NO_ADDR_B) && ptype != PT_UDP)
|
|
|
|
conversation_set_addr2(conversation, addr_b);
|
2001-09-03 00:26:31 +00:00
|
|
|
return conversation;
|
2001-09-03 07:31:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Well, that didn't find anything.
|
|
|
|
* If search address B was specified, try looking for a
|
|
|
|
* conversation with the specified address B and port B as
|
|
|
|
* the first address and port, and with any address and the
|
|
|
|
* specified port A as the second address and port (this
|
|
|
|
* packet may be going in the opposite direction from the
|
|
|
|
* first packet in the conversation).
|
|
|
|
* ("addr_a" doesn't take part in this lookup.)
|
|
|
|
*/
|
|
|
|
if (!(options & NO_ADDR_B)) {
|
2002-12-08 02:32:36 +00:00
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_addr2,
|
|
|
|
addr_b, addr_a, ptype, port_b, port_a);
|
2001-09-03 07:31:20 +00:00
|
|
|
if (conversation != NULL) {
|
|
|
|
/*
|
|
|
|
* If this is for a connection-oriented
|
|
|
|
* protocol, set the second address for
|
|
|
|
* this conversation to address A, as
|
|
|
|
* that's the address that matched the
|
|
|
|
* wildcarded second address for this
|
|
|
|
* conversation.
|
|
|
|
*/
|
|
|
|
if (ptype != PT_UDP) {
|
|
|
|
conversation_set_addr2(conversation,
|
|
|
|
addr_a);
|
|
|
|
}
|
|
|
|
return conversation;
|
|
|
|
}
|
|
|
|
}
|
2001-09-03 00:26:31 +00:00
|
|
|
}
|
|
|
|
|
2001-09-03 07:31:20 +00:00
|
|
|
/*
|
|
|
|
* Well, that didn't find anything. Try matches that wildcard
|
|
|
|
* one of the ports, if we have two addresses.
|
|
|
|
*/
|
2001-09-03 00:26:31 +00:00
|
|
|
if (!(options & NO_ADDR_B)) {
|
|
|
|
/*
|
2001-09-03 07:31:20 +00:00
|
|
|
* Search address B isn't wildcarded.
|
2001-09-03 00:26:31 +00:00
|
|
|
*
|
|
|
|
* First try looking for a conversation with the specified
|
2001-09-03 07:31:20 +00:00
|
|
|
* address A and port A as the first address and port, and
|
|
|
|
* with the specified address B and any port as the second
|
|
|
|
* address and port.
|
|
|
|
* ("port_b" doesn't take part in this lookup.)
|
2001-09-03 00:26:31 +00:00
|
|
|
*/
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_port2,
|
|
|
|
addr_a, addr_b, ptype, port_a, port_b);
|
2002-12-08 02:32:36 +00:00
|
|
|
if ((conversation == NULL) && (addr_a->type == AT_FC)) {
|
|
|
|
/* In Fibre channel, OXID & RXID are never swapped as
|
|
|
|
* TCP/UDP ports are in TCP/IP
|
|
|
|
*/
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_port2,
|
|
|
|
addr_b, addr_a, ptype, port_a, port_b);
|
|
|
|
}
|
2001-09-03 07:31:20 +00:00
|
|
|
if (conversation != NULL) {
|
|
|
|
/*
|
|
|
|
* If search port B isn't wildcarded, and this is
|
|
|
|
* for a connection-oriented protocol, set the
|
|
|
|
* second port for this conversation to port B,
|
|
|
|
* as that's the port that matched the wildcarded
|
|
|
|
* second port for this conversation.
|
|
|
|
*
|
|
|
|
* (XXX - this assumes that, for all connection-
|
|
|
|
* oriented protocols, the endpoints of a connection
|
|
|
|
* have only one port each, i.e. you don't get
|
|
|
|
* packets in a given direction coming from more than
|
|
|
|
* one port.)
|
|
|
|
*/
|
|
|
|
if (!(options & NO_PORT_B) && ptype != PT_UDP)
|
|
|
|
conversation_set_port2(conversation, port_b);
|
2001-09-03 00:26:31 +00:00
|
|
|
return conversation;
|
2001-09-03 07:31:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Well, that didn't find anything.
|
|
|
|
* If search port B was specified, try looking for a
|
|
|
|
* conversation with the specified address B and port B
|
|
|
|
* as the first address and port, and with the specified
|
|
|
|
* address A and any port as the second address and port
|
|
|
|
* (this packet may be going in the opposite direction
|
|
|
|
* from the first packet in the conversation).
|
|
|
|
* ("port_a" doesn't take part in this lookup.)
|
|
|
|
*/
|
|
|
|
if (!(options & NO_PORT_B)) {
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_port2,
|
|
|
|
addr_b, addr_a, ptype, port_b, port_a);
|
|
|
|
if (conversation != NULL) {
|
|
|
|
/*
|
|
|
|
* If this is for a connection-oriented
|
|
|
|
* protocol, set the second port for
|
|
|
|
* this conversation to port A, as
|
|
|
|
* that's the address that matched the
|
|
|
|
* wildcarded second address for this
|
|
|
|
* conversation.
|
|
|
|
*/
|
|
|
|
if (ptype != PT_UDP) {
|
|
|
|
conversation_set_port2(conversation,
|
|
|
|
port_a);
|
|
|
|
}
|
|
|
|
return conversation;
|
|
|
|
}
|
|
|
|
}
|
2000-10-21 09:54:12 +00:00
|
|
|
}
|
2001-09-03 00:26:31 +00:00
|
|
|
|
|
|
|
/*
|
2001-09-03 07:31:20 +00:00
|
|
|
* Well, that didn't find anything. Try matches that wildcard
|
|
|
|
* one address/port pair.
|
2001-09-03 00:26:31 +00:00
|
|
|
*
|
2001-09-03 07:31:20 +00:00
|
|
|
* First try looking for a conversation with the specified address A
|
2002-05-09 12:10:06 +00:00
|
|
|
* and port A as the first address and port.
|
2001-09-03 07:31:20 +00:00
|
|
|
* (Neither "addr_b" nor "port_b" take part in this lookup.)
|
|
|
|
*/
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_addr2_or_port2,
|
|
|
|
addr_a, addr_b, ptype, port_a, port_b);
|
|
|
|
if (conversation != NULL) {
|
|
|
|
/*
|
|
|
|
* If this is for a connection-oriented protocol:
|
|
|
|
*
|
|
|
|
* if search address B isn't wildcarded, set the
|
|
|
|
* second address for this conversation to address
|
|
|
|
* B, as that's the address that matched the
|
|
|
|
* wildcarded second address for this conversation;
|
|
|
|
*
|
|
|
|
* if search port B isn't wildcarded, set the
|
|
|
|
* second port for this conversation to port B,
|
|
|
|
* as that's the port that matched the wildcarded
|
|
|
|
* second port for this conversation.
|
|
|
|
*/
|
|
|
|
if (ptype != PT_UDP) {
|
|
|
|
if (!(options & NO_ADDR_B))
|
|
|
|
conversation_set_addr2(conversation, addr_b);
|
|
|
|
if (!(options & NO_PORT_B))
|
|
|
|
conversation_set_port2(conversation, port_b);
|
|
|
|
}
|
|
|
|
return conversation;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Well, that didn't find anything.
|
|
|
|
* If search address and port B were specified, try looking for a
|
|
|
|
* conversation with the specified address B and port B as the
|
|
|
|
* first address and port, and with any second address and port
|
|
|
|
* (this packet may be going in the opposite direction from the
|
|
|
|
* first packet in the conversation).
|
|
|
|
* (Neither "addr_a" nor "port_a" take part in this lookup.)
|
2001-09-03 00:26:31 +00:00
|
|
|
*/
|
2002-12-08 02:32:36 +00:00
|
|
|
if (addr_a->type == AT_FC)
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_addr2_or_port2,
|
|
|
|
addr_b, addr_a, ptype, port_a,
|
|
|
|
port_b);
|
|
|
|
else
|
|
|
|
conversation =
|
|
|
|
conversation_lookup_hashtable(conversation_hashtable_no_addr2_or_port2,
|
|
|
|
addr_b, addr_a, ptype, port_b,
|
|
|
|
port_a);
|
2001-09-03 07:31:20 +00:00
|
|
|
if (conversation != NULL) {
|
|
|
|
/*
|
|
|
|
* If this is for a connection-oriented protocol, set the
|
|
|
|
* second address for this conversation to address A, as
|
|
|
|
* that's the address that matched the wildcarded second
|
|
|
|
* address for this conversation, and set the second port
|
|
|
|
* for this conversation to port A, as that's the port
|
|
|
|
* that matched the wildcarded second port for this
|
|
|
|
* conversation.
|
|
|
|
*/
|
|
|
|
if (ptype != PT_UDP) {
|
|
|
|
conversation_set_addr2(conversation, addr_a);
|
|
|
|
conversation_set_port2(conversation, port_a);
|
|
|
|
}
|
2001-09-03 00:26:31 +00:00
|
|
|
return conversation;
|
2001-09-03 07:31:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We found no conversation.
|
|
|
|
*/
|
|
|
|
return 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
|
|
|
}
|
2000-04-12 22:53:16 +00:00
|
|
|
|
2001-09-03 10:33:12 +00:00
|
|
|
static gint
|
|
|
|
p_compare(gconstpointer a, gconstpointer b)
|
|
|
|
{
|
2002-11-27 22:44:41 +00:00
|
|
|
const conv_proto_data *ap = (const conv_proto_data *)a;
|
|
|
|
const conv_proto_data *bp = (const conv_proto_data *)b;
|
|
|
|
|
|
|
|
if (ap->proto > bp->proto)
|
2001-09-03 10:33:12 +00:00
|
|
|
return 1;
|
2002-11-27 22:44:41 +00:00
|
|
|
else if (ap->proto == bp->proto)
|
2001-09-03 10:33:12 +00:00
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
conversation_add_proto_data(conversation_t *conv, int proto, void *proto_data)
|
|
|
|
{
|
|
|
|
conv_proto_data *p1 = g_mem_chunk_alloc(conv_proto_data_area);
|
|
|
|
|
|
|
|
p1->proto = proto;
|
|
|
|
p1->proto_data = proto_data;
|
|
|
|
|
|
|
|
/* Add it to the list of items for this conversation. */
|
|
|
|
|
|
|
|
conv->data_list = g_slist_insert_sorted(conv->data_list, (gpointer *)p1,
|
|
|
|
p_compare);
|
|
|
|
}
|
|
|
|
|
|
|
|
void *
|
|
|
|
conversation_get_proto_data(conversation_t *conv, int proto)
|
|
|
|
{
|
|
|
|
conv_proto_data temp, *p1;
|
|
|
|
GSList *item;
|
|
|
|
|
|
|
|
temp.proto = proto;
|
|
|
|
temp.proto_data = NULL;
|
|
|
|
|
|
|
|
item = g_slist_find_custom(conv->data_list, (gpointer *)&temp,
|
|
|
|
p_compare);
|
|
|
|
|
|
|
|
if (item != NULL) {
|
|
|
|
p1 = (conv_proto_data *)item->data;
|
|
|
|
return p1->proto_data;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
conversation_delete_proto_data(conversation_t *conv, int proto)
|
|
|
|
{
|
|
|
|
conv_proto_data temp;
|
|
|
|
GSList *item;
|
|
|
|
|
|
|
|
temp.proto = proto;
|
|
|
|
temp.proto_data = NULL;
|
|
|
|
|
|
|
|
item = g_slist_find_custom(conv->data_list, (gpointer *)&temp,
|
|
|
|
p_compare);
|
|
|
|
|
|
|
|
if (item != NULL)
|
|
|
|
conv->data_list = g_slist_remove(conv->data_list, item);
|
|
|
|
}
|
|
|
|
|
2000-08-21 18:36:35 +00:00
|
|
|
void
|
|
|
|
conversation_set_dissector(conversation_t *conversation,
|
2001-11-27 07:13:32 +00:00
|
|
|
dissector_handle_t handle)
|
2000-08-21 18:36:35 +00:00
|
|
|
{
|
2001-11-27 07:13:32 +00:00
|
|
|
conversation->dissector_handle = handle;
|
2000-08-21 18:36:35 +00:00
|
|
|
}
|
|
|
|
|
2000-10-21 05:52:28 +00:00
|
|
|
/*
|
2001-09-03 00:26:31 +00:00
|
|
|
* Given two address/port pairs for a packet, search for a matching
|
|
|
|
* conversation and, if found and it has a conversation dissector,
|
|
|
|
* call that dissector and return TRUE, otherwise return FALSE.
|
2000-10-21 09:54:12 +00:00
|
|
|
*/
|
Allow either old-style (pre-tvbuff) or new-style (tvbuffified)
dissectors to be registered as dissectors for particular ports,
registered as heuristic dissectors, and registered as dissectors for
conversations, and have routines to be used both by old-style and
new-style dissectors to call registered dissectors.
Have the code that calls those dissectors translate the arguments as
necessary. (For conversation dissectors, replace
"find_conversation_dissector()", which just returns a pointer to the
dissector, with "old_try_conversation_dissector()" and
"try_conversation_dissector()", which actually call the dissector, so
that there's a single place at which we can do that translation. Also
make "dissector_lookup()" static and, instead of calling it and, if it
returns a non-null pointer, calling that dissector, just use
"old_dissector_try_port()" or "dissector_try_port()", for the same
reason.)
This allows some dissectors that took old-style arguments and
immediately translated them to new-style arguments to just take
new-style arguments; make them do so. It also allows some new-style
dissectors not to have to translate arguments before calling routines to
look up and call dissectors; make them not do so.
Get rid of checks for too-short frames in new-style dissectors - the
tvbuff code does those checks for you.
Give the routines to register old-style dissectors, and to call
dissectors from old-style dissectors, names beginning with "old_", with
the routines for new-style dissectors not having the "old_". Update the
dissectors that use those routines appropriately.
Rename "dissect_data()" to "old_dissect_data()", and
"dissect_data_tvb()" to "dissect_data()".
svn path=/trunk/; revision=2218
2000-08-07 03:21:25 +00:00
|
|
|
gboolean
|
2001-06-10 09:50:20 +00:00
|
|
|
try_conversation_dissector(address *addr_a, address *addr_b, port_type ptype,
|
|
|
|
guint32 port_a, guint32 port_b, tvbuff_t *tvb, packet_info *pinfo,
|
Allow either old-style (pre-tvbuff) or new-style (tvbuffified)
dissectors to be registered as dissectors for particular ports,
registered as heuristic dissectors, and registered as dissectors for
conversations, and have routines to be used both by old-style and
new-style dissectors to call registered dissectors.
Have the code that calls those dissectors translate the arguments as
necessary. (For conversation dissectors, replace
"find_conversation_dissector()", which just returns a pointer to the
dissector, with "old_try_conversation_dissector()" and
"try_conversation_dissector()", which actually call the dissector, so
that there's a single place at which we can do that translation. Also
make "dissector_lookup()" static and, instead of calling it and, if it
returns a non-null pointer, calling that dissector, just use
"old_dissector_try_port()" or "dissector_try_port()", for the same
reason.)
This allows some dissectors that took old-style arguments and
immediately translated them to new-style arguments to just take
new-style arguments; make them do so. It also allows some new-style
dissectors not to have to translate arguments before calling routines to
look up and call dissectors; make them not do so.
Get rid of checks for too-short frames in new-style dissectors - the
tvbuff code does those checks for you.
Give the routines to register old-style dissectors, and to call
dissectors from old-style dissectors, names beginning with "old_", with
the routines for new-style dissectors not having the "old_". Update the
dissectors that use those routines appropriately.
Rename "dissect_data()" to "old_dissect_data()", and
"dissect_data_tvb()" to "dissect_data()".
svn path=/trunk/; revision=2218
2000-08-07 03:21:25 +00:00
|
|
|
proto_tree *tree)
|
|
|
|
{
|
|
|
|
conversation_t *conversation;
|
|
|
|
|
2001-09-03 00:26:31 +00:00
|
|
|
conversation = find_conversation(addr_a, addr_b, ptype, port_a,
|
|
|
|
port_b, 0);
|
2002-08-28 20:41:00 +00:00
|
|
|
|
Allow either old-style (pre-tvbuff) or new-style (tvbuffified)
dissectors to be registered as dissectors for particular ports,
registered as heuristic dissectors, and registered as dissectors for
conversations, and have routines to be used both by old-style and
new-style dissectors to call registered dissectors.
Have the code that calls those dissectors translate the arguments as
necessary. (For conversation dissectors, replace
"find_conversation_dissector()", which just returns a pointer to the
dissector, with "old_try_conversation_dissector()" and
"try_conversation_dissector()", which actually call the dissector, so
that there's a single place at which we can do that translation. Also
make "dissector_lookup()" static and, instead of calling it and, if it
returns a non-null pointer, calling that dissector, just use
"old_dissector_try_port()" or "dissector_try_port()", for the same
reason.)
This allows some dissectors that took old-style arguments and
immediately translated them to new-style arguments to just take
new-style arguments; make them do so. It also allows some new-style
dissectors not to have to translate arguments before calling routines to
look up and call dissectors; make them not do so.
Get rid of checks for too-short frames in new-style dissectors - the
tvbuff code does those checks for you.
Give the routines to register old-style dissectors, and to call
dissectors from old-style dissectors, names beginning with "old_", with
the routines for new-style dissectors not having the "old_". Update the
dissectors that use those routines appropriately.
Rename "dissect_data()" to "old_dissect_data()", and
"dissect_data_tvb()" to "dissect_data()".
svn path=/trunk/; revision=2218
2000-08-07 03:21:25 +00:00
|
|
|
if (conversation != NULL) {
|
2002-10-29 07:22:55 +00:00
|
|
|
if (conversation->dissector_handle == NULL)
|
2001-10-31 05:59:20 +00:00
|
|
|
return FALSE;
|
2001-11-27 07:13:32 +00:00
|
|
|
call_dissector(conversation->dissector_handle, tvb, pinfo,
|
|
|
|
tree);
|
2000-11-18 07:00:31 +00:00
|
|
|
return TRUE;
|
Allow either old-style (pre-tvbuff) or new-style (tvbuffified)
dissectors to be registered as dissectors for particular ports,
registered as heuristic dissectors, and registered as dissectors for
conversations, and have routines to be used both by old-style and
new-style dissectors to call registered dissectors.
Have the code that calls those dissectors translate the arguments as
necessary. (For conversation dissectors, replace
"find_conversation_dissector()", which just returns a pointer to the
dissector, with "old_try_conversation_dissector()" and
"try_conversation_dissector()", which actually call the dissector, so
that there's a single place at which we can do that translation. Also
make "dissector_lookup()" static and, instead of calling it and, if it
returns a non-null pointer, calling that dissector, just use
"old_dissector_try_port()" or "dissector_try_port()", for the same
reason.)
This allows some dissectors that took old-style arguments and
immediately translated them to new-style arguments to just take
new-style arguments; make them do so. It also allows some new-style
dissectors not to have to translate arguments before calling routines to
look up and call dissectors; make them not do so.
Get rid of checks for too-short frames in new-style dissectors - the
tvbuff code does those checks for you.
Give the routines to register old-style dissectors, and to call
dissectors from old-style dissectors, names beginning with "old_", with
the routines for new-style dissectors not having the "old_". Update the
dissectors that use those routines appropriately.
Rename "dissect_data()" to "old_dissect_data()", and
"dissect_data_tvb()" to "dissect_data()".
svn path=/trunk/; revision=2218
2000-08-07 03:21:25 +00:00
|
|
|
}
|
|
|
|
return FALSE;
|
2000-04-12 22:53:16 +00:00
|
|
|
}
|