Hi,
I am new to this list so sorry if my questions seem ignorant ..
I am implementing a ethereal driver for the Cisco skinny client control
protocol, sccp (Used to communicate to Cisco VoIP hardware, like
the Cisco 7960 IP phone). For now, I only use it for my own stuff, but
I may relase it some time in the future, if there should be any interest.
My driver works all nice and fine except for the fact when
a tcp message larger than 500 bytes is sent.
The tvbuff i get seems to be max 500 bytes, so I get a malformed
message in the display.
>From earlier mails in the ethereal-dev archive it seems
that is som a builtin limitation, ie. it
does not take any measure to re-construct fragmented TCP payload,
so it is difficult to handle it correctly.
My question is: Is it possible to hardcode this 500 byte limit to something
slightly larger ? If I could for example raise it to 750, then I would get
all sccp messages unfragmented, and they would display nicely.
Or is this limited by the MTU size or something like that ?
In the project I'm working on, I implemented a mechanism similar to the
dissect callbacks for receiving TCP data. Ie. a generalization used by several
TCP protocols to handle the one-message-in-many-frames and
many-frames-in-one-message problems.
Basically I had two callbacks instead of one
For example:
uint32 get_message_lengths_sccp(void *buf,
uint32 buflength,
uint32 msg_lengths[MAX_LENGTHS]);
This callback will search the buffer "buf" of length "buflength" and look for
complete
sccp messages. The return value is the number of complete messages
found. For each complete message it finds it inserts
the length of the message into the msg_lengths[] array,
so that the caller can know how the payload is organized.
In sccp it is easy to check for complete messages, as the payload size is
given in the msg header. For example in SIP I one must look
for Content-Length and \r\n\r\n to find the length of the message.
For protocols using the TPKT stuff (like H.323), I just get the
size from the TPKT header.
If the callback returns 0, ie. no complete messages, then the
message defragmenter thingy
will think it is a one-message-in-many-frames situation and
buffer the previous input. It will call the callback when more input
is available.
When it has got a number of complete messages,
then it call a process_message_sccp(void *msg, uint32 msg_length)
callback to process a single message.
So basically to process input one have to do two passes over the frame,
one to get the number of complete messages in the frame, and the length of
each message, and then call a new callback on each message to dissect it.
Out of curiosity, would it be possible to do something similar in ethereal ?
It would mean adding an extra callback to the dissector to be able to
do it this way. I guess it would require some architectural changes, though.
Nils Henrik
