Ethereal-dev: RE: [Ethereal-dev] Reassembling a Splited TCP packet

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Gilles Galipeau <ggalipeau@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 25 Nov 2003 18:25:43 -0500
Guy,

You got it rigth.
Thanks for the input, I will use the function in Ethereal to reassemble the
payload size and I will add the check of the protocol in the
"get_vn_pdu_len()" function.

But still, with the packet I have sent to you, the content of the function
get_vn_pdu_len() was OK; It is returning the rigth value.

Any ideas on what I do wrong when trying to reassemble the packet?

Gilles

-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
Sent: Monday, November 24, 2003 7:23 PM
To: Gilles Galipeau
Cc: 'ethereal-dev@xxxxxxxxxxxx'
Subject: Re: [Ethereal-dev] Reassembling a Splited TCP packet


On Mon, Nov 24, 2003 at 06:59:17PM -0500, Gilles Galipeau wrote:
> I am currently implementing a dissector that decode the data in a TCP V4
> message and I need some help on how to reassemble a packet splited over
> multiple TCP packet.
> 
> I have tried to do it using the tcp_dissect_pdus function provided in
tcp.h,
> but I could not get it to work.
> Here is the code before:
> 
>  <<packet-vn_Back_2003-11-13.c>> 
> And here is the decoding added in order to reassemble a packet splited
over
> multiple TCP packet:
>  <<packet-vn_Back_2003-11-24_Splitted_Packet_Recover.c>> 

I have no idea what all the "MAKE" macros, such as SYS_MAKEDWORD, do, so
I can't say whether your code is correct or incorrect.

However:

> Here is how the Versatel Networks packet are composed:
> 0                               32
> |-------------------------------|
> |Versatel Header|Protoco|Signal |
> |-------------------------------|
> |Payload Size           |SN (1) |
> |-------------------------------|

I infer from that diagram, and from the code, that the "Payload Size"
field starts at an offset of 4 bytes from the beginning of the packet,
and is 3 bytes long...

...except for the stuff that does

	The payload size is encoded differently if the protocol used is 
	DUPLICATION_PROTOCOL

which seems to imply that if the presumably-one-byte-long Protocol
field, and what appears to be an offset of 2 bytes from the beginning of
the packet, has the value DUPLICATION_PROTOCOL *OR* CRITICAL_PROTOCOL,
it's a 3-byte field, whereas for any other value it's a *two*-byte field
starting at an offset of *5* bytes from the beginning of the packet.

Are those values big-endian or little-endian?  If they're big-endian,
you should fetch the payload size with "tvb_get_ntohs()" if it's 2
bytes long and with "tvb_get_ntoh24()" if it's 3 bytes long; if they're
little-endian, you use "tvb_get_letohs()" if it's 2 bytes long and
"tvb_get_letoh24()" if it's 3 bytes long.  (You *don't* use
"tvb_get_guint8()" to fetch the individual bytes and then reassemble
them yourself - why do that when you can have a routine do it for you?)

In that case, you would do that in the packet dissector *AND* in
"get_vn_pdu_len()" - if the length of the payload size field differs
depending on the Protocol field's value, you have to check that value in
"get_vn_pdu_len()".