On Sat, Apr 26, 2003 at 04:13:13PM +0200, Georg von Zezschwitz wrote:
> the reassembly functions used e.g. by packet-wtp.c use a key to
> gather fragments.
>
> This key is based on source and destination ip, as well as the
> TID of the WTP packet. However, in my case this key will reoccur
> in other WSP sessions very soon, when gathering just some
> minutes of activity on the LAN. This is dued to the fact that
> both the mobiles assigned IP addresses are reused quickly, as
> well as the mobiles are not that creative regarding their TID.
>
> Therefore, ethereal and tethereal crash after some parsing a
> few minutes of data, (g_assert(fd_head->len >= dfpos + fd->len)
> from reassemble.c:974), as a fragment of a new customer
> session exceeds the reassembled packet of a former session
> on the same IP with the same TID.
That's a bug in the reassembly code - the checks it was doing are wrong.
I've checked in something that I think should fix it.
That still leaves open the issue of what to do:
> I can think of two approaches to solve this:
> 1) The hash_table is invalidated for a certain IP on a "stop"
> event (e.g. WSP disconnect for WAP).
> 2) A timeout is used, which only glues fragments together, if
> they fall within a defined time frame. I guess this is
> the better and more general approach.
and the
3) When reassembly completes for a given packet ID, don't leave
the reassembly table around for that packet ID, mark it as
"done" and move it to a different hash table, so subsequent
fragments with the same packet ID start a new reassembly.
alternative I mentioned in my previous mail. That alternative could be
combined with 1) or 2).
You'd have to do 3) in order to do 1) if by "invalidated" you mean
"emptied" - if you empty the hash table *and* it's used to find the
fragments of reassembled packets, that means you wouldn't ever be able
to do reassembly when you click on a packet.
2), if combined with 1), would mean that you might keep the fragment in
both hash tables until the timeout expires, so that additional fragments
could be attached to it. That'd be useful if you wanted to handle, for
example, retransmissions that show up after reassembly completes. I'd
be inclined to implement that by having a fragment table be a structure
with a pointer to a hash table and a timeout value, and have
"fragment_table_init()" (re-)initialize the hash table *and* set the
timeout value.
