Here is another patch that elliminates the use of the more_flag. I still use the length to calculate for the first pass. But during the first pass the request_value entry is flagged for fragmentation. This way on subsequent scan or dissection then the packets should decode correctly.
I found the mail I was thinking of:
Date: Wed, 9 Apr 2003 14:50:53 -0700
From: Guy Harris <guy@xxxxxxxxxxxx>
To: Greg Morris <GMORRIS@xxxxxxxxxx>
Subject: NDPS reassembly doesn't work correctly
The NDPS dissection relies on global variables to keep state;
this means that it won't necessarily work correctly after the
first pass.
In particular, if you read in the capture and then immediately
go to frame 679, it's displayed as a Print Program/Bind PA
opeation.
However, if you then go to frame 725 and then go back to frame
679, it's displayed as "Data (224 bytes)", because frame 725 was
a fragment, and that set the "more_fragment" global.
Is it the case that the SPX "End of message" flag is true if an
SPX packet is the only fragment, or the last fragment, of a
fragmented NDPS packet, and false otherwise? I.e., should that
be used as the "more fragments" flag?
On Tue, Aug 19, 2003 at 04:13:39PM -0600, Greg Morris wrote:
> I did make some changes a while back to track for the spx_info->eom
> flag. This all seemed to work correctly at the time. But recent changes
> to the fragment code seemed to break it.
Perhaps "seemed" is the key word - perhaps they happened to work because
of the way the reassembly happened to work, but stopped working when the
reassembly code changed.
For NDPS-over-TCP, there's no SPX, therefore there's no "end of message"
flag, so the desegmentation should just use the length in the NDPS
header, as that's all it can use.
However, for NDPS-over-SPX, there is an end-of-message flag, so the
length might be redundant. If the SPX sequence number can be used to
indicate the ordinal numbers of the fragments, that would almost be
sufficient; the problem is that the sequence number of the first
fragment isn't always 0 (or 1, or any constant). If the "more_frags"
flag for the various "fragment_add" routines became a "first frag/last
frag/middle frag" flag, we might be able to handle that.
For many protocols, a sequence number of 0 (or some constant value, e.g.
1), or a fragment offset of 0 implies "first frag"; for those without a
sequence number (where, for example, the protocol above the one doing
the fragmentation is assumed to deliver packets reliably and in order,
e.g. NBF atop 802.2 LLC "type 2" or whatever it's called), there can
only be one reassembly in progress on a connection during the first pass
through the packets, and the absence of such a reassembly has to be
treated as a "first frag" indication (which means it's not robust if the
first fragment is missing, but I think that's extremely difficult if not
impossible to solve).
So the flag should perhaps instead be "first frag", "first or middle
frag", "middle frag", or "last frag", where:
"first frag" means "we *know* this is the first fragment";
"first or middle frag" means "this isn't the last fragment, but
that's all we know";
"middle frag" means "we know this is neither the first nor the
last fragment";
"last frag" means "this is the last fragment".
With that scheme, for NDPS-over-SPX reassembly:
we'd use "fragment_add_seq_check()" rather than
"fragment_add_seq_next()";
the sequence number would be the SPX sequence number;
we'd pass "first or middle frag" if the SPX end-of-message flag
is false and "last frag" if it's true.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
