Hi list, Hi Guy.
Good catch.
Well, sorry for that one since I am responsible for introducing that bug.
Problem seems to be that it is using the sequence number where the pdu
starts as the key
provided to fragment_add().
Without relative sequence numbers, this sequence number is almost random and
seemed good enough
to avoid collisions.
With relative sequence numbers, the sequence numbers are suddenly very
non-random and the probability for
collisions to occur is suddenly very large.
I think the best solution would be to change it to use pinfo->fd->num as the
key to fragment_add() instead since
it would provide a unique key for the PDU reassembly.
(well almost unique, it could still fail if we get TCP encapsulated ontop of
TCP and both start a new PDU in the same frame)
I am a bit internet disadvantaged right now but will try to download the
latest snapshot later today.
I will produce a fix for the problem and send to the list tomorrow.
best regards
ronnie sahlberg
Hi
A small trace with an error when:
TCP relative sequence is set.
DSI desegment set.
cf frame 6 and frame 8.
Src ip and dst ip addr are the same.
...which means that the TCP reassembly code should, arguably, use both
the addresses *AND* the port numbers when looking up stuff, although
that means it couldn't just use "fragment_add()".
Another possibility would be to have the TCP reassembly code always use
absolute sequence numbers; it might also make sense to have it *display*
both the absolute and relative sequence numbers (and ack numbers and
next sequence numbers) if relative port numbers are requested.
_________________________________________________________________
Choose an Internet access plan right for you -- try MSN!
http://resourcecenter.msn.com/access/plans/default.asp