osmith
/
wireshark
forked from osmocom/wireshark
1
0
Fork 0
Code Pull Requests Releases Wiki Activity
wireshark/epan/conversation.c

702 lines
19 KiB
C
Raw Normal View History

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"
*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* $Id: conversation.c,v 1.10 2001/06/10 09:50:20 guy Exp $
Generalize the "ip_src" and "ip_dst" members of the "packet_info" structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst" addresses, where an address is an address type, an address length in bytes, and a pointer to that many bytes. "dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}" are the network-layer source/destination; "{src,dst}" are the source/destination from the highest of those two layers that we have in the packet. Add a port type to "packet_info" as well, specifying whether it's a TCP or UDP port. Don't set the address and port columns in the dissector functions; just set the address and port members of the "packet_info" structure. Set the columns in "fill_in_columns()"; this means that if we're showing COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate the string from "src" or "dst", we don't generate a string for the link-layer address and then overwrite it with a string for the network-layer address (generating those strings costs CPU). Add support for "conversations", where a "conversation" is (at present) a source and destination address and a source and destination port. (In the future, we may support "conversations" above the transport layer, e.g. a TFTP conversation, where the first packet goes from the client to the TFTP server port, but the reply comes back from a different port, and all subsequent packets go between the client address/port and the server address/new port, or an NFS conversation, which might include lock manager, status monitor, and mount packets, as well as NFS packets.) Currently, all we support is a call that takes the source and destination address/port pairs, looks them up in a hash table, and: if nothing is found, creates a new entry in the hash table, and assigns it a unique 32-bit conversation ID, and returns that conversation ID; if an entry is found, returns its conversation ID. Use that in the SMB and AFS code to keep track of individual SMB or AFS conversations. We need to match up requests and replies, as, for certain replies, the operation code for the request to which it's a reply doesn't show up in the reply - you have to find the request with a matching transaction ID. Transaction IDs are per-conversation, so the hash table for requests should include a conversation ID and transaction ID as the key. This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses transparently (and should allow the SMB decoder to handle NetBIOS atop other protocols as well, if the source and destination address and port values in the "packet_info" structure are set appropriately). In the "Follow TCP Connection" code, check to make sure that the addresses are IPv4 addressses; ultimately, that code should be changed to use the conversation code instead, which will let it handle IPv6 transparently. svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
*
* Ethereal - Network traffic analyzer
Add an "ADDRESSES_EQUAL()" macro, taking pointers to two "address" structures as arguments, that evaluates to "true" if the two addresses are equal and "false" if they're not equal. Use that macro in the conversation code. svn path=/trunk/; revision=3509
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
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
#include <stdio.h>
#ifdef HAVE_SYS_TYPES_H
# include <sys/types.h>
#endif
#ifdef HAVE_NETINET_IN_H
# include <netinet/in.h>
#endif
#include <string.h>
#include <glib.h>
#include "packet.h"
Export the data structure used to represent a conversation. Replace "add_to_conversation()" with: "conversation_new()", which creates a new conversation, given source and destination addresses and ports, and returns a pointer to the structure for the conversation; "find_conversation()", which tries to find a conversation for given source and destination addresses and ports, and returns a pointer to the structure for the conversation if found, and a null pointer if not found. Add a private data pointer field to the conversation structure, and have "conversation_new()" take an argument that specifies what to set that pointer to; that lets clients of the conversation code hang arbitrary data off the conversation (e.g., a hash table of protocol requests and replies, in case the protocol is a request/reply protocol wherein the reply doesn't say what type of request it's a reply to, and you need that information to dissect the reply). svn path=/trunk/; revision=920
1999-10-24 07:27:20 +00:00
#include "conversation.h"
Generalize the "ip_src" and "ip_dst" members of the "packet_info" structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst" addresses, where an address is an address type, an address length in bytes, and a pointer to that many bytes. "dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}" are the network-layer source/destination; "{src,dst}" are the source/destination from the highest of those two layers that we have in the packet. Add a port type to "packet_info" as well, specifying whether it's a TCP or UDP port. Don't set the address and port columns in the dissector functions; just set the address and port members of the "packet_info" structure. Set the columns in "fill_in_columns()"; this means that if we're showing COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate the string from "src" or "dst", we don't generate a string for the link-layer address and then overwrite it with a string for the network-layer address (generating those strings costs CPU). Add support for "conversations", where a "conversation" is (at present) a source and destination address and a source and destination port. (In the future, we may support "conversations" above the transport layer, e.g. a TFTP conversation, where the first packet goes from the client to the TFTP server port, but the reply comes back from a different port, and all subsequent packets go between the client address/port and the server address/new port, or an NFS conversation, which might include lock manager, status monitor, and mount packets, as well as NFS packets.) Currently, all we support is a call that takes the source and destination address/port pairs, looks them up in a hash table, and: if nothing is found, creates a new entry in the hash table, and assigns it a unique 32-bit conversation ID, and returns that conversation ID; if an entry is found, returns its conversation ID. Use that in the SMB and AFS code to keep track of individual SMB or AFS conversations. We need to match up requests and replies, as, for certain replies, the operation code for the request to which it's a reply doesn't show up in the reply - you have to find the request with a matching transaction ID. Transaction IDs are per-conversation, so the hash table for requests should include a conversation ID and transaction ID as the key. This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses transparently (and should allow the SMB decoder to handle NetBIOS atop other protocols as well, if the source and destination address and port values in the "packet_info" structure are set appropriately). In the "Follow TCP Connection" code, check to make sure that the addresses are IPv4 addressses; ultimately, that code should be changed to use the conversation code instead, which will let it handle IPv6 transparently. svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
* Hash table for conversations with no wildcards.
*/
static GHashTable *conversation_hashtable_exact = NULL;
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* Hash table for conversations with one wildcard address.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
static GHashTable *conversation_hashtable_no_addr2 = NULL;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* Hash table for conversations with one wildcard port.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
static GHashTable *conversation_hashtable_no_port2 = NULL;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* Hash table for conversations with one wildcard address and port.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
static GHashTable *conversation_hashtable_no_addr2_or_port2 = NULL;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +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;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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;
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
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;
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
static guint
conversation_hash_exact(gconstpointer v)
{
conversation_key *key = (conversation_key *)v;
guint hash_val;
int i;
hash_val = 0;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
for (i = 0; i < key->addr1.len; i++)
hash_val += key->addr1.data[i];
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
hash_val += key->port1;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
for (i = 0; i < key->addr2.len; i++)
hash_val += key->addr2.data[i];
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
hash_val += key->port2;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
{
conversation_key *v1 = (conversation_key *)v;
conversation_key *v2 = (conversation_key *)w;
if (v1->ptype != v2->ptype)
return 0; /* different types of port */
The conversation comparison code should, if *any* of the tests that check whether the two packets are going in the same direction in the same conversation fails, check whether the two packets are going in opposite directions in the same conversation. svn path=/trunk/; revision=1014
1999-11-11 20:44:14 +00:00
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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?
The conversation comparison code should, if *any* of the tests that check whether the two packets are going in the same direction in the same conversation fails, check whether the two packets are going in opposite directions in the same conversation. svn path=/trunk/; revision=1014
1999-11-11 20:44:14 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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
/*
The conversation comparison code should, if *any* of the tests that check whether the two packets are going in the same direction in the same conversation fails, check whether the two packets are going in opposite directions in the same conversation. svn path=/trunk/; revision=1014
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
*/
The conversation comparison code should, if *any* of the tests that check whether the two packets are going in the same direction in the same conversation fails, check whether the two packets are going in opposite directions in the same conversation. svn path=/trunk/; revision=1014
1999-11-11 20:44:14 +00:00
return 1;
}
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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?
The conversation comparison code should, if *any* of the tests that check whether the two packets are going in the same direction in the same conversation fails, check whether the two packets are going in opposite directions in the same conversation. svn path=/trunk/; revision=1014
1999-11-11 20:44:14 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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
/*
The conversation comparison code should, if *any* of the tests that check whether the two packets are going in the same direction in the same conversation fails, check whether the two packets are going in opposite directions in the same conversation. svn path=/trunk/; revision=1014
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
*/
The conversation comparison code should, if *any* of the tests that check whether the two packets are going in the same direction in the same conversation fails, check whether the two packets are going in opposite directions in the same conversation. svn path=/trunk/; revision=1014
1999-11-11 20:44:14 +00:00
return 1;
Generalize the "ip_src" and "ip_dst" members of the "packet_info" structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst" addresses, where an address is an address type, an address length in bytes, and a pointer to that many bytes. "dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}" are the network-layer source/destination; "{src,dst}" are the source/destination from the highest of those two layers that we have in the packet. Add a port type to "packet_info" as well, specifying whether it's a TCP or UDP port. Don't set the address and port columns in the dissector functions; just set the address and port members of the "packet_info" structure. Set the columns in "fill_in_columns()"; this means that if we're showing COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate the string from "src" or "dst", we don't generate a string for the link-layer address and then overwrite it with a string for the network-layer address (generating those strings costs CPU). Add support for "conversations", where a "conversation" is (at present) a source and destination address and a source and destination port. (In the future, we may support "conversations" above the transport layer, e.g. a TFTP conversation, where the first packet goes from the client to the TFTP server port, but the reply comes back from a different port, and all subsequent packets go between the client address/port and the server address/new port, or an NFS conversation, which might include lock manager, status monitor, and mount packets, as well as NFS packets.) Currently, all we support is a call that takes the source and destination address/port pairs, looks them up in a hash table, and: if nothing is found, creates a new entry in the hash table, and assigns it a unique 32-bit conversation ID, and returns that conversation ID; if an entry is found, returns its conversation ID. Use that in the SMB and AFS code to keep track of individual SMB or AFS conversations. We need to match up requests and replies, as, for certain replies, the operation code for the request to which it's a reply doesn't show up in the reply - you have to find the request with a matching transaction ID. Transaction IDs are per-conversation, so the hash table for requests should include a conversation ID and transaction ID as the key. This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses transparently (and should allow the SMB decoder to handle NetBIOS atop other protocols as well, if the source and destination address and port values in the "packet_info" structure are set appropriately). In the "Follow TCP Connection" code, check to make sure that the addresses are IPv4 addressses; ultimately, that code should be changed to use the conversation code instead, which will let it handle IPv6 transparently. svn path=/trunk/; revision=909
1999-10-22 07:18:23 +00:00
}
/*
* The addresses or the ports don't match.
*/
return 0;
}
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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
*/
static guint
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_hash_no_addr2(gconstpointer v)
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
{
conversation_key *key = (conversation_key *)v;
guint hash_val;
int i;
hash_val = 0;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
for (i = 0; i < key->addr1.len; i++)
hash_val += key->addr1.data[i];
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
hash_val += key->port1;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
hash_val += key->port2;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
return hash_val;
}
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* Compare two conversation keys, except for the address 2 value.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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
{
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
conversation_key *v1 = (conversation_key *)v;
conversation_key *v2 = (conversation_key *)w;
if (v1->ptype != v2->ptype)
return 0; /* different types of port */
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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?
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (v1->port1 == v2->port1 &&
v1->port2 == v2->port2 &&
ADDRESSES_EQUAL(&v1->addr1, &v2->addr1)) {
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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.
*/
return 0;
}
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
static guint
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_hash_no_port2(gconstpointer v)
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
conversation_key *key = (conversation_key *)v;
guint hash_val;
int i;
hash_val = 0;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
for (i = 0; i < key->addr1.len; i++)
hash_val += key->addr1.data[i];
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
hash_val += key->port1;
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
for (i = 0; i < key->addr2.len; i++)
hash_val += key->addr2.data[i];
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
return hash_val;
}
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* Compare two conversation keys, except for the port 2 value.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_match_no_port2(gconstpointer v, gconstpointer w)
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
{
conversation_key *v1 = (conversation_key *)v;
conversation_key *v2 = (conversation_key *)w;
if (v1->ptype != v2->ptype)
return 0; /* different types of port */
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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?
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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)) {
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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.
*/
return 0;
}
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
static guint
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_hash_no_addr2_or_port2(gconstpointer v)
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
{
conversation_key *key = (conversation_key *)v;
guint hash_val;
int i;
hash_val = 0;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
for (i = 0; i < key->addr1.len; i++)
hash_val += key->addr1.data[i];
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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;
}
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* Compare the address 1 and port 1 in the two conversation keys.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_match_no_addr2_or_port2(gconstpointer v, gconstpointer w)
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
{
conversation_key *v1 = (conversation_key *)v;
conversation_key *v2 = (conversation_key *)w;
if (v1->ptype != v2->ptype)
return 0; /* different types of port */
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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?
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (v1->port1 == v2->port1 &&
ADDRESSES_EQUAL(&v1->addr1, &v2->addr1)) {
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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.
*/
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.
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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
}
Set "conversation_keys" to NULL after destroying the list of conversation keys. svn path=/trunk/; revision=1029
1999-11-14 19:56:32 +00:00
conversation_keys = NULL;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
if (conversation_hashtable_exact != NULL)
g_hash_table_destroy(conversation_hashtable_exact);
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
conversation_hashtable_exact =
g_hash_table_new(conversation_hash_exact,
conversation_match_exact);
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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);
/*
* Start the conversation indices over at 0.
*/
new_index = 0;
}
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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 *
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_new(address *addr1, address *addr2, port_type ptype,
guint32 port1, guint32 port2, void *data, 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;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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;
conversation->data = data;
Jeff Foster's SOCKS dissector, support for associating dissectors with conversations and having TCP and UDP check whether a packet is part of a conversation with a dissector and, if so, using that dissector on the conversation, and "ethertype()"-style support for allowing a dissector to call a sub-dissector via the same path that the TCP and UDP dissectors use, based on port numbers supplied by that dissector. svn path=/trunk/; revision=1837
2000-04-12 22:53:16 +00:00
/* clear dissector pointer */
Change from Andreas Sikkema to change the "old" and "new" members of the "dissector" union in the "conversation_t" structure to "old_d" and "new_d", to avoid using a C++ reserved word. Add "old_conversation_set_dissector()" and "conversation_set_dissector()" routines to set the dissector for a conversation, to hide the details of how that's done (e.g., details such as whether there's a union at all - eventually, when all dissectors have been tvbuffified, there won't be a need for the union - and what the names of the union members are, and so on). Convert all dissectors to use those routines (they had to be changed anyway, due to the name change). svn path=/trunk/; revision=2324
2000-08-21 18:36:35 +00:00
conversation->dissector.new_d = NULL;
Jeff Foster's SOCKS dissector, support for associating dissectors with conversations and having TCP and UDP check whether a packet is part of a conversation with a dissector and, if so, using that dissector on the conversation, and "ethertype()"-style support for allowing a dissector to call a sub-dissector via the same path that the TCP and UDP dissectors use, based on port numbers supplied by that dissector. svn path=/trunk/; revision=1837
2000-04-12 22:53:16 +00:00
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/* set the options and key pointer */
conversation->options = options;
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
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++;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (options & NO_ADDR2) {
if (options & NO_PORT2) {
g_hash_table_insert(conversation_hashtable_no_addr2_or_port2,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
new_key, conversation);
} else {
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
g_hash_table_insert(conversation_hashtable_no_addr2,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
new_key, conversation);
}
} else {
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (options & NO_PORT2) {
g_hash_table_insert(conversation_hashtable_no_port2,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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;
}
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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)
{
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* If the port 2 value is wildcarded, don't set it.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (!(conv->options & NO_PORT2))
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
return;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (conv->options & NO_ADDR2) {
g_hash_table_remove(conversation_hashtable_no_addr2_or_port2,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
conv->key_ptr);
} else {
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
g_hash_table_remove(conversation_hashtable_no_port2,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
conv->key_ptr);
}
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
conv->key_ptr, conv);
} else {
g_hash_table_insert(conversation_hashtable_exact,
conv->key_ptr, conv);
}
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
}
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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)
{
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* If the address 2 value is wildcarded, don't set it.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (!(conv->options & NO_ADDR2))
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
return;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (conv->options & NO_PORT2) {
g_hash_table_remove(conversation_hashtable_no_addr2_or_port2,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
conv->key_ptr);
} else {
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
g_hash_table_remove(conversation_hashtable_no_addr2,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
conv->key_ptr);
}
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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,
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
conv->key_ptr, conv);
} else {
g_hash_table_insert(conversation_hashtable_exact,
conv->key_ptr, conv);
}
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
}
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
static conversation_t *
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_match(GHashTable *hashtable, address *addr1, address *addr2,
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.
*/
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
key.port1 = port1;
key.port2 = port2;
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
return g_hash_table_lookup(hashtable, &key);
}
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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
* not found. If the NO_ADDR_B and/or NO_PORT_B flags are set in the
* conversation options field, that value will not be used.
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
conversation_t *
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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)
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
{
conversation_t *conversation;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (options & NO_ADDR_B) {
if (options & NO_PORT_B) {
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
* Wildcard the address and port - first try looking
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* for a conversation with the specified address 1
* and port 1, then try looking for one with an
* address 1 and port 1 that's the specified
* address *2* and port *2* (this packet may be
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
* going in the opposite direction from the first
* packet in the conversation).
*/
conversation =
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_match(conversation_hashtable_no_addr2_or_port2,
addr_a, addr_b, ptype, port_a, port_b);
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
if (conversation != NULL)
return conversation;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
return conversation_match(conversation_hashtable_no_addr2_or_port2,
addr_b, addr_a, ptype, port_b, port_a);
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
} else {
/*
* Wildcard the address - first try looking for a
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* conversation with the specified address 1 and
* port 1 and the specified port 2, then try looking
* for one with an address 1 and port 1 that's
* the specified address *2* and port *2* and
* a port 2 that's the specified port *1* (this
* packet may be going in the opposite direction
* from the first packet in the conversation).
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
*/
conversation =
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_match(conversation_hashtable_no_addr2,
addr_a, addr_b, ptype, port_a, port_b);
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
if (conversation != NULL)
return conversation;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
return conversation_match(conversation_hashtable_no_addr2,
addr_b, addr_a, ptype, port_b, port_a);
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
}
} else {
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
if (options & NO_PORT_B) {
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
/*
* Wildcard the port - first try looking for a
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* conversation with the specified address 1 and
* port 1 and the specified address 2, then try
* looking for one with an address 1 and port 1
* that's the specified address *2* and port *2*
* and an address 2 that's the specified address
* *1* (this packet may be going in the opposite
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
* direction from the first packet in the conversation).
*/
conversation =
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation_match(conversation_hashtable_no_port2,
addr_a, addr_b, ptype, port_a, port_b);
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
if (conversation != NULL)
return conversation;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
return conversation_match(conversation_hashtable_no_port2,
addr_b, addr_a, ptype, port_b, port_a);
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
2000-10-21 09:54:12 +00:00
} else {
/*
* Search for an exact match. That search checks both
* directions.
*/
return conversation_match(conversation_hashtable_exact,
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
addr_a, addr_b, ptype, port_a, port_b);
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
}
Jeff Foster's SOCKS dissector, support for associating dissectors with conversations and having TCP and UDP check whether a packet is part of a conversation with a dissector and, if so, using that dissector on the conversation, and "ethertype()"-style support for allowing a dissector to call a sub-dissector via the same path that the TCP and UDP dissectors use, based on port numbers supplied by that dissector. svn path=/trunk/; revision=1837
2000-04-12 22:53:16 +00:00
Change from Andreas Sikkema to change the "old" and "new" members of the "dissector" union in the "conversation_t" structure to "old_d" and "new_d", to avoid using a C++ reserved word. Add "old_conversation_set_dissector()" and "conversation_set_dissector()" routines to set the dissector for a conversation, to hide the details of how that's done (e.g., details such as whether there's a union at all - eventually, when all dissectors have been tvbuffified, there won't be a need for the union - and what the names of the union members are, and so on). Convert all dissectors to use those routines (they had to be changed anyway, due to the name change). svn path=/trunk/; revision=2324
2000-08-21 18:36:35 +00:00
/*
* Set the dissector for a conversation.
*/
void
old_conversation_set_dissector(conversation_t *conversation,
old_dissector_t dissector)
{
conversation->is_old_dissector = TRUE;
conversation->dissector.old_d = dissector;
}
void
conversation_set_dissector(conversation_t *conversation,
dissector_t dissector)
{
conversation->is_old_dissector = FALSE;
conversation->dissector.new_d = dissector;
}
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
/*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* Given two address/port pairs for a packet, search for a conversation
* dissector.
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
* If found, call it and return TRUE, otherwise return FALSE.
*
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
* Will search for a exact match (addr_a/port_a and addr_b/port_b), then search
* for wild card matches: try to match any address 2 with the specified port 2
* first (addr_a/port_a and {any}/addr_b), then try to match any port 2 with the
* specified address 2 (addr_a/port_a and addr_b/{any}), then try to match any
* address 2 and any port 2 (addr_a/port_a and {any}/{any}).
Wildcard matching is tricky - you have to try wildcarding both the source *and* destination port and/or both the source *and* destination address passed to "find_conversation()", because the packet for which you're trying to find the conversation may be going in the opposite direction to the packet for which the conversation was originally created. Create different hash tables for wildcarded conversations, to reduce the number of "is this a wildcard?" tests done when doing hash lookups. This is sufficient to allow the TFTP dissector to use conversations rather than being special-cased in the UDP dissector, and may also be sufficient to handle a similar problem with SMTP (request goes from client IP X port Y to server IP Z's well-known port, reply comes back from some other port on server Z to client IP X port Y), but further use may reveal other changes that should be made. svn path=/trunk/; revision=2525
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
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
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;
const guint8 *pd;
int offset;
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation = find_conversation(addr_a, addr_b, ptype, port_a, port_b,
Fix a comment. Split some lines differently. svn path=/trunk/; revision=3519
2001-06-06 01:29:17 +00:00
0);
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
if (conversation == NULL)
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation = find_conversation(addr_a, addr_b, ptype, port_a,
port_b, NO_ADDR_B);
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
if (conversation == NULL)
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation = find_conversation(addr_a, addr_b, ptype, port_a,
port_b, NO_PORT_B);
Support for conversations with "wildcard" destination addresses, from Jeff Foster. svn path=/trunk/; revision=2523
2000-10-21 05:52:28 +00:00
if (conversation == NULL)
Rename the arguments and flags for the conversation routines, so as not to imply that 1) conversations have source and destination addresses and ports - they don't (if they did, they'd be monologues, not conversations), they just have two address/port pairs for the two endpoints, with one or more of the address or port in the second pair possibly being wildcarded; 2) the first and second address or port argument to "find_conversation()" or "try_conversation_dissector()" have anything to do with the first or second address/port pair in a conversation - they don't, the two arguments to those routines are matched against *both* address/port pairs for a conversation; as otherwise people might think that they need to add flags to wildcard the first arguments "conversation_new()" or "find_conversation()" (they don't, they just have to pass the non-wildcarded address/port first and then pass the wildcarded one, even if that means passing the destination first and source second). svn path=/trunk/; revision=3537
2001-06-10 09:50:20 +00:00
conversation = find_conversation(addr_a, addr_b, ptype, port_a,
port_b, NO_PORT_B | NO_ADDR_B);
Fix a comment. Split some lines differently. svn path=/trunk/; revision=3519
2001-06-06 01:29:17 +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) {
if (conversation->is_old_dissector) {
Do the checks for the presence of a conversation dissector the same way in "try_conversation_dissector()" that they're done in "old_try_conversation_dissector()". svn path=/trunk/; revision=2656
2000-11-18 07:00:31 +00:00
if (conversation->dissector.old_d == NULL)
return FALSE;
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
/*
* New dissector calling old dissector; use
* "tvb_compat()" to remap.
Don't attempt to call the dissector for a conversation if the conversation doesn't have a dissector. svn path=/trunk/; revision=2655
2000-11-18 06:51:42 +00:00
*
* "is_old_dissector" won't be set unless
* "dissector.old_d" is set.
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
*/
tvb_compat(tvb, &pd, &offset);
Change from Andreas Sikkema to change the "old" and "new" members of the "dissector" union in the "conversation_t" structure to "old_d" and "new_d", to avoid using a C++ reserved word. Add "old_conversation_set_dissector()" and "conversation_set_dissector()" routines to set the dissector for a conversation, to hide the details of how that's done (e.g., details such as whether there's a union at all - eventually, when all dissectors have been tvbuffified, there won't be a need for the union - and what the names of the union members are, and so on). Convert all dissectors to use those routines (they had to be changed anyway, due to the name change). svn path=/trunk/; revision=2324
2000-08-21 18:36:35 +00:00
(*conversation->dissector.old_d)(pd, offset, pinfo->fd,
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
tree);
Don't attempt to call the dissector for a conversation if the conversation doesn't have a dissector. svn path=/trunk/; revision=2655
2000-11-18 06:51:42 +00:00
} else {
Do the checks for the presence of a conversation dissector the same way in "try_conversation_dissector()" that they're done in "old_try_conversation_dissector()". svn path=/trunk/; revision=2656
2000-11-18 07:00:31 +00:00
if (conversation->dissector.new_d == NULL)
Don't attempt to call the dissector for a conversation if the conversation doesn't have a dissector. svn path=/trunk/; revision=2655
2000-11-18 06:51:42 +00:00
return FALSE;
Change from Andreas Sikkema to change the "old" and "new" members of the "dissector" union in the "conversation_t" structure to "old_d" and "new_d", to avoid using a C++ reserved word. Add "old_conversation_set_dissector()" and "conversation_set_dissector()" routines to set the dissector for a conversation, to hide the details of how that's done (e.g., details such as whether there's a union at all - eventually, when all dissectors have been tvbuffified, there won't be a need for the union - and what the names of the union members are, and so on). Convert all dissectors to use those routines (they had to be changed anyway, due to the name change). svn path=/trunk/; revision=2324
2000-08-21 18:36:35 +00:00
(*conversation->dissector.new_d)(tvb, pinfo, tree);
Don't attempt to call the dissector for a conversation if the conversation doesn't have a dissector. svn path=/trunk/; revision=2655
2000-11-18 06:51:42 +00:00
}
Do the checks for the presence of a conversation dissector the same way in "try_conversation_dissector()" that they're done in "old_try_conversation_dissector()". svn path=/trunk/; revision=2656
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;
Jeff Foster's SOCKS dissector, support for associating dissectors with conversations and having TCP and UDP check whether a packet is part of a conversation with a dissector and, if so, using that dissector on the conversation, and "ethertype()"-style support for allowing a dissector to call a sub-dissector via the same path that the TCP and UDP dissectors use, based on port numbers supplied by that dissector. svn path=/trunk/; revision=1837
2000-04-12 22:53:16 +00:00
}