osmo_ss7_vty: osmo_sccp_simple_client_on_ss7_id() overwrites ASP config from VTY
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,
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.