> -----Original Message-----
> From: Pia Sahlberg [mailto:piabar@xxxxxxxxxxx]
> Sent: 13 December 2001 22:54
>
> >I'd propose to skip the OVERLAP-checking in that case as
> overlapping is
> >impossible with sequence-blocks. As for receiving an existing
> >sequence-block, that could be a re-transmission and then the
> size could
> >differ.
>
> Are you certain that the size could differ for retransmissions?
> If the size can differ for retransmissions (due to the stack
> collapsing
> multiple blocks into one) and if the only way to identify the block
> is by its sequence number, then I think it would be impossible for the
> receiving host to reliably reassemble the payload.
Well, I think it can differ in theory. WTP has no notion of length, it
relies on the underlying bearer-protocol for that (which can be many, TCP,
UDP even binary short messages). The underlying bearer should therefore stop
mangled packets from reaching WTP and all WTP can do is count it's sequence
numbers, conclude some are missing and ask for retransmission. Question is,
will Ethereal-dissection also stop dissecting when, for instance, a mangled
UDP crosses the network (that's the specific case I'm thinking of). In that
case sizes could vary. I must add that I haven't seen that though so it's
all theory.
One could argue that in this case the Ethereal UDP-dissection would be wrong
in passing the payload on and question whether WTP-dissection should cater
for such an event but in programming I always try to expect the worst...
> Well, I will add fragment_add_seq() tonight but I will
> make it handle retransmissions in the following way:
> IF a retransmitted block is received we will verify that both the size
> and the content of the block is identical to the first received block
> or else FD_OVERLAPCONFLICT will be set.
> I think this would make most sense since I belive this
> behaviour would be
> most sane and useful for a generic fragment_add_seq().
> Please, IF you are certain that WTP CAN collapse multiple
> blocks and thus
> send retransmissions with different block sizes tell me, because
> then we must make some more changes (in that case, just ignoring the
> retransmitted
> blocks is not sufficient for reliable reassembly)
See above, I'm happy with this.
> >As I won't be able to do anything significant for the next
> month or so and
> >am not really comfortable with that part of the code, you
> doing the changes
> >would be very much appreciated.
>
> OK. I will add fragment_add_seq() and I can change the WTP code to
> use it.
That'd be grand.
> However I can not test the changes since I have no WTP
> captures which are
> fragmented.
Apologies for not sending in any traces but they are under non-disclosure
agreement.
> When I have produced a patch, could I send it to you for testing
> before it gets checked in?
By all means do. As I said, it might take some time though as I'm in the
middle of moving from 1 country to another. See if I can get in contact
somewhere next week.
Thanks.
Regards,
Tom Uijldert Email: Tom.Uijldert@xxxxxx
