OpenBSC August 2011

openbsc@lists.osmocom.org

13 participants
28 discussions

by Seungju Kim

Hello, I have been testing the data setup and I found another issue. I couldn't really find out exactly what causes this. This happens rarely but it does happen time to time. I am attaching the log file of the issue. I looked through the log but I could not find anything else interesting in the log. http://pastebin.com/tQ0mcyeu This is the log file of the issue. I'll be glad to hear any thoughts about this. Envoyé de mon iPhone

13 years, 7 months

what type of RRLP protocol supported in OpenBSC

by Akib Sayyed

OpenBSC support RRLP protocol but in RRLP we have 2 modes E-OTD A-GPS what modes are supported?? if E-OTD is supported can we use OpenBSC to triangulate normal Cellphones like Motorola C123 ?? -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

13 years, 7 months

GPRS issue after idle

by Seungju Kim

Hello,I got everything up and running. Including EDGE data. The throughput of the data from the osmo-sgsn is pretty good. But recently I have spotted a problem with the SGSN. The sgsn loses the phones SNDCP entity after idling or making a phone call. Please see the log from the sgsn http://pastebin.com/2W9dZdvW

13 years, 7 months

OpenBSC + LCR

by Gus Bourg

Hello all, I'm attempting to make my OpenBSC setup work with LCR and Asterisk. I'm not sure if the problem that I'm running into is specific to the nature of my setup (running a Nokia BTS) or is a misconfiguration issue with LCR. When I run without LCR and Asterisk I can call between phones, SMS etc. With LCR I have no such luck. I can place a call into the mobile from Asterisk, and the mobile rings, but when I answer the call hangs up. A pastebin of the LCR log can be found here: http://pastebin.com/DbM3TfFp Any insight into the cause would be much appreciated. :) Thanks, Gus

13 years, 7 months

[PATCH] GPRS: Fix the parsing/interpretation of the PDP CTX status IE

by Harald Welte

The byte ordering is a bit odd: The least significant byte is ahead of the most significant byte, different from everything else in GSM that seems to be big-endian. Thanks to Seungju Kim <admin(a)manateeshome.com> for repoerting the bug. --- openbsc/src/gprs/gprs_gmm.c | 24 ++++++++++++++++-------- 1 files changed, 19 insertions(+), 11 deletions(-) diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 098e4c2..c9fe517 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -867,7 +867,7 @@ static int gsm48_tx_gmm_ra_upd_rej(struct msgb *old_msg, uint8_t cause) } static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, - uint16_t pdp_status) + uint8_t *pdp_status) { struct sgsn_pdp_ctx *pdp, *pdp2; /* 24.008 4.7.5.1.3: If the PDP context status information element is @@ -878,11 +878,20 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, * being in state PDP-INACTIVE. */ llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) { - if (!(pdp_status & (1 << pdp->nsapi))) { - LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " - "due to PDP CTX STATUS IE= 0x%04x\n", - pdp->nsapi, pdp_status); - sgsn_delete_pdp_ctx(pdp); + if (pdp->nsapi < 8) { + if (!(pdp_status[0] & (1 << pdp->nsapi))) { + LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + "due to PDP CTX STATUS IE= 0x%02x%02x\n", + pdp->nsapi, pdp_status[1], pdp_status[0]); + sgsn_delete_pdp_ctx(pdp); + } + } else { + if (!(pdp_status[1] & (1 << (pdp->nsapi - 8)))) { + LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + "due to PDP CTX STATUS IE= 0x%02x%02x\n", + pdp->nsapi, pdp_status[1], pdp_status[0]); + sgsn_delete_pdp_ctx(pdp); + } } } } @@ -975,8 +984,7 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, /* Look at PDP Context Status IE and see if MS's view of * activated/deactivated NSAPIs agrees with our view */ if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) { - uint16_t pdp_status = ntohs(*(uint16_t *) - TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)); + uint8_t *pdp_status = TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS); process_ms_ctx_status(mmctx, pdp_status); } -- 1.7.5.4 --CE+1k2dSO48ffgeK--

13 years, 7 months

[PATCH] GPRS: Fix the byte ordering of the PDP context status IE

by Harald Welte

It seems that 24.008 Section 10.5.7.1 specifies the IE to be encoded in little endian... --- openbsc/src/gprs/gprs_gmm.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 098e4c2..f83219f 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -870,6 +870,7 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, uint16_t pdp_status) { struct sgsn_pdp_ctx *pdp, *pdp2; + uint16_t pdp_status_reordered; /* 24.008 4.7.5.1.3: If the PDP context status information element is * included in ROUTING AREA UPDATE REQUEST message, then the network * shall deactivate all those PDP contexts locally (without peer to @@ -877,8 +878,13 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, * state PDP-INACTIVE on network side but are indicated by the MS as * being in state PDP-INACTIVE. */ + /* 24.008 10.5.7.1 indicates that the byte ordering is in fact + * little endian, i.e. the first octet contains NSAPI0..7 and + * the second payload octet NSAPI8..15 */ + pdp_status_reordered = (pdp_status & 0xff << 8) || (pdp_status >> 8); + llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) { - if (!(pdp_status & (1 << pdp->nsapi))) { + if (!(pdp_status_reordered & (1 << pdp->nsapi))) { LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " "due to PDP CTX STATUS IE= 0x%04x\n", pdp->nsapi, pdp_status); @@ -977,6 +983,10 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) { uint16_t pdp_status = ntohs(*(uint16_t *) TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)); + /* pdp_status is now in big endian, which is the wrong + * order. the wire encoding is little endian! We cannot + * simply drop the ntohs() above, as we migh be running + * on a big endian machine. */ process_ms_ctx_status(mmctx, pdp_status); } -- 1.7.5.4 --iq/fWD14IMVFWBCD--

13 years, 7 months

Packages in pkgsrc-wip (for NetBSD and more)

by Pierre Pronchery

Hi openbsc@, for the record I have just packaged libosmocore 0.1.30 and OpenBSC 0.9.13 in pkgsrc-wip, as released by Harald about 5 months ago, see: http://openbsc.osmocom.org/trac/wiki/Tarballs and http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/wip/libosmocore/ http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/wip/openbsc/ I had to apply a few changes, patches are found in the two links above (not all of them good enough to be pushed though). Unfortunately OpenBSC is probably not useful on NetBSD at the moment, except with the isdn4bsd patches maybe (which I don't think are maintained anymore). pkgsrc can be useful on Linux distributions though. HTH anyway, -- khorben

13 years, 7 months

GSM @ Camp 2011 preparations

by Harald Welte

Hi Peter and others, it seems like the situation regarding the GSM network at the Camp is starting to become clearer every day. I am still arguing that two relatively large BTS with circular antennas are a good idea. Therefore, I have now applied for a test license with the regulatory authority with the following parameters: * six GSM 1800 ARFCN * two antennas, circular, 18 meters above ground * 5W output power on each ARFCN. I know one of my customers in Germany has once managed to get a license for 5W, so I thought it is a good bet we should get the same. It should be more than sufficient to cover the camp. * from August 2nd through August 15th, i.e. we have time for build-up and can also run it one more day during shutdown of the camp I should be receiving "Motorola Horizon Macro" BTSs with 3 to 6 TRX each soon. They are able to drive something like >= 20W output power, way more than we need. The only problem with those BTS is: We will need to add the Motorola A-bis dialect to OpenBSC before the Camp, which could be a tough task depending on how far they are off the standard A-bis as specified in 08.58 and 12.21. If we cannot make those BTS work, our options are somewhat limited. 1) nanoBTS based The nanoBTS are 200mW only, so we would need a booster. Those cost about 1000 EUR for 6W downlink power + 18dB uplink LNA. Who is going to fund that? Also, we would need a combiner/splitter to run something like a 3-TRX setup. 2) Ericsson RBS I should have two RBS 2308 (4TRX each) soon, but both of them are GSM 1900. It is unlikely that we ge a license, and a lot of phones probably don't support it. So unless they can somehow be converted to 1800 MHz units, they are not a good fit either :/ 3) Siemens BS-11 All of them are GSM 900. No way to get a license in Germany, sorry. So we basically _have to_ make the Motorola Horizon work... 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)

13 years, 7 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC August 2011