Bug #3356
OsmoSGSN doesn't provide unique IDTAG_SERNR in IPA CCM
0%
Description
OsmoSGSN currently identifies itself simply as "SGSN" over the IPA/GSUP link to OsmoHLR.
This is wrong as it results in all OsmoSGSNs (in a multi-SGSN network) to register using the same identity, which in turn will render the HLR unable to store which SGSN is actually serving the subscriber, and/or to route messages accordingly.
It appears the change to "SGSN" was made in Change-Id: I0a60681ab4a4d73e26fe8f0637447db4b6fe6eb2 from "SGSN-00-00-00-00-00-00" before. Both the old and the new name are wrong though, as they're not unique.
The correct behavior AFAICT is "SGSN-" prefix with whatever unique identifier behind. We could make that suffix configurable in the VTY, if there's no other way to derive any other locally unique identifier. MAC addresses work fine for BTSs, but not for SGSNs: There might be any number of OsmoSGSNs running on the same physical / virtual machine with only one MAC address...
Related issues
Associated revisions
make gsup ipa name configurable in osmo-sgsn.cfg
Add a 'gsup ipa-name' VTY command which overrides the default
IPA name used by the SGSN on the GSUP link towards the HLR.
This is required for GSUP routing in multi-SGSN networks.
The 'gsup ipa-name' option can only be set via the config file
because changing the IPA name at run-time conflicts with active
GSUP connections and routes configured in the HLR. The osmo-sgsn
program must be restarted if its IPA name needs to change.
Related: OS#3356
Change-Id: Ib2f65fed9f56b9718e8a9647e3f01dce69870c1f
History
#1 Updated by laforge almost 3 years ago
- Related to Bug #3355: OsmoMSC doesn't provide unique IDTAG_SERNR in IPA CCM added
#2 Updated by laforge almost 3 years ago
- Related to Bug #2796: OsmoHLR doesn't update VLR during UpdateLocation added
#3 Updated by laforge almost 3 years ago
Note: The identifier must stay unique even across re-starts of the SGSN.
#4 Updated by stsp over 2 years ago
Would uuid_generate be a reasonable solution?
https://linux.die.net/man/3/uuid_generate
#5 Updated by neels over 2 years ago
stsp wrote:
Would uuid_generate be a reasonable solution?
https://linux.die.net/man/3/uuid_generate
The difficulty is to get the same UUID across program restarts, i.e. no random involved.
We should probably use an ID to be set in the config file (and loudly error-log if missing)?
#6 Updated by neels over 2 years ago
it would be good if the identification were at most 15 characters wide, so it fits in the HLR's sgsn_number.
#7 Updated by neels over 2 years ago
neels wrote:
it would be good if the identification were at most 15 characters wide, so it fits in the HLR's sgsn_number.
OK, turns out the GSUP clients are free to send pretty much anything they want (in the sense of arbitrary Global Title),
and osmo-hlr should be able to deal with that.
#8 Updated by neels over 2 years ago
- Related to Feature #3644: allow arbitrary bytes in Global Title (GT), a.k.a. the VLR,SGSN's identification towards the HLR added
#9 Updated by stsp over 2 years ago
- Status changed from New to In Progress
This has already been fixed in osmo-msc (see issue #3355). I'll prepare a corresponding patch for osmo-sgsn.
#11 Updated by laforge about 2 years ago
- Assignee changed from stsp to osmith
- Priority changed from High to Normal
remove pointless declaration of struct gsm_network
We were passing a NULL pointer of type struct gsm_network * to
ctrl_interface_setup_dynip(). Remove the pointless declaration
of this struct. Also, replace the sgsn_controlif_setup() helper
function with a direct call to ctrl_interface_setup_dynip().
The helper fnuction was just a thin wrapper around the latter.
Change-Id: Ib4151afa5bff01e63b462cca517fb60ac0503759
Related: OS#3356