Feature #3103
closeduse a_reset.c in osmo-msc
100%
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
Updated by neels about 6 years ago
- Related to Feature #3102: clean up and use a_reset.c in osmo-bsc added
Updated by dexter almost 6 years ago
- Status changed from New to Rejected
This is basically the same as #3102, so lets reject it.
Updated by neels almost 6 years 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.
Updated by dexter almost 6 years 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?
Updated by dexter almost 6 years 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.
Updated by dexter almost 6 years 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.
Updated by neels almost 6 years 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?
Updated by dexter almost 6 years 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.
Updated by neels almost 6 years 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.
Updated by dexter almost 6 years 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
Updated by neels almost 6 years 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)
Updated by laforge almost 6 years ago
- Related to Bug #3286: TC_cr_before_reset fails since build #148 (May 16) added
Updated by dexter almost 6 years 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.