OpenBSC April 2015

openbsc@lists.osmocom.org

6 participants
18 discussions

[PATCH 1/9] gsup: Document passing MSISDN as part of the response

by Holger Freyther

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> --- openbsc/doc/sgsn-remote-protocol.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/openbsc/doc/sgsn-remote-protocol.txt b/openbsc/doc/sgsn-remote-protocol.txt index 3369d19..88a384e 100644 --- a/openbsc/doc/sgsn-remote-protocol.txt +++ b/openbsc/doc/sgsn-remote-protocol.txt @@ -121,6 +121,7 @@ Network peer -> SGSN 01 IMSI 4.2.9 M TLV 2-10 04 PDP info complete 4.2.8 O TLV 2 05 PDP info 4.2.3 1-10 TLV + 13 MSISDN 4.2.10 O TLV 0-9 If the PDP info complete IE is present, the old PDP info list shall be cleared. @@ -357,6 +358,7 @@ IEI that shall be used for the encoding. | 0x10 PDP context id big endian int | | 0x11 PDP type 4.2.4 | | 0x12 APN 04.08, 10.5.6.1 | + | 0x13 MSISDN ISDN-AddressString/octet | | 0x20 RAND octet string | | 0x21 SRES octet string | | 0x22 Kc octet string | @@ -397,3 +399,24 @@ The IMSI is encoded like in octet 4-N of the Called Party BCD Number defined in Note 1) Either '1 1 1 1 | Number digit N' (N odd) or 'Number digit N | Number digit N-1' (N even), where N is the number of digits. + +4.2.10. ISDN-AddressString / MSISDN /Called Party BCD Number + + +MSISDN. ISDN-AddressString in GSM 09.02 and Called Party +BCD Number in GSM 04.08. + + 8 7 6 5 4 3 2 1 + +-----------------------------------------------------+ + | | IEI | octet 1 + +-----------------------------------------------------+ + | Length of IE contents | octet 2 + +-----------------------------------------------------+ + | ext | Type of num | Numbering plan | octet 2 + +-----------------------------------------------------+ + | Number digit 2 | Number digit 1 | octet 3 + +-----------------------------------------------------+ + | Number digit 4 | Number digit 3 | octet 4 + +-----------------------------------------------------+ + : : : + +-----------------------------------------------------+ -- 2.3.5

10 years, 2 months

OsmoBTS - OsmocomBB emulation project

by Dominiq T

Dear Osmcom, I am working on a project, where I am connecting OsmoBTS with OsmocomBB without hardware. I am trying to remove l1 on both sides and connect OsmoBTS with BB application via simple unix sockets. Based on the further recommendations, I am using osmobts-trx branch. Currently I am able to handle messages between BTS and TRX driver on clock and control ports, and on BB side I am in state that phone wants to connect into a cell (so its waiting for BCCH) . I am now trying to find a possible way how to handle messages on data port , between BTS – TRX ( TRX is removed, there is my application instead), and forward these messages to my customized BB l1 interface . The thing is that I need to send to BB phone (layer23) messages in structures from gsm_04_08.h (i.e. gsm48_system_information_type_3). I am not sure if I will be able to get needed from the messages coming on the data port 5702. I found, that PCU creates unix socket on “/tmp/pcu_bts” , but only in case sysmoBTS is in use (please correct me if I am wrong), so this will be not possible due compilation errors without HW. Here I found the gsm48_system_information_type_3 messages. So basically I need somehow to get this message structures on my custom l1 BB interface. Do you have any idea how to do this ? Any advice will be highly appreciated. Many thanks you for your attention :) Best regards, Dominik Tamaskovic.

10 years, 2 months

libosmo-abis/RSL queue and OS interaction

by Holger Hans Peter Freyther

