Ethereal-cvs: [ethereal-cvs] cvs commit: ethereal/gtk main.c

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 22 Oct 1999 02:18:37 -0500 (CDT)
guy         1999/10/22 02:18:28 CDT

  Modified files:
    gtk                  main.c 
  Log:
  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.
  
  Revision  Changes    Path
  1.27      +1 -9      ethereal/gtk/main.c