OpenBSC

openbsc@lists.osmocom.org

4315 discussions

mISDN/lcr/asterisk compilation issues
by carcelle 01 Mar '12

01 Mar '12

Dear openbsc folks, i am following up on the osmo-nitb/ggsn/sgsn config running w/ a nanoBTS-1800. i have been trying to get mISDN/lcr to build to be able to create the chan_lcr into asterisk (i am more familiar w/ dahdi/asterisk for isdn cahnnels) though so far i am not able to get it to work : *configuration : **host : running linux debian lenny 2.6.26-2-686) **autoconf 2.61 **mISDN-1_1_9.1 (downloaded as a tarball) builds mISDN_dsp.ko but not mISDN_l1loop.ko **lcr doest not build (./configure passes) /usr/src/lcr# git-apply --verbose lcrOpenBSC.patch Checking patch gsm_bs.cpp... error: while searching for: int bts_model_nanobts_init(void); static struct log_target *stderr_target; /* timer to store statistics */ #define DB_SYNC_INTERVAL 60, 0 static struct timer_list db_sync_timer; error: patch failed: gsm_bs.cpp:39 error: gsm_bs.cpp: patch does not apply /usr/src/lcr# make (...) gcc -DWITH_GSM_BS -I./openbsc/include -I./libosmocore/include -I./openbsc -Wall -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -D_GNU_SOURCE -fPIC -c bchannel.c -o bchannel.po bchannel.c:29:31: error: mISDN/mISDNcompat.h: No such file or directory bchannel.c:30: error: 'MISDN_AF_ISDN' undeclared here (not in a function) bchannel.c:31:24: error: mISDN/q931.h: No such file or directory bchannel.c: In function 'bchannel_create': bchannel.c:148: error: 'PF_ISDN' undeclared (first use in this function) bchannel.c:148: error: (Each undeclared identifier is reported only once bchannel.c:148: error: for each function it appears in.) bchannel.c:174: error: 'AF_ISDN' undeclared (first use in this function) make[1]: *** [bchannel.po] Error 1 make[1]: Leaving directory `/usr/src/lcr' (lcr from git : commit 6e1e99808e5b1c16b00904d31f95d0b74487023e) *questions : **do i need misdn to build lcr if running a nanobts w/ Abis-over-ip ? **am i missing something in the build order ? **any packaged version of misdn for debian 2.6.26-2-686 ? thanks for your support. Xavier.

8 19

Adding subscriber to HLR database
by Don Fanning 01 Mar '12

01 Mar '12

Does anyone have the steps/commands to add a new handset to the HLR database? I wanted to add in a new handset into my system but couldn't find the information short of opening access to the site.

4 4

Re: Specifying channel mode for speech
by Thomas Cooper 29 Feb '12

29 Feb '12

Thank you for the quick and helpful replies, Andreas and Holger! I had a feeling there was an easy answer. -Tom > Message: 6 > Date: Wed, 29 Feb 2012 08:21:13 +0100 > From: jolly <andreas(a)eversberg.eu> > To: Thomas Cooper <tacooper(a)vt.edu> > Cc: openbsc(a)lists.osmocom.org > Subject: Re: Specifying channel mode for speech > Message-ID: <4F4DD1E9.8080409(a)eversberg.eu> > Content-Type: text/plain; charset=ISO-8859-1 > > Thomas Cooper wrote: >> Osmo-bts gets the MODE_MODIFY_REQ from OpenBSC with >> GSM48_CMODE_SPEECH_EFR to use for the channel mode. However, I would >> like to be able to specify using GSM48_CMODE_SPEECH_V1 instead (which >> is FR; EFR is not supported in L1). Is there an easy way to set the >> preferred channel mode/audio support? I didn't see anything on the VTY >> wiki or in the config file. >> > hi tom, > > you may change the line 46 at mncc_builtin.c. the first entry in this > array is the full rate code, the second entry is the half rate codec. > (depending on the trx configuration) just change the first entry to > GSM48_CMODE_SPEECH_V1. > > regards, > > andreas > > ------------------------------ > > Message: 8 > Date: Wed, 29 Feb 2012 09:54:24 +0100 > From: Holger Hans Peter Freyther <holger(a)freyther.de> > To: openbsc(a)lists.osmocom.org > Subject: Re: Specifying channel mode for speech > Message-ID: <4F4DE7C0.5000000(a)freyther.de> > Content-Type: text/plain; charset=ISO-8859-1 > > On 02/29/2012 08:21 AM, jolly wrote: > >> you may change the line 46 at mncc_builtin.c. the first entry in this >> array is the full rate code, the second entry is the half rate codec. >> (depending on the trx configuration) just change the first entry to >> GSM48_CMODE_SPEECH_V1. > > you can change this with the VTY config. Look at commit > ab386e6120559ef2deb6a27f4455539cba920c9d that introduced it. > > holger >

1 0

Re: neighbour cells
by Harald Welte 29 Feb '12

29 Feb '12

