paulmataruso/osmo-mgw
1
0
Fork 0
mirror of https://gitea.osmocom.org/cellular-infrastructure/osmo-mgw.git synced 2025-10-23 08:12:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix: vlr: clear last_tuple when receiving auth tuples

Browse Source 
When receiving more than one auth tuple during AUTS resync, the VLR would go on
to send the second tuple instead of the first. The unit test didn't catch that
because its fake HLR message contained only one tuple.

Adjust the test to send two tuples to catch this error.

Fix the code to clear vlr_subscr->last_tuple whenever new auth tuples are
received.

Change-Id: I1f84e7d2619aa8d9a0dcdfb50745feeb040264b9
This commit is contained in:
Neels Hofmeyr
2017-03-04 21:09:12 +01:00
parent 9267123b88
commit 6da3bc7c0a
3 changed files with 21 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
openbsc/src/libvlr/vlr.c
View File

@@ -568,6 +568,9 @@ void vlr_subscr_update_tuples(struct vlr_subscr *vsub,
/* FIXME what now? */
// vlr_subscr_cancel(vsub, GMM_CAUSE_GSM_AUTH_UNACCEPT); ?
}
/* New tuples means last_tuple becomes invalid */
vsub->last_tuple = NULL;
}
/* Handle SendAuthInfo Result/Error from HLR */

12
openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.c
View File

@@ -398,6 +398,18 @@ void _test_umts_authen_resync(enum ran_type via_ran)
"2510" "02a83f62e9470000660d51afc75f169d"
/* TL RES */
"2708" "1df5f0b4f22b696e"
/* TL TL rand */
"0362" "2010" "ac21d34937b4e1142a2c757af2949319"
/* TL sres TL kc */
"2104" "7818bfdc" "2208" "d175571f41f314a4"
/* TL 3G IK */
"2310" "ff8edbceb6dd24799c77c3b9a6790c10"
/* TL 3G CK */
"2410" "157c39022ca9d885a7f0766a7dfee448"
/* TL AUTN */
"2510" "8a43b91898e500002cf354c6f5d1f8c3"
/* TL RES */
"2708" "f748a7078f5018db"
,NULL);
VERBOSE_ASSERT(auth_request_sent, == true, "%d");

12
openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.err
View File

