aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAndreas Eversberg <jolly@eversberg.eu>2013-07-10 08:58:03 +0200
committerNeels Hofmeyr <neels@hofmeyr.de>2017-12-01 03:37:43 +0100
commit78a00a4b7797d46348ffcd5475e6184ecc2c07a8 (patch)
tree9e61c47ab52eeb96f3f6bc0a0fdbb09133e4a256
parent096142477dab637c6c5f1a777ad09fb58825d6ef (diff)
Fix: Handle CM service request on already secured channel correctly
A CM service request must be acknowledged also, when encryption is already enabled. Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL, which causes a CM service acknowledge. On initial CM service request, the security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This will not lead to an acknowledge, because the cyphering command implies an acknowlege. An additional CM service request requires an acknowledge, so I added a new security status: GSM_SECURITY_ALREADY
-rw-r--r--src/libmsc/gsm_04_08.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/src/libmsc/gsm_04_08.c b/src/libmsc/gsm_04_08.c
index 93cbae22b..1a104fec7 100644
--- a/src/libmsc/gsm_04_08.c
+++ b/src/libmsc/gsm_04_08.c
@@ -304,6 +304,11 @@ static int _gsm0408_authorize_sec_cb(unsigned int hooknum, unsigned int event,
release_loc_updating_req(conn);
break;
+ case GSM_SECURITY_ALREADY:
+ LOGP(DMM, LOGL_ERROR, "We don't expect LOCATION "
+ "UPDATING after CM SERVICE REQUEST\n");
+ /* fall through */
+
case GSM_SECURITY_NOAVAIL:
case GSM_SECURITY_SUCCEEDED:
/* We're all good */