mirror of https://gerrit.osmocom.org/libosmocore
Neels Hofmeyr
bb6f7b7bec
So far we incremented SQN by 1, which doesn't match the procedures described in 3GPP TS 33.102. An IND (index) denotes a non-significant part of SQN, and the significant SEQ part needs to be incremented. In OsmoHLR we furthermore want to use the "exception" suggested in annex C.3.4, so that each HLR's client has a fixed IND index. In other words, we will not assign IND cyclically, but keep IND unchanged per auth vector consumer. Add 'ind_bitlen' and 'ind' to the osmo_sub_auth_data.u.umts structure and increment SQN accordingly. Add a comment explaining the details. Because 'ind_bitlen' is still passed as zero, the milenage_test does not change its behavior, which is a feature I want to clearly show in this patch. The test will be expanded for the newly implemented SQN scheme in a subsequent patch. Adjust osmo-auc-gen.c to still show the right SQN and SQN.MS -- because it is passing ind_bitlen == 0, osmo-auc-gen can rely on single increments and know SQN.MS is sqn - 1. Note that osmo-auc-gen_test output remains unchanged. Related: OS#1968 Change-Id: Ibc97e1736a797ffcbf8c1f7d41c5c4518f4e41bf |
||
---|---|---|
.. | ||
auth.h | ||
gprs_cipher.h |