Change in ...osmo-msc[master]: fix error on Ciphering Mode Complete L3 IE decoding

neels gerrit-no-reply at lists.osmocom.org
Wed Aug 28 22:45:23 UTC 2019


Hello Jenkins Builder, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmo-msc/+/15317

to look at the new patch set (#2).

Change subject: fix error on Ciphering Mode Complete L3 IE decoding
......................................................................

fix error on Ciphering Mode Complete L3 IE decoding

When an MS returns the IMEISV in the BSSMAP Ciphering Mode Complete message in
the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second
time, but instead point to it from the ran_msg.cipher_mode_complete struct.

When the MSC-A decodes the Ciphering Mode Complete message, it always wants to
also decode the enclosed DTAP from the Layer 3 Message Contents IE. However,
when the MSC-I preliminarily decodes messages, it often just wants to identify
specific messages without fully acting on them, let alone dispatching RAN_UP_L2
events more than once. So leave it up to the supplied decode_cb passed to
ran_dec_l2() implementations to decide whether to decode the DTAP.

In msc_a.c hence evaluate the DTAP by passing a non-allocated msgb instance to
msc_a_up_l3(), which will evaluate the RR Ciphering Mode Complete message found
in the BSSMAP Ciphering Mode Complete's Layer 3 Message Contents IE.

Particularly, the previous choice of calling the decode_cb a second time for
the enclosed DTAP caused a header/length parsing error: the second decode_cb
call tried to mimick DTAP by overwriting the l3h pointer and truncating the
length of the msgb, but subsequently ran_a_decode_l2() would again derive the
l3h from the l2h, obliterating the intended re-interpretation as DTAP, and
hence the previous truncation caused error messages on each and every Ciphering
Mode Complete message, like:

DBSSAP ERROR libmsc/ran_msg_a.c:764 msc_a(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0xA73E055A:GERAN-A-77923:LU)[0x5563947521e0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSMAP: BSSMAP data truncated, discarding message

This error was seen a lot at CCCamp2019.

Modifying the msgb was a bad idea to begin with, the approach taken in this
patch is much cleaner.

Note that apparently many phones include the IMEISV in the Cipher Mode Complete
message even though the BSSMAP Cipher Mode Command did not include the Cipher
Response Mode IE. So, even though we did not specifically ask for the Cipher
Mode Complete to include any identity, many MS default to including the IMEISV
of their own accord. Reproduce: attach to osmo-msc with Ciphering enabled using
a Samsung Galaxy S4mini.

Related: OS#4168
Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
---
M include/osmocom/msc/ran_msg.h
M src/libmsc/msc_a.c
M src/libmsc/ran_msg_a.c
3 files changed, 22 insertions(+), 11 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/17/15317/2
-- 
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/15317
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
Gerrit-Change-Number: 15317
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190828/092d7391/attachment.html>


More information about the gerrit-log mailing list