22 Feb
2018
22 Feb
'18
6:46 a.m.
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "An utility library for Open Source Mobile Communications".
The branch, neels/mnc3 has been updated
discards 3d8879bfbcc3ff16ef955876a1a989d26fb692ba (commit)
discards e08e9c479a3360b74c6fb947b706a43840acd639 (commit)
discards 2aa1badcd17eafc7648ac6ada81d4fbfc724c00a (commit)
discards 91892abac66e9bbf538f4453f452e67a54f876ee (commit)
discards b7199612d6e2cce676cb099ac41c96a738494ba6 (commit)
discards be4fbeaf8c61ddc2f496bb2ad520118b53c6f645 (commit)
via 4615bd65427d8bd72caffb3da93f1b8bcb09d107 (commit)
via 58c904774e33cd1c69217f000df16f7b3d739a03 (commit)
via b834794958c3889ab963df046c780be828b44159 (commit)
via d99e40f3e8da67576e3400592825283022720fce (commit)
via e228f70c14acbddc474571db10df72c16c567786 (commit)
via f4f141ef4315968f9f333ceb1d725fb54b33a5d2 (commit)
This update added new revisions after undoing existing revisions. That is
to say, the old revision is not a strict subset of the new revision. This
situation occurs when you --force push a change and generate a repository
containing something like this:
* -- * -- B -- O -- O -- O (3d8879bfbcc3ff16ef955876a1a989d26fb692ba)
\
N -- N -- N (4615bd65427d8bd72caffb3da93f1b8bcb09d107)
When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/libosmocore/commit/?id=4615bd65427d8bd72caffb3da93f…
commit 4615bd65427d8bd72caffb3da93f1b8bcb09d107
Author: Neels Hofmeyr <neels(a)hofmeyr.de>
Date: Tue Feb 20 15:14:14 2018 +0100
introduce GSM_MCC_MNC_INVALID
In some cases, we want to mark an unset MCC-MNC. Define uint16-max for this
purpose.
osmo-bsc code is already doing so with a -1 and using int data types, which
will become inconvenient with the new API that handles MCC and MNC as uint16_t.
Change-Id: Ieee7add0bd6d94cf84743a49794bbcd38561b72f
http://cgit.osmocom.org/libosmocore/commit/?id=58c904774e33cd1c69217f000df1…
commit 58c904774e33cd1c69217f000df16f7b3d739a03
Author: Neels Hofmeyr <neels(a)hofmeyr.de>
Date: Tue Feb 20 21:38:00 2018 +0100
gsm: add gsm48_mnc_from_str() and gsm48_mnc_cmp(), for 3-digit MNC
gsm48_mnc_from_str() preserves leading zeros in the string and is useful for
VTY config parsing.
gsm48_mnc_cmp() will be used by osmo-sgsn.git
Change-Id: Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6
http://cgit.osmocom.org/libosmocore/commit/?id=b834794958c3889ab963df046c78…
commit b834794958c3889ab963df046c780be828b44159
Author: Neels Hofmeyr <neels(a)hofmeyr.de>
Date: Tue Feb 20 22:20:42 2018 +0100
gsm0408_test: add test cases for MNC with leading zeros
Change-Id: I9b387e09293a6bbef84b9620ccf21ee2f9ec751c
http://cgit.osmocom.org/libosmocore/commit/?id=d99e40f3e8da67576e3400592825…
commit d99e40f3e8da67576e3400592825283022720fce
Author: Neels Hofmeyr <neels(a)hofmeyr.de>
Date: Tue Feb 20 22:19:56 2018 +0100
gsm0408_test: test new gsm48_{decode,generate}_lai2() functions
Change-Id: I4c8492b8055803d2857f1ef30aede088778b085b
http://cgit.osmocom.org/libosmocore/commit/?id=e228f70c14acbddc474571db10df…
commit e228f70c14acbddc474571db10df72c16c567786
Author: Neels Hofmeyr <neels(a)hofmeyr.de>
Date: Tue Feb 20 15:12:23 2018 +0100
gsm0408_test: check for new mnc_3_digits flag
Note that on the input side, the 3-digits flag may be left false when the MNC
is >99 anyway. On the decoded side, the flag is set accurately.
Change-Id: I89765613d8c5bd939a6957f7443ac88475f1b93c
http://cgit.osmocom.org/libosmocore/commit/?id=f4f141ef4315968f9f333ceb1d72…
commit f4f141ef4315968f9f333ceb1d725fb54b33a5d2
Author: Neels Hofmeyr <neels(a)hofmeyr.de>
Date: Tue Feb 20 13:47:08 2018 +0100
implement support for 3-digit MNC with leading zeros
Enable representing three-digit MNC with leading zeros. The MNCs 23 and 023 are
actually different; so far we treated both as 23. Re-encode an incoming BCD or
string of 023 as it were, i.e. not dropping the leading zero as 23.
Break ABI compatibility by changing the size and ordering of struct gprs_ra_id.
Ordering is changed because the canonical oder is {Mobile Country Code, Mobile
Network Code}, so have the mcc member first. Change size (and ordering) by
inserting a flag to indicate a three-digit MNC after the mnc member. ABI
compatibility cannot be maintained, since struct gprs_ra_id is a direct member
of structs bssgp_bvc_ctx and bssgp_paging_info, and even just adding a flag to
the end would cause ABI changes of those structs.
Add new API to set and read this additional flag to preserve leading zeros:
- gsm48_mcc_mnc_to_bcd2(), gsm48_mcc_mnc_from_bcd2() after
gsm48_mcc_mnc_to_bcd() and gsm48_mcc_mnc_from_bcd().
- gsm0808_create_layer3_aoip2() after gsm0808_create_layer3_aoip().
- gsm48_decode_lai2(), gsm48_generate_lai2() after
gsm48_decode_lai(), gsm48_generate_lai().
- The equivalent of gsm0808_create_layer3() for preserving leading zeros is
gsm0808_create_layer3_aoip2() with the scl argument passed as NULL; instead
of introducing a new shim function like gsm0808_create_layer3_2(), indicate
such in the API docs, only.
- gsm48_mnc_from_str() to encode leading zeros from string, useful for VTY
config parsing.
- gsm48_mnc_cmp() to compare MNC values including leading zeros.
- various osmo_*_name() functions. The amount and seeming duplication of these
may seem a bit overboard, but IMO they do make sense in this way. The root
reason is that the use of MCC and MNC is quite diverse throughout the osmocom
code base: in certain code, they are single uint16_t, in others they are
embedded in structs along with lac and rac; sometimes, all should be printed
in one go (repeatedly), in other cases (vty, ctrl) they are required singled
out. Without these functions, the formatting kind of ("%0*u", mnc_3_digits
?
3 : 2, mnc) would be duplicated all over our diverse repositories, or
printing MCC-MNC or RAI would otherwise end up to be more code.
In various log output, include the leading MNC zeros.
Mark one TODO in card_fs_sim.c, I am not sure how to communicate a leading zero
to/from a SIM card FS. The focus here is on the core network / BSS.
To indicate ABI incompatibility, bump libosmogsm and libosmogb LIBVERSIONs;
adjust debian files accordingly.
Implementation choices:
- The default behavior upon zero-initialization will be the mnc_3_digits flag
set to false, which yields exactly the previous behavior.
- I decided against packing the mnc with the mnc_3_digits field into a
sub-struct because it would enlarge this patch; plus, with a separate flag,
current code can decide when to start heeding leading zeros.
Change-Id: Id2240f7f518494c9df6c8bda52c0d5092f90f221
-----------------------------------------------------------------------
Summary of changes:
hooks/post-receive
--
An utility library for Open Source Mobile Communications