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, On Mon, Mar 25, 2019 at 01:58:21AM +0100, Neels Hofmeyr wrote: > The templates for GSUP in GSUP_Types.ttcn seem to expect the GSUP IEs in a > specific order, which shouldn't be required. It shouldn't be required like in any of the protocols we deal with. The reality is different, at least for the 3GPP defined specs: Order is strictly required. You may not change the order of IEs, even though there are IEIs in the TLV structure that would allow for it. In Osmocom C language (and likely other implementations) we don't care on the receiver side, but to be a compliant transmitter, we must use the correct order. For GSUP now we can of course do something completely different, if we want to. I'm not sure what the GSUP specification document which we publish says about it. I would personally argue in favor of not permitting any random order of IEs. If you look at the various protocol Modules that Ericsson wrote for TTCN3, they all require the spec-mandated fixed order, contary to those "possibly more elgant/generic" protocol implementations that we added but which don't enforce any order. > Also I cannot easily define certain GSUP IEs as not mattering. > > Particularly, I added Source Entity and Destination Entity IEs, and now I would > have liked to just add some source_entity := *, destination_entity := *, to > trivially make all tr_GSUP() pass, whether these IEs are present or not. > > Instead I have to now add them to a listing of IEs everywhere. > That means the test suite will only work with the new osmo-msc and even if > "nightly" works out, we will see "latest" failing, etc. why is that? You can easily have a "*" inside the list of IE templates to allow for zero or more additional IEs of any kind. The GSUP IEs are defined as "type record of GSUP_IE GSUP_IEs;" which enforces strict ordering. One could theoretically use "type set of GSUP_IE GSUP_IEs" which is an unordered set allowing any order. However, a "set of" also permits for duplicate elements. Not sure if that's what you want. An alternative is the "permutation" qualifier for a "record of" template, which basically says "all of those elements must be present exactly once, in any order possible". See slide 176 of TTCN3_P.pdf So something like the combination of the change "record of" -> "set of" and the addition of a single '*' to the list of IEs should turn a receive template into what you'd like. There's also the "superset" qualifier. So if you define a set of IE templates and state you want to permit any superset on that set, then also any additional attributes beyond those minimally requierd ones in the set are accepted. See slide 175 of the "TTCN3_P.pdf" presentation. > I'd like to use the semantics I am used to in e.g. BSSMAP messages: > - order doesn't matter This is wrong. The BSSMAP dissector does not permit any order except the one specified in the specs! Regards, Harald -- - 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)