From 047b8751f369c1e466d1264afa03ac3d49ec54e1 Mon Sep 17 00:00:00 2001 From: Guy Harris Date: Fri, 22 Oct 1999 07:18:23 +0000 Subject: 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 --- packet-ipv6.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) (limited to 'packet-ipv6.h') diff --git a/packet-ipv6.h b/packet-ipv6.h index f451de7b53..70ae4ecb81 100644 --- a/packet-ipv6.h +++ b/packet-ipv6.h @@ -1,7 +1,7 @@ /* packet-ipv6.h * Definitions for IPv6 packet disassembly * - * $Id: packet-ipv6.h,v 1.6 1999/10/14 05:41:30 itojun Exp $ + * $Id: packet-ipv6.h,v 1.7 1999/10/22 07:17:33 guy Exp $ * * Ethereal - Network traffic analyzer * By Gerald Combs @@ -86,6 +86,16 @@ struct ip6_hdr { #define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim #define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim +/* Offsets of fields within an IPv6 header. */ +#define IP6H_CTL 0 +#define IP6H_CTL_FLOW 0 +#define IP6H_CTL_PLEN 4 +#define IP6H_CTL_NXT 6 +#define IP6H_CTL_HLIM 7 +#define IP6H_CTL_VFC 0 +#define IP6H_SRC 8 +#define IP6H_DST 24 + #define IPV6_VERSION 0x60 #define IPV6_VERSION_MASK 0xf0 -- cgit v1.2.3