February 2014 - OpenBSC - lists.osmocom.org

GPRS - local and foreign TLLIs
by Luca Melette 04 Feb '26

04 Feb '26

Hello everybody, after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell. Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0. With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals. The mentioned code is contained in gprs_llc.c, involving LL Entity functions and gprs_llc_tx_ui(). /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; } The TX function uses the previously received TLLI to lookup for the LLE. The lle_by_tlli_sapi() performs the search, but preliminary it applies a foreign2local TLLI conversion to ensure to have a local one. Since no valid entry for the searched TLLI is found, a new one is created. And the problem is here. The new entry has the foreign TLLI. Next time the lookup fails again, and a new entry is created. This way, the counter N(U) is always reset, and the mobile do not recognize the message sequence and no attach is possible. My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but... What is the sense of the conversion? Should the TLLI be always stored as a local one? Can this problem be solved with another foreign2local while allocating new entries? Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way. Hope somebody can answer :) Thanks. Cheers, LM

5 6

Pysim error: SW match failed
by Martin Nagy 16 Aug '25

16 Aug '25

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

3 3

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

[libosmocore PATCH] src/socket: Added support for using socket unix
by Alvaro Neira 24 Mar '14

24 Mar '14

From: Álvaro Neira Ayuso <anayuso(a)sysmocom.de> Added some function for adding socket unix support. Signed-off-by: Alvaro Neira Ayuso <anayuso(a)sysmocom.de> --- include/osmocom/core/socket.h | 6 +++ src/socket.c | 92 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 98 insertions(+) diff --git a/include/osmocom/core/socket.h b/include/osmocom/core/socket.h index f15a03a..cb1b7a8 100644 --- a/include/osmocom/core/socket.h +++ b/include/osmocom/core/socket.h @@ -30,6 +30,12 @@ int osmo_sock_init_sa(struct sockaddr *ss, uint16_t type, int osmo_sockaddr_is_local(struct sockaddr *addr, unsigned int addrlen); +int osmo_sock_unix_init(uint16_t type, uint8_t proto, + const char *socket_path, unsigned int flags); + +int osmo_sock_unix_init_ofd(struct osmo_fd *ofd, uint16_t type, uint8_t proto, + const char *socket_path, unsigned int flags); + /*! @} */ #endif /* _OSMOCORE_SOCKET_H */ diff --git a/src/socket.c b/src/socket.c index 6ff00f0..6d4eddf 100644 --- a/src/socket.c +++ b/src/socket.c @@ -17,6 +17,7 @@ #include <sys/ioctl.h> #include <sys/socket.h> #include <sys/types.h> +#include <sys/un.h> #include <netinet/in.h> @@ -257,6 +258,97 @@ int osmo_sockaddr_is_local(struct sockaddr *addr, unsigned int addrlen) return 0; } +/*! \brief Initialize a socket unix(including bind/connect) + * \param[in] type Socket type like SOCK_DGRAM, SOCK_STREAM + * \param[in] proto Protocol like IPPROTO_TCP, IPPROTO_UDP + * \param[in] socket_path path to identify the socket + * \param[in] flags flags like \ref OSMO_SOCK_F_CONNECT + * + * This function creates a new socket unix, \a + * type and \a proto and optionally binds or connects it, depending on + * the value of \a flags parameter. + */ +int osmo_sock_unix_init(uint16_t type, uint8_t proto, + const char *socket_path, unsigned int flags) +{ + struct sockaddr_un addr; + int sfd, rc, on = 1; + + if ((flags & (OSMO_SOCK_F_BIND | OSMO_SOCK_F_CONNECT)) == + (OSMO_SOCK_F_BIND | OSMO_SOCK_F_CONNECT)) + return -EINVAL; + + memset(&addr, 0, sizeof(addr)); + addr.sun_family = AF_UNIX; + strncpy(addr.sun_path, socket_path, sizeof(addr.sun_path)-1); + + if (type == SOCK_RAW) { + sfd = socket(AF_UNIX, SOCK_DGRAM, 0); + } else { + sfd = socket(AF_UNIX, type, proto); + } + + if (sfd < 0) + return -1; + + if (flags & OSMO_SOCK_F_NONBLOCK) { + if (ioctl(sfd, FIONBIO, (unsigned char *)&on) < 0) { + perror("cannot set this socket unblocking"); + close(sfd); + return -EINVAL; + } + } + if (flags & OSMO_SOCK_F_CONNECT) { + rc = connect(sfd, (struct sockaddr*)&addr, sizeof(addr)); + if (rc < 0) { + close(sfd); + return -1; + } + } else { + rc = bind(sfd, (struct sockaddr*)&addr, sizeof(addr)); + if (rc < 0) { + close(sfd); + return -1; + } + } + + if (flags & OSMO_SOCK_F_BIND) + listen(sfd, 10); + + return sfd; +} + +/*! \brief Initialize a socket unix and fill \ref osmo_fd + * \param[out] ofd file descriptor (will be filled in) + * \param[in] type Socket type like SOCK_DGRAM, SOCK_STREAM + * \param[in] proto Protocol like IPPROTO_TCP, IPPROTO_UDP + * \param[in] socket_path path to identify the socket + * \param[in] flags flags like \ref OSMO_SOCK_F_CONNECT + * + * This function creates (and optionall binds/connects) a socket using + * \ref osmo_sock_unix_init, but also fills the \a ofd structure. + */ +int osmo_sock_unix_init_ofd(struct osmo_fd *ofd, uint16_t type, uint8_t proto, + const char *socket_path, unsigned int flags) +{ + int sfd, rc; + + sfd = osmo_sock_unix_init(type, proto, socket_path, flags); + if (sfd < 0) + return sfd; + + ofd->fd = sfd; + ofd->when = BSC_FD_READ; + + rc = osmo_fd_register(ofd); + if (rc < 0) { + close(sfd); + return rc; + } + + return sfd; +} + #endif /* HAVE_SYS_SOCKET_H */ /*! @} */

3 3

[PATCH 1/9] Complete definitions for all speech traffic frames at MNCC interface
by Andreas Eversberg 11 Mar '14

11 Mar '14

The new definitions are: half rate and AMR Change of definition name for bad frame, because it applies to all types of traffic, not only TCH/F. Increase MNCC interface version to 4. --- openbsc/include/openbsc/mncc.h | 6 ++++-- openbsc/src/libmsc/mncc.c | 6 +++++- openbsc/src/libtrau/trau_mux.c | 2 +- openbsc/tests/trau/trau_test.c | 2 +- 4 files changed, 11 insertions(+), 5 deletions(-) diff --git a/openbsc/include/openbsc/mncc.h b/openbsc/include/openbsc/mncc.h index ffc247b..c61f6b8 100644 --- a/openbsc/include/openbsc/mncc.h +++ b/openbsc/include/openbsc/mncc.h @@ -95,7 +95,9 @@ struct gsm_call { #define GSM_TCHF_FRAME 0x0300 #define GSM_TCHF_FRAME_EFR 0x0301 -#define GSM_TCHF_BAD_FRAME 0x03ff +#define GSM_TCHH_FRAME 0x0302 +#define GSM_TCH_FRAME_AMR 0x0303 +#define GSM_BAD_FRAME 0x03ff #define MNCC_SOCKET_HELLO 0x0400 @@ -161,7 +163,7 @@ struct gsm_data_frame { unsigned char data[0]; }; -#define MNCC_SOCK_VERSION 2 +#define MNCC_SOCK_VERSION 4 struct gsm_mncc_hello { uint32_t msg_type; uint32_t version; diff --git a/openbsc/src/libmsc/mncc.c b/openbsc/src/libmsc/mncc.c index b484772..73db5f0 100644 --- a/openbsc/src/libmsc/mncc.c +++ b/openbsc/src/libmsc/mncc.c @@ -84,7 +84,11 @@ static struct mncc_names { {"MNCC_FRAME_DROP", 0x0202}, {"MNCC_LCHAN_MODIFY", 0x0203}, - {"GSM_TCH_FRAME", 0x0300}, + {"GSM_TCHF_FRAME", 0x0300}, + {"GSM_TCHF_FRAME_EFR", 0x0301}, + {"GSM_TCHH_FRAME", 0x0302}, + {"GSM_TCH_FRAME_AMR", 0x0303}, + {"GSM_BAD_FRAME", 0x03ff}, {NULL, 0} }; diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c index 7b9bac0..fd1895f 100644 --- a/openbsc/src/libtrau/trau_mux.c +++ b/openbsc/src/libtrau/trau_mux.c @@ -314,7 +314,7 @@ struct msgb *trau_decode_efr(uint32_t callref, return msg; bad_frame: - frame->msg_type = GSM_TCHF_BAD_FRAME; + frame->msg_type = GSM_BAD_FRAME; return msg; } diff --git a/openbsc/tests/trau/trau_test.c b/openbsc/tests/trau/trau_test.c index f8a48db..b95f1e8 100644 --- a/openbsc/tests/trau/trau_test.c +++ b/openbsc/tests/trau/trau_test.c @@ -57,7 +57,7 @@ void test_trau_fr_efr(unsigned char *data) msg = trau_decode_efr(1, &tf); OSMO_ASSERT(msg != NULL); frame = (struct gsm_data_frame *)msg->data; - OSMO_ASSERT(frame->msg_type == GSM_TCHF_BAD_FRAME); + OSMO_ASSERT(frame->msg_type == GSM_BAD_FRAME); msgb_free(msg); } -- 1.8.1.5

4 31

[PATCH] sms_queue, smpp: Refactor MO SUBMIT code to make further changes easier.
by Alexander Chemeris 09 Mar '14

09 Mar '14

This is required to implement normal prefix/regexp routing in addition to the current "if unroutable" model. --- openbsc/src/libmsc/gsm_04_11.c | 63 +++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 26 deletions(-) diff --git a/openbsc/src/libmsc/gsm_04_11.c b/openbsc/src/libmsc/gsm_04_11.c index e554b74..7e8ede8 100644 --- a/openbsc/src/libmsc/gsm_04_11.c +++ b/openbsc/src/libmsc/gsm_04_11.c @@ -279,6 +279,39 @@ static int gsm340_gen_tpdu(struct msgb *msg, struct gsm_sms *sms) return msg->len - old_msg_len; } +static int sms_queue_try_deliver(struct gsm_subscriber_connection *conn, + struct msgb *msg, struct gsm_sms *gsms) +{ + /* determine gsms->receiver based on dialled number */ + gsms->receiver = subscr_get_by_extension(conn->bts->network, gsms->dst.addr); + if (!gsms->receiver) { + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; + goto out; + } + + switch (sms_mti) { + case GSM340_SMS_SUBMIT_MS2SC: + /* MS is submitting a SMS */ + rc = gsm340_rx_sms_submit(msg, gsms); + break; + case GSM340_SMS_COMMAND_MS2SC: + case GSM340_SMS_DELIVER_REP_MS2SC: + LOGP(DLSMS, LOGL_NOTICE, "Unimplemented MTI 0x%02x\n", sms_mti); + rc = GSM411_RP_CAUSE_IE_NOTEXIST; + break; + default: + LOGP(DLSMS, LOGL_NOTICE, "Undefined MTI 0x%02x\n", sms_mti); + rc = GSM411_RP_CAUSE_IE_NOTEXIST; + break; + } + + if (!rc && !gsms->receiver) + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; + +out: + return rc; +} + /* process an incoming TPDU (called from RP-DATA) * return value > 0: RP CAUSE for ERROR; < 0: silent error; 0 = success */ static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *msg) @@ -393,44 +426,22 @@ static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *m /* FIXME: This looks very wrong */ send_signal(0, NULL, gsms, 0); - /* determine gsms->receiver based on dialled number */ - gsms->receiver = subscr_get_by_extension(conn->bts->network, gsms->dst.addr); - if (!gsms->receiver) { + rc = sms_queue_try_deliver(conn, msg, gsms); + if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED) { #ifdef BUILD_SMPP rc = smpp_try_deliver(gsms, conn); - if (rc == 1) { - rc = 1; /* cause 1: unknown subscriber */ + if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED) { osmo_counter_inc(conn->bts->network->stats.sms.no_receiver); } else if (rc < 0) { - rc = 21; /* cause 21: short message transfer rejected */ + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; /* FIXME: handle the error somehow? */ } #else - rc = 1; /* cause 1: unknown subscriber */ osmo_counter_inc(conn->bts->network->stats.sms.no_receiver); #endif goto out; } - switch (sms_mti) { - case GSM340_SMS_SUBMIT_MS2SC: - /* MS is submitting a SMS */ - rc = gsm340_rx_sms_submit(msg, gsms); - break; - case GSM340_SMS_COMMAND_MS2SC: - case GSM340_SMS_DELIVER_REP_MS2SC: - LOGP(DLSMS, LOGL_NOTICE, "Unimplemented MTI 0x%02x\n", sms_mti); - rc = GSM411_RP_CAUSE_IE_NOTEXIST; - break; - default: - LOGP(DLSMS, LOGL_NOTICE, "Undefined MTI 0x%02x\n", sms_mti); - rc = GSM411_RP_CAUSE_IE_NOTEXIST; - break; - } - - if (!rc && !gsms->receiver) - rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; - out: sms_free(gsms); -- 1.7.9.5

1 1

[PATCH] Use generic osmocom auth api
by ☎ 07 Mar '14

07 Mar '14

Hi. Attached is a small patch which replaces direct call to comp128 from libosmocore to auth api call. This will help to remove comp128 from libosmocore public api and to use other auth functions in openbsc in future. -- best regards, Max, http://fairwaves.ru

4 7

[PATCH 1/2] msgb: Add msgb_hexdump() function
by Jacob Erlbeck 04 Mar '14

04 Mar '14

This function works like osmo_hexdump() and return a static buffer containing hex bytes along with markes for the layers. Sponsored-by: On-Waves ehf --- include/osmocom/core/msgb.h | 1 + src/msgb.c | 48 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+) diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h index c4be0c3..33e8081 100644 --- a/include/osmocom/core/msgb.h +++ b/include/osmocom/core/msgb.h @@ -73,6 +73,7 @@ extern void msgb_enqueue(struct llist_head *queue, struct msgb *msg); extern struct msgb *msgb_dequeue(struct llist_head *queue); extern void msgb_reset(struct msgb *m); uint16_t msgb_length(const struct msgb *msg); +extern const char *msgb_hexdump(const struct msgb *msg); #ifdef MSGB_DEBUG #include <osmocom/core/panic.h> diff --git a/src/msgb.c b/src/msgb.c index 359a545..98c7d79 100644 --- a/src/msgb.c +++ b/src/msgb.c @@ -153,4 +153,52 @@ void msgb_set_talloc_ctx(void *ctx) tall_msgb_ctx = ctx; } +/*! \brief Return (static) buffer containing a hexdump of the msg + * \param[in] msg message buffer + * \returns a pointer to a static char array + */ +const char *msgb_hexdump(const struct msgb *msg) +{ + static char buf[4100]; + int buf_offs = 0; + int nchars; + const unsigned char *start = msg->data; + const unsigned char *lxhs[4]; + int i; + + lxhs[0] = msg->l1h; + lxhs[1] = msg->l2h; + lxhs[2] = msg->l3h; + lxhs[3] = msg->l4h; + + for (i = 0; i < ARRAY_SIZE(lxhs); i++) { + if (lxhs[i]) { + if (lxhs[i] < msg->data) + goto out_of_range; + if (lxhs[i] > msg->tail) + goto out_of_range; + nchars = snprintf(buf + buf_offs, sizeof(buf) - buf_offs, + "%s[L%d]> ", + osmo_hexdump(start, lxhs[i] - start), + i+1); + if (nchars < 0 || nchars + buf_offs >= sizeof(buf)) + return "ERROR"; + + buf_offs += nchars; + start = lxhs[i]; + } + } + nchars = snprintf(buf + buf_offs, sizeof(buf) - buf_offs, + "%s", osmo_hexdump(start, msg->tail - start)); + if (nchars < 0 || nchars + buf_offs >= sizeof(buf)) + return "ERROR"; + + return buf; + +out_of_range: + nchars = snprintf(buf, sizeof(buf) - buf_offs, + "!!! L%d out of range", i+1); + return buf; +} + /*! @} */ -- 1.7.9.5

