- OpenBSC - lists.osmocom.org

[PATCH 1/3] Add explicit check for SI2quater index and count
by msuraev＠sysmocom.de 17 Mar '16

17 Mar '16

From: Max <msuraev(a)sysmocom.de> Right now we do not support multiple SI2quater messages, so return error if either index or count is non-zero. --- src/common/rsl.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/src/common/rsl.c b/src/common/rsl.c index a503355..ecf570c 100644 --- a/src/common/rsl.c +++ b/src/common/rsl.c @@ -298,9 +298,10 @@ static int rsl_rx_bcch_info(struct gsm_bts_trx *trx, struct msgb *msg) { struct gsm_bts *bts = trx->bts; struct tlv_parsed tp; - uint8_t rsl_si; + uint8_t rsl_si, si2q_index, si2q_count; enum osmo_sysinfo_type osmo_si; - + struct gsm48_system_information_type_2quater *si2q; + struct bitvec bv; rsl_tlv_parse(&tp, msgb_l3(msg), msgb_l3len(msg)); /* 9.3.30 System Info Type */ @@ -327,6 +328,24 @@ static int rsl_rx_bcch_info(struct gsm_bts_trx *trx, struct msgb *msg) TLVP_VAL(&tp, RSL_IE_FULL_BCCH_INFO), len); LOGP(DRSL, LOGL_INFO, " Rx RSL BCCH INFO (SI%s)\n", get_value_string(osmo_sitype_strs, osmo_si)); + + if (SYSINFO_TYPE_2quater == osmo_si) { + si2q = (struct gsm48_system_information_type_2quater *) + bts->si_buf[SYSINFO_TYPE_2quater]; + bv.data = si2q->rest_octets; + bv.data_len = 20; + bv.cur_bit = 3; + si2q_index = (uint8_t) bitvec_get_uint(&bv, 4); + si2q_count = (uint8_t) bitvec_get_uint(&bv, 4); + if (si2q_index || si2q_count) { + LOGP(DRSL, LOGL_ERROR, + " Rx RSL SI2quater witn unsupported " + "index %u, count %u\n", + si2q_index, si2q_count); + return rsl_tx_error_report(trx, + RSL_ERR_IE_CONTENT); + } + } } else if (TLVP_PRESENT(&tp, RSL_IE_L3_INFO)) { uint16_t len = TLVP_LEN(&tp, RSL_IE_L3_INFO); if (len > sizeof(sysinfo_buf_t)) -- 2.7.3

2 3

[PATCH] Fix SI2ter scheduling
by msuraev＠sysmocom.de 17 Mar '16

17 Mar '16

From: Max <msuraev(a)sysmocom.de> According to 3GPP TS 05.02 § 6.3.1.3 SI2ter messages should be scheduled in FN with TC=4 only if SI2bis messages are also available. --- src/common/sysinfo.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/common/sysinfo.c b/src/common/sysinfo.c index f079199..ee42da2 100644 --- a/src/common/sysinfo.c +++ b/src/common/sysinfo.c @@ -76,9 +76,10 @@ uint8_t *bts_sysinfo_get(struct gsm_bts *bts, struct gsm_time *g_time) /* iterate over 2ter, 2quater, 9, 13 */ /* determine how many SI we need to send on TC=4, * and which of them we send when */ - if (BTS_HAS_SI(bts, SYSINFO_TYPE_2ter)) { + if (BTS_HAS_SI(bts, SYSINFO_TYPE_2ter) && + BTS_HAS_SI(bts, SYSINFO_TYPE_2bis)) { tc4_sub[tc4_cnt] = SYSINFO_TYPE_2ter; - tc4_cnt += 1; /* 2bis */ + tc4_cnt += 1; } if (BTS_HAS_SI(bts, SYSINFO_TYPE_2quater) && (BTS_HAS_SI(bts, SYSINFO_TYPE_2bis) || -- 2.7.3

2 1

Status of osmo-ganc
by zeflo 17 Mar '16

17 Mar '16

Hi, i was wondering how is the status of osmo-ganc? Is there a working implementation? As far as i understand it, to test GAN + OpenBSC i would need a GAN capable mobile phone, or a modified version of OsmocomBB. Greetings, Florian

2 1

Iu: flimsy TMSI
by Neels Hofmeyr 17 Mar '16

17 Mar '16

Hi Daniel and 3G folks, about our difficulty in maintaining a prolonged link with the UE, I found a bit of discrepancy concerning the TMSIs used. When looking at a pcap where we authenticate and MM LU / GMM Attach successfully on CS / PS, and with TMSI assignment enabled in CSCN, I see TMSIs in these places: 1) UE sends TMSI in "(GMM) Attach Request" (PS) 2) SGSN sends TMSI in "(GMM) Attach Accept" (PS) 3) CSCN sends TMSI in "Location Update Accept" (CS) All these TMSIs differ. When I look in the RRC log of the hnb, it is logging a TMSI for pretty much every received message on CS and PS domains. But it is always and only logging the TMSI matching 1), i.e. the TMSI originally sent on the PS domain. To rephrase, the same TMSI is logged for PS and CS domain messages; for the MM LU Accept as well as the GMM Attach Accept, the hnb logs TMSI 1) even though the CN sent TMSIs 3) and 2), respectively. For 1) and 2), it seems that the SGSN should accept and use the TMSI sent by the UE during the Attach Request, right? For 3), according to the RRC log, it seems that the UE expects to see the very same TMSI in CS that it sent to PS -- that'd be a problem. On the other hand, when noting that, in the Location Updating Request, the UE identified itself using the IMSI and not a TMSI, it may be indeed the correct choice to disable TMSI use for CS? I must admit that I'm not firm in the IMSI/TMSI realm, and staring at 3GPP 04.08 doesn't clarify it right away, so I'd appreciate some feedback from this list. I can stare some more, but maybe you guys are quicker. Thanks! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

