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 Fri, Mar 16, 2018 at 03:08:03AM +0100, Neels Hofmeyr wrote: > which at first glance looks like they got the MCC-MNC digits ordered wrongly. > It is correct as long as the less significant nibble comes first. And using > these in PLMN tests gives the expected results. I am not sure why Ericsson wrote those definitions the way they are. I think its stupid (sorry) to define lots of single-length hexstrings rather than one hexstring. > Now I assume that the HEX1 means that it's a nibble, where the less significant > nibble comes first, HEX1 is a hexstring of length(1), see General_Types.ttcn: General_Types.ttcn: type hexstring HEX1 length(1) with {variant "FIELDLENGTH(1)"}; > sort of a "network nibble order" if that makes any sense. The order is not part of the HEX1 definition but it's defined in an attribute/variant of the RAW type. You can use FIELDORDER() to define the encoding order of the fields of a record. You can also use the "BYTEORDER()" and "BITORDER()" or "HEXORDER()" to define the respective parameters, see the TITAN documentation on the RAW coder for more details. > It is weird, though -- do we need to compose hex strings "reversed" as well?? I'm not sure what you're asking here? In the type definitions I wrote I simply use a construct like GSM_RR_Types.ttcn: type hexstring GsmBcdString with { variant "HEXORDER(low)" }; Which Makes sure that something like "123456" is encoded as "213265" like in IMSIs, MSISDNs etc. However, for those type definitions that are provided by Ericsson, I think it makes more sense to use them as-is rather than create our own fork. -- - 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)