Add a separate hash table to the reassembly code for reassembled
authorguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Wed, 17 Apr 2002 08:25:05 +0000 (08:25 +0000)
committerguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Wed, 17 Apr 2002 08:25:05 +0000 (08:25 +0000)
commitdaea9a75c1cf9df2fe47f53bf9900a7c83dd9981
tree621bae3a8d9d7445807c25615036ede4a0beac26
parent1cdb29fc0c8f0401151bf9a5d5a00d49b2eb457d
Add a separate hash table to the reassembly code for reassembled
packets, using the reassembly ID and the frame number of the final frame
as the key.  There is no guarantee that reassembly IDs won't be reused,
even when talking between the same source and destination address; if,
once reassembly is complete, the "fragment_data" structure is moved to
the latter hash table, this will keep reused reassembly IDs from causing
mis-reassembly.

Add a routine "fragment_add_seq_check()", which

if a fragment has the "more fragments" flag not set but is the
first fragment of a reassembly, treats that as a non-fragmented
frame, allocating a "fragment_data" structure for the reassembly
but not attaching any fragment to it, and adding it to a
reassembled packet list;

if a packet has been reassembled, removes it from the table of
reassemblies and moves it to the table of reassembled packets;

if the frame's been seen already, looks it up in the table of
reassembled packets rather than the table of reassemblies.

Add reassembly support for fragmented 802.11 frames.  Use
"fragment_add_seq_check()" to cope with the fact that some
hardware+drivers apparently hands us reassembled frames with a non-zero
fragment number and the "more fragments" bit clear (as if it puts the
802.11 header of the *last* fragment onto the reassembled data).

git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@5177 f5534014-38df-0310-8fa8-9805f1628bb7
packet-ieee80211.c
reassemble.c
reassemble.h