2 1

[PATCH 1/2] Add function to add bits from array to bitvec
by msuraev＠sysmocom.de 17 Mar '16

17 Mar '16

From: Max <msuraev(a)sysmocom.de> Add function which adds specified number of bits from each element of array to the bit vector prefixing each addition with one and finishing entire sequence with adding 0. This is very common patter for various repetitive data structures described with CSN.1 in 3GPP standards. Corresponding test vectors and doxygen headers are added too. --- include/osmocom/core/bitvec.h | 3 +++ src/bitvec.c | 40 ++++++++++++++++++++++++++++++++++++++++ tests/bitvec/bitvec_test.c | 43 +++++++++++++++++++++++++++++++++++++++++++ tests/bitvec/bitvec_test.ok | 33 +++++++++++++++++++++++++++++++++ 4 files changed, 119 insertions(+) diff --git a/include/osmocom/core/bitvec.h b/include/osmocom/core/bitvec.h index 5314cf2..c3c1153 100644 --- a/include/osmocom/core/bitvec.h +++ b/include/osmocom/core/bitvec.h @@ -91,5 +91,8 @@ void bitvec_zero(struct bitvec *bv); unsigned bitvec_rl(const struct bitvec *bv, bool b); void bitvec_shiftl(struct bitvec *bv, unsigned int n); int16_t bitvec_get_int16_msb(const struct bitvec *bv, unsigned int num_bits); +unsigned int bitvec_add_array(struct bitvec *bv, const uint32_t *array, + unsigned int array_len, bool dry_run, + unsigned int num_bits); /*! @} */ diff --git a/src/bitvec.c b/src/bitvec.c index 00ae150..6f0c15a 100644 --- a/src/bitvec.c +++ b/src/bitvec.c @@ -570,4 +570,44 @@ void bitvec_shiftl(struct bitvec *bv, unsigned n) bv->cur_bit -= n; } +/*! \brief Add given array to bitvec + * \param[in,out] bv bit vector to work with + * \param[in] array elements to be added + * \param[in] array_len length of array + * \param[in] dry_run indicates whether to return number of bits required + * instead of adding anything to bv for real + * \param[in] num_bits number of bits to consider in each element of array + * \returns number of bits necessary to add array elements if dry_run is true, + * 0 otherwise (only in this case bv is actually changed) + * + * N. B: no length checks are performed on bv - it's callee's job to ensure + * enough space is available - for example by calling with dry_run = true first. + * + * Useful for common pattern in CSN.1 spec which looks like: + * { 1 < XXX : bit (num_bits) > } ** 0 + * which means repeat any times (between 0 and infinity), + * start each repetition with 1, mark end of repetitions with 0 bit + * see app. note in 3GPP TS 24.007 § B.2.1 Rule A2 + */ +unsigned int bitvec_add_array(struct bitvec *bv, const uint32_t *array, + unsigned int array_len, bool dry_run, + unsigned int num_bits) +{ + unsigned i, bits = 1; /* account for stop bit */ + for (i = 0; i < array_len; i++) { + if (dry_run) { + bits += (1 + num_bits); + } else { + bitvec_set_bit(bv, 1); + bitvec_set_uint(bv, array[i], num_bits); + } + } + + if (dry_run) + return bits; + + bitvec_set_bit(bv, 0); /* stop bit - end of the sequence */ + return 0; +} + /*! @} */ diff --git a/tests/bitvec/bitvec_test.c b/tests/bitvec/bitvec_test.c index 76d6773..a98a91c 100644 --- a/tests/bitvec/bitvec_test.c +++ b/tests/bitvec/bitvec_test.c @@ -132,6 +132,43 @@ static void test_unhex(const char *hex) printf("%s\n", hex); } +static inline void test_array_item(unsigned t, struct bitvec *b, unsigned int n, + uint32_t *array, unsigned int p) +{ + unsigned int i, x, y; + bitvec_zero(b); + x = b->cur_bit; + i = bitvec_add_array(b, array, n, true, t); + y = b->cur_bit; + bitvec_add_array(b, array, n, false, t); + printf("\nbits: %u, est: %u, real: %u, x: %u, y: %u\n", + t, i, b->cur_bit, x, y); + for (i = 0; i < p; i++) { + printf(OSMO_BIT_SPEC " ", OSMO_BIT_PRINT(b->data[i])); + if (0 == (i + 1) % 15) + printf("\n"); + } +} + +static void test_array() +{ + struct bitvec b; + uint8_t d[4096]; + b.data = d; + b.data_len = sizeof(d); + + unsigned int i, n = 64; + uint32_t array[n]; + for (i = 0; i < n; i++) { + array[i] = i * i * i + i; + printf("0x%x ", array[i]); + } + + test_array_item(3, &b, n, array, n); + test_array_item(9, &b, n, array, n * 2); + test_array_item(17, &b, n, array, n * 3); +} + int main(int argc, char **argv) { struct bitvec bv; @@ -204,5 +241,11 @@ int main(int argc, char **argv) test_unhex("DEADFACE000000000000000000000000000000BEEFFEED"); test_unhex("FFFFFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"); + printf("arrr...\n"); + + test_array(); + + printf("\nbitvec ok.\n"); + return 0; } diff --git a/tests/bitvec/bitvec_test.ok b/tests/bitvec/bitvec_test.ok index 1c993d3..e256108 100644 --- a/tests/bitvec/bitvec_test.ok +++ b/tests/bitvec/bitvec_test.ok @@ -134,3 +134,36 @@ DEADFACE000000000000000000000000000000BEEFFEED 0 -=> cur_bit=512 fffffaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa FFFFFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB +arrr... +0x0 0x2 0xa 0x1e 0x44 0x82 0xde 0x15e 0x208 0x2e2 0x3f2 0x53e 0x6cc 0x8a2 0xac6 0xd3e 0x1010 0x1342 0x16da 0x1ade 0x1f54 0x2442 0x29ae 0x2f9e 0x3618 0x3d22 0x44c2 0x4cfe 0x55dc 0x5f62 0x6996 0x747e 0x8020 0x8c82 0x99aa 0xa79e 0xb664 0xc602 0xd67e 0xe7de 0xfa28 0x10d62 0x12192 0x136be 0x14cec 0x16422 0x17c66 0x195be 0x1b030 0x1cbc2 0x1e87a 0x2065e 0x22574 0x245c2 0x2674e 0x28a1e 0x2ae38 0x2d3a2 0x2fa62 0x3227e 0x34bfc 0x376e2 0x3a336 0x3d0fe +bits: 3, est: 257, real: 257, x: 0, y: 0 +1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. +111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. +11..1.1. 111.111. ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ +bits: 9, est: 641, real: 641, x: 0, y: 0 +1....... ..1..... ..1.1... ..1.1.1. ...1111. 1..1...1 ..1.1... ..1.1.11 .1111.11 .1.1111. 1.....1. ..1.111. ..1.1111 11..1.11 ..11111. +1.11..11 ..1.1.1. ..1.1.11 ...11.11 ..11111. 1....1.. ..11.1.. ..1.1.11 .11.1.1. 11.1111. 11.1.1.1 ..1..1.. ..1.111. 1.111.11 1..1111. +1....11. ..11..1. ..1.1.11 ....1.1. 1111111. 1111.111 ..11.11. ..1.111. .1.11.1. .111111. 1...1... ..1.1... ..1.111. 1.1.1.11 1..1111. +1..11..1 ..1..... ..1.1..1 11111.11 11.1111. 1...1.1. ..11.11. ..1.111. .1..1.1. 1.11111. 1.111.11 ..1...1. ..1.1..1 1..11.11 1.11111. +1...11.. ..1111.. ..1.1..1 111.1.1. .1.1111. 11.111.1 ..1111.. ..1.11.1 ..111.1. ...1111. 1...111. ..111.1. ..1.1..1 1...1.1. .111111. +11111111 ..1.111. ..1.11.. 11.11.1. 1111111. ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ +bits: 17, est: 1153, real: 1153, x: 0, y: 0 +1....... ........ ..1..... ........ ..1.1... ........ ..1.1.1. ........ ...1111. 1....... ...1...1 ..1..... ....1... ..1.1... ......11 +.1111.1. .......1 .1.1111. 1....... 1.....1. ..1..... ..1.111. ..1.1... ....1111 11..1.1. .....1.1 ..11111. 1......1 1.11..11 ..1..... +1...1.1. ..1.1... ..1.1.11 ...11.1. ....11.1 ..11111. 1....1.. .....1.. ..1....1 ..11.1.. ..1.1... .1.11.11 .11.1.1. ...11.1. 11.1111. +1....111 11.1.1.1 ..1...1. .1...1.. ..1.1... 1.1..11. 1.111.1. ..1.1111 1..1111. 1...11.1 1....11. ..1...11 11.1..1. ..1.1..1 ...1..11 +....1.1. .1..11.. 1111111. 1..1.1.1 .111.111 ..1..1.1 1111.11. ..1.1..1 1.1..11. .1.11.1. .111.1.. .111111. 1.1..... ....1... ..1.1... +11..1... ..1.1.1. .11..11. 1.1.1.1. 1.1..111 1..1111. 1.1.11.1 1..11..1 ..1.11.. .11..... ..1.1.11 .1.11..1 11111.1. 111..111 11.1111. +1.11111. 1...1.1. ..11.... 11.1.11. ..1.11.. 1....11. .1..1.11 ..11.11. 1.11111. 11.1..11 ..111.11 ..11.11. .1....1. ..1.11.1 1111...1 +1..11.11 1..1.1.1 1.11111. 111.11.. ....11.. ..1111.. 1.1111.. ..1.1111 1.1....1 111.1.1. .....11. .1.1111. 1...1..1 .1.111.1 ..1..1.. +.1.111.. ..1.1..1 1..111.1 ..111.1. 1...1.1. ...1111. 1.1.1.11 1...111. ..1.11.1 ..111.1. ..1.1.11 111.1..1 1...1.11 ..1...1. .111111. +11.1..1. 11111111 ..11.111 .11.111. ..1.111. 1...11.. 11.11.11 11.1.... 1111111. ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +bitvec ok. -- 2.7.3

