Project

General

Profile

Feature #3103

use a_reset.c in osmo-msc

Added by neels over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/23/2018
Due date:
% Done:

100%

Resolution:

Description

The a_reset.c FSM is actually not used at all: a_reset_conn_fail() is never invoked.
The proper trigger to invoke a_reset_conn_fail(): it was mentioned that specific N-Disconnect causes indicate a failure versus a normal disconnect.
a_reset_conn_fail() should be invoked upon receiving such failure cause.


Related issues

Related to OsmoBSC - Feature #3102: clean up and use a_reset.c in osmo-bscResolved03/23/2018

Related to OsmoMSC - Bug #3286: TC_cr_before_reset fails since build #148 (May 16)Resolved05/23/2018

History

#1 Updated by neels over 1 year ago

  • Related to Feature #3102: clean up and use a_reset.c in osmo-bsc added

#2 Updated by dexter over 1 year ago

  • Status changed from New to Rejected

This is basically the same as #3102, so lets reject it.

#3 Updated by neels over 1 year ago

  • Status changed from Rejected to New

Sorry, it's not the same: the one is the a_reset FSM in OsmoBSC, while this here is in OsmoMSC.
True, both MSC and BSC currently kind of don't touch their a_reset implementations in a similar way,
but tracking each side should be separate, depending on what each side should be doing.

#4 Updated by dexter over 1 year ago

neels: Both parts were intended to be generalized and put in a library somehow. Maybe we should fix that. Possibly libosmo-sigtran is a good place?

#5 Updated by dexter over 1 year ago

Note: Neels and me agree that it might make sense to send a reset immediately when there is some connection attempt from a BSC. Just blocking every connection attempts from not yet known BSCs until the BSC sends a reset is fine, however, responding with a reset to a connection attempt from an unknown BSC is better and it speeds up the process of re-negotiation.

#6 Updated by dexter over 1 year ago

  • Status changed from New to Resolved

I have checked the a_iface.c. When we receive a connection request in sccp_sap_up() we lookup the BSC context information. If we can not find a a context, we allocate a new one and we also send an BSSMAP RESET back immediately. This means this part works also as expected.

So if the MSC restarts and if we loose all context we will re-learn the context on the next connection attempt and send a reset immediately. I think we have no problem here.

#7 Updated by neels over 1 year ago

  • Status changed from Resolved to Feedback

Please clarify:

  • is a_reset.c currently used in osmo-msc?
  • do we use the part of it designed to detect stale connections?
  • Any actions required to get rid of dead code?

#8 Updated by dexter over 1 year ago

  • is a_reset.c currently used in osmo-msc?
    Yes
  • do we use the part of it designed to detect stale connections?
    No
  • Any actions required to get rid of dead code?
    We have two options: We can remove the unused parts of the code locally or we
    move the whole FSM over to a library (but which one?). I think the first option
    would be the simplest and it would not hurt to much. I could do that now if you
    agree.

#9 Updated by dexter over 1 year ago

  • Assignee changed from dexter to neels

#10 Updated by neels over 1 year ago

  • Assignee changed from neels to dexter

dexter wrote:

  • is a_reset.c currently used in osmo-msc?
    Yes

ok. Which part? (I think you showed me before, but I forgot. We can discuss it personally next week. not urgent.)

  • Any actions required to get rid of dead code?
    We can remove the unused parts of the code locally

yes, I don't think it's worth the trouble to move it around.

#11 Updated by dexter over 1 year ago

  • Assignee changed from dexter to neels

I have now stripped all unnecessary code, please see:

https://gerrit.osmocom.org/8054 a_reset: cleanup + remove dead code

#12 Updated by neels over 1 year ago

  • Assignee changed from neels to dexter

Ok, nice. Took the opportunity to read the rest of it again and added some general comments about the rest of the code at that same gerrit patch (even though it's not strictly related to that patch)

#13 Updated by laforge over 1 year ago

  • Related to Bug #3286: TC_cr_before_reset fails since build #148 (May 16) added

#14 Updated by dexter over 1 year ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

The patch (https://gerrit.osmocom.org/8054) is now merged and the cleanups to a_reset.c are now done.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)