Project

General

Profile

Bug #2499

osmo_ss7_vty: osmo_sccp_simple_client_on_ss7_id() overwrites ASP config from VTY

Added by neels 13 days ago. Updated 1 day ago.

Status:
In Progress
Priority:
Normal
Assignee:
Start date:
09/07/2017
Due date:
% Done:

100%

Spec Reference:

Description

Take this osmo-msc config, I have an ASP with remote-ip defined, but no AS:

network
 network country code 1
 mobile network code 1
 short name OsmoMSC
 long name OsmoMSC
 auth policy closed
 location updating reject cause 13
 encryption a5 0
 rrlp mode none
 mm info 1
cs7 instance 0
 point-code 0.23.1
 asp asp-clnt-OsmoMSC-A-Iu 2905 0 m3ua
  ! where to reach the STP:
  remote-ip 10.23.24.1
msc
 cs7-instance-a 0
 cs7-instance-iu 0
 mgcpgw remote-ip 10.23.24.1
 assign-tmsi

What happens when osmo-msc starts is:
- a new AS is created because none exists yet.

- for that AS, no ASP is defined, so one is created. But this by doing
osmo_ss7_asp_find_or_create(ss7, asp_name, default_remote_port,
default_local_port, prot);
Because I have created in the VTY an ASP that has exactly the name that is
autogenerated, instead of creating a fresh one, the
osmo_ss7_asp_find_or_create() returns exactly that one the VTY created.

- next, the code does:
asp->cfg.remote.host = default_remote_ip [...];
i.e. it silently overwrites the IP address I have configured in the VTY.

Writing the config back results in

cs7 instance 0
 point-code 0.23.1
 asp asp-clnt-OsmoMSC-A-Iu 2905 0 m3ua
  remote-ip 127.0.0.1
 as as-clnt-OsmoMSC-A-Iu m3ua
  asp asp-clnt-OsmoMSC-A-Iu
  routing-key 0 0.23.1

(i.e. with a different ASP remote-ip than originally)

What the user clearly requested is dropped on the floor without any warning.
Also the previous value in asp->cfg.remote.host is un-freed.

Of course this only happens when the ASP's name exactly matches the default
name, but when we use config generated by 'show running-config' or 'write file'
and tweak that, this is actually a quite common case.

History

#1 Updated by neels 13 days ago

  • Description updated (diff)

#2 Updated by dexter 6 days ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

I have now implemented a check for that cornercase, see: https://gerrit.osmocom.org/3948

#3 Updated by neels 6 days ago

the patch is not yet through code review ... maybe marking as resolved should wait until it is actually merged?

#4 Updated by dexter 1 day ago

  • Status changed from Resolved to In Progress

Also available in: Atom PDF