[Guy Harris <guy@xxxxxxxxxxxxxxxxxxx>]

guy         2003/04/19 19:11:29 CDT

  Modified files:
    .                    reassemble.c reassemble.h packet-ip.c 
  Log:
  We can't use the frame_data structure as a key structure when looking
  for reassembled frames - in Tethereal, there's only one frame_data
  structure used for all frames.  Instead, use the frame number itself as
  the key.
  
  Add a "fragment_add_check()" routine, for fragments where there's a
  fragment offset rather than a fragment sequence number, which does the
  same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
  is done, it puts the reassembled fragment into a separate hash table, so
  that there're only incomplete reassemblies in the fragment hash table.
  That's necessary in order to handle cases where the packet ID field can
  be reused.
  
  Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
  fact, RFC 791 suggests that doing so might be a feature:
  
      It is appropriate for some higher level protocols to choose the
      identifier. For example, TCP protocol modules may retransmit an
      identical TCP segment, and the probability for correct reception
      would be enhanced if the retransmission carried the same identifier
      as the original transmission since fragments of either datagram
      could be used to construct a correct TCP segment.
  
  and RFC 1122 says that it's permitted to do so, although it also says
  "we believe that retransmitting the same Identification field is not
  useful":
  
           3.2.1.5  Identification: RFC-791 Section 3.2
  
              When sending an identical copy of an earlier datagram, a
              host MAY optionally retain the same Identification field in
              the copy.
  
              DISCUSSION:
                   Some Internet protocol experts have maintained that
                   when a host sends an identical copy of an earlier
                   datagram, the new copy should contain the same
                   Identification value as the original.  There are two
                   suggested advantages:  (1) if the datagrams are
                   fragmented and some of the fragments are lost, the
                   receiver may be able to reconstruct a complete datagram
                   from fragments of the original and the copies; (2) a
                   congested gateway might use the IP Identification field
                   (and Fragment Offset) to discard duplicate datagrams
                   from the queue.
  
                   However, the observed patterns of datagram loss in the
                   Internet do not favor the probability of retransmitted
                   fragments filling reassembly gaps, while other
                   mechanisms (e.g., TCP repacketizing upon
                   retransmission) tend to prevent retransmission of an
                   identical datagram [IP:9].  Therefore, we believe that
                   retransmitting the same Identification field is not
                   useful.  Also, a connectionless transport protocol like
                   UDP would require the cooperation of the application
                   programs to retain the same Identification value in
                   identical datagrams.
  
  and, in any case, I've seen that in at least one capture, and it
  confuses the current reassembly code).
  
  Unfortunately, that means that fragments other than the last fragment
  can't be tagged with the frame number in which the reassembly was done;
  see the comment in packet-ip.c for a discussion of that problem.
  
  Revision  Changes    Path
  1.33      +248 -131  ethereal/reassemble.c
  1.15      +13 -1     ethereal/reassemble.h
  1.188     +43 -8     ethereal/packet-ip.c