Project

General

Profile

Bug #4605

GMM_ATTACH_REQ_FSM: Event E_AUTH_RESP_RECV_SUCCESS not permitted

Added by laforge 26 days ago. Updated 21 days ago.

Status:
New
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
06/08/2020
Due date:
% Done:

0%

Spec Reference:

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 issues

Related to OsmoSGSN - Bug #4602: SGSN crash with "Assert failed mm->gb.llme == NULL gprs_sgsn.c:358"Feedback06/08/2020

History

#1 Updated by laforge 26 days ago

  • Related to Bug #4602: SGSN crash with "Assert failed mm->gb.llme == NULL gprs_sgsn.c:358" added

#2 Updated by lynxis 23 days ago

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.

#3 Updated by lynxis 23 days ago

  • Assignee changed from lynxis to laforge

#4 Updated by lynxis 23 days ago

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.

#5 Updated by laforge 21 days ago

  • 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

Add picture from clipboard (Maximum size: 48.8 MB)