Bug #2850
closedOsmoMSC fails to send MM INFO despite vty configured to do so
Added by laforge over 6 years ago. Updated about 6 years ago.
0%
Description
I just noted that OsmoMSC is never sending MM INFO, even if the VTY is configured to.
There seems no single user of the gsm48_tx_mm_info() function !
Updated by neels about 6 years ago
ah, is that why my lab phones never update the network names anymore!
Updated by stsp about 6 years ago
The caller of gsm48_tx_mm_info() was removed in this commit:
commit 2483f1b050496eda7f8707327204251c57212906 "Use libvlr in libmsc (large refactoring)"
Following the call chain we can see that it got chopped off at mm_rx_id_resp() where the
call to gsm0408_authorize(), which would eventually call finish_lu() -> gsm48_tx_mm_info(),
was removed.
Where should this message be sent from in the post-refactoring world?
The new code ends up in vlr_subscr_rx_id_resp() which triggers the location update FSM ('lu_fsm').
Should this FSM be taking care of sending out MM info now?
Updated by laforge about 6 years ago
On Mon, Mar 12, 2018 at 06:51:16PM +0000, stsp [REDMINE] wrote:
The caller of gsm48_tx_mm_info() was removed in this commit:
commit 2483f1b050496eda7f8707327204251c57212906 "Use libvlr in libmsc (large refactoring)"
thanks for tracking this down.
Where should this message be sent from in the post-refactoring world?
I think Neels knows the MSC/VLR state machines best.
The new code ends up in vlr_subscr_rx_id_resp() which triggers the location update FSM ('lu_fsm').
Should this FSM be taking care of sending out MM info now?
I think the high-level goal is to send the MM INFO (if enabled) at every Location Update of type
"IMSI ATTACH". This is the "first registration" of a given IMSI, and at that point communicating
the network identity makes sense.
Sending it at every subsequent "normal" or "periodic" LU is possible, but actually just a waste
of resources, as the phone will still know the information sent during the initial attach.
So if it's easy to send only after LU IMSI ATTACH, great. If not, send it all the time. If
you have nothing better to do: make it configurable :P
Updated by stsp about 6 years ago
I found a section in the spec which recommends sending MM info after sending an AUTHENTICATION REQUEST.
A patch which implements this approach is at https://gerrit.osmocom.org/#/c/7268/
Would this be acceptable?
Or should we instead be sending this message after a location update has successfully completed?
Updated by laforge about 6 years ago
On Tue, Mar 13, 2018 at 02:41:19PM +0000, stsp [REDMINE] wrote:
I found a section in the spec which recommends sending MM info after sending an AUTHENTICATION REQUEST.
interesting. Where was that? And what if there is no authentication enabled at all?
Would this be acceptable?
theoretically yes, but we have to consider the use case of 'open networks' which are used
in practical deployments.
Or should we instead be sending this message after a location update has successfully completed?
As I wrote before, I think the best time is after an imsi-attach type LU.
Updated by stsp about 6 years ago
laforge wrote:
On Tue, Mar 13, 2018 at 02:41:19PM +0000, stsp [REDMINE] wrote:
I found a section in the spec which recommends sending MM info after sending an AUTHENTICATION REQUEST.
interesting. Where was that? And what if there is no authentication enabled at all?
It is on page 123 in http://www.etsi.org/deliver/etsi_TS/100900_100999/100940/07.08.00_60/ts_100940v070800p.pdf
Would this be acceptable?
theoretically yes, but we have to consider the use case of 'open networks' which are used
in practical deployments.Or should we instead be sending this message after a location update has successfully completed?
As I wrote before, I think the best time is after an imsi-attach type LU.
..
OK. I think I've already seen a place in the code where we could put this, just need to find it again.
Updated by stsp about 6 years ago
OK, I think I have found a way. See https://gerrit.osmocom.org/#/c/7276/
Tested with the mobile program in a virtual-um setup.
The MM info shows up in wireshark when the mobile program sends an IMSI attach location update (I couldn't figure out how to achieve this via configuration files, so I just hacked the mobile code to always send such an LU).
Updated by stsp about 6 years ago
- Status changed from In Progress to Resolved
Above change has been merged.
