Differentiate between "IMSI unknown" and "IMSI has no auth data": in case of
known IMSI lacking auth data, return -ENOKEY instead of -ENOENT.
Fix API doc comments to reflect what the functions actually return, on top of
adding the -ENOKEY detail.
Adjust db_test expectations from -ENOENT to -ENOKEY where appropriate.
Adjust VTY and CTRL command rc evaluation.
A subsequent patch will use these return values to log details on each of these
situations.
Change-Id: Icf6304d23585f2ed45e050fa27c787f2d66fd3f7
To make the db_bind_text() error reporting mention "imsi", change the
DB_STMT_AUC_BY_IMSI to use a named parameter.
Change-Id: I49bd5eb78170cf4cdf8abb386c766d20d9f1cf73
Use the common db_bind_int64() so that the stmt bindings are cleared for any
errors and to get error logging for free.
On error with sqlite3_step(), log the SQL error message, and make sure the stmt
is cleared of bindings and reset.
After sqlite3_step(), verify that exactly one row was modifed, log and return
errors otherwise.
After this patch, the DB interaction closely matches the other (refactored) DB
functions.
Change-Id: I0d870d405e2e0a830360d9ad19f0a3f9e09d8cf2
Adopt the error handling of the other db functions: return -ENOENT on unknown
subscriber and -EIO on SQL failure. Return 0 for no error, instead of the
number of rows modified.
Adjust the single caller: db_get_auc()
(and db_test.c).
Change-Id: I006f471962bdad95d00a3a4c41a28ebbc9740884
The SQLite db does not support uint64_t, and we are always binding the uint64_t
id actually as signed int64_t. Hence be consistent and actually handle it as
int64_t in the code as well.
This means that if we ever see a negative subscriber ID in the SQL database
(however unlikely), we will also see it negative in our log output.
The SQN handled in osmo_auth* is actually of unsigned type, and, unless we
store the SQN as 64bit hex string, we are forced to feed this unsigned value as
signed int64_t to the SQLite API. The upcoming db regression test for SQN in
change-id I0d870d405e2e0a830360d9ad19f0a3f9e09d8cf2 verifies that the SQN
uint64_t translates to signed int64_t and back as expected.
Change-Id: I83a47289a48ac37da0f712845d422e897a5e8171
In LOGHLR and LOGAUC, log IMSI='<imsi>' instead of just <imsi>:
In the log, it is not always obvious to the reader that the printed number
refers to an IMSI (vs. an MSISDN or in the future an IMEI).
In db_get_auth_data(), log "No such subscriber" instead of just "Unknown", to
clarify what exactly is meant.
Change-Id: I2ec8ab5e67d4e95083f6e39232fc91ebaa080cb8
There are upcoming additions, and some seem too general without a proper common
prefix in the identifiers, like 'CREATE'.
Change-Id: I51b677db31a1ebbbc45dc7925074de7493fbde1f
Add ind_bitlen column to auc_3g to record each USIM's IND size according to
3GPP TS 33.102 -- default is 5 bits, as suggested by the spec.
Introduce auc_3g_ind to each connecting GSUP client to use as IND index for
generating auth tuples sent to this client.
With osmo_gsup_server_add_conn(), implement a scheme where clients receive
fixed auc_3g_ind indexes based on the order in which they connect; each new
connection takes the lowest unused auc_3g_ind, so in case one of the clients
restarts, it will most likely receive the same auc_3g_ind, and if one client
disconnects, no other clients' auc_3g_ind are affected.
Add gsup_server_test.c to test the auc_3g_ind index distribution scheme.
Depends: libosmocore I4eac5be0c0b2cede04464c4c3a0873102d952453 for llist_first
Related: OS#1969
Change-Id: If4501ed4ff8e923fa6fe8b80c44c5ad647a8ed60
We can no longer accurately print the SQN from AUTS resync, since the SQN is
incremented after AUTS. Instead, always print the SQN from the generated tuple,
i.e. exactly the one left in auth data *after* the tuple was generated.
This change was forgotten in recent adjustments to the new SQN incrementing
scheme from libosmocore, in change-id I4ec5a578537acb1d9e1ebfe00a72417fc3ca5894
for libosmocore change-id Iadf43f21e0605e9e85f7e8026c40985f7ceff1a3.
It should have been obvious that something was missing in the previous patch
from the auc_test output: the SQN in the output changed while the AUTN remained
the same. That slipped by without being noticed :/
Change-Id: I0e1e828da931a3d22c75306c55bdb7f44df6512f
The database stores the key material as hex-ascii, we thus need to go
through osmo_hexparse() when reading. We could also store the material
as BLOB in the database. That would however complicate matters, as it
would basically mean using the sqlite3 command to manually
inspect/modify data from the console would no longer be easily possible.
Using this commit I have 2G authentication working against osmo-sgsn
with GSUP and 'auth policy remote'.
When responding to a SendAuthInfo.req, we need to differentiate
an error case caused by an unknown IMSI, or an error caused by
an error regarding accessing the database or data integrity.
Neels Hofmeyr
Neels Hofmeyr
Harald Welte