https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-12-14T01:29:26ZOpen Source Mobile CommunicationsOsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=67992017-12-14T01:29:26Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>I can reproduce the error with a sysmoUSIM set to 2G=COMP128v3 3G=MILENAGE, and both 2G and 3G data available from the HLR db.</p>
<p>I observe <strong>two</strong> errors:</p>
<ol>
<li>We send a UMTS AUTN challenge in the authentication request, even though 2G is set to COMP128v3.<br /> Nevertheless, the UMTS AKA succeeds, i.e. the SIM responds with a valid extended RES.</li>
<li>During the BSSMAP Cipher Mode Command that follows, according to wireshark, we are sending only A5/7 as permitted, while the MSC (as well as BSC) config has 'encryption a5 3' configured.</li>
</ol>
<pre>
No. Time Length Source Source Port Destination Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
316 25.032538428 158 185 187 BSSAP SACK DT1 (DTAP) (MM) Authentication Request
Frame 316: 158 bytes on wire (1264 bits), 158 bytes captured (1264 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 50788 (50788)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F DTAP - Authentication Request
Protocol Discriminator: Mobility Management messages (5)
.... 0101 = Protocol discriminator: Mobility Management messages (0x5)
0000 .... = Skip Indicator: No indication of selected PLMN (0)
00.. .... = Sequence number: 0
..01 0010 = DTAP Mobility Management Message Type: Authentication Request (0x12)
0000 .... = Spare bit(s): 0
Ciphering Key Sequence Number
.... 0... = Spare bit(s): 0
.... .000 = Ciphering Key Sequence Number: 0
Authentication Parameter RAND - UMTS challenge or GSM challenge
RAND value: 06cf2ddd6a55e98693e55fd01f90cb6f
Authentication Parameter AUTN (UMTS and EPS authentication challenge)
Element ID: 0x20
Length: 16
AUTN value: d18b74d5ae0e00004686a93e9bcb9687
SQN xor AK: d18b74d5ae0e
AMF: 0000
MAC: 4686a93e9bcb9687
No. Time Length Source Source Port Destination Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
333 25.965076597 118 187 185 BSSAP DT1 (DTAP) (MM) Authentication Response
Frame 333: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 43964 (43964)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F DTAP - Authentication Response
Protocol Discriminator: Mobility Management messages (5)
.... 0101 = Protocol discriminator: Mobility Management messages (0x5)
0000 .... = Skip Indicator: No indication of selected PLMN (0)
10.. .... = Sequence number: 2
..01 0100 = DTAP Mobility Management Message Type: Authentication Response (0x14)
Authentication Response Parameter
SRES value: 95c27877
Authentication Response Parameter (extension) (UMTS authentication challenge only)
Element ID: 0x21
Length: 4
XRES value: 98c48e56
No. Time Length Source Source Port Destination Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
335 25.966740569 134 185 187 BSSAP SACK DT1 (BSSMAP) Cipher Mode Command
Frame 335: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 50788 (50788)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F BSSMAP - Cipher Mode Command
Message Type Cipher Mode Command
Encryption Information
Element ID: 0x0a
Length: 9
1... .... = GSM A5/7: Permitted
.0.. .... = GSM A5/6: Not permitted
..0. .... = GSM A5/5: Not permitted
...0 .... = GSM A5/4: Not permitted
.... 0... = GSM A5/3: Not permitted
.... .0.. = GSM A5/2: Not permitted
.... ..0. = GSM A5/1: Not permitted
.... ...0 = No encryption: Not permitted
Key: 818709baba205891
No. Time Length Source Source Port Destination Destination Port Protocol Media Port Context-ID CN-DomainIndicator Info
337 25.967697395 122 187 185 BSSAP SACK DT1 (BSSMAP) Cipher Mode Reject
Frame 337: 122 bytes on wire (976 bits), 122 bytes captured (976 bits) on interface 1
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Stream Control Transmission Protocol, Src Port: 2905 (2905), Dst Port: 43964 (43964)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
BSSAP
GSM A-I/F BSSMAP - Cipher Mode Reject
Message Type Cipher Mode Reject
Missing Mandatory element (0x04) Cause, rest of dissection is suspect
[Expert Info (Warning/Protocol): Missing Mandatory element (0x04) Cause, rest of dissection is suspect]
[Missing Mandatory element (0x04) Cause, rest of dissection is suspect]
[Severity level: Warning]
[Group: Protocol]
Extraneous Data, dissector bug or later version spec(report to wireshark.org)
[Expert Info (Note/Protocol): Extraneous Data, dissector bug or later version spec(report to wireshark.org)]
[Extraneous Data, dissector bug or later version spec(report to wireshark.org)]
[Severity level: Note]
[Group: Protocol]
</pre> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68172017-12-14T20:42:26Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p><a class="external" href="https://gerrit.osmocom.org/5376">https://gerrit.osmocom.org/5376</a> fixes passing the proper encryption algorithm on from MSC to BSC.<br /><a class="external" href="https://gerrit.osmocom.org/5380">https://gerrit.osmocom.org/5380</a> fixes passing encryption algorithms other than A5/1 on from BSC to BTS.</p> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68182017-12-14T21:35:41Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The remaining issue is that in the presence of both 2G and 3G tokens in the HLR db, we do UMTS AKA but send a GSM AKA Kc.</p>
<p>This happens because the MSC doesn't really know what algorithms have been set in the HLR db. All that the MSC sees is the presence of UMTS AKA tokens in the auth vector.</p>
<p>There will always be GSM AKA tokens in the vector as well: either because explicit GSM tokens are set in the HLR DB, or because the GSM tokens were derived from the 3G tokens. The 3G derived tokens and the 2G tokens take the same place in the auth vector, only one of the two will be provided, without an indication which ones they are.</p>
<p>So, if the MS indicates it is R99 capable on an R99 GERAN, and if there are 3G tokens available in the auth vector, we always send a UMTS challenge complete with AUTN. The response we receive is allowed to be just a GSM SRES, which the MS may decide to send when on a GERAN. But practically, what I see is, that, despite COMP128v3 set on the USIM as 2G algo, the USIM actually responds with a full UMTS AKA RES+XRES matching the 3G tokens. That works out and auth succeeds.</p>
<p>Next up is ciphering. On a GERAN, we always use the Kc from the auth tuple for the Ciphering Mode Command. Since the auth token received from the HLR contains a 2G Kc calculated <em>separately</em> from the 3G tokens, the Kc now mismatches the UMTS AKA that took place earlier. IOW, since COMP128v3 is set for that subscriber in the HLR db, that Kc has not been derived from the 3G data we used for authn, but it has been calculated from the GSM KI and uses COMP123v3. We naturally never receive a Ciphering Mode Response and reject in timeout.</p>
<p>How to solve this? Things that come to mind...</p>
<ul>
<li>Q: the sysmo-usim-tool names the USIM settings to set auth algos "2G" and "3G". Would the naming be more accurately be "GSM" and "UMTS"? i.e. that when "2G = COMP128v3" and "3G = MILENAGE" are set on the USIM, are we instructing to use milenage on R99 capable 2G networks, and COMP128v3 only in non-R99 2G networks? (This seems to make most sense to me)
<ul>
<li>If this is so, we need to receive a 3G-derived Kc from the HLR independently from whether aud_2g tokens were also provided or not. Currently, a 2G Kc completely replaces the 3G derived one, instead we need <em>both</em> sent in the vector from the HLR.</li>
<li>So, for an <strong>R99</strong> GERAN or MS, we would use UMTS AKA and the 3G derived Kc.</li>
<li>For a <strong>pre</strong>-R99 GERAN or MS, we would use GSM AKA and the separately calculated Kc.</li>
</ul></li>
</ul>
<ul>
<li>If the MSC knew that the 2G tokens were explicitly calculated from a separate GSM algo and <em>not</em> derived from 3G, it could refrain from sending a UMTS challenge on 2G, even if it is R99. Hence we would use only the 2G data, the shorter SRES and the ciphering key Kc would correspond with the keys used for authentication. (This would mean we would do UMTS AKA on 2G <em>only</em> if no aud_2g tokens are added to the HLR DB; R99 or not. So we would not be able to dynamically choose between UMTS or GSM AKA, which makes little sense to me.)</li>
</ul>
Either way it seems to me we need to extend the IEs sent via GSUP from the HLR,
<ul>
<li>either to add a separate 3G-derived Kc and SRES (I'm favoring this),</li>
<li>or to add a flag whether Kc was derived from 3G or not.</li>
</ul>
<p>Am I missing something?</p> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68192017-12-14T21:39:27Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>To clarify the status quo, a workaround is to have only one set of auth tokens in the HLR db, either remove the aud_2g or remove the aud_3g.</p>
<ul>
<li>If <strong>only</strong> 2G tokens are present in the HLR db, auth and ciphering works well, using GSM AKA.</li>
<li>If <strong>only</strong> 3G tokens are present in the HLR db, auth and ciphering works well, using UMTS AKA if R99 and 3G derived Kc.</li>
<li>If <strong>both</strong> 2G and 3G tokens are present in the HLR db, authentication works (using UMTS AKA), but ciphering fails.</li>
</ul> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68202017-12-15T08:46:00Zlaforge
<ul></ul><p>Hi Neels,</p>
<p>On Thu, Dec 14, 2017 at 09:35:41PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>The remaining issue is that in the presence of both 2G and 3G tokens<br />in the HLR db, we do UMTS AKA but send a GSM AKA Kc.</p>
</blockquote>
<p>Isn't this exactly what is expected?</p>
<blockquote>
<p>This happens because the MSC doesn't really know what algorithms have<br />been set in the HLR db. All that the MSC sees is the presence of UMTS<br />AKA tokens in the auth vector.</p>
</blockquote>
<p>This is how I understand it should be.</p>
<blockquote>
<p>So, if the MS indicates it is R99 capable on an R99 GERAN, and if<br />there are 3G tokens available in the auth vector, we always send a<br />UMTS challenge complete with AUTN.</p>
</blockquote>
<p>Also fits with my understanding.</p>
<blockquote>
<p>The response we receive is allowed to be just a GSM SRES, which the MS<br />may decide to send when on a GERAN.</p>
</blockquote>
<p>This is what I'm surprised to hear. Do you have a spec reference for<br />that? My understanding has been that basically <strong>if</strong> the MS is UMTS-AKA<br />capable, then we perform UMTS AKA and should also expect a full<br />RES+XRES. So if we send a 3G AKA, we expect to receive 3G AK.</p>
<blockquote>
<p>But practically, what I see is, that, despite COMP128v3 set on the<br />USIM as 2G algo, the USIM actually responds with a full UMTS AKA<br />RES+XRES matching the 3G tokens.</p>
</blockquote>
<p>Of course. The radio technology has no relation on the way how the<br />phone firmware talks to the SIM card. If the phone talks to the SIM<br />using the USIM application (which at least any 3G capable phone will<br />do), then it will use the "3G algo" of the SIM. If however the phone<br />firmware talks to the SIM in "SIM" mode, then the card will use the "2G<br />algo".</p>
<blockquote>
<p>Next up is ciphering. On a GERAN, we always use the Kc from the auth<br />tuple for the Ciphering Mode Command. Since the auth token received<br />from the HLR contains a 2G Kc calculated <em>separately</em> from the 3G<br />tokens, the Kc now mismatches the UMTS AKA that took place earlier.<br />IOW, since COMP128v3 is set for that subscriber in the HLR db, that Kc<br />has not been derived from the 3G data we used for authn, but it has<br />been calculated from the GSM KI and uses COMP123v3. We naturally never<br />receive a Ciphering Mode Response and reject in timeout.</p>
</blockquote>
<p>This is also expected. The choice of Kc must be made based on the<br />authentication algorithm used. So if authentication proceeds with<br />UMTS AKA, then the Kc must be derived from Ck/Ik using one of those<br />mapping functions given in the relevant specs. According to some<br />notes I took years ago I think it was function "c3" in TS 33.102</p>
<p>btw: Please also not the similar c4/c5 functions which must be used<br />if a UMTS AKA is to be performed purely on GSM auth tuples (e.g. using<br />a classic SIM wihout USIM capability)</p>
<p>Only if authentication was made using the classic 2G RAND, the Kc value<br />received in the quintuple from the HLR/AuC must be used in the MSC!</p>
<blockquote>
<ul>
<li>Q: the sysmo-usim-tool names the USIM settings to set auth algos<br />"2G" and "3G". Would the naming be more accurately be "GSM" and<br />"UMTS"?</li>
</ul>
</blockquote>
<p>The correct naming would be "SIM application" and "USIM application".<br />However, we used the naming of the SIM card OS maker. The choice of<br />which "application" the phone firmware talks to is irrespective of which<br />current RAT is in use. The SIM has [normally, ignoring proactive SIM]<br />no knowledge on the current RAT.</p>
<blockquote>
<p>i.e. that when "2G = COMP128v3" and "3G = MILENAGE" are set on<br />the USIM, are we instructing to use milenage on R99 capable 2G<br />networks, and COMP128v3 only in non-R99 2G networks? (This seems to<br />make most sense to me)</p>
</blockquote>
<p>Correct.</p>
<blockquote>
<ul>
<li>If this is so, we need to receive a 3G-derived Kc from the HLR<br />independently from whether aud_2g tokens were also provided or not.<br />Currently, a 2G Kc completely replaces the 3G derived one, instead we<br />need <em>both</em> sent in the vector from the HLR.</li>
</ul>
</blockquote>
<p>Why would this have to be done in the HLR? Why can't the MSC simply<br />derive the Kc? Changing the bits communicated between HLR and MSC to<br />something that's not present in GSM MAP would make it impossible to ever<br />interoperate with MAP.</p>
<p>I think all that's needed to do in the MSC in such cases is</p>
<p>for (i = 0; i < 8; i++)<br /> kc[i] = ck[i] ^ ck[i + 8] ^ ik[i] ^ ik[i + 8];</p>
<p>See libosmocor/src/gsm/milenage/milenage.c:gsm_milenage()</p>
<blockquote>
<ul>
<li>If the MSC knew that the 2G tokens were explicitly calculated from a<br />separate GSM algo and <em>not</em> derived from 3G, it could refrain from<br />sending a UMTS challenge on 2G, even if it is R99.</li>
</ul>
</blockquote>
<p>Why?</p>
<blockquote>
Either way it seems to me we need to extend the IEs sent via GSUP from the HLR,
<ul>
<li>either to add a separate 3G-derived Kc and SRES (I'm favoring this),</li>
<li>or to add a flag whether Kc was derived from 3G or not.</li>
</ul>
</blockquote>
<p>I don't think so.</p>
<blockquote>
<p>Am I missing something?</p>
</blockquote>
<p>gsm_milenage</p> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68332017-12-15T18:18:27Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>so, to recap: if on R99 capable devices and aud_3g data is present in the HLR, we use full UMTS AKA and expect the "3G" a.k.a. USIM app's auth algo to be used (not the SIM app a.k.a. "2G").</p>
<p>My thinko there lies in the fact that the Kc-from-UMTS-tokens formula is actually algorithm agnostic.<br />3GPP TS 33.103 4.2.2 "Authentication and key agreement (AKA USIM )" <br /><pre>
The following cryptographic functions need to be implemented on the USIM:
[...]
c3: Conversion function for interoperation with GSM from Ck and IK (UMTS) to Kc (GSM).</pre><br /></pre></p>
<p>Since c3 is algorithm agnostic, the MSC can employ it without having to know whether the HLR and USIM are using Milenage or whatever.</p>
<p>When using UMTS AKA, we should never use the Kc we got from GSUP. Instead, we always use c3(). (If the Kc from GSUP was derived from 3G in the HLR, incidentally that will be the same Kc as we will calculate in the MSC, and that doesn't bear any meaning; ignore the GSUP Kc, calculate it from UMTS tokens.)</p>
<p>If there are no aud_2g data in the HLR, the HLR will derive Kc and SRES from the UMTS tokens; that will only be used on non-R99 MS/GERAN, in which case we use the GSUP Kc for ciphering.</p>
<table>
<tr>
<td> </td>
<td> non-R99 GERAN / non-R99 MS </td>
<td> R99 GERAN and R99 MS </td>
</tr>
<tr>
<td> only aud_2g in HLR,<br /> GSUP sent only Kc and SRES </td>
<td colspan="2">use GSUP's Kc and SRES </td>
</tr>
<tr>
<td> only aud_3g in HLR,<br /> GSUP sent UMTS AKA tokens<br /> as well as Kc and SRES derived from 3G AKA </td>
<td> use GSUP's Kc and SRES, incidentally derived from 3G keys </td>
<td> use full UMTS AKA; MSC ignores GSUP's Kc and calculates Kc from c3() (incidentally ends up to be the same Kc as from GSUP) </td>
</tr>
<tr>
<td> aud_2g and aud_3g in HLR,<br /> GSUP sent UMTS AKA tokens<br /> as well as Kc and SRES from <strong>separate</strong> 2G algo </td>
<td> use GSUP's Kc and SRES </td>
<td> use full UMTS AKA; MSC ignores GSUP's Kc and calculates Kc from c3() (incidentally differs from GSUP's Kc) </td>
</tr>
</table> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68352017-12-15T19:04:22Zneelsnhofmeyr@sysmocom.de
<ul></ul><blockquote><blockquote>
<p>The response we receive is allowed to be just a GSM SRES, which the MS<br />may decide to send when on a GERAN.</p>
</blockquote>
<p>This is what I'm surprised to hear. Do you have a spec reference for<br />that?</p>
</blockquote>
<p>There is a code comment in that direction:</p>
<p>osmo-msc/src/libvlr/vlr_auth_fsm.c<br /><pre>
/* We have a R99 capable UE and have a UMTS AKA capable USIM.
* However, the ME may still choose to only perform GSM AKA, as
* long as the bearer is GERAN */
</pre></p>
<p>You added that comment on first vlr_auth_fsm.c implementation, so you may have had your reasons for that?</p> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68402017-12-16T21:14:40Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Subject</strong> changed from <i>2G auth does not work when 3G keys are provisioned.</i> to <i>UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.</i></li></ul> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68422017-12-16T21:24:59Zlynxis
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-2 priority-default closed" href="/issues/2765">Bug #2765</a>: umts auth timed out on a 2G network.</i> added</li></ul> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68542017-12-17T21:35:55Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-1 status-6 priority-2 priority-default closed" href="/issues/2765">Bug #2765</a>: umts auth timed out on a 2G network.</i>)</li></ul> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68562017-12-17T21:36:06Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Has duplicate</strong> <i><a class="issue tracker-1 status-6 priority-2 priority-default closed" href="/issues/2765">Bug #2765</a>: umts auth timed out on a 2G network.</i> added</li></ul> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68572017-12-18T03:31:19Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>90</i></li></ul><p>issue fixed by <a class="external" href="https://gerrit.osmocom.org/5470">https://gerrit.osmocom.org/5470</a> (And patches leading up to it, see topic 'encryption' on gerrit)<br /><a class="external" href="https://gerrit.osmocom.org/#/q/status:open+topic:encryption">https://gerrit.osmocom.org/#/q/status:open+topic:encryption</a></p>
<p>Depends on libosmocore <a class="external" href="https://gerrit.osmocom.org/5466">https://gerrit.osmocom.org/5466</a></p> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=68582017-12-18T03:31:32Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Project</strong> changed from <i>OsmoHLR</i> to <i>OsmoMSC</i></li></ul> OsmoMSC - Bug #2745: UMTS ciphering on GSM does not work when both 2G and 3G keys are present in the HLR.https://osmocom.org/issues/2745?journal_id=71062018-01-11T11:28:43Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>all merged, yet <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: phone "swiss one SC230" fails to do ciphering with 2G and 3G auth tokens present (Resolved)" href="https://osmocom.org/issues/2793">#2793</a> may be related</p>