2 12

[PATCH 1/8] agch: Recalculate length limit of AGCH queue
by Jacob Erlbeck 03 Mar '14

03 Mar '14

This patch adds a function bts_update_agch_max_queue_length() to compute a limit of the AGCH queue. This is based on the idea, that the AGCH queue has a limited drain rate and that CHANNEL REQUESTs must be answered within a certain time frame, given by the minimum value of T3126 (see GSM 04.08). When the AGCH queue reaches that limit, the last message would be delivered in time if there were no other delays involved (which is not the case). The calculation is based on the ratio of the number RACH slots and CCCH blocks per time: Lmax = (T + 2*S) / R_RACH * R_CCCH where T3126_min = (T + 2*S) / R_RACH R_RACH is the RACH slot rate (e.g. RACHs per multiframe) R_CCCH is the CCCH block rate (same time base like R_RACH) The value depends control_channel_desc.ccch_conf and rach_control.tx_integer (both from SYSINFO_TYPE_3) and should therefore by called at least each time after one of these is changed. For this reason, a signal callback is registered under SS_GLOBAL/S_NEW_SYSINFO which invokes bts_update_agch_max_queue_length(). Based-On: "bts: Calculate length of agch queue" by Ivan Kluchnikov <kluchnikovi(a)gmail.com> --- include/osmo-bts/bts.h | 1 + include/osmo-bts/gsm_data.h | 1 + src/common/bts.c | 86 ++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 87 insertions(+), 1 deletion(-) diff --git a/include/osmo-bts/bts.h b/include/osmo-bts/bts.h index 49ef617..ec061e8 100644 --- a/include/osmo-bts/bts.h +++ b/include/osmo-bts/bts.h @@ -26,6 +26,7 @@ void bts_setup_slot(struct gsm_bts_trx_ts *slot, uint8_t comb); int bts_agch_enqueue(struct gsm_bts *bts, struct msgb *msg); struct msgb *bts_agch_dequeue(struct gsm_bts *bts); +void bts_update_agch_max_queue_length(struct gsm_bts *bts); int bts_ccch_copy_msg(struct gsm_bts *bts, uint8_t *out_buf, struct gsm_time *gt, int is_ag_res); diff --git a/include/osmo-bts/gsm_data.h b/include/osmo-bts/gsm_data.h index aee56a9..ea3fa5e 100644 --- a/include/osmo-bts/gsm_data.h +++ b/include/osmo-bts/gsm_data.h @@ -50,6 +50,7 @@ struct gsm_bts_role_bts { uint8_t max_ta; struct llist_head agch_queue; int agch_queue_length; + int agch_max_queue_length; struct paging_state *paging_state; char *bsc_oml_host; unsigned int rtp_jitter_buf_ms; diff --git a/src/common/bts.c b/src/common/bts.c index 7bbf587..2a6c1bd 100644 --- a/src/common/bts.c +++ b/src/common/bts.c @@ -42,6 +42,7 @@ #include <osmo-bts/bts_model.h> #include <osmo-bts/rsl.h> #include <osmo-bts/oml.h> +#include <osmo-bts/signal.h> struct gsm_network bts_gsmnet = { @@ -51,11 +52,32 @@ struct gsm_network bts_gsmnet = { void *tall_bts_ctx; +/* Table 3.1 TS 04.08: Values of parameter S */ +static const uint8_t tx_integer[] = { + 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 16, 20, 25, 32, 50, +}; + +static const uint8_t s_values[][2] = { + { 55, 41 }, { 76, 52 }, { 109, 58 }, { 163, 86 }, { 217, 115 }, +}; + +static int bts_signal_cbfn(unsigned int subsys, unsigned int signal, + void *hdlr_data, void *signal_data) +{ + if (subsys == SS_GLOBAL && signal == S_NEW_SYSINFO) { + struct gsm_bts *bts = signal_data; + + bts_update_agch_max_queue_length(bts); + } + return 0; +} + int bts_init(struct gsm_bts *bts) { struct gsm_bts_role_bts *btsb; struct gsm_bts_trx *trx; int rc; + static int initialized = 0; /* add to list of BTSs */ llist_add_tail(&bts->list, &bts_gsmnet.bts_list); @@ -110,6 +132,11 @@ int bts_init(struct gsm_bts *bts) bts_gsmnet.num_bts++; + if (!initialized) { + osmo_signal_register_handler(SS_GLOBAL, bts_signal_cbfn, NULL); + initialized = 1; + } + return rc; } @@ -209,11 +236,68 @@ int lchan_init_lapdm(struct gsm_lchan *lchan) return 0; } +#define CCCH_RACH_RATIO_COMBINED256 (256*1/9) +#define CCCH_RACH_RATIO_SEPARATE256 (256*10/55) + +void bts_update_agch_max_queue_length(struct gsm_bts *bts) +{ + struct gsm_bts_role_bts *btsb = bts_role_bts(bts); + struct gsm48_system_information_type_3 *si3; + int T, S, ccch_rach_ratio256, i; + int T_group = 0; + int ccch_comb = 0; + int old_max_length = btsb->agch_max_queue_length; + + if (!(bts->si_valid & (1<<SYSINFO_TYPE_3))) + return; + + si3 = GSM_BTS_SI(bts, SYSINFO_TYPE_3); + + if (si3->control_channel_desc.ccch_conf == 1) + ccch_comb = 1; + + /* + * The calculation is based on the ratio of the number RACH slots and + * CCCH blocks per time: + * Lmax = (T + 2*S) / R_RACH * R_CCCH + * where + * T3126_min = (T + 2*S) / R_RACH, as defined in GSM 04.08, 11.1.1 + * R_RACH is the RACH slot rate (e.g. RACHs per multiframe) + * R_CCCH is the CCCH block rate (same time base like R_RACH) + * S and T are defined in GSM 04.08, 3.3.1.1.2 + * The ratio is mainly influenced by the downlink only channels + * (BCCH, FCCH, SCH, CBCH) that can not used for CCCH. + * An estimation with an error of < 10% is used: + * ~ 1/9 if CCCH is combined with SDCCH, and + * ~ 1/5.5 otherwise. + */ + ccch_rach_ratio256 = ccch_comb ? + CCCH_RACH_RATIO_COMBINED256 : + CCCH_RACH_RATIO_SEPARATE256; + + T = si3->rach_control.tx_integer; + for (i = 0; i < 15; i++) { + if (tx_integer[i] == T) { + T_group = i % 5; + break; + } + } + S = s_values[T_group][ccch_comb]; + + btsb->agch_max_queue_length = (T + 2 * S) * ccch_rach_ratio256 / 256; + + if (btsb->agch_max_queue_length != old_max_length) + LOGP(DRSL, LOGL_INFO, "Updated AGCH max queue length to %d, " + "T = %d, S = %d, CCCH/RACH = %d%%, AG_BLK_RES = %d\n", + btsb->agch_max_queue_length, + T, S, ccch_rach_ratio256 * 100 / 256, + si3->control_channel_desc.bs_ag_blks_res); +} + int bts_agch_enqueue(struct gsm_bts *bts, struct msgb *msg) { struct gsm_bts_role_bts *btsb = bts_role_bts(bts); - /* FIXME: implement max queue length */ msgb_enqueue(&btsb->agch_queue, msg); btsb->agch_queue_length++; -- 1.7.9.5

5 18

[osmo-bts PATCH 1/3] src/misc/sysmobts_misc: Fixed wrong TEMP_PATH
by Alvaro Neira 27 Feb '14

27 Feb '14

From: Álvaro Neira Ayuso <anayuso(a)sysmocom.de> Before, this patch the program try to catch the info of the temperature sensor in a wrong ubication file. Signed-off-by: Alvaro Neira Ayuso <anayuso(a)sysmocom.de> --- src/osmo-bts-sysmo/misc/sysmobts_misc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/osmo-bts-sysmo/misc/sysmobts_misc.c b/src/osmo-bts-sysmo/misc/sysmobts_misc.c index 74414d0..c043045 100644 --- a/src/osmo-bts-sysmo/misc/sysmobts_misc.c +++ b/src/osmo-bts-sysmo/misc/sysmobts_misc.c @@ -45,7 +45,7 @@ * Temperature handling *********************************************************************/ -#define TEMP_PATH "/sys/class/hwmon/hwmon0/device%u_%s" +#define TEMP_PATH "/sys/class/hwmon/hwmon0/device/temp%u_%s" static const char *temp_type_str[_NUM_TEMP_TYPES] = { [SYSMOBTS_TEMP_INPUT] = "input",

1 2

TOMORROW: Osmocom Berlin User Group meeting
by dexter 25 Feb '14

25 Feb '14

Hi All. It's time Again! This is the announcement for the next Osmocom Berlin meeting. Tomorrow, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. I am looking forward to see you there! regards. Philipp

1 0

[PATCH] db: use WAL journaling mode for higher concurrency
by Alexey Shamrin 22 Feb '14

22 Feb '14

SQLite uses DELETE journaling mode by default. It became a problem on a real-world, actively used network (several hundred subscribers, several thousands SMS per day). Some location updates and SMS delivery marks were not getting written because database file was locked: 2013-12-13_07:26:10.10665 <0002> gsm_subscriber.c:362 Subscriber 334020422525672 ATTACHED LAC=3 2013-12-13_07:26:10.10668 <000d> db.c:170 DBI: 5: database is locked 2013-12-13_07:26:10.10865 <000d> db.c:969 Failed to update Subscriber (by IMSI). Switching to WAL mode fixed the problem. WAL journaling mode is persistent; it stays in effect after closing and reopening the database. WAL mode database requires SQLite >= 3.7.0. All credit belongs Ivan Kluchnikov who diagnosed and fixed this issue. --- openbsc/src/libmsc/db.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/openbsc/src/libmsc/db.c b/openbsc/src/libmsc/db.c index e720c78..3a989d4 100644 --- a/openbsc/src/libmsc/db.c +++ b/openbsc/src/libmsc/db.c @@ -232,11 +232,18 @@ static int db_configure(void) dbi_result result; result = dbi_conn_query(conn, + "PRAGMA journal_mode = WAL"); + if (!result) + LOGP(DDB, LOGL_NOTICE, "Warning: failed to set journal_mode = WAL.\n"); + else + dbi_result_free(result); + + result = dbi_conn_query(conn, "PRAGMA synchronous = FULL"); if (!result) return -EINVAL; - dbi_result_free(result); + return 0; } -- 1.7.7.5 (Apple Git-26)

4 8

[PATCH 1/5] bts/vty: Use new vty_install_default() function, adjust prompts
by Jacob Erlbeck 21 Feb '14

21 Feb '14

This patch removes the local 'end' and 'exit' implementations (which aren't used anyway) and uses the generic ones provided by libosmocore instead, which are enabled automatically when vty_install_default() is used. The prompt strings are modified to match those in libosmocore/openbsc. Ticket: OW#952 Sponsored-by: On-Waves ehf --- src/common/vty.c | 39 ++++----------------------------------- 1 file changed, 4 insertions(+), 35 deletions(-) diff --git a/src/common/vty.c b/src/common/vty.c index 5eddc8d..d818f3f 100644 --- a/src/common/vty.c +++ b/src/common/vty.c @@ -71,37 +71,6 @@ int bts_vty_is_config_node(struct vty *vty, int node) } } -gDEFUN(ournode_exit, ournode_exit_cmd, "exit", - "Exit current node, go down to provious node") -{ - switch (vty->node) { - case TRX_NODE: - vty->node = BTS_NODE; - { - struct gsm_bts_trx *trx = vty->index; - vty->index = trx->bts; - } - break; - default: - break; - } - return CMD_SUCCESS; -} - -gDEFUN(ournode_end, ournode_end_cmd, "end", - "End current mode and change to enable mode") -{ - switch (vty->node) { - default: - vty_config_unlock(vty); - vty->node = ENABLE_NODE; - vty->index = NULL; - vty->index_sub = NULL; - break; - } - return CMD_SUCCESS; -} - static const char osmobts_copyright[] = "Copyright (C) 2010, 2011 by Harald Welte, Andreas Eversberg and On-Waves\r\n" "License AGPLv3+: GNU AGPL version 3 or later <http://gnu.org/licenses/agpl-3.0.html>\r\n" @@ -140,13 +109,13 @@ struct gsm_bts *gsm_bts_num(struct gsm_network *net, int num) static struct cmd_node bts_node = { BTS_NODE, - "%s(bts)#", + "%s(config-bts)# ", 1, }; static struct cmd_node trx_node = { TRX_NODE, - "%s(trx)#", + "%s(config-bts-trx)# ", 1, }; @@ -509,7 +478,7 @@ int bts_vty_init(const struct log_info *cat) install_node(&bts_node, config_write_bts); install_element(CONFIG_NODE, &cfg_bts_cmd); - install_default(BTS_NODE); + vty_install_default(BTS_NODE); install_element(BTS_NODE, &cfg_bts_unit_id_cmd); install_element(BTS_NODE, &cfg_bts_oml_ip_cmd); install_element(BTS_NODE, &cfg_bts_rtp_bind_ip_cmd); @@ -523,7 +492,7 @@ int bts_vty_init(const struct log_info *cat) /* add and link to TRX config node */ install_element(BTS_NODE, &cfg_bts_trx_cmd); install_node(&trx_node, config_write_dummy); - install_default(TRX_NODE); + vty_install_default(TRX_NODE); install_element(ENABLE_NODE, &bts_t_t_l_jitter_buf_cmd); -- 1.7.9.5

2 7

LAPDm code issues (ladpm.c)
by Jacob Erlbeck 21 Feb '14

21 Feb '14

Hi LAPDm guys, while I was digging into the LAPDm code to find out, why a broken SABM message is sent on a SAPI3 establish SACCH request during an active call (leading to a delay of 3s between RSL EST request and response), I stumbled over the following: The initial SABM message (not the retransmitted one after T200) has a non-zero length and ends with 3 bytes that have been taken from the end of the RSL EST REQ message. The MS does not answer to this. Interestingly the second SABM message that gets sent after T200 (2s) has a length field of 0 and no trailing garbage. The difference lies in the way the msgb is handled. In rslms_rx_rll_est_req() the msg buffer passed from RSL is being used. In the case of IPA, the l2h is prepended by the 3 byte IPA header. Since all code in lapdm.c that handles RSL message seem to assume, that msg->data == msg->l2h, length computation is done based on that assumption in some places. In addition, msgb_pull() is used in a way that would also lead to undefined results in this case, e.g. in msgb_pull_l2h() just the difference between l2h and l3h is pulled from the beginning (msg->data). The main difficulty to find this, was that much msgb handling is done by manual access to the msgb fields. I'd really favor the use of the predefined macros/inlines instead of meddling around with the fields. I've added a function msgb_pull_to_l3() to msgb.h which just skips over everything in front of l3 (and therefore invalidates l2h and l1h) and replaced all calls to msgb_pull_l2h() by calls to msgb_pull_to_l3(). In addition, I replaced manual l3 length adjustment by calls to msgb_trim(). That alone fixed the SABM issue described above. See the jerlbeck/fixes/lapd-sms branch for details. But AFAICS there is still something to do: - The remaining msgb_pull() need to be checked (at least the one in l2_ph_data_ind() looks suspicious to me. - L3 length computation should be done with the macros, how it is done in lapdm_send_ph_data_req() is broken. - Why does lapd_msg_ctx have a length field that is not used? - ladp_test.c should be extended to check other execution paths, too. I've tried it for dummy packets and I didn't get it working without failing assertions (see below) - How l2/data/.. in a msg are expected to be used/set should be documented somewhere. - It should be clarified, whether all abis driver should reset the msg to start with l2. Cheers Jacob ====== The following patch still breaks the assertions, at least changing the l3len computation in lapdm_send_ph_data_req() influences but doesn't fix it. --- a/tests/lapd/lapd_test.c +++ b/tests/lapd/lapd_test.c @@ -123,8 +123,10 @@ static struct msgb *create_empty_msg(void) static struct msgb *create_dummy_data_req(void) { struct msgb *msg; + const int dummy_l1len = 3; msg = msgb_from_array(dummy1, sizeof(dummy1)); + msgb_push(msg, dummy_l1len); rsl_rll_push_l3(msg, RSL_MT_DATA_REQ, 0, 0, 1); return msg; }

3 5

[PATCH 1/3] bsc_init: Check BTS configuration, BTS should not use duplicate ARFCNs
by Ivan Kluchnikov 21 Feb '14

21 Feb '14

--- openbsc/src/libbsc/bsc_init.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 8fd72cf..cd5ee58 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -351,6 +351,8 @@ static int inp_sig_cb(unsigned int subsys, unsigned int signal, static int bootstrap_bts(struct gsm_bts *bts) { int i, n; + struct gsm_bts_trx *cur_trx; + struct gsm_bts_trx *trx; if (bts->model->start && !bts->model->started) { int ret = bts->model->start(bts->network); @@ -394,6 +396,17 @@ static int bootstrap_bts(struct gsm_bts *bts) return -EINVAL; } + llist_for_each_entry(cur_trx, &bts->trx_list, list) { + llist_for_each_entry(trx, &bts->trx_list, list) { + if ((cur_trx->arfcn == trx->arfcn) && (cur_trx->nr != trx->nr)) { + LOGP(DNM, LOGL_ERROR, "BTS should not use duplicate ARFCNs. " + "Duplicate ARFCN = %d BTS = %d TRX = %d TRX = %d\n", + trx->arfcn, bts->nr, cur_trx->nr, trx->nr); + return -EINVAL; + } + } + } + if (bts->network->auth_policy == GSM_AUTH_POLICY_ACCEPT_ALL && !bts->si_common.rach_control.cell_bar) LOGP(DNM, LOGL_ERROR, "\nWARNING: You are running an 'accept-all' " -- 1.7.9.5

6 10

[PATCH] rsl: Implement handling of rsl Delete Ind message
by Ivan Kluchnikov 18 Feb '14

18 Feb '14

If bsc receives Delete_Ind message from bts, bsc should release allocated channel, which was specified in dropped imm_assign message. --- openbsc/src/libbsc/abis_rsl.c | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/openbsc/src/libbsc/abis_rsl.c b/openbsc/src/libbsc/abis_rsl.c index f53ba84..ed6d8cd 100644 --- a/openbsc/src/libbsc/abis_rsl.c +++ b/openbsc/src/libbsc/abis_rsl.c @@ -1539,6 +1539,41 @@ static int rsl_rx_ccch_load(struct msgb *msg) return 0; } +/* CCCH overloaded, IMM_ASSIGN was dropped */ +static int rsl_rx_delete_ind(struct gsm_bts_trx *trx, struct msgb *msg) +{ + struct abis_rsl_dchan_hdr *rqd_hdr = msgb_l2(msg); + struct gsm48_imm_ass *ia; + struct gsm_lchan *lchan; + struct gsm_bts_trx *cur_trx; + uint8_t chan_nr; + uint16_t arfcn; + + /* bts didn't send IMM_ASSIGN, so we should release allocated channel */ + if (msgb_l2len(msg) != MACBLOCK_SIZE + 6) + return -EIO; + + ia = (struct gsm48_imm_ass *) (rqd_hdr->data + 2); + + if (ia->msg_type == GSM48_MT_RR_IMM_ASS) { + chan_nr = ia->chan_desc.chan_nr; + arfcn = ia->chan_desc.h0.arfcn_high; + arfcn = (arfcn << 8) | ia->chan_desc.h0.arfcn_low; + llist_for_each_entry(cur_trx, &trx->bts->trx_list, list) { + if (cur_trx->arfcn == arfcn) { + lchan = lchan_lookup(cur_trx, chan_nr); + if (!lchan) + return -EINVAL; + if (lchan->state != LCHAN_S_ACTIVE) + return -EINVAL; + rsl_direct_rf_release(lchan); + } + } + } + + return 0; +} + static int abis_rsl_rx_cchan(struct msgb *msg) { struct e1inp_sign_link *sign_link = msg->dst; @@ -1558,6 +1593,8 @@ static int abis_rsl_rx_cchan(struct msgb *msg) break; case RSL_MT_DELETE_IND: /* CCCH overloaded, IMM_ASSIGN was dropped */ + rc = rsl_rx_delete_ind(sign_link->trx, msg); + break; case RSL_MT_CBCH_LOAD_IND: /* current load on the CBCH */ LOGP(DRSL, LOGL_NOTICE, "Unimplemented Abis RSL TRX message " -- 1.7.9.5

4 7

OsmoDevCon participation
by Ciaby 17 Feb '14

17 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everybody, I know that's a bit late, but... I'm part of the Rhizomatica project, we're currently building a GSM/SIP hybrid network in Mexico. I'll be around Europe at the time of the conference, and I was wondering if there is still space available to attend. I'm not a developer of Osmocom, but we're patching OpenBSC here and there to make it fit our platform. I could come and present what is the current status, the code we wrote to manage the network from a user perspective, and where we're going in the near future. Could that be of any interest to the Osmocom crew? Cheers Ciaby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREKAAYFAlMCef8ACgkQC30ZhxNccpHkggD+M4Sn1Zakc+1oDilvm0dkfY3P 2LidV/BIiTM7P/rgXmEA/29U6I+BhvqIyFcj0ICdZkJoB66aYc70Zk5VOhtv/92f =tvJk -----END PGP SIGNATURE-----

1 0

Docker container for OpenBSC in NITB mode
by Alexey Shamrin 17 Feb '14

17 Feb '14

Hi all, I've recently played with Docker [1] and OpenBSC (osmo-nitb). The result is osmonitb-docker: https://github.com/shamrin/osmonitb-docker What you can do with it? You can use it to hack on OpenBSC under Mac or even Windows (there's Vagrant+VirtualBox config). Or you can try to streamline deployment and testing on production hardware. I've tested it under Mac working together with Fairwaves UmSITE hardware (running OsmoBTS). SMS and phone calls all work. Does it make sense to submit osmonitb-docker as a patch to OpenBSC? Quick start, under real or virtual Ubuntu 12.04, with Docker installed: git clone https://github.com/shamrin/osmonitb-docker.git cd osmonitb-docker docker build -rm -t shamrin/osmonitb . docker run -v $HOME/db:/var/db -i -t -p 3002:3002 -p 3003:3003 -p 30000:30000/udp -p 30001:30001/udp -p 30002:30002/udp -p 30003:30003/udp -p 30004:30004/udp -p 30005:30005/udp -p 30006:30006/udp shamrin/osmonitb start-nitb -i 10.0.0.10 GSM1800 10 20 (replace last 4 arguments as necessary) [1]: https://www.docker.io/ Alexey

3 4

[PATCH] rsl/si: Fix resetting bits in bts->si_valid
by Jacob Erlbeck 15 Feb '14

15 Feb '14

Use 'var &= ~(1 << x)' to reset bits instead of 'var &= (1 << x)'. Sponsored-by: On-Waves ehf --- src/common/rsl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/common/rsl.c b/src/common/rsl.c index 8b7702b..b7dc2b5 100644 --- a/src/common/rsl.c +++ b/src/common/rsl.c @@ -331,7 +331,7 @@ static int rsl_rx_bcch_info(struct gsm_bts_trx *trx, struct msgb *msg) LOGP(DRSL, LOGL_INFO, " Rx RSL BCCH INFO (SI%s)\n", get_value_string(osmo_sitype_strs, osmo_si)); } else { - bts->si_valid &= (1 << osmo_si); + bts->si_valid &= ~(1 << osmo_si); LOGP(DRSL, LOGL_INFO, " RX RSL Disabling BCCH INFO (SI%s)\n", get_value_string(osmo_sitype_strs, osmo_si)); } @@ -445,7 +445,7 @@ static int rsl_rx_sacch_fill(struct gsm_bts_trx *trx, struct msgb *msg) LOGP(DRSL, LOGL_INFO, " Rx RSL SACCH FILLING (SI%s)\n", get_value_string(osmo_sitype_strs, osmo_si)); } else { - bts->si_valid &= (1 << osmo_si); + bts->si_valid &= ~(1 << osmo_si); LOGP(DRSL, LOGL_INFO, " Rx RSL Disabling SACCH FILLING (SI%s)\n", get_value_string(osmo_sitype_strs, osmo_si)); } -- 1.7.9.5

2 2

Unbounded AGCH queue in OsmoBTS
by Alexander Chemeris 13 Feb '14

13 Feb '14

Hi all, We're moving this discussion to the mailing list, as it seems it is more generic and complex than we've thought initially. The issue arose when I started doing load testing of the OsmoTRX transceiver and disabled all gating in it. As a result, all incoming noise was processed as valid Normal Bursts and Access Bursts and sent up to OsmoBTS. This leads to a situation, similar to a RACH flood, when there are more RACH requests coming, than a BTS could reasonably process. And this leads to an unbounded increase of the AGCH queue in the BTS - it consumes a few Mb per minute. I think that this is the root cause of the issue we've seen at a Netherlands festival installation, when 20K phones suddenly started connecting to our station after official networks went down. When the amount of RACH requests exceeded available CCCH capacity (took <5 seconds), mobile phones stopped answering out IMM.ASS messages. Hypothesis is that the AGCH queue became so long, requests were sent too late for a phone to receive it. And thus no phones answered to our IMM.ASS messages. Unfortunately, I wasn't able to collect enough data to check this hypothesis during that time and we don't have another big festival on hands atm. An attached is a quick fix for the unbounded queue growth. It uses a hardcoded value for the maximum queue length, which is fine for our load testing, but not flexible enough for the real life usage. We should make the AGCH queue long enough to keep high performance. At the same time, it must not exceed MS timeout or _all_ IMM.ASS messages will miss their target MS's. We could make this parameter user-configurable on a BTS side, but it seems more reasonable to automatically calculate it, depending on the channel combination and timeout values. But this should be done on the BSC side. So the questions are: 1) what is a good way to calculate it? 2) should we configure this queue length over OML, or move the queue from BTS to BSC? -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

5 23

[libosmocore PATCH v3] src/serial.c: Add serial helper read and write function
by Alvaro Neira 13 Feb '14

13 Feb '14

From: Álvaro Neira Ayuso <anayuso(a)sysmocom.de> This patch provide two new functions for reading and writing from the serial interface. I think this two functions makes it easy reading and writing from the serial interface. Signed-off-by: Alvaro Neira Ayuso <anayuso(a)sysmocom.de> --- v3: Fixed the bug that i send errno when in this case errno don't return anything. Fixed some format error for having consistency with the others function and now, I control when read function return the value 0 for saying the end of the file. v2: Fixed the write function for don't supposing that i will write all the msg in one time. I have studied the limit in the read function and i have used the -errno like the other functions inside serial.c for having consistency. The previous version, i have supposed that we need to liberate the info in case of error, now if we have a error we can check the info that we have received or we must to send again. include/osmocom/core/serial.h | 4 +++ src/serial.c | 53 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) diff --git a/include/osmocom/core/serial.h b/include/osmocom/core/serial.h index 1640a6d..056010b 100644 --- a/include/osmocom/core/serial.h +++ b/include/osmocom/core/serial.h @@ -33,10 +33,14 @@ #include <termios.h> +struct msgb; + int osmo_serial_init(const char *dev, speed_t baudrate); int osmo_serial_set_baudrate(int fd, speed_t baudrate); int osmo_serial_set_custom_baudrate(int fd, int baudrate); int osmo_serial_clear_custom_baudrate(int fd); +int osmo_serial_write(int fd, struct msgb *msg); +int osmo_serial_read(int fd, struct msgb *msg, int numbytes); /*! @} */ diff --git a/src/serial.c b/src/serial.c index 66ee756..8c28e7a 100644 --- a/src/serial.c +++ b/src/serial.c @@ -43,6 +43,7 @@ #endif #include <osmocom/core/serial.h> +#include <osmocom/core/msgb.h> #if 0 @@ -226,4 +227,56 @@ osmo_serial_clear_custom_baudrate(int fd) return 0; } +/*! \brief Read data from Serial interface + * \param[in] fd File descriptor of the open device + * \param[in] msg Struct where we save the info + * \param[in] numbytes Number of bytes that we want read + * \returns 0 for success or negative errno. + */ +int +osmo_serial_read(int fd, struct msgb *msg, int numbytes) +{ + int rc, bread = 0; + + if (numbytes > msg->data_len) + return -ENOSPC; + + while (bread < numbytes) { + rc = read(fd, msg->tail, numbytes - bread); + if (rc < 0) + return -errno; + if (rc == 0) + break; + + bread += rc; + msgb_put(msg, rc); + } + + return bread; +} + +/*! \brief Write data to Serial interface + * \param[in] fd File descriptor of the open device + * \param[in] msg Struct where we have the info for writing + * \returns 0 for success or negative errno. + * + * The msgb->data pointer is updated when consuming this message + */ +int +osmo_serial_write(int fd, struct msgb *msg) +{ + int rc, bwritten = 0; + + while (msg->len > 0) { + rc = write(fd, msg->data, msg->len); + if (rc < 0) + return -errno; + + msgb_pull(msg, rc); + bwritten += rc; + } + + return bwritten; +} + /*! @} */

1 0

[libosmocore PATCH v2] src/serial.c: Add serial helper read and write function
by Alvaro Neira 13 Feb '14

13 Feb '14

From: Álvaro Neira Ayuso <anayuso(a)sysmocom.de> This patch provide two new functions for reading and writing from the serial interface. I think this two functions makes it easy reading and writing from the serial interface. Signed-off-by: Alvaro Neira Ayuso <anayuso(a)sysmocom.de> --- v2: Fixed the write function for don't supposing that i will write all the msg in one time. I have studied the limit in the read function and i have used the -errno like the other functions inside serial.c for having consistency. The previous version, i have supposed that we need to liberate the info in case of error, now if we have a error we can check the info that we have received or we must to send again. include/osmocom/core/serial.h | 4 +++ src/serial.c | 51 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+) diff --git a/include/osmocom/core/serial.h b/include/osmocom/core/serial.h index 1640a6d..056010b 100644 --- a/include/osmocom/core/serial.h +++ b/include/osmocom/core/serial.h @@ -33,10 +33,14 @@ #include <termios.h> +struct msgb; + int osmo_serial_init(const char *dev, speed_t baudrate); int osmo_serial_set_baudrate(int fd, speed_t baudrate); int osmo_serial_set_custom_baudrate(int fd, int baudrate); int osmo_serial_clear_custom_baudrate(int fd); +int osmo_serial_write(int fd, struct msgb *msg); +int osmo_serial_read(int fd, struct msgb *msg, int numbytes); /*! @} */ diff --git a/src/serial.c b/src/serial.c index 66ee756..c71ee6a 100644 --- a/src/serial.c +++ b/src/serial.c @@ -43,6 +43,7 @@ #endif #include <osmocom/core/serial.h> +#include <osmocom/core/msgb.h> #if 0 @@ -226,4 +227,54 @@ osmo_serial_clear_custom_baudrate(int fd) return 0; } +/*! \brief Read datas from Serial interface + * \param[in] fd File descriptor of the open device + * \param[in] msg Struct where we save the info + * \param[in] numbytes Number of bytes that we want read + * \returns 0 for success or negative errno. + */ +int +osmo_serial_read(int fd, struct msgb *msg, int numbytes) +{ + int rc, bread = 0; + + if (numbytes > msg->data_len) + return -errno; + + while (bread < numbytes) { + rc = read(fd, msg->tail, numbytes - bread); + if (rc < 0) + return -errno; + + bread += rc; + msgb_put(msg, rc); + } + + return bread; +} + +/*! \brief Write datas to Serial interface + * \param[in] fd File descriptor of the open device + * \param[in] msg Struct where we have the info for writing + * \returns 0 for success or negative errno. + * + * The msgb->data pointer is updated when consuming this message + */ +int +osmo_serial_write(int fd, struct msgb *msg) +{ + int rc, bwritten = 0; + + while (msg->len > 0) { + rc = write(fd, msg->data, msg->len); + if (rc == -1) + return -errno; + + msgb_pull(msg, rc); + bwritten += rc; + } + + return bwritten; +} + /*! @} */

3 2

Force Channel Release after abrupt call end (aka battery pull of mobile device)
by j h 13 Feb '14

13 Feb '14

I've come across an issue where any channel that are active do not release in the case of an abrupt end from the mobile (such as battery being pulled). I attempting to go in programmatically and send a CC Disconnect and a CC Release to the BSC however this doesn't solve my issue. Any thoughts of how to remedy this programatically?

2 1

osmoSGSN
by Michal Grznár 12 Feb '14

12 Feb '14

Hi, I am trying to use osmoSGSN in topology with openGGSN and sim-bss, which is simulator of BSS made by company Alcatel-Lucent. I have a problem that my osmoSGSN can not communicate with sim-BSS and it can not connect correctly. It is caused by non function bssgp. I would like to ask you, how can I configure bssgp on osmoSGSN? I can configure ns states also from vty on osmoSGSN but I can not bssgp states such as bvci etc...Please could you help me? I hope you will reply me soon. Thank you very much Best regards, Michal Grznár

2 3

[PATCH] src/serial.c: Add serial helper read and write function
by Alvaro Neira 11 Feb '14

11 Feb '14

From: Álvaro Neira Ayuso <anayuso(a)sysmocom.de> This patch provide two new functions for reading and writing from the serial interface. I think this two functions makes it easy reading and writing from the serial interface. Signed-off-by: Alvaro Neira Ayuso <anayuso(a)sysmocom.de> --- include/osmocom/core/serial.h | 4 ++++ src/serial.c | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+) diff --git a/include/osmocom/core/serial.h b/include/osmocom/core/serial.h index 1640a6d..056010b 100644 --- a/include/osmocom/core/serial.h +++ b/include/osmocom/core/serial.h @@ -33,10 +33,14 @@ #include <termios.h> +struct msgb; + int osmo_serial_init(const char *dev, speed_t baudrate); int osmo_serial_set_baudrate(int fd, speed_t baudrate); int osmo_serial_set_custom_baudrate(int fd, int baudrate); int osmo_serial_clear_custom_baudrate(int fd); +int osmo_serial_write(int fd, struct msgb *msg); +int osmo_serial_read(int fd, struct msgb *msg, int numbytes); /*! @} */ diff --git a/src/serial.c b/src/serial.c index 66ee756..818426a 100644 --- a/src/serial.c +++ b/src/serial.c @@ -43,6 +43,7 @@ #endif #include <osmocom/core/serial.h> +#include <osmocom/core/msgb.h> #if 0 @@ -226,4 +227,36 @@ osmo_serial_clear_custom_baudrate(int fd) return 0; } +int +osmo_serial_read(int fd, struct msgb *msg, int numbytes) +{ + int rc, bread = 0; + + while (bread < numbytes) { + rc = read(fd, msg->tail, numbytes - bread); + if (rc < 0) { + msgb_free(msg); + return -1; + } + bread += rc; + msgb_put(msg, rc); + } + + return bread; +} + +int +osmo_serial_write(int fd, struct msgb *msg) +{ + int bwritten = 0, ret = 0; + + bwritten = write(fd, msg->data, msg->len); + if (bwritten < 0 || bwritten < msg->len) { + msgb_free(msg); + ret = -1; + } + + return ret; +} + /*! @} */

4 3

SMS RP-Data spec violation. Somebody wants to fix it?
by Holger Hans Peter Freyther 09 Feb '14

09 Feb '14

Hi, I just looked at a trace and saw that the RP-MessageReference we assign is hardcoded to 42. It should be a sequence number going from 0 to 255. It is somehow idiotic as there can only be one SMS per direction and there is the transaction identifier as well. I would propose a patch that does: Change gsm411_send_sms to ask the subscriber connection/transaction code for a message reference. For added bonus also "put" the number so we could verify to not re-use the number too early. anyones wants to come up with a fix? holger

2 5

possible bug in OpenBSC
by Ciaby 07 Feb '14

07 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, we are currently experiencing some issues with OpenBSC paired with a sysmobts-2050. SDCCH channels are getting stick into BROKEN/UNUSABLE state, and they don't get released. This accumulates over time and reaches a point where we have to manually restart osmo-nitb because there are no channels availables and the whole network breaks down. Is it a know issue or only us? :) This is the "show lchan" output: BTS 0, TRX 0, Timeslot 0, Lchan 0: Type SDCCH Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -87 dBm, RXL-SUB-ul: -47 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 1, TRX 0, Timeslot 0, Lchan 2: Type NONE Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 1, TRX 0, Timeslot 0, Lchan 3: Type NONE Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Timeslot 0 is configured as CCCH+SDCCH4. Cheers Ciaby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREKAAYFAlL0A7MACgkQC30ZhxNccpEr7QD/WugVMQo5LW1u2RVNeK6TL6Rx hNl/h7f2UB/3lhedCTIBALcMXoglpdx/CLIo5nrZVQqoVVRCTD8Jd6UzQFtbejx+ =l7KL -----END PGP SIGNATURE-----

2 1

Fwd: [dispatch] SIP and GSM/UMTS with OpenBTS
by Jim Forster 05 Feb '14

05 Feb '14

Dear list members, I posted the following message to the IETF DISPATCH mailing list earlier today. It's got a bit of a lengthy intro, as that community is not familiar with OpenBTS (and probably not OpenBSC either), and in preliminary discussions with them it was clear that it needed a good explanation. I invite you all to join the IETF DISPATCH list, and participate in the discussion. Tim Panton has already raised some good points. See http://trac.tools.ietf.org/wg/dispatch/trac/wiki for info about the DISPATCH group and https://www.ietf.org/mailman/listinfo/dispatch to join the list. -- Jim Range Networks Begin forwarded message: > From: Jim Forster <jim.forster(a)rangenetworks.com> > Subject: [dispatch] SIP and GSM/UMTS with OpenBTS > Date: February 5, 2014 at 12:09:45 PM GMT+5:30 > To: "dispatch(a)ietf.org" <dispatch(a)ietf.org> > > Dear DISPATCH group, > > OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new and interesting ways. I think there is some value to the community in discussing these in the DISPATCH mailing list and having an related meeting at the London IETF. There is both some short-term, relatively straightforward work to be done to agree on the usage of SIP in these existing implementations. There may also be some very interesting work to be done on more advanced approaches. > > First, some background: OpenBTS is an open source project started by the founders of Range Networks to make a 'GSM system in a box', by implementing a system which supports the air interface for GSM phones (Um) using a Software Defined Radio (SDR) for the RF. While the GSM & 3GPP defined air interface to the phones is supported, OpenBTS diverges from these standards by immediately gatewaying the call to SIP. Each GSM or UMTS phone can then appear on the Internet as a SIP endpoint. A local SIP switching decision is made to route the call; Asterix, Freeswitch, Yate have been. The call is then sent to another local connected phone or to some other SIP service point on the Internet. > > With this in place, because the air interface to the phones is supported with no changes, standard GSM/UMTS phones can make calls to other phones on the same OpenBTS system or to any SIP endpoint on the Internet, and thence to the PSTN via any of the many SIP-PSTN gateways in operation. > > A fair question would be "Why do all this? What's wrong with GSM & 3GPP systems?". One reason is that the OpenBTS approach allows very small, stand alone systems, which efficiently connect GSM and UMTS phones to the Internet based SIP systems with a minimum of other systems. Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP 'Core' which is usually beyond the means of smaller users. OpenBTS aspires to be the simplest way for a GSM/UMTS phone to make phone calls to the SIP & PSTN world. > > At least several hundred, and likely several thousand of these systems are deployed already. Many are in labs, but others are production usage on all continents. Universities find these systems very attractive for teaching and researching: all the code from RF to Signaling is visible and may be changed as desired. > > Furthermore, additional SDRs are popping up all the time. There are 3-4 separate SDR based systems that run OpenBTS and more are coming. Right now they range from $2000 up, but it's easy to see them dropping to $500 or so this year; even Kickstarter campaigns are funding some of them. There's no natural floor below that; adding GSM/UMTS to a home router and making it a micro-cell running SIP to the Internet could conceivably be a $10 HW delta and some more SW. Secondly, there are several countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so some efforts are underway to do exactly that. > > When facing the Internet, OpenBTS is simply a SIP client. However, to assure interoperability, there may be value in standardized behavior, including these issues: > > * Which elements of SIP are needed for this operation? > * Should these be documented in a profile of SIP usage to be OpenBTS Ready? > * Should ICE be recommended or possibly be required for operation behind NATs? > * What about BTS-BTS neighbor discovery > * Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS to a neighbor > * For somewhat different use cases: one could separate signaling from media transport and thus might support WebRTC or other such systems. E.164 addresses are used in phones, but temporary numbers can be assigned as needed (as done in Roaming) and not surfaced to the WebRTC level. > * What Changes required for IPv6? > * Required and recommended security provisions > * Is IETF an appropriate forum for this, or should it be in 3GPP, or Sipforum.org, or a separate industry group formed? > > I look forward to discussion on the mailing list, and hopefully meeting and discussing in London. > > Yours, > > Jim Forster > Range Networks > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch

1 0

OsmoDevCon 2014: CFP
by Sylvain Munaut 05 Feb '14

05 Feb '14

Dear all, Time has come to fill out the "Talks/Discussions/Workshop / Hacking" section of the wiki page. If you have something you'd like to present, talk about or hack on, add it there. A simple descriptive title along with an estimated duration is enough. I guess we'll collect those for 2/3 weeks and then start making the schedule. Cheers, Sylvain

1 0

GPRS vs. voice with openbsc
by Ralph A. Schmid, dk5ras 03 Feb '14

03 Feb '14

Hi out there, I am using OpenBTS with an USRP1, so not absolutely on-topic here, but I have here some effects with GPRS that are a bit annoying, and I would like to ask if something similar is known with the openbsc familiy when using GPRS. GPRS works, but with a reduced operating distance. While voice and SMS work over 200m (USRP1, WBX, small omni antennae) GPRS stops after 20-25 m, when downlink level is around -70dBm. Digging a bit deeper showed me that GPRS uses a somehow strange power control model, not a closed loop but a kind of dedicated guess, derived from the downlink RSSI at the ME. Setting the corresponding gamma value has a strong influence, but even with its lowest value I do not reach more than those 25m, and I can reduce the operating range to 2m with it. Playing with rxgain and other parameters did not really improve things. Is similar behavior known with the openbsc familiy GSM systems? I even know similar effects from commercial operators (O2 Germany with EDGE), not knowing if it is the same issue or something completely different. A first glance at some documents showed me that this power level calculation seems to be normal - is there really no closed loop for GPRS available? With best regards Ralph.

3 4

Calls from BTS to PTSN planification doubts
by Diego Fernandez Alonso 03 Feb '14

03 Feb '14

Hello, my name is Diego. I've a configurated sysmoBTS in OpenBSC network-in-the-box (NITB) mode, and the osmo-nitb is working fine, doing and receiving calls and messages between the phones connected to the sysmoBTS network. At this point I would need to call outside the OpenBSC, and I would be very gratefull if someone could help me with some doubts I have. I'm new in this. For the isdn card capable of NT-mode, I've seen the "OpenVox B200P 2-port ISDN BRI PCI" card for buying, but: 1-An "OpenVox B100P ISDN BRI PCI" card, with only one RJ45 female connector, could be used correctly, working together with an already installed PCI Ethernet Controller card? Or, is it better an isdn card with two RJ45 connectors in the same card? One for connecting the BTS to the computer, and the another for connecting the computer to a LAN through a router or switch? I would like to avoid to cut cables as the LCR guide says, http://isdn.eversberg.eu/download/doc-1.4/linux-call-router-1.4_1.pdf, and the problems with the cross over and not crossed cables. 2-The "Howto OpenBSC with Asterisk and LCR" guide, http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR, indicates that it's necessary compile and install LibOsmocore and OpenBSC, but the OpenBSC/OsmoNITB inside the sysmoBTS is working, so I'm not sure about this step. If the solution is to build, configure and run OpenBSC/OsmoNITB + OsmoSGSN + OpenGGSN on a PC and configure the sysmoBTS to connect to this, should I change the image of the BTS and its whole configuration? 3-Although I don't have the isdn card yet, for testing some configurations in the PC I followed the "Building and Running OpenBSC with Asterisk" Pierre Kim guide, that I believe is newer than the "How to OpenBSC with Asterisk and LCR", and I haven't problems with the installations. So if I run the lcr: # lcr start ** LCR Version 1.14 LCR 1.14 started, waiting for calls... and running the osmo-nitb: # ./osmo-nitb -m -P DB: Database initialized. DB: Database prepared. My question in this point, is it only necessary to connect the BTS to the isdn card with the right OpenBSC to finish the system configuration? Many thanks for your time and for your work. Kindest regards, Diego.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2014