From 62c148c1d58c84791033da807db32c5a5752c4b8 Mon Sep 17 00:00:00 2001 From: Stephen Fisher Date: Sun, 21 Jan 2007 23:36:53 +0000 Subject: [PATCH] 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 --- epan/dissectors/packet-bssap.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/epan/dissectors/packet-bssap.c b/epan/dissectors/packet-bssap.c index ac8fdcca9c..88ee341a84 100644 --- a/epan/dissectors/packet-bssap.c +++ b/epan/dissectors/packet-bssap.c @@ -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: