This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Neels, IPA CCM made sense on the Abis interface, where each BTS reports with its unit_id and MAC address. I'm not quite sure how much sense that makes in the core network. I also don't know if existing implementations of e.g. A interface over IPA multiplex actually use it. In terms of future outlook, the MSC/VLR/SGSN should register at the HLR with some kind of identity. In MAP, it is the SCCP Address that is used for this purpose. In absence of SCCP on GSUP, I used the CCM identity as a replacement. However, it is used as an opaque string, so that any GSUP/MAP gateway might simply translate the SCCP address into a string of its choosing, and then talk to OsmoHLR. OsmoHLR would then simply do a strcmp() on the string to match the identity. Sooner or later, OsmoHLR will have to store this identity in the database, e.g. for imlpementing message-waiting-lists of SMSCs in case of MT-SMS from real SMSCs. All-in-all, I think the string approach is not too bad in terms of keeping GSUP simple while having a clan approach to interworkng with MAP. On Fri, Feb 24, 2017 at 06:43:26AM +0100, Neels Hofmeyr wrote: > I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. > It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM > means) to route GSUP replies back to its sender. > > It looks like "NAME-00-00-00-00-00-00". > > However, all of our GSUP client code simply sets the unit id to: > "SGSN-00-00-00-00-00-00". > > The result is that the VLR never receives an UPDATE LOCATION RESULT, because it > is sent to the SGSN instead, since that was the first one to say that it is > "SGSN-00...". this is of course not good. > I would extend the GSUP clients to allow setting an ID from VTY, or maybe a > random ID. At this point it would suffice to make the MSC side say it is > "MSC-00-00-00-00-00-00" but that's beside the point. A random ID would not be permissible, as it has to be persistent accross MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms working. I would say, why not simply use the same approach as in OsmoBTS, i.e. use the MAC address (together with the MSC or SGSN prefix). The MAC address is unlikely to change frequently or on short notice. For people who know what they're doing, we can have a VTY command to override the identity with a manually-specified string. If that option is not set, the default "(SGSN|MSC)-MAC" is used. > Do we really want to do that? Any peer could come along and say it is someone > else, very easy to misconfigure (and not very security sensitive when thinking > of OAP -- which we're not using but maybe we will one day). I don't think we are aiming for anyone to use those protocols on public[ly accessible] networks. There's no message authentication or other cryptographic protection anyway. OAP seems like a funny but futile minor obstacle, but nothing that can provide any reasonable level of security. > For some messages, OsmoHLR uses the conn pointer from msg rx to route the > response back -- that works. This should be done in all request-response style procedures, I think. > AFAICT it just receives messages and replies to them right away (but > haven't seen / understood all of it). For the case of the UPDATE > LOCATION RESULT, it would also be possible to use the same conn > pointer, but the code chooses to resolve by id and then sends to the > wrong peer. If it used the peer's IP address and port instead, things > would work out. Looking up by ID would also work in case meanwhile the old connection has died and a new connection has been established > With the attached and possibly very stupid patch, OsmoHLR works for me with > both MSC and SGSN talking to it even though they have identical IPA IDs: I > bluntly store the conn in struct lu_operation and re-use it later. For synchronous responses (i.e. no asynchronous activity in between) this will work. So I think it's an optimization for those cases, and we shouldn't rely on this to always work for all transactions at all time in the future. Rather, we should make sure it works even without that optimization? -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)