On Mon, May 13, 2002 at 01:32:13PM +0100, Peter O'Neill wrote:
> A single packet (from 250 captured)
>
> 0000 00 10 4b b7 4e 0b 00 c0 1b 04 36 9e 08 00 45 00 ..K.N.....6...E.
> 0010 00 2c 7e 00 40 00 80 06 38 e1 89 2b 1a 46 89 2b .,[email protected]..+.F.+
> 0020 17 4e 04 07 03 e7 00 01 7a c9 9b cd 9c c1 50 18 .N......z.....P.
> 0030 7e ea 2e ac 00 00 03 00 00 00 ~.........
>
> is decoded differently (and it seems incorrectly) by 0.9.3 instead of 0.9.0
Ethereal uses heuristic dissectors for a number of protocols, and
sometimes heuristics get the wrong answer.
> The packets were captured by Epiphan Consulting CENiffer on Compaq iPAQ
> 3630, during synchronisation. Ethereal was running on the desktop PC at the
> same time, and the corresponding decoded packet at that end is similarly
> incorrectly shown as unreassembled by 0.9.3 but as [PSH, ACK] by 0.9.0
It's a [PSH, ACK] frame according to 0.9.3, too:
> Flags: 0x0018 (PSH, ACK)
It's just that 0.9.3 decided it looked enought like a
Q.931-over-TPKT-over-TCP frame that it went past the TCP dissection to
dissect the TCP payload as a TPKT packet with Q.931 payload.
The heuristic can probably be tightened, given that the length in the
TPKT header includes the length of the TPKT header itself, so it has an
absolute minimum value of 4 and, as the protocols running atop TPKT have
their own minimum PDU lengths, it can probably be boosted above that.
That would prevent it from dissecting that *particular* frame as a
Q.931-over-TPKT frame, as, if it were one, the packet length field would
be 0, but it cannot guarantee that *no* frames will be misdissected as
Q.931-over-TPKT frames.