Attention is currently required from: laforge, pespin.
dexter has posted comments on this change by dexter. ( https://gerrit.osmocom.org/c/osmo-msc/+/43237?usp=email )
Change subject: sgs_iface: clean up code in function decode_mme_name ......................................................................
Patch Set 4:
(2 comments)
File src/libmsc/sgs_iface.c:
https://gerrit.osmocom.org/c/osmo-msc/+/43237/comment/c6388a77_7018663e?usp=... : PS2, Line 178:
the questions is what such proprietary formats are, how they look like, used by whom, and why there […]
We do try to parse it again (see below). We also use it to extract the gummei but as it seems the result is only used to name an FSM. The mme_fqdn is also used in the VLR. It is probably difficult to trace if it is really safe to use an arbitrary string as MME name.
https://gerrit.osmocom.org/c/osmo-msc/+/43237/comment/e01fb919_6e4be4c2?usp=... : PS2, Line 204: OSMO_ASSERT(osmo_parse_mme_domain(&gummei, mme_fqdn) == 0); As it seems it gets even more problematic here: Let's assume we have called decode_mme_name before with a SGSAP_IE_MME_NAME that was not acceted by osmo_parse_mme_domain, so we took the memcpy path and just copied the value. Now we call sgs_mme_fqdn_received here with that value. Since the value didn't change, osmo_parse_mme_domain will reject it and the OSMO_ASSERT will crash the MSC.
The OSMO_ASSERT was introduced with:
``` commit 0df904dea9106587f40ec379e9cc05ea251beb7e Author: Harald Welte laforge@gnumonks.org Date: Mon Dec 3 11:00:04 2018 +0100 ```
This is much earlier than:
``` commit e2bd9eb37d8160b436a5a1bffc14690321f40ae6 Author: Omar Ramadan omar.ramadan93@gmail.com Date: Fri Apr 12 09:03:39 2019 -0700
```
So from what I can see the alternate path was never actively used, as it would have crashed the MSC. If this is true I would see that as an argument for removing the alternate path altogether as it has never worked.