Dear Pablo, Ciaby, from what I see we have the following OpenBSC/OS integration. * OpenBSC wants to send some RSL data and calls abis_rsl_sendmsg ** abis_rsl_sendmsg entails the msgb into a queue and informs the lower layer driver (ipa in our case) ** ipa sets the when to ~= BSC_FD_WRITE * code returns * OpenBSC runs select for all fds/timers.. * libosmocore dispatches fd's ** libosmo-abis/ipaccess.c will try to write a single message ** libosmo-abis/ipaccess.c will set the BSC_FD_WRITE again if the queue is not empty * Linux/TCP will run nagle to combine these messages * OpenBSC runs select for all fds/timers... .... The integration does work but appears to be a bit painful for busy and high latency links. E.g. OpenBSC starts timers when abis_rsl_sendmsg is invoked which might just be a little bit later. I wonder if there is a better way? For reading we could read until -EWOULDBLOCK but then this might not be too fair for the other parts of the software. For writing we might end up in the situation where a write only partially succeeds and we need to remember how much of the msgb to write next... So we would need to do ioctl's to check how much space is left in the send buffer Do you have ideas? comments? is it a non issue? is it something we can do better? Is there a TCP mode where a "write" either fully succeeds or fails with -ENOSPC or such? holger

10 years, 2 months

[PATCH 1/4] mncc: Select the codec similar to the modify handling

by Holger Freyther

From: Holger Hans Peter Freyther <holger(a)moiji-mobile.com> In case the default TCH/F codec is "EFR" and we do an early assignment from SDCCH to a TCH we would assign the TCH/H codec. This is because the lchan_type will be neither a TCH/H nor a TCH/F. At the same time the _gsm48_lchan_modify code to check for half vs. full-rate is the other way around. Align both. It is full-rate if it is not a TCH_H. This will have some other complications down the way (early assignment on cells with only TCH/H). So the mode should not depend on the _current_ channel but the kind of channel we want. --- openbsc/src/libmsc/mncc_builtin.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/libmsc/mncc_builtin.c b/openbsc/src/libmsc/mncc_builtin.c index a5a463b..5c3461b 100644 --- a/openbsc/src/libmsc/mncc_builtin.c +++ b/openbsc/src/libmsc/mncc_builtin.c @@ -69,7 +69,7 @@ static uint8_t determine_lchan_mode(struct gsm_mncc *setup) { /* FIXME: check codec capabilities of the phone */ - if (setup->lchan_type == GSM_LCHAN_TCH_F) + if (setup->lchan_type != GSM_LCHAN_TCH_H) return mncc_int.def_codec[0]; else return mncc_int.def_codec[1]; -- 2.1.4

10 years, 2 months

[PATCH 1/4] nat: Fix timeslot range in 'show bsc mgcp' VTY command

by Jacob Erlbeck

Currently the inner loop in show_bsc_mgcp iterates of the timeslot interval [0, 31]. Timeslot 0 is not valid, which causes mgcp_timeslot_to_endpoint to generate a corresponding warning and to return an invalid endp value. That value causes an out-of-bound read access, possibly hitting unallocated memory. This patch fixes the loop range by starting with timeslot 1. Note that this does not prevent mgcp_timeslot_to_endpoint from returning an invalid endpoint index when called with arguments not within its domain. Addresses: <000b> ../../include/openbsc/mgcp.h:250 Timeslot should not be 0 [...] vty=0xb4203db0, argc=1, argv=0xbfffebb0) at bsc_nat_vty.c:256 max = 1 con = 0xb4a004f0 i = 0 j = 0 [...] ==15700== ERROR: AddressSanitizer: heap-use-after-free on address 0xb520be4f at pc 0x8062a42 bp 0xbfffeb18 sp 0xbfffeb0c Sponsored-by: On-Waves ehf --- openbsc/src/osmo-bsc_nat/bsc_nat_vty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c b/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c index 5f4ad28..2b7db2e 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c @@ -250,7 +250,7 @@ DEFUN(show_bsc_mgcp, show_bsc_mgcp_cmd, "show bsc mgcp NR", vty_out(vty, "MGCP Status for %d%s", con->cfg->nr, VTY_NEWLINE); max = bsc_mgcp_nr_multiplexes(con->max_endpoints); for (i = 0; i < max; ++i) { - for (j = 0; j < 32; ++j) { + for (j = 1; j < 32; ++j) { endp = mgcp_timeslot_to_endpoint(i, j); vty_out(vty, " Endpoint 0x%x %s%s", endp, con->_endpoint_status[endp] == 0 -- 1.9.1

10 years, 2 months

[PATCH 1/2] msgb: Check the return value of msgb_alloc (Coverity)

by Jacob Erlbeck

In some places, the return value of msgb_alloc/msgb_alloc_headroom is not checked before it is dereferenced. This commit adds NULL checks to return with -ENOMEM from the calling functions if the alloc function has failed. Fixes: Coverity CID 1249692, 1293376 Sponsored-by: On-Waves ehf --- src/gsm/lapdm.c | 3 +++ src/sim/reader.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/src/gsm/lapdm.c b/src/gsm/lapdm.c index 698f850..54d3a0b 100644 --- a/src/gsm/lapdm.c +++ b/src/gsm/lapdm.c @@ -675,6 +675,9 @@ static int l2_ph_rach_ind(struct lapdm_entity *le, uint8_t ra, uint32_t fn, uint struct gsm_time gt; struct msgb *msg = msgb_alloc_headroom(512, 64, "RSL CHAN RQD"); + if (!msg) + return -ENOMEM; + msg->l2h = msgb_push(msg, sizeof(*ch)); ch = (struct abis_rsl_cchan_hdr *)msg->l2h; rsl_init_cchan_hdr(ch, RSL_MT_CHAN_RQD); diff --git a/src/sim/reader.c b/src/sim/reader.c index 160f175..e7169b5 100644 --- a/src/sim/reader.c +++ b/src/sim/reader.c @@ -58,6 +58,9 @@ static int transceive_apdu_t0(struct osim_card_hdl *st, struct msgb *amsg) uint16_t sw; int rc, num_resp = 0; + if (!tmsg) + return -ENOMEM; + /* create TPDU header from APDU header */ tpduh = (struct osim_apdu_cmd_hdr *) msgb_put(tmsg, sizeof(*tpduh)); memcpy(tpduh, msgb_apdu_h(amsg), sizeof(*tpduh)); -- 1.9.1

10 years, 2 months

[PATCH 1/3] bssgp: Always expect dup != NULL in bssgp_tx_dl_ud (Coverity)

by Jacob Erlbeck

Currently the implementation of bssgp_tx_dl_ud conditionally adds some optional IE if dup != NULL. Later on is dereferences dup to access qos_profile and fc, but this without checking dup in advance. This may lead to an segmentation violation fault. This commit changes the value range of the function to only accept dup != NULL. An assertion will fail otherwise. All other explicit checks for non-NULL are removed. Fixes: Coverity CID 1040673 Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 49 ++++++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 25 deletions(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index 2f23290..a3fd6aa 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -1092,6 +1092,8 @@ int bssgp_tx_dl_ud(struct msgb *msg, uint16_t pdu_lifetime, uint16_t _pdu_lifetime = htons(pdu_lifetime); /* centi-seconds */ uint16_t drx_params; + OSMO_ASSERT(dup != NULL); + /* Identifiers from UP: TLLI, BVCI, NSEI (all in msgb->cb) */ if (bvci <= BVCI_PTM ) { LOGP(DBSSGP, LOGL_ERROR, "Cannot send DL-UD to BVCI %u\n", @@ -1124,35 +1126,32 @@ int bssgp_tx_dl_ud(struct msgb *msg, uint16_t pdu_lifetime, /* FIXME: optional elements: Alignment, UTRAN CCO, LSA, PFI */ - if (dup) { - /* Old TLLI to help BSS map from old->new */ - if (dup->tlli) { - uint32_t tlli = htonl(*dup->tlli); - msgb_tvlv_push(msg, BSSGP_IE_TLLI, 4, (uint8_t *) &tlli); - } - - /* IMSI */ - if (dup->imsi && strlen(dup->imsi)) { - uint8_t mi[10]; - int imsi_len = gsm48_generate_mid_from_imsi(mi, dup->imsi); - if (imsi_len > 2) - msgb_tvlv_push(msg, BSSGP_IE_IMSI, - imsi_len-2, mi+2); - } + /* Old TLLI to help BSS map from old->new */ + if (dup->tlli) { + uint32_t tlli = htonl(*dup->tlli); + msgb_tvlv_push(msg, BSSGP_IE_TLLI, 4, (uint8_t *) &tlli); + } - /* DRX parameters */ - drx_params = htons(dup->drx_parms); - msgb_tvlv_push(msg, BSSGP_IE_DRX_PARAMS, 2, - (uint8_t *) &drx_params); + /* IMSI */ + if (dup->imsi && strlen(dup->imsi)) { + uint8_t mi[10]; + int imsi_len = gsm48_generate_mid_from_imsi(mi, dup->imsi); + if (imsi_len > 2) + msgb_tvlv_push(msg, BSSGP_IE_IMSI, + imsi_len-2, mi+2); + } - /* FIXME: Priority */ + /* DRX parameters */ + drx_params = htons(dup->drx_parms); + msgb_tvlv_push(msg, BSSGP_IE_DRX_PARAMS, 2, + (uint8_t *) &drx_params); - /* MS Radio Access Capability */ - if (dup->ms_ra_cap.len) - msgb_tvlv_push(msg, BSSGP_IE_MS_RADIO_ACCESS_CAP, - dup->ms_ra_cap.len, dup->ms_ra_cap.v); + /* FIXME: Priority */ - } + /* MS Radio Access Capability */ + if (dup->ms_ra_cap.len) + msgb_tvlv_push(msg, BSSGP_IE_MS_RADIO_ACCESS_CAP, + dup->ms_ra_cap.len, dup->ms_ra_cap.v); /* prepend the pdu lifetime */ msgb_tvlv_push(msg, BSSGP_IE_PDU_LIFETIME, 2, (uint8_t *)&_pdu_lifetime); -- 1.9.1

10 years, 2 months

recurring issue with OpenBSC

by Ciaby

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi! First a small update: we finally decided to _not_ use token mode, as it confuses a lot of phones, after receiving the token message the SIM goes into an error state and the only way to recover is to reboot the phone. Now we just read the IMSI straight from the SIM (using the card python library, just like osmo-sim-auth does) and register them. Now, the issue we see is that 1-2 users every day reach a point where they can make phone calls and send messages, but they can't receive neither of them. Sometimes the problem can be fixed by running: > subscriber extension <EXT> clear-requests but this only work when there are pending requests. In other cases, the phone has to be rebooted. Did anyone encounter the same issue? Cheers Ciaby -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUef1WAAoJEPU83OtbD4fQ69kQAI7peg30lHwbDPMXnTX80gUu 0dGsiK2iB5oWZ6Ohbs3W+/+xVoMseuG1di6Rk0XT9buN2IOR5fMfAs3INQ2EuAlV qz1RRn5Ux8uV0RJWyAJoSt7eFh3gbnDgsJ+x8SXEHQRw4rYHG2P+HXyEtncW6A6y L8/oPeIxH/LlP/55MP3KUY5BnQmN658LnJU9AFSwPkpjn2f/dj4o6mUdWo8haTTQ UWPWEdhQoeXPBqHsn2cKamT13SmiepMYAGuDEJci9LCS+J8vd70ukAP/oa1L6u1w +3+RbcNvC9fwAKDLU01b/cu630v6/mhk0lxWNlIz/kNL1aHPZe8QhP5sM4SuLtzj UaeHLxp4u2Pb7N31b3qtRA4jgl+5YFla5376F3d00jPSfZpmFggFgdRB2qWhF1m8 WucfzLc41dV1AVTdL90ISSRt1LZ/fLHBea8kgUxK+KrhBO7U7AV3PXk9of4EAf7y VKMX3KZWwtEKhpi0v3PihgW8bS/RaG3zEmsr30QXzXVaZknCfjGi8OOOB0JaHY48 o3g40YpzeyEq1gOyKKfBmtf1qk4GgLyPKfMUoTvXE2oNHmrg3ZlJldABKNzR9qz3 5hsHJ6/QGsBST1E3dphI0Zb6ubLnFwqBl02GyeJELLbtPCLPQMDicx03cqT4BjO3 vzDcPdIWg1sfSomYKMK9 =Zw4T -----END PGP SIGNATURE-----

10 years, 2 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC April 2015