OpenBSC

openbsc@lists.osmocom.org

4315 discussions

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

[PATCH] Add vty command for setting Access control classes
by Ivan Kluchnikov 25 Jul '13

25 Jul '13

Hi all, Attached patch adds vty command for setting Access control classes (GSM 02.11 Section 4 Access control) in RACH Control Parameters (GSM 04.08 Section 10.5.2.29 RACH Control Parameters). -- Regards, Ivan Kluchnikov. http://fairwaves.ru

5 24

Nokia InSite handover
by Sipos Csaba 22 Jul '13

22 Jul '13

Today, after I successfully started two InSite BTS units on the same E1 line, I tried to test the OpenBSC handover function. I got a strange error message, that I have to enable RTP Proxy mode with "-P" in osmo-nitb. Because these units are running from E1, I just simply ask: do we have handover support for E1 based BTSs? Cell reselection and inter BTS voice calls, SMSs are working just fine. BR, Csaba

2 4

GPRS roaming
by Andreas Eversberg 22 Jul '13

22 Jul '13

hi harald, i know that you talked about before so maybe you can give me a hint. i like to make osmo-sgsn allow roaming (different PLMN of the phone than the one in the RAI of the BTS). regards, andreas

7 16

Dropping support for the HSL bts
by Holger Hans Peter Freyther 21 Jul '13

21 Jul '13

Good Morning Harald, do you mind if we drop support for the HSL BTS? The support is spewing out compile warnings, now turns up in coverity reports as well and we don't even know if it is working with the latest version of the software running on these BTS. holger

4 10

Any BS11 user please test the following patch
by Holger Hans Peter Freyther 18 Jul '13

18 Jul '13

Hi, Coverity pointed out a missing break. I have added it now but the fix might break BS11 code that relied on this broken functionality. Could anyone with a BS11 please test this? I will integrate the change in a week. holger

3 4

DAHDI and LAPd errors
by Sipos Csaba 17 Jul '13

17 Jul '13

Dear Members, From the beginning I am having various LAPd related error messages with Nokia InSite and a DAHDI E1 card. The LAPd connection resets itself several times before a working OML and RSL connection is made. I don't know, maybe this is due to a change in the DAHDI code. I am getting lapd errors during the BTS initialization like this one: ^[[0;m^[[1;36mTue Jul 16 13:55:10 2013 <0005> bsc_init.c:91 shutting down OML for BTS 0 ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:159 LAPD state change on TEI 1: NONE -> ASSIGNED ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:212 LAPD Allocating SAP for SAPI=62 / TEI=1 ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:223 k=1 N200=3 N201=260 T200=1.0 T203=10.0 ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:292 Init DL layer: sequence range = 128, k = 1, history range = 2 ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:229 new state LAPD_STATE_NULL -> LAPD_STATE_IDLE ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:485 LAPD DL-ESTABLISH request TEI=1 SAPI=62 ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:2171 Message DL-ESTABLISH-REQUEST received in state LAPD_STATE_IDLE ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:1685 perform normal establishm. (SABM) ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:229 new state LAPD_STATE_IDLE -> LAPD_STATE_SABM_SENT ^[[0;mTue Jul 16 13:55:14 2013 <0018> input/lapd.c:600 TX: fa 03 7f ^[[0;mTue Jul 16 13:55:14 2013 <0018> lapd_core.c:198 start T200 ^[[0;m^[[1;38mTue Jul 16 13:55:14 2013 <001d> sms_queue.c:220 Attempting to send 20 SMS ^[[0;m^[[1;38mTue Jul 16 13:55:14 2013 <001d> sms_queue.c:280 SMSqueue added 0 messages in 0 rounds ^[[0;mTue Jul 16 13:55:15 2013 <0018> lapd_core.c:551 Timeout T200 (0x822cb80) state=5 ^[[0;mTue Jul 16 13:55:15 2013 <0018> input/lapd.c:600 TX: fa 03 7f ^[[0;mTue Jul 16 13:55:15 2013 <0018> lapd_core.c:198 start T200 ^[[0;mTue Jul 16 13:55:16 2013 <0018> lapd_core.c:551 Timeout T200 (0x822cb80) state=5 ^[[0;mTue Jul 16 13:55:16 2013 <0018> input/lapd.c:600 TX: fa 03 7f ^[[0;mTue Jul 16 13:55:16 2013 <0018> lapd_core.c:198 start T200 ^[[0;mTue Jul 16 13:55:17 2013 <0018> lapd_core.c:551 Timeout T200 (0x822cb80) state=5 ^[[0;mTue Jul 16 13:55:17 2013 <0018> input/lapd.c:600 TX: fa 03 7f ^[[0;mTue Jul 16 13:55:17 2013 <0018> lapd_core.c:198 start T200 ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:551 Timeout T200 (0x822cb80) state=5 ^[[0;mTue Jul 16 13:55:18 2013 <0018> input/lapd.c:628 LAPD DL-RELEASE indication TEI=1 SAPI=62 ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:307 Resetting LAPDm instance ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:229 new state LAPD_STATE_SABM_SENT -> LAPD_STATE_IDLE ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:384 sending MDL-ERROR-IND cause 1 ^[[0;mTue Jul 16 13:55:18 2013 <0018> lapd_core.c:229 new state LAPD_STATE_IDLE -> LAPD_STATE_IDLE ^[[0;m^[[1;36mTue Jul 16 13:55:33 2013 <0005> bsc_init.c:91 shutting down OML for BTS 0 Anyway, it would be nice to know a recommended DAHDI version and/or kernel version which is used during the development or something. For example - as I mentioned it earlier - DAHDI 2.7.x breaks the compatibility with OpenBSC due to the changed addressing scheme. BR, Csaba

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC