diff options
| author | Max <msuraev@sysmocom.de> | 2019-02-13 14:48:59 +0100 |
|---|---|---|
| committer | Max <msuraev@sysmocom.de> | 2019-02-14 11:07:48 +0000 |
| commit | b6f8b74b07cef1f04bf45e6dc5592c4b24cca4c0 (patch) | |
| tree | 60a264e462d6ee2bc8ed073828a848e38910b2f1 | |
| parent | 34604c26b4178f7a75388ca1de84eb1dc033feb1 (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.c | 8 |
1 files changed, 7 insertions, 1 deletions
diff --git a/src/gprs/gprs_gmm_attach.c b/src/gprs/gprs_gmm_attach.c index 6fdb3af40..1ab11f76e 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, |