Project

General

Profile

Actions

Bug #2785

closed

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

Added by laforge about 6 years ago. Updated almost 5 years ago.

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

100%

Spec Reference:

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 onlyResolved04/10/2018

Actions
Related to OsmoMSC - Bug #3601: OsmoMSC's GSUP client doesn't send CN domain to the HLRResolvedneels09/28/2018

Actions
Actions #1

Updated by laforge about 6 years ago

  • Assignee set to neels
  • Priority changed from Normal to High
Actions #2

Updated by laforge about 6 years ago

  • Assignee changed from neels to stsp
Actions #3

Updated by laforge about 6 years ago

There's now a test case: HLR_Tests.TC_vty_msisdn_isd

https://gerrit.osmocom.org/7039

Actions #4

Updated by stsp almost 6 years 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?

Actions #5

Updated by stsp almost 6 years ago

  • Status changed from New to In Progress
Actions #6

Updated by neels almost 6 years 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).

Actions #7

Updated by stsp almost 6 years 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.

Actions #8

Updated by stsp almost 6 years ago

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

Actions #9

Updated by neels almost 6 years ago

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

Updated by stsp almost 6 years ago

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

Actions #11

Updated by stsp almost 6 years ago

  • Status changed from In Progress to Resolved

Above change has been merged. Closing this issue.

Actions #12

Updated by laforge almost 6 years 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...

Actions #13

Updated by neels over 5 years ago

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

Updated by neels over 5 years 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).

Actions #16

Updated by neels over 5 years ago

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

Updated by neels over 5 years ago

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

Actions #18

Updated by neels over 5 years ago

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

Actions #19

Updated by neels almost 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)