July 2010 - OpenBSC - lists.osmocom.org

New utility for drawing protocol ladder diagrams

by Harald Welte

Hi! With the help of graphviz, I have written a small perl-based tool that allows you to generate ladder diagrams. It can be found at git://git.osmocom.org/gen_ladder.git For your reference, I'm attaching a sample input and output file. The bent/curved arrows are a result of graphviz trying to indicate that the message is between e.g. MS and MSC and 'bypasses' BTS and BSC. I'm still waiting for somebody with more graphviz skills to make this an option. Hope this is useful for some of you... -- - 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, 2 months

2
1
0 0

Proposed OpenBSC application interface

by Harald Welte

Hi! Collin Mulliner, Tobias Engel and myself have been meeting yesterday to discuss a generic application interface for OpenBSC. They are both doing security analysis and want to achieve a clean way how an external application can get access to a more or less transparent communication channel to the phone. The purpose of this is to be able to send intentionally malformed packets to the mobile phone GSM stack at various different levels within the stack. As of now, they have both hacked some custom code into openbsc that gets them half way where they want to be - but not quite all the way. The requirements can be summarized as follows: 1) Ability to establish a SDCCH or TCH channel by paging the phone As of now, the 'silent call' feature from the VTY already does this. 2) Ability to send arbitrary layer3 protocol messages to the phone Adding this is relatively easy (use rsl_sendmsg on the lchan from the silent call) 3) Ability to receive responses from the phone, as well as error conditions such as 'readio link failure'. We don't have a solution for this yet, and we also have no clean way to identify what might be a response from the phone to the external app, and what might be a message from the phone to the normal network code in OpenBSC 4) Ability to selectively disable partial protocol handling in OpenBSC. Let's say you want to play with the mobile phone call control implementation. In this case, you want to make sure all CC related messages go from/to the external program and not from the regular OpenBSC network code. So what I've been thinking of as a solution to the problem: * store a bypass_flags bitmask related to the subscriber structure, where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC, BYPASS_SAPI3. * if we process an incoming message from the MS in gsm0408_rcvmsg(), we check if a bypass flag matching the message is found. If yes, forward the message to the external program * if we want to send a message from our own protocol stack to the MS, we check if a bypass flag matching the message is found. If yes, we drop the message that we were about to send. * any messages received from the application will be forwarded to the MS The application interface protocol will likely have a close resemblance to RSL RLL. We need to exchange the following primitives with the application, like: * ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI) * ESTABLISH CONFIRM -- network confirms a channel has been established * ESTABLISH INDICATION -- network tells app connection was made by MS * [UNIT] DATA REQUEST -- app requests data to be sent to MS * [UNIT] DATA INDICATION -- network indicates data was received from MS * ERROR INDICATION -- network tells app something went wrong * RELEASE REQUEST -- app asks network to release channel * RELEASE CONFIRM -- net tells app that channel was released (as rqd) * RELEASE INDICATION -- net tells app that channel was released (by MS) The channel_number of RSL (indicating on-air timeslot) doesn't make much sense in this context, of course. The link_identifier on the other hand is great as it allows the app to indicate SDCCH/FACCH or SACCH as well as the SAPI. The actual RSL-like protocol would be encapsulated by UDP and available on a socket of the MSC. What do you think? 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, 3 months

3
9
0 0

RFC: Relicensing OpenBSC under AGPLv3

by Harald Welte

Hi all! This subject came to my attention again recently: Why not relicense OpenBSC under AGPLv3? Right now we are licensing under GPLv2+ (v2 or any later version). However, if an operator was to make lots of private modifications and then operate it on his own network, there would be no distribution and thus no need for him to release his modified versions of the source code. This may sound a bit strange to those who have been with the project since its early days. But we are reaching production quality now, and we already have the first number of production deployments of the software. Companies like Netzing and On-waves have been FOSS-friendly and funding parts of our development effort. They have no issues with the result being Free Software again. However, there are definitely other companies out there who are less fond of sharing... So thus my idea is to put OpenBSC under AGPLv3. This way whoever uses OpenBSC _in modified form_ to operate a communications network will have to provide the source code to that modified form on a network server at no charge. The only controversial question to me is "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source". 1) does a gsm network count as computer network? i'd say yes. 2) is using a gsm network 'interacting with it remotely'? I'd also say yes 3) what does 'prominently offer' mean in the context of GSM? We don't want the operator to spam their users with advertisement SMS just to know that they can get the soruce code, after all. Notwithstanding those open questions, such a network operator would always have the option of simply sending back his changes for integration in the official project - and thus he would no longer use a modified version which then means there is no need for the prominent notice / download at all. We can make this very clear in the project documentation, putting further encouragement The actual relicensing should be less problematic than I thought, since AGPLv3 is compatible with GPLv3. So I could re-license all parts that I own copyright on (which should be the majority of the code base anyway) under AGPLv3, while the former GPLv2+ components (like VTY code from zebra, or contributions by other people) then become GPLv3-or-later. Of course I would want to encourage all developers/contributors to also follow the re-licensing. Particularly Holger Freyther, Dieter Spaar, Andreas Eversberg, Jan Luebbe, Sylvain Munaut, Daniel Willmann, Stefan Schmidt. So let's start with a poll: a) Do you think re-licensing to AGPLv3 is a good idea? b) If you have contributed, would you re-license your code under AGPLv3? If we have some kind of concesus in the community, I would approach On-waves whether they would want to do the same for their share of the copyright. As their "modifications" are all part of OpenBSC git repository, they would not be subject to any different conditions than before. Thanks in advance for your feedback, 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, 4 months

3
5
0 0

[PATCH 0/1] Add bport0/1 support for bs11_config

by Daniel Willmann

Hello, second try to add support to bs11_config for bport0/1 configuration. This time with enum abis_bs11_line_cfg. It seems sometimes creating bport1 fails, even LMT shows create obj greyed out. Don't know why yet. Regards, Daniel Willmann Daniel Willmann (1): Add {create,delete}-bport1 and bport0-{star,multidrop} to bs11-config openbsc/include/openbsc/abis_nm.h | 10 +++++++++- openbsc/src/abis_nm.c | 31 +++++++++++++++++++++++++++++-- openbsc/src/bs11_config.c | 26 ++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 3 deletions(-)

13 years, 5 months

4
5
0 0

Wanted: Osmocom logo

by Harald Welte

Hi! It's about time that we find some kind of graphical project logo for the Osmocom project. Osmocom is intended as an umbrella project for software like OpenBSC, OsmoSGSN, OsmocomBB and others. So it might even be interesting to have some kind of 'family' of logos that all have the same general theme.... At least the bigger projects like OpenBSC and OsmocomBB definitely deserve their own incarnation within that family. If you want to contribute to our project but are not a die-hard C developer, this is your option to contribute! The logo must be under a license that permits use+modification for the Osmocom project itself. Editability for the general public is not important. With regard to formats, I would prefer something as SVG that we can then render into pngs of various sizes whenever there is demand for it. If you have a proposal, simply send it (or a link to a URL) to the openbsc(a)lists.gnumonks.org mailing list. Thanks in advance for any submissions! -- - 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, 9 months

11
20
0 0

Channel Release Changes to Master

by Holger Freyther

Hi all, I have merged the Channel Release changes that were prototyped/used in the on-waves/bsc-master branch and basic testing shows that it is working. If you see weird things happening, please tell me and I try to figure out if it is due the changes I made or not. The problem I tried to solve was this: Assume a phone sends a SMS (allocates SAPI=3) and then we do release the channel. Now this can happen with a nanoBTS (and I think it is a bug): BSC BTS/MS RF Channel Release -> <- RF Channel Release Ack <- Release Indication SAPI=0 <- Release Indication SAPI=3 The OpenBSC code used to declare the lchan as available with the RF Channel Release ACK, we also decided to release the channel with the SAPI release indication.. So we were sending a RF Channel Release twice... Now with a loaded cell we could have re-allocated this lchan and then we release someone's else lchan... I was seeing from RF Failures, to BTS crashes with two concurrent phones doing call testing.. Our release procedure now works like this: chan_alloc.c is called to release the lchan. 1.) we remember the release reason and if we should send a SACH deactivate 2.) we declare the channel to be in state release request 3.) we start to release the highest allocated SAPI != 0 (well only three) 4.) from abis_rsl.c we will call to chan_alloc.c in case a SAPI got released and repeat 3rd). 5.) If only SAPI=0 is left we either release or send a SACH deactivate.. 6.) we send a RF Channel Release...

13 years, 9 months

1
0
0 0

New cellmgr-ng git repository filled with content

by Holger Hans Peter Freyther

Hi all, I have just pushed some code to a public repository. It was written to run on an embedded Linux platform and convert from E1/MTP-Level1 to TCP/IP. Besides being hacky (I had to do more than initially planned) it provides some code for MTP-Level3 and handles the link test (SLTM/SLTA). The code is using a library that has only existed for a couple of days and need to be ported to libosmocore, the new vty code and such, it will eventually happen. regards holger

13 years, 9 months

1
0
0 0

AW: OpenBSC+LCR+Asterisk: I got it!

by Andreas.Eversberg

i did not write this howto, also i have no access to change it anyway. > To use in extensions.conf is: > > [btsctrl] > exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4) > exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)}) > exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG}) > exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120) > > So can I define a prefix (02) for mobiles and forward the calls to LCR. > > Maybe help someone other having my problem. > I suggest Andreas Everberg to update his HowTo...

13 years, 9 months

1
0
0 0

AW: OpenBSC+LCR+Asterisk: I got it!

by Andreas.Eversberg

hi, what howto do you mean? can you give me the link to it? regards, andreas > To use in extensions.conf is: > > [btsctrl] > exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4) > exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)}) > exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG}) > exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120) > > So can I define a prefix (02) for mobiles and forward the calls to LCR. > > Maybe help someone other having my problem. > I suggest Andreas Everberg to update his HowTo...

13 years, 9 months

1
0
0 0

Unable to configure a BTS

by Luca Bertoncello

Hi, again! So, as I said in my last E-Mail, I got a new BTS (DSC1800). Now I have to configure it, so I started ipaccess-find to get his IP and then ipaccess-config to configure it. I get this error: lucabert@Luca:/tmp$ ipaccess-config -u 151/0/0 -o 192.168.1.18 192.168.1.108 ipaccess-config (C) 2009-2010 by Harald Welte and others This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY Trying to connect to ip.access BTS ... Lost some E1 TEI link Lost some E1 TEI link Segmentation fault Can someone say me what is the problem? Thanks! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 9 months

5
27
0 0

Detect phone calls

by Luca Bertoncello

Hi, list! Of course OpenBSC knows which phone-calls there are right now. I'd like to get this list. How can I do this? Thanks a lot! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 9 months

3
4
0 0

Re: PATCH/RFC use recvfrom with MSG_TRUNC as flag

by Dieter Spaar

Hello Holger, On Fri, 23 Jul 2010 21:38:36 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote: > > PS: How big is your diff to make it compile on Windows? I have not ported the TUN calls yet. My last try for OpenBSC plus GPRS was in a Linux VM, however I had problems there with the TUN interface. I could see outgoing packets with proper NAT translation (the DNS queries from the phone) and I could also see the DNS replies "outside" the VM but they never got through to the TUN interface. Maybe its a problem related to the VM, but after this experience I decided to wait playing with the TUN interface on Cygwin because it probably makes sense to have a running reference system first. BTW, anyone having OpenBSC plus GPRS running on MacOS X ? Thats the closest to Unix I have here besides a VM. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 9 months

1
0
0 0

[PATCH] Subscriber data in measurement report

by Luca Bertoncello

I find the measurement report of OpenBSC very difficult to read, because it is not possible to distinguish the various phones. Of course, it is possible to filter the log (logging filter imsi ...), but sometimes, as in my case, it is necessary to get the measurement reports of many phones at the same time. In this case, it is not possible to know which phone generate which report. I create a patch to solve this problem. With this patch, the measurement reports contain the lchan in which the call (or SMS) runs (just as information), the IMSI and the extension of the phone. If you are interested, here is it! Greetings -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 9 months

1
0
0 0

Re: PATCH/RFC use recvfrom with MSG_TRUNC as flag

by Dieter Spaar

Hello Holger, On Fri, 23 Jul 2010 19:07:55 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote: > > Dieter do you know if cygwin will silently ignore the MSG_TRUNC > flag or if you will have a problem on Window? Thanks for asking. According to what I found so far, Cygwin should support MSG_TRUNC. However considering the fact that there is much more to do to get OpenBSC and GPRS running under Cygwin (porting the calls to access the TUN interface in OpenGGSN), one more obstacle should not really care ;-) (I guess I am the only one who uses OpenBSC on Cygwin). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 9 months

2
1
0 0

PATCH/RFC use recvfrom with MSG_TRUNC as flag

by Holger Hans Peter Freyther

Hi Harald, Dieter, what do you think of using MSG_TRUNC and checking if we have truncated our packets in a recv call? Dieter do you know if cygwin will silently ignore the MSG_TRUNC flag or if you will have a problem on Window? diff --git a/openbsc/src/gprs/gprs_ns.c b/openbsc/src/gprs/gprs_ns.c index 3db1d67..ab2d937 100644 --- a/openbsc/src/gprs/gprs_ns.c +++ b/openbsc/src/gprs/gprs_ns.c @@ -867,7 +867,7 @@ static struct msgb *read_nsip_msg(struct bsc_fd *bfd, int *error, return NULL; } - ret = recvfrom(bfd->fd, msg->data, NS_ALLOC_SIZE - NS_ALLOC_HEADROOM, 0, + ret = recvfrom(bfd->fd, msg->data, NS_ALLOC_SIZE - NS_ALLOC_HEADROOM, MSG_TRUNC, (struct sockaddr *)saddr, &saddr_len); if (ret < 0) { LOGP(DNS, LOGL_ERROR, "recv error %s during NSIP recv\n", @@ -879,6 +879,11 @@ static struct msgb *read_nsip_msg(struct bsc_fd *bfd, int *error, msgb_free(msg); *error = ret; return NULL; + } else if (ret > NS_ALLOC_SIZE - NS_ALLOC_HEADROOM) { + LOGP(DNS, LOGL_ERROR, "truncated msg. real size is: %d\n", ret); + msgb_free(msg); + *error = -ENOSPC; + return NULL; } msg->l2h = msg->data;

13 years, 9 months

1
0
0 0

Problem to compile the last version of OpenBSC

by Luca Bertoncello

Hi, list! A very strange problem... Today I got a new BTS (DSC1800) and I tried to configure it. Unfortunately it does not respond correctly (I'll send a separate E-Mail about this problem), so I decided to try with the last version of OpenBSC (maybe a bug in ipaccess-config?). Unfortunately I can't compile it. I get these errors: gcc -Wall -I/usr/local/include/ -I/usr/local/include/ -g -O2 -L/usr/local/lib -losmocore -o bsc_hack bsc_hack.o bsc_init.o bsc_vty.o vty_interface_layer3.o libmsc.a libbsc.a libvty.a libmsc.a -ldl -ldbi -L/usr/local/lib -losmovty -lcrypt bsc_init.o:(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here bsc_vty.o:(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here vty_interface_layer3.o:(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(gsm_subscriber.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(db.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(mncc.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(gsm_04_08.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(gsm_04_11.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(transaction.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(token_auth.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(rrlp.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(ussd.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(silent_call.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(handover_decision.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(auth.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(osmo_msc.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libmsc.a(gsm_04_80.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(abis_rsl.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(abis_nm.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(gsm_data.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(gsm_04_08_utils.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(chan_alloc.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(debug.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(abis_nm_vty.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(gsm_subscriber_base.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(bsc_rll.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(trau_mux.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(paging.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(e1_config.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(e1_input.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(misdn.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(ipaccess.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(handover_logic.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(talloc_ctx.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(system_information.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(rest_octets.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(rtp_proxy.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(bts_siemens_bs11.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(bts_ipaccess_nanobts.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(bts_unknown.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(bsc_api.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(meas_rep.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(socket.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libbsc.a(subchan_demux.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here libvty.a(common_vty.o):(.data+0x0): multiple definition of `gsm_7bit_alphabet' bsc_hack.o:(.data+0x0): first defined here collect2: ld gab 1 als Ende-Status zurück make[3]: *** [bsc_hack] Fehler 1 make[3]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc' make: *** [all] Fehler 2 Can someone confirm me, that the problem is in this version and not in my PC? Thanks -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 23 Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 9 months

2
2
0 0

libosmocore now abort()s on msgb overflow/underflow

by Harald Welte

Hi! I've just committed a patch that will cause libosmocore to abort in case we try to msgb_put() beyond the end fo the buffer or msgb_push() ahead of the start. I hope we can uncover any hidden buffer under/overflows this way, if they exist. 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, 9 months

1
0
0 0

installing openbsc on opensuse

by jason mercury

Hi to all, I want to use openbsc on opensuse linux. What procedure shoul i follow? Thanks. Jason

13 years, 9 months

2
1
0 0

Switch with PowerOverEthernet for a BaseStation

by Luca Bertoncello

Hi, list! We have actually 4 BaseStation (but in the future we will buy at least other 2). Now want my Boss to buy a PoE-Switch at which we connect all BaseStation. This Switch has to supply power, too. Now, I'm not sure (I don't know PoE in detail) if I can use every PoE-Switch. I searched in Internet and I found a Netgear FS108P. It's cheap and it will be enough for us. Can I use it with our BaseStation or have I to use the power supplier of the BaseStations, too? Thanks a lot for your answers! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 10 months

4
6
0 0

[PATCH] tests: don't hardcode length values of expected encoding gsm_7bit_encode: make sure to return the number of actually written bytes gsm_7bit_decode: calculate length of resulting septets from input length before decoding

by Nico Golde

The input length to gsm_7bit_decode reflects the number of encoded bytes to be decoded. As the decoding is done on the input in septetes we need to take this into account and recalculate the length. --- src/gsm_utils.c | 10 ++++++---- tests/sms/sms_test.c | 21 ++++++++++----------- 2 files changed, 16 insertions(+), 15 deletions(-) diff --git a/src/gsm_utils.c b/src/gsm_utils.c index 3a378ac..818655e 100644 --- a/src/gsm_utils.c +++ b/src/gsm_utils.c @@ -49,21 +49,23 @@ static int gsm_septet_lookup(uint8_t ch) /* GSM 03.38 6.2.1 Character unpacking */ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t length) { - int i = 0; + int i = 0,y; int l = 0; + int septet_l = (length * 8) / 7; uint8_t *rtext = calloc(length, sizeof(uint8_t)); uint8_t tmp; /* FIXME: We need to account for user data headers here */ i += l; - for (; i < length; i ++){ + for (; i < septet_l; i++){ rtext[i] = ((user_data[(i * 7 + 7) >> 3] << (7 - ((i * 7 + 7) & 7))) | (user_data[(i * 7) >> 3] >> ((i * 7) & 7))) & 0x7f; } - for(i = 0; i < length; i++){ + + for(i = 0; i < septet_l; i++){ /* this is an extension character */ if(rtext[i] == 0x1b && i + 1 < length){ tmp = rtext[i+1]; @@ -139,7 +141,7 @@ int gsm_7bit_encode(uint8_t *result, const char *data) } free(rdata); - return i; + return z; } /* determine power control level for given dBm value, as indicated diff --git a/tests/sms/sms_test.c b/tests/sms/sms_test.c index 3742dd8..9d87b5b 100644 --- a/tests/sms/sms_test.c +++ b/tests/sms/sms_test.c @@ -37,7 +37,7 @@ struct test_case { static const char simple_text[] = "test text"; static const uint8_t simple_enc[] = { - 0xf4, 0xf2, 0x9c, 0x0e, 0xa2, 0x97, 0xf1, 0x74, 0x00, + 0xf4, 0xf2, 0x9c, 0x0e, 0xa2, 0x97, 0xf1, 0x74 }; static const char escape_text[] = "!$ a more#^- complicated test@@?_\%! case"; @@ -46,7 +46,6 @@ static const uint8_t escape_enc[] = { 0x86, 0xd2, 0x02, 0x8d, 0xdf, 0x6d, 0x38, 0x3b, 0x3d, 0x0e, 0xd3, 0xcb, 0x64, 0x10, 0xbd, 0x3c, 0xa7, 0x03, 0x00, 0xbf, 0x48, 0x29, 0x04, 0x1a, 0x87, 0xe7, 0x65, - 0x00, 0x00, 0x00, 0x00, 0x00 }; static const struct test_case test_encode[] = @@ -54,12 +53,12 @@ static const struct test_case test_encode[] = { .input = simple_text, .expected = simple_enc, - .expected_length = 9, + .expected_length = sizeof(simple_enc), }, { .input = escape_text, .expected = escape_enc, - .expected_length = 41, + .expected_length = sizeof(escape_enc), }, }; @@ -67,12 +66,12 @@ static const struct test_case test_decode[] = { { .input = simple_enc, - .input_length = 9, + .input_length = sizeof(simple_enc), .expected = simple_text, }, { .input = escape_enc, - .input_length = 41, + .input_length = sizeof(escape_enc), .expected = escape_text, }, }; @@ -89,13 +88,13 @@ int main(int argc, char** argv) char result[256]; /* test 7-bit encoding */ - for (i = 0; i < ARRAY_SIZE(test_encode); ++i) { - memset(coded, 0, sizeof(coded)); + for (i = 0; i < ARRAY_SIZE(test_encode); ++i) { + memset(coded, 0x42, sizeof(coded)); length = gsm_7bit_encode(coded, test_encode[i].input); if (length != test_encode[i].expected_length) { - fprintf(stderr, "Failed to encode case %d. Got %d\n", - i, length); + fprintf(stderr, "Failed to encode case %d. Got %d, expected %d\n", + i, length, test_encode[i].expected_length); return -1; } @@ -108,7 +107,7 @@ int main(int argc, char** argv) /* test 7-bit decoding */ for (i = 0; i < ARRAY_SIZE(test_decode); ++i) { - memset(result, 0, sizeof(coded)); + memset(result, 0x42, sizeof(coded)); gsm_7bit_decode(result, test_decode[i].input, test_decode[i].input_length); -- 1.7.1 --7JfCtLOvnd9MIVvH--

13 years, 10 months

1
0
0 0

[PATCH] * when comparing the coded result with the expected coded values, do not compare n bytes where n is the result of gsm_7bit_encode() but the actual length of the input string as gsm_7bit_encode() returns the number of septets not octets

by Nico Golde

--- tests/sms/sms_test.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/sms/sms_test.c b/tests/sms/sms_test.c index 3742dd8..cab91ab 100644 --- a/tests/sms/sms_test.c +++ b/tests/sms/sms_test.c @@ -99,7 +99,7 @@ int main(int argc, char** argv) return -1; } - if (memcmp(coded, test_encode[i].expected, length) != 0) { + if (memcmp(coded, test_encode[i].expected, strlen(test_encode[i].expected)) != 0) { fprintf(stderr, "Encoded content does not match for %d\n", i); return -1; -- 1.7.1 --Kj7319i9nmIyA2yE--

13 years, 10 months

1
0
0 0

Re: RFC about Osmcoom TCAP / MAP implementation

by mosbah abdelkader

Hello, Is the source code made public.

13 years, 10 months

2
2
0 0

RFC about Osmcoom TCAP / MAP implementation

by Harald Welte

Hi! As some of you will have noticed, I've been working hard on a TCAP implementation. As this is now getting into pretty good shape, I'm looking at implementing MAP. Right now I'm trying to come up with a good design to implement both MAP client (let's say a SGSN or MSC that issues a Location Updating Request) and server applications (think of HLR receiving + processing the Loc Upd Req). The full flow of primitives can be seen in the attached diagram (which by the way was designed unsing the new gen_ladder tool from git://git.osmocom.org/gen_ladder.git). In TCAP, it is relatively hard to grasp that every message consists of a dialogue part and an (optional) collection of component parts. The dialogue and component state machines are separate but interact. Since a lot of functionality is possibly contained in one PDU, this ladder diagram does not really care about actual messages/packets, but about the sequencing of primitives. First, terminology: client: A "request-side" client like a SGSN or MSC wanting to do loc upd libmap-cl: The libosmo-map instance at the client libtcap-cl: The libosmo-tcap instance at the client [between the two libtcap instances we have the signalling link] libtcap-srv: The libosmo-tcap instance at the server libmap-srv: The libosmo-map instance at the server server: The "responder-side" server like a HLR that receives loc upd 1) MAP-OPEN primitive is sent sent from client to libosmo-map. Note that no actual packets are exchanged on the signalling linke yet! 2) two MAP-INVOKE component requests are sent to libosmo-map. They contain the actual location updating requests (two of them for two different MS) 3) MAP-DELIMITER.req primitive is issued by client to libosmo-map. At this point, a TCAP TC-BEGIN.req primitive is issued to libosmo-tcap. libosmo-tcap assembles a TCAP message consisting of a TC-BEGIN dialogue portion (including loc upd req application context) containing two TC-INVOKE components. This message is sent over the signalling link. 4) The server libosmo-tcap receives the TC-BEGIN message with two TC-INVOKE components. It issues a TC-BEGIN.indication to libosmo-map, which in turn generates a MAP-OPEN.indicatin for the server application 5) The server application checks if it supports the application context and then confirms the MAP-OPEN by a MAP-OPEN.response primitive. This primitive is "cached" at libosmo-map at that time. 6) the server libosmo-tcap sends the first TC-INVOKE.indication to libosmo-map which forwards it to the server application. the application respondes with a 'result-last' primitive that is passed up to libosmo-tcap 7) the server libosmo-tcap sends the second TC-INVOKE.indication to libosmo-map which forwards it to the server application. the application respondes with a 'result-last' primitive that is passed up to libosmo-tcap Since this TC-INVOKE.ind is flagged as 'last', libosmo-map will issue a MAP-DELIMITER.indication to the server program. 8) The server application responds with MAP-DELIMITER.request, which triggers libosmo-map to issue a TC-CONTINUE.request, which in turn triggers generating the TCAP TC-CONTINUE message containing the two TC-RESULT-Last components [...] This primitive sequencing is mandated by the combination of the ITU-T Q.77x specifications and the GSM TS 09.02 / 29.002. Now the task at hand is to decide on the software architecture and which parts have to be handled synchronously or not. It was my idea to pass everything by-value at the libosmo-tcap/libosmo-map interface. While they both keep state information, I do not want to pass any information by reference at thee inter-layer boundaries. This might cause headaches in memory management (reference counting, etc.) Another aspect is that the actual execution of the function (e.g. location updating operation) might not be finished synchronously. If the server process implements a HLR, the HLR might be implemented as on-disk storage (e.g. SQL). In that case, the MAP-INVOKE.ind containing the location update will trigger some disk access. Only once that disk access has finished, the corresponding MAP-RESULT-L.req can be generated. The rough idea would be to have a queue of those tcap<->map primitives. This way, we could have single-threaed or (with proper locking) a thread pool approach, where each thread then dequeues one primitive, processes it, and sends a response primitive once it is finished. Any feedback/comments to this proposed architecture are most welcome. 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, 10 months

1
1
0 0

AW: LCR crashes. Please help me!

by Andreas.Eversberg

hi luca, it seems that there is a change in the API. therefore i prepared a "snapshot" at www.linux-call-router.de to be downloaded. this version of openbsc and lcr is older, but works together. as soon as the current openbsc has been tested more (channel ressource handling has changed for example), i will make it work again. regards, andreas > #0 0x0805b009 in gsm0408_rcvmsg (msg=0x864ffb8, link_id=0 '\0') at openbsc/src/bsc_api.c:111 > 111 rc = api->compl_l3(lchan->conn, msg, 0); > > The problem seems to be the variable api, which is NULL. > > (gdb) print api > $1 = (struct bsc_api *) 0x0

13 years, 10 months

4
5
0 0

OpenBSC+LCR+Asterisk: I got it!

by Luca Bertoncello

Hi, List! I got it! Now can I call mobile phones with Asterisk. If someone is interested, the problem was in the Asterisk-configuration (from HowTo). To use in extensions.conf is: [btsctrl] exten => _02X.,1,GotoIf($[${CALLERID(name)} != ""]?4) exten => _02X.,2,Set(CALLIDORIG=${CALLERID(num)}) exten => _02X.,3,Set(CALLERID(num)=02${CALLIDORIG}) exten => _02X.,4,Dial(LCR/GSM/${EXTEN:2},120) So can I define a prefix (02) for mobiles and forward the calls to LCR. Maybe help someone other having my problem. I suggest Andreas Everberg to update his HowTo... And now the next problem: calling a VoIP-phone from mobile phone... :) I'll get it, too! Bye -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 10 months

1
0
0 0

Re: [BUG REPORT]: Unable to send SMS

by Dieter Spaar

Hello Luca, On Wed, 14 Jul 2010 11:22:05 +0200, "Luca Bertoncello" <bertoncello(a)netzing.de> wrote: > > I can confirm, that "neci 1" solve my problem! > I can call and send SMS without any problem, from the NE110, too! Great to hear that. I am not sure how well OpenBSC is tested with NECI set to "1" but I guess it should not cause too many problems, its only the channel allocator which behaves differently. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 10 months

1
0
0 0

Re: [BUG REPORT]: Unable to send SMS

by Dieter Spaar

Hello Holger, On Wed, 14 Jul 2010 17:52:51 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote: > > maybe I was too blind and didn't see it in GSM 04.08, but setting NECI=1 > will not allow us to assign a TCH/F for MO Call. What about this: 0100xxxx Originating speech call from dual-rate mobile station when TCH/H is sufficient and supported by the MS for speech calls and the network sets NECI bit to 1 At least this is what the Nokia 3310 uses for a voice call. OpenBSC should than allocate a TCH for it. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 10 months

2
1
0 0

Re: [BUG REPORT]: Unable to send SMS

by Dieter Spaar

Hello Harald, On Tue, 13 Jul 2010 16:06:55 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > The Netzing NE110 (as well as other MTK phones) seem to have a bug in > their MO-SMS code. Dieter has told me he is looking at a workaround to this > (by sending dummy authentication request/response), and he will e-mail this > list once he has some results. This was a tough one. I tried Authentication and Ciphering commands in various combinations without any success. Finally I changed the allocated channel to SDCCH instead of TCH. And voila, it worked, even without Authentication and/or Ciphering. So it seems that there is a problem with MTK phones (and maybe others) and MO-SMS on a TCH channel. I am not sure yet if there is a workaround to solve this and still use the TCH. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 10 months

3
2
0 0

Re: [BUG REPORT]: Unable to send SMS

by Dieter Spaar

Hello Holger, On Wed, 14 Jul 2010 14:56:27 +0800, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote: > > do you remember which kind of channel the phone is requesting? is it > really asking for a channel for calls? Yes, the phone always sets the mask according to this (from the spec): 111xxxxx Originating call and TCH/F is needed, or originating call and the network does not set NECI bit to 1, or procedures that can be completed with a SDCCH and the network does not set NECI bit to 1 This was the same for other phones, not just MTK based phones. NECI was set to 0, however I think that setting NECI to 1 might be the solution for the problem, without the need to change the Very Early Assignment procedure. I have not yet tested this in detail, so I might miss something. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 10 months

2
1
0 0

Re: [BUG REPORT]: Unable to send SMS

by Dieter Spaar

Hello Luca, On Wed, 14 Jul 2010 10:04:05 +0200, "Luca Bertoncello" <bertoncello(a)netzing.de> wrote: > > Wow! It works! And I can send SMS with the NE110 phones too! > Maybe could it be a solution to set lctype to GSM_LCHAN_SDCCH if the > phone tried to send an SMS? Harald probably knows the details better, but the basic problem is that the phone does not tell you exactly what channels it needs when it sends the Channel Request, at least if NECI is set to 0 (new establishment causes are not supported). So the channel allocator allocates a TCH channel, to be able to handle everything (SMS and Voice). One solution for this is to switch from Very Early Assignment to other assignment procedures. I think Holger and Harald have plans to support this. However there also seems to be a different solution: You can set NECI to 1, this way the phone can tell you in more detail what it wants. I have not done extensive tests, but it seems that this could solve the problem without the need to change the code. You just have to set "neci 1" in the OpenBSC configuration file. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 10 months

2
2
0 0

Re: [BUG REPORT]: Unable to send SMS

by Dieter Spaar

Hello Luca, On Wed, 14 Jul 2010 08:45:49 +0200, "Luca Bertoncello" <bertoncello(a)netzing.de> wrote: > > Of course! I tested OpenBSC with GSM1800, too. And, unfortunately, it > does not work... Attached the pcap-file and the config of OpenBSC. > Here some information from ipaccess-find: If you want to find out if the SMS sending problem is related to what I posted yesterday, you can try the following: In "/src/abis_rsl.c", function "rsl_rx_chan_rqd()" replace the line lctype = get_ctype_by_chreq(bts, rqd_ref->ra, bts->network->neci); with lctype = GSM_LCHAN_SDCCH; This will always allocate an SDCCH and you can check if SMS sending now works. However this is only for testing, voice calls will no longer work with this change. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 10 months

2
1
0 0

Re: [BUG REPORT]: Unable to send SMS

by Luca Bertoncello

Am Wed, 23 Jun 2010 20:18:56 +0800 schrieb Holger Freyther <zecke(a)selfish.org>: > the first pointer is to the sha1/commit id[1]. So every commit has an > id, it happens to be the sha1 hash over some parts of the content. Now > git log will show all these as "commit". Now the openbsc version is > generated by the little "./git-version-gen" utility. In fact the > utility is calling "git describe" (man git-describe). > > E.g. it looks like this: > 0.9.0-891-gaf7edd9 > > 0.9.0 is the last tag we had.. > 891 is the number of commits since that tag > gaf7edd9 is the commit/sha1. This is what you want. > > I hope this helps Unfortunately not... I tried to give git-describe in the tree of the "sms-sending"-BSC (0.9.0-531-gb938d6b) and in the tree of the last version (0.9.0-890-g2788b96), then I tried to use git bisect: lucabert@Luca:/tmp/bsc/openbsc$ git bisect good gb938d6b Bad rev input: gb938d6b lucabert@Luca:/tmp/bsc/openbsc$ git bisect bad g2788b96 fatal: Needed a single revision Bad rev input: g2788b96 It seems not to work... Maybe I need vacancy? I can't understand what you suppose I can do... Thanks for your suggestion! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 10 months

4
28
0 0

[PATCH] * rewrite GSM 7bit default encoding/decoding based on a lookup table as the previous code produced wrong encodings for certain characters.

by Nico Golde

--- include/osmocore/gsm_utils.h | 28 ++++++++++++ src/gsm_utils.c | 99 +++++++++++++++++++++++++++++++++-------- tests/sms/sms_test.c | 17 +++++++- 3 files changed, 123 insertions(+), 21 deletions(-) diff --git a/include/osmocore/gsm_utils.h b/include/osmocore/gsm_utils.h index 7dc2388..64f9edc 100644 --- a/include/osmocore/gsm_utils.h +++ b/include/osmocore/gsm_utils.h @@ -3,6 +3,7 @@ * (C) 2008 by Daniel Willmann <daniel(a)totalueberwachung.de> * (C) 2009 by Holger Hans Peter Freyther <zecke(a)selfish.org> * (C) 2009-2010 by Harald Welte <laforge(a)gnumonks.org> + * (C) 2010 by Nico Golde <nico(a)ngolde.de> * * All Rights Reserved * @@ -53,6 +54,33 @@ enum gsm_band { GSM_BAND_810 = 0x80, }; +/* ETSI GSM 03.38 6.2.1 and 6.2.1.1 default alphabet + * Greek symbols at hex positions 0x10 and 0x12-0x1a + * left out as they can't be handled with a char and + * since most phones don't display or write these + * characters this would only needlessly make the code + * more complex +*/ +unsigned char gsm_7bit_alphabet[] = { + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0a, 0xff, 0xff, 0x0d, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0x20, 0x21, 0x22, 0x23, 0x02, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, + 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, + 0x3c, 0x3d, 0x3e, 0x3f, 0x00, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, + 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, + 0x5a, 0x3c, 0x2f, 0x3e, 0x14, 0x11, 0xff, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, + 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, + 0x78, 0x79, 0x7a, 0x28, 0x40, 0x29, 0x3d, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0x0c, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x40, 0xff, 0x01, 0xff, + 0x03, 0xff, 0x7b, 0x7d, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5b, 0x7e, 0x5d, 0xff, 0x7c, 0xff, 0xff, 0xff, + 0xff, 0x5b, 0x0e, 0x1c, 0x09, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5d, + 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0x0b, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0x1e, 0x7f, + 0xff, 0xff, 0xff, 0x7b, 0x0f, 0x1d, 0xff, 0x04, 0x05, 0xff, 0xff, 0x07, 0xff, 0xff, 0xff, + 0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff +}; + const char *gsm_band_name(enum gsm_band band); enum gsm_band gsm_band_parse(const char *mhz); diff --git a/src/gsm_utils.c b/src/gsm_utils.c index dc97cef..fb69377 100644 --- a/src/gsm_utils.c +++ b/src/gsm_utils.c @@ -2,6 +2,7 @@ * (C) 2008 by Daniel Willmann <daniel(a)totalueberwachung.de> * (C) 2009 by Holger Hans Peter Freyther <zecke(a)selfish.org> * (C) 2009-2010 by Harald Welte <laforge(a)gnumonks.org> + * (C) 2010 by Nico Golde <nico(a)ngolde.de> * * All Rights Reserved * @@ -34,52 +35,110 @@ #include "../config.h" -/* GSM 03.38 6.2.1 Charachter packing */ +/* GSM 03.38 6.2.1 Character lookup for decoding */ +static int gsm_septet_lookup(uint8_t ch) +{ + int i = 0; + for(; i < sizeof(gsm_7bit_alphabet); i++){ + if(gsm_7bit_alphabet[i] == ch) + return i; + } + return -1; +} + +/* GSM 03.38 6.2.1 Character unpacking */ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t length) { int i = 0; int l = 0; + uint8_t *rtext = calloc(length, sizeof(uint8_t)); + uint8_t tmp; - /* FIXME: We need to account for user data headers here */ + /* FIXME: We need to account for user data headers here */ i += l; - for (; i < length; i ++) - *(text ++) = + for (; i < length; i ++){ + rtext[i] = ((user_data[(i * 7 + 7) >> 3] << (7 - ((i * 7 + 7) & 7))) | (user_data[(i * 7) >> 3] >> ((i * 7) & 7))) & 0x7f; + } + for(i = 0; i < length; i++){ + /* this is an extension character */ + if(rtext[i] == 0x1b){ + tmp = rtext[i+1]; + *(text++) = gsm_7bit_alphabet[0x7f + tmp]; + i++; + continue; + } + + *(text++) = gsm_septet_lookup(rtext[i]); + } + *text = '\0'; + free(rtext); - return i - l; + return i; } +/* GSM 03.38 6.2.1 Prepare character packing */ +static int gsm_septet_encode(uint8_t *result, const char *data) +{ + int i, y = 0; + uint8_t ch; + for(i = 0; i < strlen(data); i++){ + ch = data[i]; + switch(ch){ + /* fall-through for extension characters */ + case 0x0c: + case 0x5e: + case 0x7b: + case 0x7d: + case 0x5c: + case 0x5b: + case 0x7e: + case 0x5d: + case 0x7c: + result[y++] = 0x1b; + default: + result[y] = gsm_7bit_alphabet[ch]; + break; + } + y++; + } -/* GSM 03.38 6.2.1 Charachter packing */ + return y; +} + +/* GSM 03.38 6.2.1 Character packing */ int gsm_7bit_encode(uint8_t *result, const char *data) { - int i,j = 0; - unsigned char ch1, ch2; + int i,y,z = 0; + /* prepare for the worst case, every character expanding to two bytes */ + uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t)); + uint8_t cb, nb; int shift = 0; - for ( i=0; i<strlen(data); i++ ) { + y = gsm_septet_encode(rdata, data); - ch1 = data[i] & 0x7F; - ch1 = ch1 >> shift; - ch2 = data[(i+1)] & 0x7F; - ch2 = ch2 << (7-shift); + for(i = 0; i < y; i++) { + if(shift == 7 && i + 1 < y){ + shift = 0; + continue; + } - ch1 = ch1 | ch2; + cb = (rdata[i] & 0x7f) >> shift; + if(i + 1 < y){ + nb = (rdata[i + 1] & 0x7f) << (7 - shift); + cb = cb | nb; + } - result[j++] = ch1; + result[z++] = cb; shift++; - - if ((shift == 7) && (i+1<strlen(data))) { - shift = 0; - i++; - } } + free(rdata); return i; } diff --git a/tests/sms/sms_test.c b/tests/sms/sms_test.c index f5183d5..4daf003 100644 --- a/tests/sms/sms_test.c +++ b/tests/sms/sms_test.c @@ -1,5 +1,6 @@ /* * (C) 2008 by Daniel Willmann <daniel(a)totalueberwachung.de> + * (C) 2010 by Nico Golde <nico(a)ngolde.de> * All Rights Reserved * * This program is free software; you can redistribute it and/or modify @@ -32,7 +33,7 @@ int main(int argc, char** argv) uint8_t *sms; uint8_t i; - /* test 7-bit coding/decoding */ + /* test 7-bit coding/decoding */ const char *input = "test text"; uint8_t length; uint8_t coded[256]; @@ -43,5 +44,19 @@ int main(int argc, char** argv) if (strcmp(result, input) != 0) { printf("7 Bit coding failed... life sucks\n"); printf("Wanted: '%s' got '%s'\n", input, result); + return -1; } + + memset(coded, 0, sizeof(coded)); + memset(result, 0, sizeof(coded)); + input = strdup("!$ a more#^- complicated test@@?_\%! case"); + length = gsm_7bit_encode(coded, input); + gsm_7bit_decode(result, coded, length); + if (strcmp(result, input) != 0) { + printf("7 Bit coding failed... life sucks\n"); + printf("Wanted: '%s' got '%s'\n", input, result); + return -2; + } + + return 0; } -- 1.7.1 --ibTvN161/egqYuK8--

13 years, 10 months

1
0
0 0

[PATCH] rewritten gsm 7 bit encoding

by Nico Golde

Hi, I've rewritten the GSM 7 bit default encoding as the current implementation results in wrong encoding for certain characters, e.g. '@'. The septet packing lacked the lookup and this only worked for characters that had a 1-1 mapping between their ascii value and the default alphabet table. I introduced a lookup table and now do the character translation before packing the data. Patch is attached. I guess the decoding needs to be rewritten as well and I may provide a patch for that in the future as well. For now the encoding produced enough headaches for me :) I adjusted the copyright stanza in these files but I'm not completely sure if this is appropriate or not, so feel free to remove, I won't be offended :) Cheers Nico

13 years, 10 months

6
15
0 0

[PATCH] * rewrite gsm_7bit_encode() based on a lookup table as the previous code produced wrong encodings for certain characters.

by Nico Golde

--- include/osmocore/gsm_utils.h | 28 ++++++++++++++++++ src/gsm_utils.c | 64 ++++++++++++++++++++++++++++++++---------- 2 files changed, 77 insertions(+), 15 deletions(-) diff --git a/include/osmocore/gsm_utils.h b/include/osmocore/gsm_utils.h index 7dc2388..661846a 100644 --- a/include/osmocore/gsm_utils.h +++ b/include/osmocore/gsm_utils.h @@ -3,6 +3,7 @@ * (C) 2008 by Daniel Willmann <daniel(a)totalueberwachung.de> * (C) 2009 by Holger Hans Peter Freyther <zecke(a)selfish.org> * (C) 2009-2010 by Harald Welte <laforge(a)gnumonks.org> + * (C) 2010 by Nico Golde <nico(a)ngolde.de> * * All Rights Reserved * @@ -53,6 +54,33 @@ enum gsm_band { GSM_BAND_810 = 0x80, }; +/* ETSI GSM 03.38 6.2.1 and 6.2.1.1 default alphabet + * Greek symbols at hex positions 0x10 and 0x12-0x1a + * left out as they can't be handled with a char and + * since most phones don't display or write these + * characters this would only needlessly make the code + * more complex +*/ +unsigned char gsm_7bit_alphabet[] = { + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0a, 0xff, 0x0a, 0x0d, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0x20, 0x21, 0x22, 0x23, 0x02, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, + 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, + 0x3c, 0x3d, 0x3e, 0x3f, 0x00, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, + 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, + 0x5a, 0x3c, 0x2f, 0x3e, 0x14, 0x11, 0xff, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, + 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, + 0x78, 0x79, 0x7a, 0x28, 0x40, 0x29, 0x3d, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0x24, + 0x03, 0xff, 0x5f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x60, 0xff, 0xff, 0xff, + 0xff, 0x5b, 0x0e, 0x1c, 0x09, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5d, + 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0x0b, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0x1e, 0x7f, + 0xff, 0xff, 0xff, 0x7b, 0x0f, 0x1d, 0xff, 0x04, 0x05, 0xff, 0xff, 0x07, 0xff, 0xff, 0xff, + 0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff +}; + const char *gsm_band_name(enum gsm_band band); enum gsm_band gsm_band_parse(const char *mhz); diff --git a/src/gsm_utils.c b/src/gsm_utils.c index dc97cef..ce5cefd 100644 --- a/src/gsm_utils.c +++ b/src/gsm_utils.c @@ -2,6 +2,7 @@ * (C) 2008 by Daniel Willmann <daniel(a)totalueberwachung.de> * (C) 2009 by Holger Hans Peter Freyther <zecke(a)selfish.org> * (C) 2009-2010 by Harald Welte <laforge(a)gnumonks.org> + * (C) 2010 by Nico Golde <nico(a)ngolde.de> * * All Rights Reserved * @@ -53,33 +54,66 @@ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t length) return i - l; } +/* GSM 03.38 6.2.1 Prepare character packing */ +static int gsm_septet_encode(uint8_t *result, const char *data) +{ + int i, y = 0; + uint8_t ch; + for(i = 0; i < strlen(data); i++){ + ch = data[i]; + switch(ch){ + case 0x0c: + case 0x5e: + case 0x7b: + case 0x7d: + case 0x5c: + case 0x5b: + case 0x7e: + case 0x5d: + case 0x7c: + result[y] = 0x1b; + result[y + 1] = gsm_7bit_alphabet[ch]; + y++; + break; + default: + result[y] = gsm_7bit_alphabet[ch]; + break; + } + y++; + } -/* GSM 03.38 6.2.1 Charachter packing */ + return y; +} + +/* GSM 03.38 6.2.1 Character packing */ int gsm_7bit_encode(uint8_t *result, const char *data) { - int i,j = 0; - unsigned char ch1, ch2; + int i,y,z = 0; + /* prepare for the worst case, every character expanding to two bytes */ + uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t)); + uint8_t cb, nb; int shift = 0; - for ( i=0; i<strlen(data); i++ ) { + y = gsm_septet_encode(rdata, data); - ch1 = data[i] & 0x7F; - ch1 = ch1 >> shift; - ch2 = data[(i+1)] & 0x7F; - ch2 = ch2 << (7-shift); + for(i = 0; i < y; i++) { + if(shift == 7 && i + 1 < y){ + shift = 0; + continue; + } - ch1 = ch1 | ch2; + cb = (rdata[i] & 0x7f) >> shift; + if(i + 1 < y){ + nb = (rdata[i + 1] & 0x7f) << (7 - shift); + cb = cb | nb; + } - result[j++] = ch1; + result[z++] = cb; shift++; - - if ((shift == 7) && (i+1<strlen(data))) { - shift = 0; - i++; - } } + free(rdata); return i; } -- 1.7.1 --liOOAslEiF7prFVr--

13 years, 10 months

1
0
0 0

[PATCH] * rewrite gsm_7bit_encode() based on a lookup table as the previous code produced wrong encodings for certain characters.

by Nico Golde

--- include/osmocore/gsm_utils.h | 28 ++++++++++++++++++ src/gsm_utils.c | 64 ++++++++++++++++++++++++++++++++---------- 2 files changed, 77 insertions(+), 15 deletions(-) diff --git a/include/osmocore/gsm_utils.h b/include/osmocore/gsm_utils.h index 7dc2388..661846a 100644 --- a/include/osmocore/gsm_utils.h +++ b/include/osmocore/gsm_utils.h @@ -3,6 +3,7 @@ * (C) 2008 by Daniel Willmann <daniel(a)totalueberwachung.de> * (C) 2009 by Holger Hans Peter Freyther <zecke(a)selfish.org> * (C) 2009-2010 by Harald Welte <laforge(a)gnumonks.org> + * (C) 2010 by Nico Golde <nico(a)ngolde.de> * * All Rights Reserved * @@ -53,6 +54,33 @@ enum gsm_band { GSM_BAND_810 = 0x80, }; +/* ETSI GSM 03.38 6.2.1 and 6.2.1.1 default alphabet + * Greek symbols at hex positions 0x10 and 0x12-0x1a + * left out as they can't be handled with a char and + * since most phones don't display or write these + * characters this would only needlessly make the code + * more complex +*/ +unsigned char gsm_7bit_alphabet[] = { + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0a, 0xff, 0x0a, 0x0d, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0x20, 0x21, 0x22, 0x23, 0x02, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, + 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, + 0x3c, 0x3d, 0x3e, 0x3f, 0x00, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, + 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, + 0x5a, 0x3c, 0x2f, 0x3e, 0x14, 0x11, 0xff, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, + 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, + 0x78, 0x79, 0x7a, 0x28, 0x40, 0x29, 0x3d, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01, 0x24, + 0x03, 0xff, 0x5f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x60, 0xff, 0xff, 0xff, + 0xff, 0x5b, 0x0e, 0x1c, 0x09, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5d, + 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0x0b, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0x1e, 0x7f, + 0xff, 0xff, 0xff, 0x7b, 0x0f, 0x1d, 0xff, 0x04, 0x05, 0xff, 0xff, 0x07, 0xff, 0xff, 0xff, + 0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff +}; + const char *gsm_band_name(enum gsm_band band); enum gsm_band gsm_band_parse(const char *mhz); diff --git a/src/gsm_utils.c b/src/gsm_utils.c index dc97cef..f0b031d 100644 --- a/src/gsm_utils.c +++ b/src/gsm_utils.c @@ -2,6 +2,7 @@ * (C) 2008 by Daniel Willmann <daniel(a)totalueberwachung.de> * (C) 2009 by Holger Hans Peter Freyther <zecke(a)selfish.org> * (C) 2009-2010 by Harald Welte <laforge(a)gnumonks.org> + * (C) 2010 by Nico Golde <nico(a)ngolde.de> * * All Rights Reserved * @@ -53,33 +54,66 @@ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t length) return i - l; } +/* GSM 03.38 6.2.1 Prepare character packing */ +static int gsm_septet_encode(uint8_t *result, const char *data) +{ + int i, y = 0; + uint8_t ch; + for(i = 0; i < strlen(data); i++){ + ch = data[i]; + switch(ch){ + case 0x0c: + case 0x5e: + case 0x7b: + case 0x7d: + case 0x5c: + case 0x5b: + case 0x7e: + case 0x5d: + case 0x7c: + result[y] = 0x1b; + result[y + 1] = gsm_7bit_alphabet[ch]; + y++; + break; + default: + result[y] = gsm_7bit_alphabet[ch]; + break; + } + y++; + } -/* GSM 03.38 6.2.1 Charachter packing */ + return y; +} + +/* GSM 03.38 6.2.1 Character packing */ int gsm_7bit_encode(uint8_t *result, const char *data) { - int i,j = 0; - unsigned char ch1, ch2; + int i,y,z = 0; + /* prepare for the worst case, every character expanding to two bytes */ + uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t)); + uint8_t cb, nb; int shift = 0; - for ( i=0; i<strlen(data); i++ ) { + y = gsm_septet_encode(rdata, data); - ch1 = data[i] & 0x7F; - ch1 = ch1 >> shift; - ch2 = data[(i+1)] & 0x7F; - ch2 = ch2 << (7-shift); + for(i = 0; i < y; i++) { + if(shift == 7 && i + 1 < y){ + shift = 0; + continue; + } - ch1 = ch1 | ch2; + cb = (rdata[i] & 0x7f) >> shift; + if(i + 1 < y){ + nb = (rdata[i + 1] & 0x7f) << (7 - shift); + cb = cb | nb; + } - result[j++] = ch1; + result[z++] = cb; shift++; - - if ((shift == 7) && (i+1<strlen(data))) { - shift = 0; - i++; - } } + free(rdata); return i; } -- 1.7.1 --fUYQa+Pmc3FrFX/N--

13 years, 10 months

1
0
0 0

Re: Working GSM1800 config for latest OpenBSC

by Stephen Mortimer

Thanks Sylvian, Removing the E1 config lines did the trick. Regards, Steve

13 years, 10 months

1
0
0 0

Fuzzing your GSM phone with OpenBSC and Scapy

by Stephen Mortimer

Hi, Is there a version of Scapy with the GSM protocol layers that I can use with the ipaccess-proxy, as discussed in Harold Welte's presentation? Many thanks, Steve

13 years, 10 months

1
0
0 0

nanobts sends no BCCH

by Nordin

Hi guys, Today I git-cloned the latest version opnbsc/libosmocore and built it successfully. But when running the nanoBTS900, no BCCH is sent, just the carrier signal. I can confirm this, because I've two nanoBTSs, one 900 and the other 1800, the 1800 version works well. With a special gsm module (Telit), I can perform a scan for the available BCCHs in the environment. Anyone recognize this?

13 years, 10 months

1
0
0 0

LCR crashes. Please help me!

by Luca Bertoncello

Hi, List! I'm trying to get OpenBSC working with Asterisk. I have a working configuration of Asterisk, and a working configuration of OpenBSC. I use a nanoBTS DSC1800. The O.S. is Debian lenny and I have a Cologne Chip Designs GmbH ISDN network Controller [HFC-E1] ISDN card. In my interface.conf I just have: [GSM] gsm-bs nt layer1hold no layer2hold no tones yes earlyb no channel-in free channel-out any nodtmf My gsm.conf: interface-bsc mISDN_l1loop.1 interface-lcr mISDN_l1loop.2 debug DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNCC:DMNSMS:DPAG:DMUX:DMEAS config /home/lucabert/bscAsterisk/lucabertBSC.cfg hlr /home/lucabert/bscAsterisk/hlr.sqlite3 In my options.conf I have a line: gsm and in my routing.conf I have this line by [main]: interface=GSM : remote application=asterisk context=btsctrl Now I start LCR (as root): /usr/local/sbin/lcr start It starts and wait until the nanoBTS log in. Then, when I try to use the net with my mobile, LCR crashes. I generated a core file. With gdb I see: Program terminated with signal 11, Segmentation fault. [New process 4026] [New process 4029] #0 0x0805b009 in gsm0408_rcvmsg (msg=0x864ffb8, link_id=0 '\0') at openbsc/src/bsc_api.c:111 111 rc = api->compl_l3(lchan->conn, msg, 0); The problem seems to be the variable api, which is NULL. (gdb) print api $1 = (struct bsc_api *) 0x0 Can someone help me? I use OpenBSC 0.9.0.967-02d3 and LCR 1.7 (both downloaded yesterday with git clone). Thanks a lot for your help -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 10 months

1
0
0 0

Re: Help by connecting OpenBSC with Asterisk

by Sylvain Munaut

> As I don't have access to a nanoBTS I never tried it, but you could take a > look at Sylvain's chan_openbsc for Asterisk > (http://github.com/smunaut/ast_chan_openbsc). Yeah, that probably doesn't work anymore. Yet another thing I must finish. But that's pretty low on my list ... Sylvain

13 years, 10 months

1
0
0 0

Can't change nanoBTS id.

by Nordin

Hello guys, I want to change a nanoBTS's id, so I can control two BTSs each as a seperate BTS (not as a seperate TRX). But this is what I get: $ ./ipaccess-config -u 1801/1/0 10.100.2.27 ipaccess-config (C) 2009-2010 by Harald Welte and others This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY Trying to connect to ip.access BTS ... <0005> abis_nm.c:518 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) <0005> abis_nm.c:518 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked OML link established using TRX 0 setting Unit ID to '1801/1/0' <0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked <0005> abis_nm.c:518 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xf1): <0005> abis_nm.c:2757 SET NVATTR NACK CAUSE=Parameter value outside permitted range Failure to set attribute. This seems fatal Is this familiar to you? Thank you.

13 years, 10 months

3
3
0 0

Help by connecting OpenBSC with Asterisk

by Luca Bertoncello

Hi, List! I have now to connect OpenBSC with Asterisk, in order to use a VoIP-phone to call mobiles (and viceversa). I found this HowTo: http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR Since I don't know Asterisk I'm not sure if it is what I really need... In the HowTo 2 ISDN-Cards are used. Need I really these? I'm using a nanoBTS (accessed over Ethernet), so I think I don't need the Cologne Chips E1 PCI card. Is it right? Then, at least as first step, I don't want to connect my Asterisk with the rest of the world. I really want to create my own test-network with a VoiIP-phone and a couple of mobiles. Do I really need a ISDN-card? And last, but not least, (as I said, I don't know Asterisk!!), how can I decide, that a number I choose from mobile or VoiIP-phone is a mobile or a VoiIP-phone? Maybe there is a running configuration of Asterisk I can use as example? Thanks a lot for your help! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

13 years, 10 months

2
1
0 0

Segfault from Race condition when closing channel?

by Harald Welte

As horiz0n on IRC points out: 00:16 <horiz0n> hehe, calling the c123 from my 9500 communicator crashes openbsc 00:17 <horiz0n> here is the log http://notepad.cc/share/LQ3awCtXz9 00:21 <horiz0n> and here the debug log http://notepad.cc/share/tPJYXo3SJG <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:1109 CIPHERING MODE COMPLETE <0003> gsm_04_08_utils.c:197 Sending Channel Release: Chan: Number: 0 Type: 2 <0004> abis_rsl.c:586 (bts=0,trx=0,ts=1,ss=0) DEACTivate SACCH CMD <0000> chan_alloc.c:363 (bts=0,trx=0,ts=1,ss=0) Recycling Channel <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION ./runbsc.sh: line 6: 1179 Segmentation fault sudo ./bsc_hack -e 1 -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0 So what happens: We get a CM Service request, then go through authentication and ciphering. At that point, the network decides to release the channel and the channel is not completely closed yet (only SACCH deactivated) when we get an incoming SETUP message. This message is treated as a new message (msc_compl_l3, but it has no conn->subscr and the code segfaults in trans_find_by_id(subscr=NULL, ...) So I think there are actually multiple bugs. 1) the channel should not be released at that time 2) we have some kind of a race condition at channel release, where incoming messages should either be discarded _or_ should still be processed with all the data structures intact. Cheers, 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, 10 months

2
2
0 0

GPRS / OsmoSGSN status update

by Harald Welte

Good news, everyone [tm] GPRS is by now in a fairly useful state. I've spent the better part of the last 3 days to fix all the remaining known bugs. It is working fine from a variety of phones including a G1 (MSM7200) , K800i (unkown baseband), TYTN2 (also Qualcomm MSM but with windows mobile), E680 (Neptune LTE), ... The following parts are still missing: * Integration with the HLR, so every phone is accepted on GPRS * IP Header compression (ROHC) * Data compression (v.42bis) * Authentication (depends on HLR integration) * GEA3 Encryption (though most of the infrastructure is there) * Ability to route APNs to different GGSNs So everyone who has access to a nanoBTS: Try it now. The build/config instructions haven't changed from what I described last time when I wrote a GPRS status update to this list. Happy hacking, 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, 10 months

2
2
0 0

Re: Segmentation fault while sending sms via bsc_hack_VTY

by Richard Zahoransky

-------- Original-Nachricht -------- > Datum: Wed, 30 Jun 2010 12:10:20 +0800 > Von: Holger Hans Peter Freyther <holger(a)freyther.de> > An: openbsc(a)lists.gnumonks.org > Betreff: Re: Segmentation fault while sending sms via bsc_hack_VTY > > > > thanks a lot for starting to debug this. Could you help me a bit with > > your test setup? Which type of BTS do you use? Could you get us a pcap > > file for the Channel Activate NACK? Attached I have a pcap file from bsc_hack. It logged until the segmentation fault happened. Additionally, I have captured the bsc_hack output and valgrind output in the other file. There you also find the openbsc config file. Only bsc_hack was started, without lcr or openggsn for this testing. We use two nanoBTS - ipaccess-find prints out: MAC Address='00:02:95:00:2f:b7' IP Address='10.1.1.10' Unit ID='1802/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='165a029_48' Software Version='168c002_v100b16d0' Unit Name='nbts-00-02-95-00-2F-B7' Serial Number='00071355' MAC Address='00:02:95:00:57:3e' IP Address='10.1.1.11' Unit ID='1800/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='165a029_55' Software Version='168a302_v142b13d0' Unit Name='nbts-00-02-95-00-57-3E' Serial Number='00107709' Each BTS has its own part in the openbsc.cfg > > please confirm that both the SMS crash and the NACKs are resolved. I loaded and built the current version from OpenBSC (Jun., 30. ~ 3:00 p.m.). SMS still crashes when sending from vty console. As far as I can tell, the NACKs are resolved. > > thanks thank you too!

13 years, 10 months

3
2
0 0

Re: Cryptography VTY Bugreport (patch inside)

by cscan＠gmx.net

Sorry. Now with the patch file included.

13 years, 10 months

1
0
0 0

Cryptography VTY Bugreport

by Philipp Fabian Benedikt Maier

Hi folks. I am currently playing with the crypto features of openBSC. When i want to enter the key for a specific subscriber in the VTY console openBSC crashes. When i create the entry manually with sqlite3 and try again the entry in the database will be overwritten and it seems to work. The string i entered in VTY was: subscriber imsi 001010000000000 a3a8 comp128v1 DEADBEEF0C0FFEE0F00D013370D00F23 The gdb backtrace is: openbsc@openBSC:~/openbsc/openbsc/src$ gdb -- pid 1612 GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... pid: No such file or directory. Attaching to process 1612 Reading symbols from /home/openbsc/openbsc/openbsc/src/bsc_hack...done. Reading symbols from /usr/local/lib/libosmocore.so.0...done. Loaded symbols for /usr/local/lib/libosmocore.so.0 Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libdbi.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdbi.so.0 Reading symbols from /usr/local/lib/libosmovty.so.0...done. Loaded symbols for /usr/local/lib/libosmovty.so.0 Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1 Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libm.so.6 Reading symbols from /usr/lib/dbd/libdbdsqlite3.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/dbd/libdbdsqlite3.so Reading symbols from /usr/lib/libsqlite3.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsqlite3.so.0 Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0 0x00c9d422 in __kernel_vsyscall () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0046450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x0046450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6 #1 0x00484147 in vasprintf () from /lib/tls/i686/cmov/libc.so.6 #2 0x006b042f in dbi_conn_queryf () from /usr/lib/libdbi.so.0 #3 0x08054c05 in db_sync_authinfo_for_subscr (ainfo=0x579ff4, subscr=0x994ec18) at db.c:413 #4 0x0805408e in ena_subscr_a3a8 (self=0x8089ee0, vty=0x99501f8, argc=4, argv=0xbfc33f6c) at vty_interface_layer3.c:502 #5 0x00a74cfb in cmd_execute_command_real (vline=<value optimized out>, vty=<value optimized out>, cmd=0x0) at command.c:1874 #6 0x00a74e27 in cmd_execute_command (vline=0x994a5c0, vty=0x99501f8, cmd=0x0, vtysh=0) at command.c:1909 #7 0x00a7766f in vty_command (vty=0x99501f8) at vty.c:321 #8 vty_execute (vty=0x99501f8) at vty.c:585 #9 vty_read (vty=0x99501f8) at vty.c:1319 #10 0x00a793aa in client_data (fd=0x99504d4, what=1) at telnet_interface.c:128 #11 0x003b7925 in bsc_select_main (polling=0) at select.c:119 #12 0x0804bc66 in main (argc=3, argv=0xbfc34604) at bsc_hack.c:271 (gdb) Maybe this helps to find the bug. regards. Philipp -- ______________________________________ Philipp Fabian Benedikt Maier philipp.maier(a)runningserver.com Funk: DO5DXT http://www.runningserver.com http://www.diskettenschlitz.de ______________________________________

13 years, 10 months

4
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2010