https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-02-07T09:00:49ZOpen Source Mobile CommunicationsOsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=75422018-02-07T09:00:49Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>daniel</i></li></ul> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=78402018-02-26T00:24:43Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>ah, is <strong>that</strong> why my lab phones never update the network names anymore!</p> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=79392018-03-01T16:36:56Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>daniel</i> to <i>stsp</i></li></ul> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=81842018-03-12T18:51:16Zstsp
<ul></ul><p>The caller of gsm48_tx_mm_info() was removed in this commit:</p>
<p>commit 2483f1b050496eda7f8707327204251c57212906 "Use libvlr in libmsc (large refactoring)"</p>
<p>Following the call chain we can see that it got chopped off at mm_rx_id_resp() where the<br />call to gsm0408_authorize(), which would eventually call finish_lu() -> gsm48_tx_mm_info(),<br />was removed.</p>
<p>Where should this message be sent from in the post-refactoring world?<br />The new code ends up in vlr_subscr_rx_id_resp() which triggers the location update FSM ('lu_fsm').<br />Should this FSM be taking care of sending out MM info now?</p> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=81852018-03-12T18:51:36Zstsp
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=81862018-03-12T19:13:32Zlaforge
<ul></ul><p>On Mon, Mar 12, 2018 at 06:51:16PM +0000, stsp [REDMINE] wrote:</p>
<blockquote>
<p>The caller of gsm48_tx_mm_info() was removed in this commit:</p>
<p>commit 2483f1b050496eda7f8707327204251c57212906 "Use libvlr in libmsc (large refactoring)"</p>
</blockquote>
<p>thanks for tracking this down.</p>
<blockquote>
<p>Where should this message be sent from in the post-refactoring world?</p>
</blockquote>
<p>I think Neels knows the MSC/VLR state machines best.</p>
<blockquote>
<p>The new code ends up in vlr_subscr_rx_id_resp() which triggers the location update FSM ('lu_fsm').<br />Should this FSM be taking care of sending out MM info now?</p>
</blockquote>
<p>I think the high-level goal is to send the MM INFO (if enabled) at every Location Update of type<br />"IMSI ATTACH". This is the "first registration" of a given IMSI, and at that point communicating<br />the network identity makes sense.</p>
<p>Sending it at every subsequent "normal" or "periodic" LU is possible, but actually just a waste<br />of resources, as the phone will still know the information sent during the initial attach.</p>
<p>So if it's easy to send only after LU IMSI ATTACH, great. If not, send it all the time. If<br />you have nothing better to do: make it configurable :P</p> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=81962018-03-13T14:41:19Zstsp
<ul></ul><p>I found a section in the spec which recommends sending MM info after sending an AUTHENTICATION REQUEST.<br />A patch which implements this approach is at <a class="external" href="https://gerrit.osmocom.org/#/c/7268/">https://gerrit.osmocom.org/#/c/7268/</a></p>
<p>Would this be acceptable?<br />Or should we instead be sending this message after a location update has successfully completed?</p> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=81972018-03-13T15:20:12Zlaforge
<ul></ul><p>On Tue, Mar 13, 2018 at 02:41:19PM +0000, stsp [REDMINE] wrote:</p>
<blockquote>
<p>I found a section in the spec which recommends sending MM info after sending an AUTHENTICATION REQUEST.</p>
</blockquote>
<p>interesting. Where was that? And what if there is no authentication enabled at all?</p>
<blockquote>
<p>Would this be acceptable?</p>
</blockquote>
<p>theoretically yes, but we have to consider the use case of 'open networks' which are used<br />in practical deployments.</p>
<blockquote>
<p>Or should we instead be sending this message after a location update has successfully completed?</p>
</blockquote>
<p>As I wrote before, I think the best time is after an imsi-attach type LU.</p> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=82092018-03-13T19:21:24Zstsp
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>On Tue, Mar 13, 2018 at 02:41:19PM +0000, stsp [REDMINE] wrote:</p>
<blockquote>
<p>I found a section in the spec which recommends sending MM info after sending an AUTHENTICATION REQUEST.</p>
</blockquote>
<p>interesting. Where was that? And what if there is no authentication enabled at all?</p>
</blockquote>
<p>It is on page 123 in <a class="external" href="http://www.etsi.org/deliver/etsi_TS/100900_100999/100940/07.08.00_60/ts_100940v070800p.pdf">http://www.etsi.org/deliver/etsi_TS/100900_100999/100940/07.08.00_60/ts_100940v070800p.pdf</a></p>
<blockquote><blockquote>
<p>Would this be acceptable?</p>
</blockquote>
<p>theoretically yes, but we have to consider the use case of 'open networks' which are used<br />in practical deployments.</p>
<blockquote>
<p>Or should we instead be sending this message after a location update has successfully completed?</p>
</blockquote>
<p>As I wrote before, I think the best time is after an imsi-attach type LU.</p>
</blockquote>
<p>..<br />OK. I think I've already seen a place in the code where we could put this, just need to find it again.</p> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=82122018-03-13T20:17:11Zstsp
<ul></ul><p>OK, I think I have found a way. See <a class="external" href="https://gerrit.osmocom.org/#/c/7276/">https://gerrit.osmocom.org/#/c/7276/</a></p>
<p>Tested with the mobile program in a virtual-um setup.<br />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).</p> OsmoMSC - Bug #2850: OsmoMSC fails to send MM INFO despite vty configured to do sohttps://osmocom.org/issues/2850?journal_id=82182018-03-14T11:11:14Zstsp
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul><p>Above change has been merged.</p>