OpenBSC July 2013

openbsc@lists.osmocom.org

28 participants
42 discussions

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

Re: Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite
by Sipos Csaba 02 Aug '13

02 Aug '13

Hi Holger, I was able to narrow it down, and it seems this is the patch that causing the problem: http://cgit.osmocom.org/libosmocore/commit/?id=f5a079f739c57d8be7c59149fd45… Up to that patch it works (more or less), but after I applied it, I got this seg faults. I don't know how to do back traces but I try to get some info about this topic and will send the results. Csaba

3 12

Adding SDR Drivers
by Ash Gibbons 01 Aug '13

01 Aug '13

Hello, I am wonder how to add support for other Transceivers, in particular the BladeRF ( http://nuand.com/ ). If anyone has a start point for me to learn how to do this, it would be fantastic! Many thanks

2 1

Re: SGSN Crash Report
by Holger Hans Peter Freyther 01 Aug '13

01 Aug '13

On Tue, Jul 02, 2013 at 11:51:49PM -0700, Caleb Pal wrote: > Holger, Hi, I have a reliable re-producer of the issue. It happens when the PCU is dead and we still receive segmented data from the GGSN. The re-producer is inside a branch of mine of the OsmoPCU code[1]. The commit message has some information about how to re-produce (what is missing is the ACL config of the SGSN to allow this test). Maybe you want to try to fix the issue based on this setup? kind regards holger [1] http://git.osmocom.org/osmo-pcu/commit/?h=zecke/features/emulator&id=a727a2…

2 3

[PATCH] SGSN: set pctx->lib = NULL after calling pdp_freepdp(pctx->lib)
by Harald Welte 29 Jul '13

29 Jul '13

If we don't do this, we will generate a bogus warning in gprs_sgsn:sgsn_pdp_ctx_free() when we release a pctx which still has the lib pointer set to non-NULL. At the same point, we introduce an OSMO_ASSERT() to verify that the pctx->lib really equals the pdp context which libgtp reported to us. --- openbsc/src/gprs/sgsn_libgtp.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c index f2eb35d..c244e2c 100644 --- a/openbsc/src/gprs/sgsn_libgtp.c +++ b/openbsc/src/gprs/sgsn_libgtp.c @@ -264,6 +264,10 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) DEBUGP(DGPRS, "Received CREATE PDP CTX CONF, cause=%d(%s)\n", cause, get_value_string(gtp_cause_strs, cause)); + /* make sure that libgtp doesn't call us with inconsistent + * pointers */ + OSMO_ASSERT(pctx->lib == pdp); + /* Check for cause value if it was really successful */ if (cause < 0) { LOGP(DGPRS, LOGL_NOTICE, "Create PDP ctx req timed out\n"); @@ -292,8 +296,13 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) reject: pctx->state = PDP_STATE_NONE; - if (pdp) + if (pdp) { pdp_freepdp(pdp); + /* unlink the now non-existing library handle from the + * pdp context */ + pctx->lib = NULL; + } + /* Send PDP CTX ACT REJ to MS */ rc = gsm48_tx_gsm_act_pdp_rej(pctx->mm, pctx->ti, reject_cause, 0, NULL); -- 1.8.3.2 -- - 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 0

TLLI problems and proposed solution
by Holger Hans Peter Freyther 29 Jul '13

29 Jul '13

Dear LaF0rge, I pushed "zecke/features/emulator" to the osmo-pcu repository. All it does is to send a static GPRS Attach for a foreign TLLI. Looking at the communication with Wireshark one will see: Identity Requests messages.. always with N(U) = 0 and in the SGSN log one can see: <0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly ... <0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly What happens is the following: When receiving the GPRS Attach we create a LLME for the 'foreign' TLLI, but the look-up will never compare tlli/old_tlli with the foreign one. It will always be localized. The smallest change is this one: diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 8af5367..52727ce 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -777,9 +777,10 @@ int gprs_llc_rcvmsg(struct msgb *msg, struct tlv_parsed *tv) (llhp.cmd == GPRS_LLC_XID || llhp.cmd == GPRS_LLC_UI)) { struct gprs_llc_llme *llme; /* FIXME: don't use the TLLI but the 0xFFFF unassigned? */ - llme = llme_alloc(msgb_tlli(msg)); + llme = llme_alloc(tlli_foreign2local(msgb_tlli(msg))); LOGP(DLLC, LOGL_DEBUG, "LLC RX: unknown TLLI 0x%08x, " - "creating LLME on the fly\n", msgb_tlli(msg)); + "creating LLME on the fly\n", + tlli_foreign2local(msgb_tlli(msg))); lle = &llme->lle[llhp.sapi]; } else { LOGP(DLLC, LOGL_NOTICE, (but one could move that into llme_alloc and then it works for RX/TX). After this patch the Identity Request requests will have an increasting N(U) and the tlli in the message will be 0xadf11820. The SGSN will still print: <0012> gprs_llc.c:142 TLLI 0xadf11820 is foreign, converting to local TLLI 0xedf11820 So this means that for the entire GPRS attach procedure we will use the initial foreign TLLI.... so somehow... the code in the MM handling... /* Even if there is no P-TMSI allocated, the MS will switch from * foreign TLLI to local TLLI */ ctx->tlli_new = gprs_tmsi2tlli(ctx->p_tmsi, TLLI_LOCAL); /* Inform LLC layer about new TLLI but keep old active */ gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, GPRS_ALGO_GEA0, NULL); So this tlli_new does not appear to be used at all and I don't see how/where we would use/create the OLD_TLLI IE? Is it implemented? holger

2 16

[PATCH 2/2] gprs_llc: Assert that we send frames with either tlli or old_tlli
by Holger Hans Peter Freyther 29 Jul '13

29 Jul '13

In case we have access to the context verify that the selected msgb_tlli is either the old_tlli or the tlli. It is wrong to use any other TLLI. --- openbsc/src/gprs/gprs_llc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 57e557a..c3bd9d2 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -52,6 +52,10 @@ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx) dup.drx_parms = mmctx->drx_parms; dup.ms_ra_cap.len = mmctx->ms_radio_access_capa.len; dup.ms_ra_cap.v = mmctx->ms_radio_access_capa.buf; + + /* make sure we only send it to the right llme */ + OSMO_ASSERT(msgb_tlli(msg) == mmctx->llme->tlli + || msgb_tlli(msg) == mmctx->llme->old_tlli); } memcpy(&dup.qos_profile, qos_profile_default, sizeof(qos_profile_default)); -- 1.8.3.2 --UugvWAfsgieZRqgk--

1 0

7 patches
by Andreas Eversberg 29 Jul '13

29 Jul '13

hi, these 7 patches have been tested with sysmobts and osmo-bts (trx interface). it works with calls and gprs. before applying any of these patches, i suggest to double check it with a different test setup. regards, andreas

2 5

[PATCH 1/2] gprs_llc: Lookup lle based on the real TLLI
by Holger Hans Peter Freyther 29 Jul '13

29 Jul '13

During the GPRS Attach procedure we might have a foreign tlli and in the RX create a LLME on the fly for this tlli. The GMM GPRS Attach handling code will then assign a new TLLI and keep the foreign tlli as the llme->old_tlli. When the GMM is sending the identity request the msgb_tlli will point to the foreign tlli. The GPRS LLC code will then try to find that foreign tlli but due the conversion this will not be found. Instead a new ad-hoc LLE/LLME will be created on the fly for each message (this means there are duplicate LLE/LLMEs in the list). Make the code more strict and remove the tlli_foreign2local change from the look-up routine. This will make the GPRS LLC code find the right LLE/LLME and the N(U) will be handled correctly. Addresses: <0012> gprs_llc.c:773 LLC RX: unknown TLLI 0xadf11820, creating LLME on the fly ... <0012> gprs_llc.c:357 LLC TX: unknown TLLI 0xedf11820, creating LLME on the fly Reproducable: Use pcu_emu (gprs attach) and observe with wireshark. --- openbsc/src/gprs/gprs_llc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 8af5367..57e557a 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -147,12 +147,10 @@ static inline uint32_t tlli_foreign2local(uint32_t tlli) } /* lookup LLC Entity based on DLCI (TLLI+SAPI tuple) */ -static struct gprs_llc_lle *lle_by_tlli_sapi(uint32_t tlli, uint8_t sapi) +static struct gprs_llc_lle *lle_by_tlli_sapi(const uint32_t tlli, uint8_t sapi) { struct gprs_llc_llme *llme; - tlli = tlli_foreign2local(tlli); - llist_for_each_entry(llme, &gprs_llc_llmes, list) { if (llme->tlli == tlli || llme->old_tlli == tlli) return &llme->lle[sapi]; -- 1.8.3.2 --UugvWAfsgieZRqgk Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-gprs_llc-Assert-that-we-send-frames-with-either-tlli.patch"

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2013