Hi Jolly, On Wed, Feb 29, 2012 at 09:21:34AM +0100, jolly wrote: > i improved the generation of neighbour cells of openbsc. the patch is > committed at origin/jolly/rtpmux. Thanks a lot for working on this. It's a really nasty subject with lots of bit-fiddling and many strange cases. > it generated the system information messages of neighbour cells in the > same and in other bands. depending on the location of the bcch and the > neighbour cells, the messages SI 2/5 and optionally SI 2bis/5bis and SI > 2ter/5ter are generated. > > i have tested it with several configurations. i would like to commit it > to master. any suggestions? I've reviewed it, and the patch seems fine to me. I haven't tested it, though. Feel free to commit it to master. And thanks for the verbose changelog message. 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 0

Specifying channel mode for speech
by Thomas Cooper 29 Feb '12

29 Feb '12

Osmo-bts gets the MODE_MODIFY_REQ from OpenBSC with GSM48_CMODE_SPEECH_EFR to use for the channel mode. However, I would like to be able to specify using GSM48_CMODE_SPEECH_V1 instead (which is FR; EFR is not supported in L1). Is there an easy way to set the preferred channel mode/audio support? I didn't see anything on the VTY wiki or in the config file. Thanks, Tom

3 3

Easterhegg 2012 registration open
by Miguel Elias 26 Feb '12

26 Feb '12

Hi together, the registration for the next Easterhegg in Basel (Switzerland) is open. -->> https://easterhegg.ch We are still looking for workshops and lectures. You can find more information in the attached text file. Here our poster: https://easterhegg.ch/eh2012-plakat-a3.pdf Gruss Miguel aka nobody -- ------------------------------------------------------------------ Chaostreff Basel, Birsfelderstrasse 6, 4132 Muttenz, Schweiz WEB: https://www.chaostreff.ch Wiki: http://wiki.chaostreff.ch Jabber: nobody_su(a)jabber.ccc.de ------------------------------------------------------------------ === Please don't print this e-mail unless you really need to, this is your contribution to save the environment. ===

1 0

SMSC Thoughts
by Harald Welte 25 Feb '12

25 Feb '12

Hi! I'm just writiing this up as you mentioned that you were considering to look into implementing an external SMSC. This is great news, and of course you can do it whatever way you want to do it. However, to put things a bit more into perspective and ensure that this SMSC can also be used in a real GSM core network later on, I would like to ask you to consider staying in line with how the primitives/transacitions look like in a real GSM network. The idea here is that with every new interface we introduce in osmo-nitb, we should try ot move towards that of a real network. This does't mean that it has to implement the actual detailed MAP/TCAP/SCCP encoding as specified, but simply that they semantic of the primitives/messages and their order and time of occurrence is the same.

3 2

OpenBSC bug that triggers Qualcomm baseband bug (patch)
by Tobias Engel 24 Feb '12

24 Feb '12

Hi, currently, when OpenBSC receives any mobile originated Supplementary Service request, it always treats it as an USSD request (because the only SS it supports is a USSD request for sending back the extension of the subscriber). What I think the code in handle_rcv_ussd is meant to be doing is: If the request contained an USSD string, and if that string is equal to "*#100#", return the subscriber extension. In all other cases reject the request with "unrecognized component". But currently it returns the extension even when the SS request wasn't even an USSD request. That causes several phones with Qualcomm baseband to hang and reboot after a while because in some situations they send an interrogateSS request to query if any call forwardings are active and cannot handle the wrong answer they receive. (Strangely, that happens with most "modern" HTC phones i have tried right after logging into the network, rendering them completely useless for use with OpenBSC) Here is a patch: --- a/openbsc/src/libmsc/ussd.c +++ b/openbsc/src/libmsc/ussd.c @@ -54,7 +54,7 @@ int handle_rcv_ussd(struct gsm_subscriber_connection *conn, struct msgb *msg) if (req.text[0] == 0xFF) /* Release-Complete */ return 0; - if (strstr(USSD_TEXT_OWN_NUMBER, req.text) != NULL) { + if (strcmp(USSD_TEXT_OWN_NUMBER, (const char *) req.text) == 0) { DEBUGP(DMM, "USSD: Own number requested\n"); rc = send_own_number(conn, msg, &req); } else { -Tobias

5 6

uint32_t does not name a type
by Don Fanning 24 Feb '12

24 Feb '12

