From Tobias Witek:

I found a rare situation in which the BSSAP dissector seems to wrongly
assume a packet.

When a RANAP DirectTransfer message contains the GSM Supplementary
Service 'Call Confirmed' this seems to yield a message that the BSSAP
dissector recognizes as a BSSMAP BLOCK message (and from the perspective
of BSSAP, this is perfectly correct).

My patch includes code that checks this very special case.


svn path=/trunk/; revision=20520
This commit is contained in:
Stephen Fisher 2007-01-21 23:36:53 +00:00
parent 597faab3c6
commit 62c148c1d5
1 changed files with 5 additions and 0 deletions

View File

@ -2133,11 +2133,16 @@ dissect_bssap_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
* If octet_1 == 0x00 and octet_2 == length(tvb) - 2
* or if octet_1 == 0x01 and octet_3 == length(tvb) - 3
* then we'll assume it is a bssap packet
* If octet_1 == 0x00 a further check is done
* to differentiate a BSSMAP BLOCK message from a
* RANAP DirectTransfer (under certain conditions)
*/
switch (tvb_get_guint8(tvb, 0))
{
case 0x00:
if (tvb_get_guint8(tvb, 1) != (tvb_length(tvb) - 2)) { return(FALSE); }
if (tvb_get_guint8(tvb, 2) == 0x40 && tvb_get_guint8(tvb, 3) != 0x01) {
return(FALSE); }
break;
case 0x01: