Bug #4605
open
GMM_ATTACH_REQ_FSM: Event E_AUTH_RESP_RECV_SUCCESS not permitted
Added by laforge almost 4 years ago.
Updated almost 4 years ago.
Description
I'm seeing quite a bit of these and don't think that's right.
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x56242275e5e0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x56242275e5e0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x5624227600a0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x5624227600a0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x562422762bc0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x562422762bc0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
any idas?
- Related to Bug #4602: SGSN crash with "Assert failed mm->gb.llme == NULL gprs_sgsn.c:358" added
According to the spec, an ID Request/Response is allowed at any time. But it's started by the SGSN.
I think those messages comes from RAU which calls gmm_authorize().
gmm_authorize() might do an ID Request/Response when the ID is unknown.
I think the best way is to remove the gmm_authorized() and implementing RAU as fsm and authentication as fsm.
- Assignee changed from lynxis to laforge
These messages should be normal, because we don't check everywhere if the GMM attach fsm is still running or not when receiving ID responses. gmm_authorize() are also sending ID Request/Responses.
- Status changed from Feedback to New
- Assignee changed from laforge to lynxis
- Priority changed from Normal to High
lynxis wrote:
These messages should be normal, because we don't check everywhere if the GMM attach fsm is still running or not when receiving ID responses. gmm_authorize() are also sending ID Request/Responses.
I think the log output is confusing. In general, we don't expect to run into such situations and in other code using osmo_fsm such messages typically indicate something is quite wrong. This is why libosmocore/src/fsm.c logs them as LOGL_ERROR.
The application code should be modified to suppress sending events to the fsm. So given you state this behavior is expected, it could e.g. be hidden in an inline function that first checks for the state and only dispatches if the state is as expected.
Also available in: Atom
PDF