Trying to replicate my setup to a new machine. Not sure what I'm missing as now my old LCR source is showing the same issue on Debian 6.06. No difference with the current GIT commit... same error. root@Netbox:/usr/src/lcr# make make all-am make[1]: Entering directory `/usr/src/lcr' g++ -DHAVE_CONFIG_H -I. -DWITH_MISDN -DWITH_CRYPT -DWITH_GSM_BS -Wall -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -g -O2 -MT gsm.o -MD -MP -MF .deps/gsm.Tpo -c -o gsm.o gsm.cpp In file included from gsm.cpp:14: mncc.h:195: error: ‘uint32_t’ does not name a type mncc.h:196: error: ‘uint32_t’ does not name a type mncc.h:197: error: ‘uint32_t’ does not name a type mncc.h:198: error: ‘uint16_t’ does not name a type mncc.h:199: error: ‘uint32_t’ does not name a type mncc.h:200: error: ‘uint32_t’ does not name a type gsm.cpp: In member function ‘void Pgsm::send_mncc_rtp_connect()’: gsm.cpp:133: error: ‘struct gsm_mncc_rtp’ has no member named ‘ip’ gsm.cpp:134: error: ‘struct gsm_mncc_rtp’ has no member named ‘port’ gsm.cpp:137: error: ‘struct gsm_mncc_rtp’ has no member named ‘payload_msg_type’ gsm.cpp:140: error: ‘struct gsm_mncc_rtp’ has no member named ‘payload_msg_type’ gsm.cpp:143: error: ‘struct gsm_mncc_rtp’ has no member named ‘payload_msg_type’ gsm.cpp:146: error: ‘struct gsm_mncc_rtp’ has no member named ‘payload_msg_type’ gsm.cpp:149: error: ‘struct gsm_mncc_rtp’ has no member named ‘payload_type’ gsm.cpp:150: error: ‘struct gsm_mncc_rtp’ has no member named ‘payload_msg_type’ gsm.cpp:150: error: ‘struct gsm_mncc_rtp’ has no member named ‘payload_type’ gsm.cpp:151: error: ‘struct gsm_mncc_rtp’ has no member named ‘msg_type’ gsm.cpp: In member function ‘void Pgsm::setup_cnf(unsigned int, unsigned int, gsm_mncc*)’: gsm.cpp:500: error: ‘struct gsm_mncc_rtp’ has no member named ‘msg_type’ gsm.cpp: In member function ‘void Pgsm::rtp_create_ind(unsigned int, unsigned int, gsm_mncc*)’: gsm.cpp:649: error: ‘struct gsm_mncc_rtp’ has no member named ‘ip’ gsm.cpp:649: error: ‘struct gsm_mncc_rtp’ has no member named ‘port’ gsm.cpp:650: error: ‘struct gsm_mncc_rtp’ has no member named ‘ip’ gsm.cpp:651: error: ‘struct gsm_mncc_rtp’ has no member named ‘port’ gsm.cpp:656: error: ‘struct gsm_mncc_rtp’ has no member named ‘ip’ gsm.cpp:656: error: ‘struct gsm_mncc_rtp’ has no member named ‘port’ gsm.cpp: In member function ‘void Pgsm::rtp_connect_ind(unsigned int, unsigned int, gsm_mncc*)’: gsm.cpp:669: error: ‘struct gsm_mncc_rtp’ has no member named ‘ip’ gsm.cpp:669: error: ‘struct gsm_mncc_rtp’ has no member named ‘port’ gsm.cpp:670: error: ‘struct gsm_mncc_rtp’ has no member named ‘ip’ gsm.cpp:671: error: ‘struct gsm_mncc_rtp’ has no member named ‘port’ make[1]: *** [gsm.o] Error 1 make[1]: Leaving directory `/usr/src/lcr' make: *** [all] Error 2

2 2

OsmoDevCon preliminary schedule
by Harald Welte 24 Feb '12

24 Feb '12

Hi all! = Schedule = I've put together a preliminary schedule for OsmoDevCon. It can be seen at http://laforge.gnumonks.org/tmp/OsmoDevCon.ics or as a html rendering at http://laforge.gnumonks.org/tmp/OsmoDevCon.html Pleaes notice that there is still a lot of flexibility, let me know if I forgot anything or if there is something missing. Please also note that there are some topics which were suggested and where there is an obvious speaker/moderator, but where that person probably doesn't really know anything about having to talk about that topic yet (e.g. Holgers work on cellmgr-ng, Smalltalk projects, ...). So please don't be too surprised if you find your name somewhere. We will probably want to talk about the topic, whether you will have time to prepare some slides or not ;) If somebody knows a good way to render a nice overview HTML table from the .ics file, I would appreciate that, as it would give a better overview. I've attached a icedove screenshot for your reference meanwhile. = Arrival / Departure = We are starting at 11am on friday, for people who arrive that very morning in Berlin. There are no scheduled talks/discussions after the lunch break on monday, but we still have the room until monday night, so feel free to stay around for more unscheduled discussions and hacking. = Meals = == Lunch == We will probably have sponsored lunches on one or two days brought by catering into c-base, but apart from that all meals will be on your own expense. Nevertheless we could try to organize something (like ordering large pizzas) and then share the cost. This would avoid the time delays associated with having to go to a restaurant, make an order, wait for the food, go back to c-base, etc. == Dinner == All I could offer with regard to dinner is to make reservations in not-too-far-away restaurants, where we could go together. Please let me know if I should take care of that or rather not. 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)

7 18

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC