Bug #4660
openGSM AUTH failure: mismatching sres - with module TRM-5 ext
0%
Description
Hello,
The Triorail TRM-5 ext cellular module cannot connect to the osmocom network. A string of errors begins with "GSM AUTH failure: mismatching sres (expected sres=e6 33 aa d8 )".
The log from the MSC and the HLR parameters is attached. The SIM used is sysmoUSIM-SJS1 in the factory config.
I am ready to cooperate in (collecting logs, provide more details, ...).
BR
Marek
MYIMSI=9017xxxxxxxxxxx
gsm_04_08.c:324 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_VALIDATE_L3}: LOCATION UPDATING REQUEST: MI=IMSI-MYIMSI LU-type=NORMAL
<0002> gsm_04_08.c:367 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_VALIDATE_L3}: USIM: old LAI: 901-70-65534
<000e> fsm.c:461 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_IDLE}: Allocated
<000e> fsm.c:491 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_IDLE}: is child of msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]
<000e> vlr_lu_fsm.c:1523 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_IDLE}: rev=R99 net=GERAN Auth (no Ciph)
<000e> vlr_lu_fsm.c:1529 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
<000e> vlr.c:435 set IMSI on subscriber; IMSI=MYIMSI id=MYIMSI
<000e> vlr.c:386 New subscr, IMSI: MYIMSI
<0006> gsm_04_08.c:1374 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_VALIDATE_L3}: Received Event MSC_A_EV_COMPLETE_LAYER_3_OK
<0006> msc_a.c:202 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_VALIDATE_L3}: State change to MSC_A_ST_AUTH_CIPH (keeping X1, 4.999s remaining)
<000e> vlr_lu_fsm.c:924 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1_pre()
<000e> vlr_lu_fsm.c:901 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
<000e> vlr_lu_fsm.c:908 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_IDLE}: State change to VLR_ULA_S_WAIT_AUTH (T0, 30s)
<000e> fsm.c:461 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_NEEDS_AUTH}: Allocated
<000e> fsm.c:491 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]
<000e> vlr_auth_fsm.c:629 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
<000e> vlr_auth_fsm.c:318 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_NEEDS_AUTH}: State change to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI (T0, 30s)
<000e> vlr.c:769 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
<000e> vlr.c:743 SUBSCR(IMSI-MYIMSI) Received 5 auth tuples
<000e> vlr_auth_fsm.c:375 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: State change to VLR_SUB_AS_WAIT_RESP (no timeout)
<000e> vlr_auth_fsm.c:286 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use UMTS AKA (is_r99=yes, at->vec.auth_types=0x3)
<0010> msc_a.c:1614 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: Sending DTAP: MM GSM48_MT_MM_AUTH_REQ
<0010> ran_msg_a.c:1201 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: RAN encode: BSSMAP: DTAP
<0006> msc_a.c:1620 msc_i(IMSI-MYIMSI:GERAN-A-3:LU)[0x11765b0]{READY}: Received Event MSC_I_EV_FROM_A_FORWARD_ACCESS_SIGNALLING_REQUEST
<0006> ran_peer.c:412 msc_i(IMSI-MYIMSI:GERAN-A-3:LU)[0x11765b0]{READY}: Received Event MSC_EV_FROM_RAN_UP_L2
<0006> msc_i.c:85 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: Received Event MSC_A_EV_FROM_I_PROCESS_ACCESS_SIGNALLING_REQUEST
<0010> msc_a.c:1547 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSAP DTAP
<0000> msc_a.c:1182 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: Dispatching 04.08 message: MM GSM48_MT_MM_AUTH_RESP
<0002> gsm_04_08.c:984 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: MM GSM AUTHENTICATION RESPONSE (sres = 7c33dae4)
<000e> vlr.c:1330 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
<000e> vlr_auth_fsm.c:136 SUBSCR(IMSI-MYIMSI) AUTH on GERAN received SRES/RES: 7c33dae4 (4 bytes)
<000e> vlr_auth_fsm.c:203 SUBSCR(IMSI-MYIMSI) GSM AUTH failure: mismatching sres (expected sres=e6 33 aa d8 )
<000e> vlr_auth_fsm.c:244 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result Illegal MS
<000e> vlr_auth_fsm.c:250 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_WAIT_RESP}: State change to VLR_SUB_AS_AUTH_FAILED (no timeout)
<000e> vlr_auth_fsm.c:253 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_AUTH_FAILED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
<000e> vlr_auth_fsm.c:253 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_AUTH_FAILED}: Removing from parent vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]
<000e> vlr_auth_fsm.c:253 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_AUTH_FAILED}: Freeing instance
<000e> fsm.c:573 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_AUTH_FAILED}: Deallocated
<000e> vlr_auth_fsm.c:253 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
<0002> gsm_04_08.c:108 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: LOCATION UPDATING REJECT
<0010> msc_a.c:1614 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: Sending DTAP: MM GSM48_MT_MM_LOC_UPD_REJECT
<0010> ran_msg_a.c:1201 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: RAN encode: BSSMAP: DTAP
<0006> msc_a.c:1620 msc_i(IMSI-MYIMSI:GERAN-A-3:LU)[0x11765b0]{READY}: Received Event MSC_I_EV_FROM_A_FORWARD_ACCESS_SIGNALLING_REQUEST
<000e> vlr_lu_fsm.c:741 vlr_lu_fsm(IMSI-MYIMSI:GERAN-A-3:LU)[0x1176a00]{VLR_ULA_S_WAIT_AUTH}: State change to VLR_ULA_S_DONE (no timeout)
<0006> vlr_lu_fsm.c:733 msc_a(IMSI-MYIMSI:GERAN-A-3:LU)[0x11768d0]{MSC_A_ST_AUTH_CIPH}: Received Event MSC_A_EV_CN_CLOSE
smoHLR# subscriber imsi MYIMSI show
ID: xxx
IMSI: MYIMSI
MSISDN: xxxxxxxxxx
VLR number: MSC-00-00-00-00-00-00
SGSN number: SGSN-00-00-00-00-00-00
PS purged
last LU seen on CS: Tue Jul 7 09:08:49 2020 UTC
last LU seen on PS: Tue Jul 7 09:08:53 2020 UTC
3G auth: MILENAGE
K=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
OPC=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
IND-bitlen=5 last-SQN=xxxxx
Updated by fixeria almost 4 years ago
Hello,
The Triorail TRM-5 ext cellular module [...]
huh, this is a GSM-R modem, right? Interesting.
OsmoHLR# subscriber imsi MYIMSI show
3G auth: MILENAGE
...
You have configured 3G authentication parameters, but as the log states:
gsm_04_08.c:324 msc_a(IMSI-MYIMSI:GERAN-A-3:LU) ...
you're trying to authenticate in GERAN, i.e. 2G. I don't know if the MSC is supposed to derive the 2G authentication parameters from 3G parameters somehow, but I would try to configure 2G authentication parameters first. Also, make sure that the SIM card is actually configured to use MILENAGE (can be checked/changed using sysmo-usim-tool).
Updated by MPoslusny almost 4 years ago
You're right the TRM-5 can connect GSM-R, not just GSM-R. I have tested that it connects to a commercial operator with a commercial SIM with a commercial service via GPRS / EDGE (T-mobile, Vodafone).
Here is datasheet
https://www.triorail.com/fileadmin/editor/triorail/downloads/en/Datasheets_2019correction/Datasheet_TRM-5_ext__022019.pdf
The osmo-HLR seems to be trying to convert. I see it in the log.
DAUC DEBUG db_auc.c:147 IMSI='MYIMSI': No 2G Auth Data DAUC DEBUG db_auc.c:219 IMSI='MYIMSI': Calling to generate 5 vectors DAUC DEBUG auc.c:94 Computing 5 auth vectors: 3G only (2G derived from 3G keys) DAUC DEBUG auc.c:96 3G: k = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:99 3G: opc = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:101 3G: for sqn ind 0, previous sqn was xxxxxx DAUC DEBUG auc.c:113 vector [0]: rand = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:137 vector [0]: sqn = xxxxxx DAUC DEBUG auc.c:139 vector [0]: autn = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:140 vector [0]: ck = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:141 vector [0]: ik = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:142 vector [0]: res = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:143 vector [0]: res_len = 8 DAUC DEBUG auc.c:147 vector [0]: deriving 2G from 3G DAUC DEBUG auc.c:148 vector [0]: kc = xxxxxxxxxxxxxxxx DAUC DEBUG auc.c:149 vector [0]: sres = 3a91885b DAUC DEBUG auc.c:150 vector [0]: auth_types = 0x3 DAUC DEBUG auc.c:113 vector [1]: rand = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:137 vector [1]: sqn = xxxxxx DAUC DEBUG auc.c:139 vector [1]: autn = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:140 vector [1]: ck = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:141 vector [1]: ik = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:142 vector [1]: res = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:143 vector [1]: res_len = 8 DAUC DEBUG auc.c:147 vector [1]: deriving 2G from 3G DAUC DEBUG auc.c:148 vector [1]: kc = xxxxxxxxxxxxxxxx DAUC DEBUG auc.c:149 vector [1]: sres = f486783a DAUC DEBUG auc.c:150 vector [1]: auth_types = 0x3 DAUC DEBUG auc.c:113 vector [2]: rand = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:137 vector [2]: sqn = xxxxxx DAUC DEBUG auc.c:139 vector [2]: autn = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:140 vector [2]: ck = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:141 vector [2]: ik = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:142 vector [2]: res = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:143 vector [2]: res_len = 8 DAUC DEBUG auc.c:147 vector [2]: deriving 2G from 3G DAUC DEBUG auc.c:148 vector [2]: kc = xxxxxxxxxxxxxxxx DAUC DEBUG auc.c:149 vector [2]: sres = c813099c DAUC DEBUG auc.c:150 vector [2]: auth_types = 0x3 DAUC DEBUG auc.c:113 vector [3]: rand = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:137 vector [3]: sqn = xxxxxx DAUC DEBUG auc.c:139 vector [3]: autn = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:140 vector [3]: ck = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:141 vector [3]: ik = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:142 vector [3]: res = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:143 vector [3]: res_len = 8 DAUC DEBUG auc.c:147 vector [3]: deriving 2G from 3G DAUC DEBUG auc.c:148 vector [3]: kc = xxxxxxxxxxxxxxxx DAUC DEBUG auc.c:149 vector [3]: sres = 179240ae DAUC DEBUG auc.c:150 vector [3]: auth_types = 0x3 DAUC DEBUG auc.c:113 vector [4]: rand = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:137 vector [4]: sqn = xxxxxx DAUC DEBUG auc.c:139 vector [4]: autn = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:140 vector [4]: ck = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:141 vector [4]: ik = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:142 vector [4]: res = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx DAUC DEBUG auc.c:143 vector [4]: res_len = 8 DAUC DEBUG auc.c:147 vector [4]: deriving 2G from 3G DAUC DEBUG auc.c:148 vector [4]: kc = xxxxxxxxxxxxxxxx DAUC DEBUG auc.c:149 vector [4]: sres = 434ef59d DAUC DEBUG auc.c:150 vector [4]: auth_types = 0x3 DAUC INFO db_auc.c:228 IMSI='MYIMSI': Generated 5 vectors DAUC DEBUG db_auc.c:233 IMSI='MYIMSI': Updating SQN=xxxxxx in DB ................... DMAIN DEBUG hlr.c:688 Unhandled GSUP message type OSMO_GSUP_MSGT_AUTH_FAIL_REPORT
Updated by laforge almost 4 years ago
On Thu, Jul 09, 2020 at 01:30:06PM +0000, MPoslusny [REDMINE] wrote:
The Triorail TRM-5 ext cellular module cannot connect to the osmocom network. A string of errors begins with "GSM AUTH failure: mismatching sres (expected sres=e6 33 aa d8 )".
The log from the MSC and the HLR parameters is attached. The SIM used is sysmoUSIM-SJS1 in the factory config.
The sysmoUSIM in factory default uses MILENAGE for 3G and COMP128V1 for GSM authentication.
The log file shows that you are using an A interface. However, the phone indicates R99 (and hence UMTS)
support, so UMTS AKA over GERAN will be used:
<000e> vlr_auth_fsm.c:286 VLR_Authenticate(IMSI-MYIMSI:GERAN-A-3:LU)[0x11706c0]{VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use UMTS AKA (is_r99=yes, at->vec.auth_types=0x3)
I think what may be happening here is that the phone does not properly handle either
- UMTS AKA over GERAN, or
- situations where the key material and/or algorithm for GSM and UMTS AKA are different
You could either
- change the SIM to a SIM without USIM (see sysmoUSIM manual) and remove 3G authentication data from HLR, OR
- configure both SIM and HLR to use MILENAGE for both 2G and 3G
If you have a SIMtrace around, it would be interesting to see if the
modem/phone is performing GSM or UMTS authentication towards the SIM
card during those attempts. But this is just curiosity.
Updated by MPoslusny almost 4 years ago
The strange thing is that it works with a regular SIM operator. It is a sim where I can also connect to UMTS or LTE on another MS / UE.
Do you have information on how common SIM T-mobile or Vodafone are configured?
Updated by MPoslusny almost 4 years ago
Do you see the possibility to enable support of these modules with sysmoUSIM without ADM code?
Updated by laforge almost 4 years ago
On Fri, Jul 10, 2020 at 11:47:33AM +0000, MPoslusny [REDMINE] wrote:
Do you have information on how common SIM T-mobile or Vodafone are configured?
I would presume they mostly use the same algorithm for SIM AKA and UMTS AKA.
The nature of the cryptographic authentication being an implementation detail that
is only known to the HLR + SIM card itself means that nobody knows what is actually
happening. It may not even be any of the published cryptographic algorithms. As long
as SIM and HLR agree what they do, no other part of the netowrk nor any third party
needs to know.
Updated by laforge almost 4 years ago
MPoslusny wrote:
Do you see the possibility to enable support of these modules with sysmoUSIM without ADM code?
Unfortunately not, sorry.
