Project

General

Profile

Bug #2785

OsmoHLR forgets to send InsertSubscriberData to VLR/SGSN when data changes

Added by laforge 10 months ago. Updated 4 days ago.

Status:
In Progress
Priority:
High
Assignee:
Target version:
-
Start date:
12/28/2017
Due date:
% Done:

90%


Description

OsmoHLR allows for subscriber data to be changed, but forgets to inform the VLR+SGSN about related changes (such as MSISDN, service subscription).

A quick fix is unfortunately not very simple as the ISD procedure is currently intertwined with the LocationUpdate procedure in the code :/


Related issues

Related to OsmoHLR - Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN onlyResolved2018-04-10

Related to OsmoMSC - Bug #3601: OsmoMSC's GSUP client doesn't send CN domain to the HLRResolved2018-09-28

History

#1 Updated by laforge 9 months ago

  • Assignee set to neels
  • Priority changed from Normal to High

#2 Updated by laforge 8 months ago

  • Assignee changed from neels to stsp

#3 Updated by laforge 8 months ago

There's now a test case: HLR_Tests.TC_vty_msisdn_isd

https://gerrit.osmocom.org/7039

#4 Updated by stsp 7 months ago

Looking at the HLR TC_vty_msisdn_isd test, it looks like this test:
  1. Sends a location update sending the subscriber's initial msisdn.
  2. Changes the subscriber's msisdn in the HLR's database via VTY.
  3. Now waits and expects a communication of this new msisdn, initiated by the HLR.
I am unsure how the HLR could initiate this communication in its current implementation.
The HLR runs as a gsup server loop which only responds to incoming requests from clients.
The way I understand it, to fix the problem we would need to either:
  1. Make the test send another location update or initiate some other GSUP communication with the HLR, and then expect to receive updated subscriber information.
  2. Make it possible for the HLR to initiate a new (client) connection to the VLR (server) and then send the insert subscriber data message.

Am I missing something?

#5 Updated by stsp 7 months ago

  • Status changed from New to In Progress

#6 Updated by neels 7 months ago

for the record, as discussed today: the GSUP connection between {MSC,SGSN} and HLR persists, you can send messages anytime. If an {MSC,SGSN} isn't connected then per definition it is not ready to receive subscriber updates (probably down or broken).

#7 Updated by stsp 6 months ago

This patch fixes the external behaviour: https://gerrit.osmocom.org/7685
It may not be the perfect solution in terms of code maintainability but
already gets us one step further.

#8 Updated by stsp 6 months ago

Now waiting for a review of https://gerrit.osmocom.org/#/c/7743/

#9 Updated by neels 6 months ago

  • Related to Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN only added

#10 Updated by stsp 5 months ago

Now waiting for review of this change: https://gerrit.osmocom.org/#/c/7992/

#11 Updated by stsp 5 months ago

  • Status changed from In Progress to Resolved

Above change has been merged. Closing this issue.

#12 Updated by laforge 4 months ago

  • Status changed from Resolved to New

I'll be reverting to the old behavior in https://gerrit.osmocom.org/#/c/osmo-hlr/+/9647, so this bug must be reopened. The new behavior was just as broken as the previuos...

#13 Updated by neels 18 days ago

  • Related to Bug #3601: OsmoMSC's GSUP client doesn't send CN domain to the HLR added

#14 Updated by neels 18 days ago

  • Assignee changed from stsp to neels

I have working patches ready on branches neels/upd_subscr (both in osmo-hlr and osmo-msc).
The remaining question is still what identification to use for GSUP clients like MSC and SGSN.
So far using the IPA_IDTAG_SERNR ('MSC-00-00-00-00-00-00') which is technically too long for the HLR db
(enlarged the storage but that is questionable).

#16 Updated by neels 11 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 90

#17 Updated by neels 5 days ago

above patch waiting for https://gerrit.osmocom.org/11232 which needs further code review, after first remarks were addressed.

#18 Updated by neels 4 days ago

first preparatory patch merged, now https://gerrit.osmocom.org/c/osmo-hlr/+/11233 waiting for code review.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)