diff options
| author | Neels Hofmeyr <nhofmeyr@sysmocom.de> | 2017-03-04 21:09:12 +0100 |
|---|---|---|
| committer | Neels Hofmeyr <nhofmeyr@sysmocom.de> | 2017-03-16 15:32:29 +0100 |
| commit | 6da3bc7c0afd0352fb46b271b9e6a01aaa3c5cfe (patch) | |
| tree | bcc02d39b7d384fb6a8d6cb27a56f33f41f4d3c8 | |
| parent | 9267123b882d1e35a4cb6a3bf746d33c4e84c8ce (diff) | |
fix: vlr: clear last_tuple when receiving auth tuples
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
| -rw-r--r-- | openbsc/src/libvlr/vlr.c | 3 | ||||
| -rw-r--r-- | openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.c | 12 | ||||
| -rw-r--r-- | openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.err | 12 |
3 files changed, 21 insertions, 6 deletions
diff --git a/openbsc/src/libvlr/vlr.c b/openbsc/src/libvlr/vlr.c index db874f298..a8404b246 100644 --- a/openbsc/src/libvlr/vlr.c +++ b/openbsc/src/libvlr/vlr.c @@ -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 */ diff --git a/openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.c b/openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.c index 9b4d0188d..219be3ab7 100644 --- a/openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.c +++ b/openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.c @@ -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"); diff --git a/openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.err b/openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.err index 28b2394eb..eb1cf4a31 100644 --- a/openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.err +++ b/openbsc/tests/msc_vlr/msc_vlr_test_umts_authen.err @@ -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... |