3 4

[PATCH] gsm48: factor out MCC+MNC BCD parsing for re-use in UMTS
by Neels Hofmeyr 17 Mar '16

17 Mar '16

For 3G, I need a BCD composer/parser similar to gsm48_generate_lai()/ gsm48_decode_lai(). Those functions also handle a trivial extra member (lac) which I don't need in this way for 3G. So create new functions to take on the MCC+MNC BCD handling and call those from gsm48_generate_lai() and gsm48_decode_lai(). In this way, the 3G code in openbsc can use only the BCD functionality without code duplication. --- include/osmocom/gsm/gsm48.h | 3 +++ src/gsm/gsm48.c | 55 ++++++++++++++++++++++++++++----------------- src/gsm/libosmogsm.map | 2 ++ 3 files changed, 39 insertions(+), 21 deletions(-) diff --git a/include/osmocom/gsm/gsm48.h b/include/osmocom/gsm/gsm48.h index 74ac52c..d6e58c2 100644 --- a/include/osmocom/gsm/gsm48.h +++ b/include/osmocom/gsm/gsm48.h @@ -39,3 +39,6 @@ void gsm48_parse_ra(struct gprs_ra_id *raid, const uint8_t *buf); int gsm48_construct_ra(uint8_t *buf, const struct gprs_ra_id *raid); int gsm48_number_of_paging_subchannels(struct gsm48_control_channel_descr *chan_desc); + +void gsm48_mcc_mnc_to_bcd(uint8_t *bcd_dst, uint16_t mcc, uint16_t mnc); +void gsm48_mcc_mnc_from_bcd(uint8_t *bcd_src, uint16_t *mcc, uint16_t *mnc); diff --git a/src/gsm/gsm48.c b/src/gsm/gsm48.c index 60937cb..d0a2286 100644 --- a/src/gsm/gsm48.c +++ b/src/gsm/gsm48.c @@ -278,25 +278,50 @@ static void to_bcd(uint8_t *bcd, uint16_t val) val = val / 10; } -void gsm48_generate_lai(struct gsm48_loc_area_id *lai48, uint16_t mcc, - uint16_t mnc, uint16_t lac) +/* Convert given mcc and mnc to BCD and write to *bcd_dst, which must be an + * allocated buffer of (at least) 3 bytes length. */ +void gsm48_mcc_mnc_to_bcd(uint8_t *bcd_dst, uint16_t mcc, uint16_t mnc) { uint8_t bcd[3]; to_bcd(bcd, mcc); - lai48->digits[0] = bcd[0] | (bcd[1] << 4); - lai48->digits[1] = bcd[2]; + bcd_dst[0] = bcd[0] | (bcd[1] << 4); + bcd_dst[1] = bcd[2]; to_bcd(bcd, mnc); /* FIXME: do we need three-digit MNC? See Table 10.5.3 */ if (mnc > 99) { - lai48->digits[1] |= bcd[2] << 4; - lai48->digits[2] = bcd[0] | (bcd[1] << 4); + bcd_dst[1] |= bcd[2] << 4; + bcd_dst[2] = bcd[0] | (bcd[1] << 4); + } else { + bcd_dst[1] |= 0xf << 4; + bcd_dst[2] = bcd[1] | (bcd[2] << 4); + } +} + +/* Convert given 3-byte BCD buffer to integers and write results to *mcc and + * *mnc. The first three BCD digits result in the MCC and the remaining ones in + * the MNC. */ +void gsm48_mcc_mnc_from_bcd(uint8_t *bcd_src, uint16_t *mcc, uint16_t *mnc) +{ + *mcc = (bcd_src[0] & 0x0f) * 100 + + (bcd_src[0] >> 4) * 10 + + (bcd_src[1] & 0x0f); + + if ((bcd_src[1] & 0xf0) == 0xf0) { + *mnc = (bcd_src[2] & 0x0f) * 10 + + (bcd_src[2] >> 4); } else { - lai48->digits[1] |= 0xf << 4; - lai48->digits[2] = bcd[1] | (bcd[2] << 4); + *mnc = (bcd_src[2] & 0x0f) * 100 + + (bcd_src[2] >> 4) * 10 + + (bcd_src[1] >> 4); } +} +void gsm48_generate_lai(struct gsm48_loc_area_id *lai48, uint16_t mcc, + uint16_t mnc, uint16_t lac) +{ + gsm48_mcc_mnc_to_bcd(&lai48->digits[0], mcc, mnc); lai48->lac = htons(lac); } @@ -304,20 +329,8 @@ void gsm48_generate_lai(struct gsm48_loc_area_id *lai48, uint16_t mcc, int gsm48_decode_lai(struct gsm48_loc_area_id *lai, uint16_t *mcc, uint16_t *mnc, uint16_t *lac) { - *mcc = (lai->digits[0] & 0x0f) * 100 - + (lai->digits[0] >> 4) * 10 - + (lai->digits[1] & 0x0f); - - if ((lai->digits[1] & 0xf0) == 0xf0) { - *mnc = (lai->digits[2] & 0x0f) * 10 - + (lai->digits[2] >> 4); - } else { - *mnc = (lai->digits[2] & 0x0f) * 100 - + (lai->digits[2] >> 4) * 10 - + (lai->digits[1] >> 4); - } + gsm48_mcc_mnc_from_bcd(&lai->digits[0], mcc, mnc); *lac = ntohs(lai->lac); - return 0; } diff --git a/src/gsm/libosmogsm.map b/src/gsm/libosmogsm.map index 7eebe7f..0aeefbb 100644 --- a/src/gsm/libosmogsm.map +++ b/src/gsm/libosmogsm.map @@ -138,6 +138,8 @@ gsm48_number_of_paging_subchannels; gsm48_parse_ra; gsm48_rr_att_tlvdef; gsm48_mi_type_name; +gsm48_mcc_mnc_to_bcd; +gsm48_mcc_mnc_from_bcd; gsm_7bit_decode; gsm_7bit_decode_ussd; -- 2.1.4