@@ -834,11 +834,11 @@ DVLR VLR_Authenticate(901700000010650){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_S
auth_request_sent == 0
lu_result_sent == 0
- HLR replies with new tuples
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000000156f0036220100f1feb1623e1bf626334e37ec448ac182104efde99da220814778c855c52373023108a90c769b7272f3bb7a1c1fbb1ea9349241043ffc1cf8c89a7fd6ab94bd8d6162cbf251002a83f62e9470000660d51afc75f169d27081df5f0b4f22b696e
DVLR GSUP rx 111: 0a010809710000000156f0036220100f1feb1623e1bf626334e37ec448ac182104efde99da220814778c855c52373023108a90c769b7272f3bb7a1c1fbb1ea9349241043ffc1cf8c89a7fd6ab94bd8d6162cbf251002a83f62e9470000660d51afc75f169d27081df5f0b4f22b696e
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000000156f0036220100f1feb1623e1bf626334e37ec448ac182104efde99da220814778c855c52373023108a90c769b7272f3bb7a1c1fbb1ea9349241043ffc1cf8c89a7fd6ab94bd8d6162cbf251002a83f62e9470000660d51afc75f169d27081df5f0b4f22b696e03622010ac21d34937b4e1142a2c757af294931921047818bfdc2208d175571f41f314a42310ff8edbceb6dd24799c77c3b9a6790c102410157c39022ca9d885a7f0766a7dfee44825108a43b91898e500002cf354c6f5d1f8c32708f748a7078f5018db
DVLR GSUP rx 211: 0a010809710000000156f0036220100f1feb1623e1bf626334e37ec448ac182104efde99da220814778c855c52373023108a90c769b7272f3bb7a1c1fbb1ea9349241043ffc1cf8c89a7fd6ab94bd8d6162cbf251002a83f62e9470000660d51afc75f169d27081df5f0b4f22b696e03622010ac21d34937b4e1142a2c757af294931921047818bfdc2208d175571f41f314a42310ff8edbceb6dd24799c77c3b9a6790c102410157c39022ca9d885a7f0766a7dfee44825108a43b91898e500002cf354c6f5d1f8c32708f748a7078f5018db
DREF VLR subscr IMSI:901700000010650 usage increases to: 2
DVLR VLR_Authenticate(901700000010650){VLR_SUB_AS_NEEDS_AUTH_WAIT_SAI_RESYNC}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI:901700000010650) Received 1 auth tuples
DVLR SUBSCR(IMSI:901700000010650) Received 2 auth tuples
DVLR VLR_Authenticate(901700000010650){VLR_SUB_AS_NEEDS_AUTH_WAIT_SAI_RESYNC}: state_chg to VLR_SUB_AS_WAIT_RESP_RESYNC
DVLR VLR_Authenticate(901700000010650){VLR_SUB_AS_WAIT_RESP_RESYNC}: got auth tuple: use_count=1 key_seq=0
- sending UMTS Auth Request for IMSI:901700000010650: tuple use_count=1 key_seq=0 auth_types=0x3 and...
@@ -1004,11 +1004,11 @@ DVLR VLR_Authenticate(901700000010650){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_S
auth_request_sent == 0
lu_result_sent == 0
- HLR replies with new tuples
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000000156f0036220100f1feb1623e1bf626334e37ec448ac182104efde99da220814778c855c52373023108a90c769b7272f3bb7a1c1fbb1ea9349241043ffc1cf8c89a7fd6ab94bd8d6162cbf251002a83f62e9470000660d51afc75f169d27081df5f0b4f22b696e
DVLR GSUP rx 111: 0a010809710000000156f0036220100f1feb1623e1bf626334e37ec448ac182104efde99da220814778c855c52373023108a90c769b7272f3bb7a1c1fbb1ea9349241043ffc1cf8c89a7fd6ab94bd8d6162cbf251002a83f62e9470000660d51afc75f169d27081df5f0b4f22b696e
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000000156f0036220100f1feb1623e1bf626334e37ec448ac182104efde99da220814778c855c52373023108a90c769b7272f3bb7a1c1fbb1ea9349241043ffc1cf8c89a7fd6ab94bd8d6162cbf251002a83f62e9470000660d51afc75f169d27081df5f0b4f22b696e03622010ac21d34937b4e1142a2c757af294931921047818bfdc2208d175571f41f314a42310ff8edbceb6dd24799c77c3b9a6790c102410157c39022ca9d885a7f0766a7dfee44825108a43b91898e500002cf354c6f5d1f8c32708f748a7078f5018db
DVLR GSUP rx 211: 0a010809710000000156f0036220100f1feb1623e1bf626334e37ec448ac182104efde99da220814778c855c52373023108a90c769b7272f3bb7a1c1fbb1ea9349241043ffc1cf8c89a7fd6ab94bd8d6162cbf251002a83f62e9470000660d51afc75f169d27081df5f0b4f22b696e03622010ac21d34937b4e1142a2c757af294931921047818bfdc2208d175571f41f314a42310ff8edbceb6dd24799c77c3b9a6790c102410157c39022ca9d885a7f0766a7dfee44825108a43b91898e500002cf354c6f5d1f8c32708f748a7078f5018db
DREF VLR subscr IMSI:901700000010650 usage increases to: 2
DVLR VLR_Authenticate(901700000010650){VLR_SUB_AS_NEEDS_AUTH_WAIT_SAI_RESYNC}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI:901700000010650) Received 1 auth tuples
DVLR SUBSCR(IMSI:901700000010650) Received 2 auth tuples
DVLR VLR_Authenticate(901700000010650){VLR_SUB_AS_NEEDS_AUTH_WAIT_SAI_RESYNC}: state_chg to VLR_SUB_AS_WAIT_RESP_RESYNC
DVLR VLR_Authenticate(901700000010650){VLR_SUB_AS_WAIT_RESP_RESYNC}: got auth tuple: use_count=1 key_seq=0
- sending UMTS Auth Request for IMSI:901700000010650: tuple use_count=1 key_seq=0 auth_types=0x3 and...