It returns FALSE even if the packet is a session packet, except when it
appears to return a number rather than a true/false value.
Could you please explain what do you mean ?
dissect_ses always returns TRUE or FALSE.What is a number ?
The only check it does is to check whether the packet is at least 4 bytes
long; that's not enough - that means that it could accept packets that
aren't session-layer packets, which means that other heuristic dissectors
for COTP, such as the SMB dissector, might not get a chance to check
whether the packet is one of theirs.
Actually,it's a little bit complicated.
First,is the packet at least 4 >bytes long ? (You've seen it)
Second:
/* can we recognize session PDU ? */
/* get SPDU type */
reply_pdu = (struct SES_PDU*)tvb;
type = tvb_get_guint8(tvb, offset);
switch(type)
{
case SES_CONNECTION_REQUEST:
....... skip ....
default:
/* no, it isn't our business at all. */
return FALSE;
}
.... skip ...
return TRUE;
So if we can't recognize session pdu we'll return FALSE.
Do you think this is not enogh ?
Probably, we should say this is not session pdu in this case:
switch(parms->type)
{
case Called_SS_user_Reference:
sprintf(tmp,"Called SS user Reference:");
........
default:
sprintf(tmp,"Unknown session parameter:0x%02x",parms->type);
break;
}
But it might really have been good session packet with wrong parameters.
If it's not possible to have a good heuristic to check for OSI Session
packets, perhaps the COTP dissector should try its heuristics and, if none
of them match, try the session dissector.
Do you mean we have to change packet-clnp.c ? Probably, this is a good
solution.
It also casts "dissect_ses" to a "void *", which hides the compiler errors
that would have detected the original problem. Remove those casts, and
either fix or remove the lines that get errors or warnings as a result of
that change. (All the lines I saw could just be removed.)
OK.
Note also that you have a number of places where you do a "switch()" on
some value and select a constant string based on the value; that's probably
best done using a value_string table - especially if the value has a field
associated with it, because you can then associate that value_string table
with the field.
Thank you for your attention.
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus