November 2013 - 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

[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

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

Re: Openbsc support for new BTS
by Harald Welte 21 Jan '14

21 Jan '14

Hi Jason, On Fri, Nov 08, 2013 at 01:21:46PM +0000, Jason DSouza wrote: > But I'm waiting at Opstart for Obj Class - RADIO_CARRIER to trigger > trx-init() which is never received from BSC. That is where I'm struck > now. All this so far is similar to sysmobts interface, something > similar to bts_model_opstart() function in osmo-bts-sysmo. Please see the following code from bts_ipaccess_nanobts.c: ============== /* Callback function to be called whenever we get a GSM 12.21 state change event */ static int nm_statechg_event(int evt, struct nm_statechg_signal_data *nsd) { [...] case NM_OC_RADIO_CARRIER: trx = obj; if (new_state->operational == NM_OPSTATE_DISABLED && new_state->availability == NM_AVSTATE_OK) abis_nm_opstart(trx->bts, obj_class, trx->bts->bts_nr, trx->nr, 0xff); break; ============== So the opstrart for the RADIO_CARRIER is sent in response to an incoming NM_MT_STATECHG_EVENT_REP withe the operational state set to DISABLED and the availability set to OK. My guess is that you are not sending such a state event from the BTS to the BSC. I can also not see that in the pcap file you have sent. All OML messages in there relate to the Site MAnager or the BTS object class, but there are no messages related to any other MOs. As indicated, it is best to start from a known-working setup with a supported BTS model, or at least from a protocol trace of an existing supported configuration. Please also make sure to set your 'bts model' to nanobts, I _think_ the 'bts model sysmobts' is still broken. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 8

[PATCH] libabis: Enable TCP keepalive by default on all BTS connections
by Jacob Erlbeck 14 Jan '14

14 Jan '14

From: Daniel Willmann <daniel(a)totalueberwachung.de> This way we can find out fast if the connection is broken. Ticket: OW#1060 --- src/input/ipaccess.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/src/input/ipaccess.c b/src/input/ipaccess.c index 4a56569..371b21c 100644 --- a/src/input/ipaccess.c +++ b/src/input/ipaccess.c @@ -28,6 +28,7 @@ #include <stdlib.h> #include <stdbool.h> #include <errno.h> +#include <netinet/tcp.h> #include <string.h> #include <time.h> #include <sys/fcntl.h> @@ -50,6 +51,10 @@ static void *tall_ipa_ctx; #define TS1_ALLOC_SIZE 900 +#define DEFAULT_TCP_KEEPALIVE_IDLE_TIMEOUT 30 +#define DEFAULT_TCP_KEEPALIVE_INTERVAL 3 +#define DEFAULT_TCP_KEEPALIVE_RETRY_COUNT 10 + /* * Common propietary IPA messages: * - PONG: in reply to PING. @@ -605,7 +610,7 @@ static int ipaccess_bsc_oml_cb(struct ipa_server_link *link, int fd) { int ret; int idx = 0; - int i; + int i, val; struct e1inp_line *line; struct e1inp_ts *e1i_ts; struct osmo_fd *bfd; @@ -638,6 +643,34 @@ static int ipaccess_bsc_oml_cb(struct ipa_server_link *link, int fd) goto err_line; } + /* Enable TCP keepalive to find out if the connection is gone */ + val = 1; + ret = setsockopt(bfd->fd, SOL_SOCKET, SO_KEEPALIVE, &val, sizeof(val)); + if (ret < 0) + LOGP(DLINP, LOGL_NOTICE, "Failed to set keepalive: %s\n", + strerror(errno)); + else + LOGP(DLINP, LOGL_NOTICE, "Keepalive is set: %i\n", ret); + +#if defined(TCP_KEEPIDLE) && defined(TCP_KEEPINTVL) && defined(TCP_KEEPCNT) + /* The following options are not portable! */ + val = DEFAULT_TCP_KEEPALIVE_IDLE_TIMEOUT; + ret = setsockopt(bfd->fd, IPPROTO_TCP, TCP_KEEPIDLE, &val, sizeof(val)); + if (ret < 0) + LOGP(DLINP, LOGL_NOTICE, "Failed to set keepalive idle time: %s\n", + strerror(errno)); + val = DEFAULT_TCP_KEEPALIVE_INTERVAL; + ret = setsockopt(bfd->fd, IPPROTO_TCP, TCP_KEEPINTVL, &val, sizeof(val)); + if (ret < 0) + LOGP(DLINP, LOGL_NOTICE, "Failed to set keepalive interval: %s\n", + strerror(errno)); + val = DEFAULT_TCP_KEEPALIVE_RETRY_COUNT; + ret = setsockopt(bfd->fd, IPPROTO_TCP, TCP_KEEPCNT, &val, sizeof(val)); + if (ret < 0) + LOGP(DLINP, LOGL_NOTICE, "Failed to set keepalive count: %s\n", + strerror(errno)); +#endif + /* Request ID. FIXME: request LOCATION, HW/SW VErsion, Unit Name, Serno */ ret = ipaccess_send_id_req(bfd->fd); if (ret < 0) { -- 1.7.9.5

3 15

[PATCH] nitb: Set the DST field in generated MM info messages
by Jacob Erlbeck 07 Jan '14

07 Jan '14

Currently the NET_DST information element (see GSM 24.008) is not included in generated MM info messages even when the DST field in the timezone info has been set via the VTY or the control interface. This patch modifies gsm48_tx_mm_info() to append this information element if (and only if) a non-zero DST has been configured. The DST IE is not part of GSM 4.8. Therefore it will only be sent, if the DST offset is configured to a value != 0. Sponsored-by: On-Waves ehf --- openbsc/src/libmsc/gsm_04_08.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index 3cfc455..0d1ba7b 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -656,6 +656,7 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) struct tm* gmt_time; struct tm* local_time; int tzunits; + int dst = 0; msg->lchan = conn->lchan; @@ -749,6 +750,9 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) tzunits = tzunits + (bts->tz.mn/15); ptr8[7] = bcdify(tzunits); } + /* Convert DST value */ + if (bts->tz.dst >= 0 && bts->tz.dst <= 2) + dst = bts->tz.dst; } else { /* Need to get GSM offset and convert into 15 min units */ @@ -768,8 +772,19 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) } else ptr8[7] = bcdify(tzunits); + + /* Does not support DST +2 */ + if (local_time->tm_isdst) + dst = 1; } +#ifdef GSM48_IE_NET_DST + ptr8 = msgb_put(msg, 3); + ptr8[0] = GSM48_IE_NET_DST; + ptr8[1] = 1; + ptr8[2] = dst; +#endif + DEBUGP(DMM, "-> MM INFO\n"); return gsm48_conn_sendmsg(msg, conn, NULL); -- 1.7.9.5

2 2

OsmoDevCon 2014 / Date / Venue
by Harald Welte 01 Jan '14

01 Jan '14

Hi all, time is moving fast, and I want to start some initial discussion and planning for OsmoDevCon 2014. There are basically four questions which I'm raising below. Please provide your feedback to the osmocom-event-orga mailing list only, to avoid cross-posting over all the project lists. = Who? = My intention is to keep it an 'active developer/contributer only' event, like we had it before. I would also want to keep the group relatively small, to keep the 'Osmocom family' atmosphere. If desired, we could have one half or full day of public prsentations in a larger auditorium, but the developer meeting should be a close group, as known so far. = Where? = If we keep the number of attendees within the same range as this year, then I'm sure we could again hold it at the same venue. I know it is not perfect, but it is a place that we have access to, 24 hours per day, and free of cost for community projects like osmocom.org. If the community wants a larger event, then this is something that would require more funds and much more time organizing. And that is something that I personally could not offer to take care of, sorry. I'm happy to attend and support any larger events, but I'm unable to take care of fundraising and venue research. = When? = Q1/2014. In January, I'm not aware of any 'blocker' events. February, there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg March 17-21). Did I miss any other FOSS / mobile event that might clash in Q1? So my preference woudl be to do it either late January (23-26) or in February (6-9 or 13-16). Any preferences regarding preferred schedule? Once we have some concencus here on the list [and we want to do it in the same size / venue], I'll talk to IN-Berlin. = What? = I think that question is easy to answer, if we have the above three figured out... There's no shortage of topics, I suppose. You can start adding your suggestions to http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 1