Project

General

Profile

Bug #2785

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

Added by laforge 7 months ago. Updated about 1 month ago.

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

0%

Estimated time:

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

History

#1 Updated by laforge 7 months ago

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

#2 Updated by laforge 5 months ago

  • Assignee changed from neels to stsp

#3 Updated by laforge 5 months ago

There's now a test case: HLR_Tests.TC_vty_msisdn_isd

https://gerrit.osmocom.org/7039

#4 Updated by stsp 4 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 4 months ago

  • Status changed from New to In Progress

#6 Updated by neels 4 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 3 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 3 months ago

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

#9 Updated by neels 3 months ago

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

#10 Updated by stsp 2 months ago

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

#11 Updated by stsp 2 months ago

  • Status changed from In Progress to Resolved

Above change has been merged. Closing this issue.

#12 Updated by laforge about 1 month 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...

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)