Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 15744: /trunk/epan/dissectors/: packet
Guy Harris wrote:
ulfl@xxxxxxxxxxxx wrote:
reassemble.c:
I had to change the way the reassemble code works if the dissector
is telling that more fragments *will* follow.
That assumes that fragments arrive in order.
They don't always do so.
For example, the fragments of a fragmented IP datagram might well
arrive in *reverse* order; I have a capture where that happens. (I
seem to remember a claim that some version of Linux sent IP fragments
out in reverse order.)
Hmmm, unfortunately, I'm confused now. I understand what you're talking
about and I was already questioning myself *how* this "problem" is
handled in a any way.
However, in this case I don't understand what the more_frags flag is all
about, could someone explain (or even better explain it in the
reassemble.h) ...
What my problem is with the DCE/RPC defragmentation, connection oriented
TCP based (SMB works equally):
In the connection oriented DCE/RPC fragmentation (connectionless is
different here, as it uses sequence numbers), all packets are send in
sequence and there's *no* fragment offset inside the packet data, this
is handled by the byte position in the TCP stream.
What I've tried is to use the fragment total length as a way to keep the
current offset in the fragment data. The end of the last fragment must
be the offset of the next one. Assuming that the TCP dissector is
working correct, this would be a simple model and should work well.
Unfortunately, this doesn't work well with the reassemble code.
Any ideas how to solve this in a better way? Do we have other dissectors
doing a similar thing where I could have a look how I could solve this?
Regards, ULFL
