Ethereal-cvs: [Ethereal-cvs] cvs commit: ethereal file.c packet-ncp-int.h packet-ncp.c packet-

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

From: Gilbert Ramirez Jr. <gram@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 4 Jan 2002 22:12:15 -0600 (CST)
gram        2002/01/04 22:12:15 CST

  Modified files:
    .                    file.c packet-ncp-int.h packet-ncp.c 
                         packet-ncp2222.inc 
  Log:
  Long NCP traces can easily have many packets whose "uniqueness"
  variables wrap-around. Since the request/reply packets are related via
  a hash based on these uniqueness variables, long NCP traces can
  have mis-matches reqeust/reply records.
  
  Thus, only do the hash-lookup for the reply packet during the first
  sequential scan of the trace file. Once the pertinent info is found,
  store it in the packet's private data area.
  
  Since the memory allocated for the hash and for the structures that make
  up the keys are no longer needed after the first sequential run through
  the trace file, arrange to free that memory after the first sequential
  run. Similar to the register_init_routine() that allows dissectors
  to register callbacks for calling *before* a capture file is loaded,
  set up a register_postseq_cleanup_routine() function that allows
  dissectors to register callbacks for calling *after* the first
  sequential run-through of the trace file is made. This is not
  a *final* cleanup callback, since Ethereal will still have that trace file
  open for random-access reading.
  
  I didn't have tethereal call postseq_cleanup_all_protocols() since
  tethereal doesn't keep the trace file open for random-access reading.
  I could easily be swayed to make tethereal call that function, however.
  
  Revision  Changes    Path
  1.257     +9 -1      ethereal/file.c
  1.5       +3 -6      ethereal/packet-ncp-int.h
  1.53      +24 -36    ethereal/packet-ncp.c
  1.7       +21 -13    ethereal/packet-ncp2222.inc