aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMax <msuraev@sysmocom.de>2019-02-13 14:48:59 +0100
committerMax <msuraev@sysmocom.de>2019-02-14 11:07:48 +0000
commitb6f8b74b07cef1f04bf45e6dc5592c4b24cca4c0 (patch)
tree60a264e462d6ee2bc8ed073828a848e38910b2f1
parent34604c26b4178f7a75388ca1de84eb1dc033feb1 (diff)
GMM: permit VLR_ANSWERED event in attach FSM
This fixes following error: DMM gprs_gmm.c:1126 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x5589e78dded0]{WaitAttachComplete}: Event VLR answered not permitted There seems to be a race condition in FSM when MS establishes MM context which isn't immediately followed up by PDP context (for example when no APN is configured in MS). This does not affect actual functionality because in this case MS won't be able to use GPRS anyway but it's still nice to get our FSM fixed even in this corner case. Change-Id: I14d234632224e20faf865d2273c83cfff31abf61
-rw-r--r--src/gprs/gprs_gmm_attach.c8
1 files changed, 7 insertions, 1 deletions
diff --git a/src/gprs/gprs_gmm_attach.c b/src/gprs/gprs_gmm_attach.c
index 6fdb3af..1ab11f7 100644
--- a/src/gprs/gprs_gmm_attach.c
+++ b/src/gprs/gprs_gmm_attach.c
@@ -195,6 +195,12 @@ static void st_accept(struct osmo_fsm_inst *fi, uint32_t event, void *data)
extract_subscr_hlr(ctx);
osmo_fsm_inst_state_chg(fi, ST_INIT, 0, 0);
break;
+ case E_VLR_ANSWERED:
+ extract_subscr_msisdn(ctx);
+ extract_subscr_hlr(ctx);
+ LOGMMCTXP(LOGL_NOTICE, ctx,
+ "Unusual event: if MS got no data connection, check that it has APN configured.\n");
+ break;
}
}
@@ -295,7 +301,7 @@ static struct osmo_fsm_state gmm_attach_req_fsm_states[] = {
.action = st_iu_security_cmd,
},
[ST_ACCEPT] = {
- .in_event_mask = X(E_ATTACH_COMPLETE_RECV),
+ .in_event_mask = X(E_ATTACH_COMPLETE_RECV) | X(E_VLR_ANSWERED),
.out_state_mask = X(ST_INIT) | X(ST_REJECT),
.name = "WaitAttachComplete",
.onenter = st_accept_on_enter,