2 2

[PATCH] Add explicit check for SI2quater index and count
by msuraev＠sysmocom.de 16 Mar '16

16 Mar '16

From: Max <msuraev(a)sysmocom.de> Right now we do not support multiple SI2quater messages, so return error if either index or count is non-zero. --- src/common/rsl.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/src/common/rsl.c b/src/common/rsl.c index a503355..ed8cced 100644 --- a/src/common/rsl.c +++ b/src/common/rsl.c @@ -298,9 +298,10 @@ static int rsl_rx_bcch_info(struct gsm_bts_trx *trx, struct msgb *msg) { struct gsm_bts *bts = trx->bts; struct tlv_parsed tp; - uint8_t rsl_si; + uint8_t rsl_si, si2q_index, si2q_count; enum osmo_sysinfo_type osmo_si; - + struct gsm48_system_information_type_2quater *si2q; + struct bitvec bv; rsl_tlv_parse(&tp, msgb_l3(msg), msgb_l3len(msg)); /* 9.3.30 System Info Type */ @@ -327,6 +328,22 @@ static int rsl_rx_bcch_info(struct gsm_bts_trx *trx, struct msgb *msg) TLVP_VAL(&tp, RSL_IE_FULL_BCCH_INFO), len); LOGP(DRSL, LOGL_INFO, " Rx RSL BCCH INFO (SI%s)\n", get_value_string(osmo_sitype_strs, osmo_si)); + + if (SYSINFO_TYPE_2quater == osmo_si) { + si2q = (struct gsm48_system_information_type_2quater *) + bts->si_buf[SYSINFO_TYPE_2quater]; + bv.data = si2q->rest_octets; + bv.data_len = 20; + bv.cur_bit = 3; + si2q_index = (uint8_t) bitvec_get_uint(&bv, 4); + si2q_count = (uint8_t) bitvec_get_uint(&bv, 4); + if (si2q_index || si2q_count) { + LOGP(DRSL, LOGL_ERROR, + " Rx RSL SI2quater witn unsupported index %u, count %u\n", + si2q_index, si2q_count); + return rsl_tx_error_report(trx, RSL_ERR_IE_CONTENT); + } + } } else if (TLVP_PRESENT(&tp, RSL_IE_L3_INFO)) { uint16_t len = TLVP_LEN(&tp, RSL_IE_L3_INFO); if (len > sizeof(sysinfo_buf_t)) -- 2.7.3

2 1

[PATCH 1/3] abis: Send the message without enforcing to wait for a response
by Holger Hans Peter Freyther 16 Mar '16

16 Mar '16

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> The user might issue restarts while no BTS is connected and we should not block the abis queue because of these messages. --- openbsc/src/libbsc/abis_nm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/libbsc/abis_nm.c b/openbsc/src/libbsc/abis_nm.c index c05e2f9..3afc4c4 100644 --- a/openbsc/src/libbsc/abis_nm.c +++ b/openbsc/src/libbsc/abis_nm.c @@ -2598,7 +2598,7 @@ int abis_nm_ipaccess_restart(struct gsm_bts_trx *trx) fill_om_fom_hdr(oh, 0, NM_MT_IPACC_RESTART, NM_OC_BASEB_TRANSC, trx->bts->nr, trx->nr, 0xff); - return abis_nm_sendmsg(trx->bts, msg); + return abis_nm_sendmsg_direct(trx->bts, msg); } int abis_nm_ipaccess_set_attr(struct gsm_bts *bts, uint8_t obj_class, -- 2.6.3

1 2

Authentication Response msg type: 0x14 in spec, 0x94 from a 3G phone
by Neels Hofmeyr 16 Mar '16

16 Mar '16

Hi list, today I saw an MM Authentication Response sent from a 3G UE that mismatches the GSM 04.08 spec. The spec says 0x14, the 3G phone sent 0x94. And wireshark agrees that 0x94 is an Authentication Response. The spec ETSI TS 100 940 V7.21.0 (2003-12) chapter 10.4 defines the MM Authentication Response message type as 8 7 6 5 4 3 2 1 0 x 0 1 - - - - Security messages: 0 1 0 0 AUTHENTICATION RESPONSE So this would be 0x14 or 0x54, depending on the don't-care bit 7. The Osmocom code acts according to spec by applying a bitmask of 0xbf (0b10111111) before comparing to 0x14, caring about bit 8. However, the 3G phone sent an Authentication Response message type of 0x94 (0b10010100) with bit 8 set. Interestingly enough, wireshark interprets this as a 0x14 with the highest two bits as sequence nr. So it seems the reality in the field differs from the spec in that bit 8 should be masked away before comparing to the MM message type code. In consequence, I need to adjust the MM message type bitmask to 0x3f in upcoming patches. The thing is, our code has the apparently wrong 0xbf bitmask hardcoded in numerous places. So as a first step, I will introduce bitmask #defines in libosmocore and apply these in openbsc. I will introduce separate bitmask defines for MM and CC messages, because I'm not sure yet whether CC message types should also be masked with 0x3f in the field and will leave the CC mask as 0xbf for now. While doing that, I also noticed that some places apply a 0xbf bitmask even though the message types in question aren't defined as having any don't-care bit in TS 100 940. I'll adjust those in a separate patch. - So at first, I will replace 0xbf with GSM48_MT_MM_MSG_TYPE_MASK or GSM48_MT_CC_MSG_TYPE_MASK. - Then I'll adjust the MM mask to 0x3f to allow testing 3G auth. - Finally I'll remove bit masks where they shouldn't be applicable, which could use a second opinion by you guys. Are the upper bits always some sequence number, and the spec simply doesn't reflect the field? The patch submissions will follow right up... ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

2 5

[PATCH] Add function to add bits from array to bitvec
by msuraev＠sysmocom.de 16 Mar '16

16 Mar '16

From: Max <msuraev(a)sysmocom.de> Add function which adds specified number of bits from each element of array to the bit vector prefixing each addition with one and finishing entire sequence with adding 0. This is very common patter for various repetitive data structures described with CSN.1 in 3GPP standards. Corresponding test vectors and doxygen headers are added too. --- include/osmocom/core/bitvec.h | 3 +++ src/bitvec.c | 40 ++++++++++++++++++++++++++++++++++++++++ tests/bitvec/bitvec_test.c | 43 +++++++++++++++++++++++++++++++++++++++++++ tests/bitvec/bitvec_test.ok | 33 +++++++++++++++++++++++++++++++++ 4 files changed, 119 insertions(+) diff --git a/include/osmocom/core/bitvec.h b/include/osmocom/core/bitvec.h index 5314cf2..a49d178 100644 --- a/include/osmocom/core/bitvec.h +++ b/include/osmocom/core/bitvec.h @@ -91,5 +91,8 @@ void bitvec_zero(struct bitvec *bv); unsigned bitvec_rl(const struct bitvec *bv, bool b); void bitvec_shiftl(struct bitvec *bv, unsigned int n); int16_t bitvec_get_int16_msb(const struct bitvec *bv, unsigned int num_bits); +unsigned int bitvec_add_array(struct bitvec *bv, const uint32_t *array, + unsigned int array_len, bool estimate, + unsigned int num_bits); /*! @} */ diff --git a/src/bitvec.c b/src/bitvec.c index 00ae150..7cd2f06 100644 --- a/src/bitvec.c +++ b/src/bitvec.c @@ -570,4 +570,44 @@ void bitvec_shiftl(struct bitvec *bv, unsigned n) bv->cur_bit -= n; } +/*! \brief Add given array to bitvec + * \param[in,out] bv bit vector to work with + * \param[in] array elements to be added + * \param[in] array_len length of array + * \param[in] estimate indicates whether to return number of bits required + * instead of actually changing bv + * \param[in] num_bits number of bits to consider in each element of array + * \returns number of bits necessary to add given PCIDs if estimate is true, + * 0 otherwise + * + * N. B: no length checks are performed on bv - it's callee's job to ensure + * enough space is available - for example by calling with estimate = true first. + * + * Useful for common pattern in CSN.1 spec which looks like: + * { 1 < XXX : bit (num_bits) > } ** 0 + * which means repeat any times (between 0 and infinity), + * start each repetition with 1, mark end of repetitions with 0 bit + * see app. note in 3GPP TS 24.007 § B.2.1 Rule A2 + */ +unsigned int bitvec_add_array(struct bitvec *bv, const uint32_t *array, + unsigned int array_len, bool estimate, + unsigned int num_bits) +{ + unsigned i, bits = 1; /* account for stop bit */ + for (i = 0; i < array_len; i++) { + if (estimate) { + bits += (1 + num_bits); + } else { + bitvec_set_bit(bv, 1); + bitvec_set_uint(bv, array[i], num_bits); + } + } + + if (estimate) + return bits; + + bitvec_set_bit(bv, 0); /* stop bit - end of the sequence */ + return 0; +} + /*! @} */ diff --git a/tests/bitvec/bitvec_test.c b/tests/bitvec/bitvec_test.c index 76d6773..a98a91c 100644 --- a/tests/bitvec/bitvec_test.c +++ b/tests/bitvec/bitvec_test.c @@ -132,6 +132,43 @@ static void test_unhex(const char *hex) printf("%s\n", hex); } +static inline void test_array_item(unsigned t, struct bitvec *b, unsigned int n, + uint32_t *array, unsigned int p) +{ + unsigned int i, x, y; + bitvec_zero(b); + x = b->cur_bit; + i = bitvec_add_array(b, array, n, true, t); + y = b->cur_bit; + bitvec_add_array(b, array, n, false, t); + printf("\nbits: %u, est: %u, real: %u, x: %u, y: %u\n", + t, i, b->cur_bit, x, y); + for (i = 0; i < p; i++) { + printf(OSMO_BIT_SPEC " ", OSMO_BIT_PRINT(b->data[i])); + if (0 == (i + 1) % 15) + printf("\n"); + } +} + +static void test_array() +{ + struct bitvec b; + uint8_t d[4096]; + b.data = d; + b.data_len = sizeof(d); + + unsigned int i, n = 64; + uint32_t array[n]; + for (i = 0; i < n; i++) { + array[i] = i * i * i + i; + printf("0x%x ", array[i]); + } + + test_array_item(3, &b, n, array, n); + test_array_item(9, &b, n, array, n * 2); + test_array_item(17, &b, n, array, n * 3); +} + int main(int argc, char **argv) { struct bitvec bv; @@ -204,5 +241,11 @@ int main(int argc, char **argv) test_unhex("DEADFACE000000000000000000000000000000BEEFFEED"); test_unhex("FFFFFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"); + printf("arrr...\n"); + + test_array(); + + printf("\nbitvec ok.\n"); + return 0; } diff --git a/tests/bitvec/bitvec_test.ok b/tests/bitvec/bitvec_test.ok index 1c993d3..e256108 100644 --- a/tests/bitvec/bitvec_test.ok +++ b/tests/bitvec/bitvec_test.ok @@ -134,3 +134,36 @@ DEADFACE000000000000000000000000000000BEEFFEED 0 -=> cur_bit=512 fffffaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa FFFFFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB +arrr... +0x0 0x2 0xa 0x1e 0x44 0x82 0xde 0x15e 0x208 0x2e2 0x3f2 0x53e 0x6cc 0x8a2 0xac6 0xd3e 0x1010 0x1342 0x16da 0x1ade 0x1f54 0x2442 0x29ae 0x2f9e 0x3618 0x3d22 0x44c2 0x4cfe 0x55dc 0x5f62 0x6996 0x747e 0x8020 0x8c82 0x99aa 0xa79e 0xb664 0xc602 0xd67e 0xe7de 0xfa28 0x10d62 0x12192 0x136be 0x14cec 0x16422 0x17c66 0x195be 0x1b030 0x1cbc2 0x1e87a 0x2065e 0x22574 0x245c2 0x2674e 0x28a1e 0x2ae38 0x2d3a2 0x2fa62 0x3227e 0x34bfc 0x376e2 0x3a336 0x3d0fe +bits: 3, est: 257, real: 257, x: 0, y: 0 +1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. +111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. 11..1.1. 111.111. 1...1.1. 1.1.111. +11..1.1. 111.111. ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ +bits: 9, est: 641, real: 641, x: 0, y: 0 +1....... ..1..... ..1.1... ..1.1.1. ...1111. 1..1...1 ..1.1... ..1.1.11 .1111.11 .1.1111. 1.....1. ..1.111. ..1.1111 11..1.11 ..11111. +1.11..11 ..1.1.1. ..1.1.11 ...11.11 ..11111. 1....1.. ..11.1.. ..1.1.11 .11.1.1. 11.1111. 11.1.1.1 ..1..1.. ..1.111. 1.111.11 1..1111. +1....11. ..11..1. ..1.1.11 ....1.1. 1111111. 1111.111 ..11.11. ..1.111. .1.11.1. .111111. 1...1... ..1.1... ..1.111. 1.1.1.11 1..1111. +1..11..1 ..1..... ..1.1..1 11111.11 11.1111. 1...1.1. ..11.11. ..1.111. .1..1.1. 1.11111. 1.111.11 ..1...1. ..1.1..1 1..11.11 1.11111. +1...11.. ..1111.. ..1.1..1 111.1.1. .1.1111. 11.111.1 ..1111.. ..1.11.1 ..111.1. ...1111. 1...111. ..111.1. ..1.1..1 1...1.1. .111111. +11111111 ..1.111. ..1.11.. 11.11.1. 1111111. ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ +bits: 17, est: 1153, real: 1153, x: 0, y: 0 +1....... ........ ..1..... ........ ..1.1... ........ ..1.1.1. ........ ...1111. 1....... ...1...1 ..1..... ....1... ..1.1... ......11 +.1111.1. .......1 .1.1111. 1....... 1.....1. ..1..... ..1.111. ..1.1... ....1111 11..1.1. .....1.1 ..11111. 1......1 1.11..11 ..1..... +1...1.1. ..1.1... ..1.1.11 ...11.1. ....11.1 ..11111. 1....1.. .....1.. ..1....1 ..11.1.. ..1.1... .1.11.11 .11.1.1. ...11.1. 11.1111. +1....111 11.1.1.1 ..1...1. .1...1.. ..1.1... 1.1..11. 1.111.1. ..1.1111 1..1111. 1...11.1 1....11. ..1...11 11.1..1. ..1.1..1 ...1..11 +....1.1. .1..11.. 1111111. 1..1.1.1 .111.111 ..1..1.1 1111.11. ..1.1..1 1.1..11. .1.11.1. .111.1.. .111111. 1.1..... ....1... ..1.1... +11..1... ..1.1.1. .11..11. 1.1.1.1. 1.1..111 1..1111. 1.1.11.1 1..11..1 ..1.11.. .11..... ..1.1.11 .1.11..1 11111.1. 111..111 11.1111. +1.11111. 1...1.1. ..11.... 11.1.11. ..1.11.. 1....11. .1..1.11 ..11.11. 1.11111. 11.1..11 ..111.11 ..11.11. .1....1. ..1.11.1 1111...1 +1..11.11 1..1.1.1 1.11111. 111.11.. ....11.. ..1111.. 1.1111.. ..1.1111 1.1....1 111.1.1. .....11. .1.1111. 1...1..1 .1.111.1 ..1..1.. +.1.111.. ..1.1..1 1..111.1 ..111.1. 1...1.1. ...1111. 1.1.1.11 1...111. ..1.11.1 ..111.1. ..1.1.11 111.1..1 1...1.11 ..1...1. .111111. +11.1..1. 11111111 ..11.111 .11.111. ..1.111. 1...11.. 11.11.11 11.1.... 1111111. ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ +bitvec ok. -- 2.7.3

3 2