<p>neels <strong>uploaded patch set #3</strong> to this change.</p><p><a href="https://gerrit.osmocom.org/c/osmo-msc/+/15317">View Change</a></p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">fix error on BSSMAP Cipher Mode Complete L3 msg IE<br><br>When an MS returns the IMEISV in the BSSMAP Cipher Mode Complete message in<br>the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second<br>time, but instead point to it from the ran_msg.cipher_mode_complete struct.<br><br>When the MSC-A decodes the Ciphering Mode Complete message, it always wants to<br>also decode the enclosed DTAP from the Layer 3 Message Contents IE. However,<br>when the MSC-I preliminarily decodes messages, it often just wants to identify<br>specific messages without fully acting on them, let alone dispatching RAN_UP_L2<br>events more than once. So leave it up to the supplied decode_cb passed to<br>ran_dec_l2() implementations to decide whether to decode the DTAP.<br><br>In msc_a.c hence evaluate the DTAP by passing a non-allocated msgb instance to<br>msc_a_up_l3(), which will evaluate the RR Ciphering Mode Complete message found<br>in the BSSMAP Cipher Mode Complete's Layer 3 Message Contents IE.<br><br>Particularly, the previous choice of calling the decode_cb a second time for<br>the enclosed DTAP caused a header/length parsing error: the second decode_cb<br>call tried to mimick DTAP by overwriting the l3h pointer and truncating the<br>length of the msgb, but subsequently ran_a_decode_l2() would again derive the<br>l3h from the l2h, obliterating the intended re-interpretation as DTAP, and<br>hence the previous truncation caused error messages on each and every Cipher<br>Mode Complete message, like:<br><br>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<br><br>This error was seen a lot at CCCamp2019.<br><br>Modifying the msgb was a bad idea to begin with, the approach taken in this<br>patch is much cleaner.<br><br>Note that apparently many phones include the IMEISV in the Cipher Mode Complete<br>message even though the BSSMAP Cipher Mode Command did not include the Cipher<br>Response Mode IE. So, even though we did not specifically ask for the Cipher<br>Mode Complete to include any identity, many MS default to including the IMEISV<br>of their own accord. Reproduce: attach to osmo-msc with ciphering enabled using<br>a Samsung Galaxy S4mini.<br><br>Related: OS#4168<br>Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d<br>---<br>M include/osmocom/msc/ran_msg.h<br>M src/libmsc/msc_a.c<br>M src/libmsc/ran_msg_a.c<br>3 files changed, 22 insertions(+), 11 deletions(-)<br><br></pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;">git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/17/15317/3</pre><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-msc/+/15317">change 15317</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-msc/+/15317"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-msc </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d </div>
<div style="display:none"> Gerrit-Change-Number: 15317 </div>
<div style="display:none"> Gerrit-PatchSet: 3 </div>
<div style="display:none"> Gerrit-Owner: neels <nhofmeyr@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-MessageType: newpatchset </div>