OpenBSC

openbsc@lists.osmocom.org

3 participants
4155 discussions

Start a nNew thread

RFC: sgsn should command/response set to 1 in gsm48_tx_gmm_ra_upd_rej?

by Holger Hans Peter Freyther

Hi, I think the REJECT should be sent with the C/R bit set to 1? holger

13 years, 8 months

"Mandatory info element out of sequence"

by anish achenkunju

Hi All, I'm getting the following error "Received packet without a valid source address!!!" on sgsnemu 0.84 [root@n003-000-000-000 openggsn-0.84]# sgsnemu --listen 7.7.7.7 --remote 7.7.7.1 --timelimit 10 --contexts 1 --apn internet --imsi 2400112 34567890 --msisdn 46702123456 -u root -p nsil --createif --defaultroute Using default DNS server Local IP address is: 7.7.7.7 (7.7.7.7) Remote IP address is: 7.7.7.1 (7.7.7.1) IMSI is: 240011234567890 (0xf098765432110042) Using NSAPI: 0 Using GTP version: 1 Using APN: internet Using selection mode: 1 Using MSISDN: 46702123456 Initialising GTP library openggsn[4597]: GTP: gtp_newgsn() started Setting up interface Done initialising GTP library Sending off echo request Setting up PDP context #0 Waiting for response from ggsn........ Received echo response Received create PDP context response. IP address: 218.59.100.38 Disconnecting PDP context #0 Received packet without a valid source address!!! [root@n003-000-000-000 openggsn-0.84]# The error I get on GGSN (Cisco 7200) on debugging is "Mandatory info element out of sequence" *Oct 13 17:01:42.444: GTP IE:4200113254769800:rcvd 0 out of order previous IE 0 *Oct 13 17:01:42.448: %GTP-2-PDPACTIVATIONFAIL: GTP PDP activation/update failed, GSN: 0.0.0.0, TID: 00, Reason: Mandatory info element out of sequence I'm sticking with 0.84 as 0.91 has a bug while sending echo " Mandatory IE invalid" . Any help on this is greatly appreciated. Thank you, Anish

13 years, 8 months

libosmocore licensing

by Alexander Chemeris

Hi all, but especially Harald, We're looking for a good library with complex arithmetic, bit functions and other RF processing stuff to be used as a base for porting of our WiMAX stuff to C/C++. I'm looking at libosmocore as a perfect candidate for that, but we're going to release our work under LGPL and thus we want an LGPL base library. I wonder, is it possible to re-license libosmocore under LGPL instead of GPL? I know that Sylvain has no strong objections about that. Harald, Holger and other contributors - what would you say? In general, I believe that LGPL is much better suited for libraries then GPL and many widely used libraries, like ffmpeg, use it with great success. And I wish libosmocore to be as successful as those LGPL libraries. PS Our WiMAX effort is to create an open-source receiver for Mobile WiMAX: http://code.google.com/p/wimax-scanner/ We have written somewhat working Matlab code and we're going to port it to something more real-time now. -- Regards, Alexander Chemeris.

13 years, 8 months

libosmocore lapd_rx_u and unitialized rc

by Holger Hans Peter Freyther

Hi all, in the above method there are paths were rc will never be initialized. I think initializing rc = 0 or -EINVAL would be cheating, instead we should consider splitting it into manageable pieces. holger

13 years, 8 months

[PATCH 0/1] [v2] openbsc (master): libctrl: bugfix to prevent a SIGABRT

by Alexander Huemer

In case the control interface on TCP port 4249 is used in an unintended way, a SIGABRT can be caused because of a missing initialization of a msgb*. The upcoming patch fixes this bug. If the patch seems useful, please feel free to merge it. Kind regards, -Alexander Huemer Alexander Huemer(1): libctrl: only free() msgb if it was alloc()ed openbsc/src/libctrl/control_if.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

13 years, 9 months

[PATCH 0/1] openbsc (master): libctrl: bugfix to prevent a SIGABRT

by Alexander Huemer

In case the control interface on TCP port 4249 is used in an unintended way, a SIGABRT can be caused because of a double talloc_free() call on a msgb*. The upcoming patch fixes this bug. If the patch seems useful, please feel free to merge it. Kind regards, -Alexander Huemer Alexander Huemer(1): libctrl: only free() msgb if it was alloc()ed openbsc/src/libctrl/control_if.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)

13 years, 9 months

Re: Mandatory info element invalid

by anish achenkunju

Hi All, Finally I got the setup up and running using Openggsn 0.84, seems like there is a bug in version 0.91 which was causing the earlier reported issue. I've sgsnemu sending packets to Cisco 7200 gprs code emulated on dynmips now which inturn is configured to authenticate via FreeRadius. Everything works now, i'm able to get sgnsemu send packets with username password for the apn to get it authenticated via AAA. My next challenge are: 1. To get sgsnemu read configuration file. Can anyone help me with a sample to do this, would like to see a configuration file where i can have multiple packets with different apn, qos ,imsi being sent out with having to manually type via cli. At this point , i see that there is a limitation of binding only one sgsnemu instance to local interface, is there a way to have multiple instances running? 2. Also would want to setup charging gateway if possible, i couldnt find a live download link to open charging gateway . Would greatly appreciate any inputs on the same. Thank you, Anish ________________________________ From: anish achenkunju <anish_achenkunju(a)yahoo.com> To: "openbsc(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> Sent: Wednesday, September 21, 2011 4:57 PM Subject: Fw: Mandatory info element invalid Dear All, I'm using sgsnemu of openggsn 0.91 to send traffic to Cisco 7200 GGSN code running on dynamips. [root@localhost ~]# sgsnemu -l 3.3.3.3 -r 3.3.3.1 Using default DNS server Local IP address is: 3.3.3.3 (3.3.3.3) Remote IP address is: 3.3.3.1 (3.3.3.1) IMSI is: 240010123456789 (0xf987654321010042) Using NSAPI: 0 Using GTP version: 1 Using APN: internet Using selection mode: 1 Using MSISDN: 46702123456 Initialising GTP library openggsn[24632]: GTP: gtp_newgsn() started Done initialising GTP library Sending off echo request Setting up PDP context #0 Waiting for response from ggsn........ I'm getting the following error on GGSN: *Sep 19 20:45:35.487: %GTP-2-PDPACTIVATIONFAIL: GTP PDP activation/update failed, GSN: 0.0.0.0, TID: 00, Reason: Mandatory info element invalid *Sep 19 20:45:35.491: %GTP-0-GTPv1PACKETPARSINGERROR: GSN: 3.3.3.1, TEID: 1, APN: NULL, Reason: Mandatory ie incorrect Mandatory info element invalid And the following cause value on sgsnemu: Received echo response Received create PDP context response. Cause value: 201 Seems like the GSN adddr 0.0.0.0 ,TID: 00 generated by sgsnemu are invalid. Looking forward for a workaround fix to help me move forward, any help is greatly appreciated. Thank you in advance, Anish

13 years, 9 months

GPRS' PDCH idle filling

by Alexander Chemeris

Hi all, Does anyone know how should we fill PDCH when no downlink transmission is present? I can't find any mention about this in the standard. If someone have traces from existing networks, I would very much appreciate this. Some background - we've recently started working on GPRS implementation for OpenBTS, and we're stuck at the very beginning - mobile sends RACH, but doesn't respond to our Packet Channel Immediate Assignment. After spending quite some time tweaking Immediate Assignment message, our conclusion is that mobile may want to see some "filler" date at the idle PDCH and we don't do this yet. I know that OpenBSC has GPRS working, so I hope someone here may help us. -- Regards, Alexander Chemeris.

13 years, 9 months

Update to gen_ladder.pl tool

by Harald Welte

Hi! I've finally taken some time to re-write the gen_ladder tool in order to avoid the stupid 'bent arrow' problem that was caused by using 'dot'. I'm now drawing bitmap images directly from Perl using 'GD', rendering PNG images. Support for printing a title and automati scaling of the font size has been added. However, this new version doesn't yet support the bi-directional arrows and dashed lines. Patches are welcome ;) I tried to use GD::SVG at some earlier version, and it seemed to work too, i.e. we will have an easy path to still generate vector graphics, if required. There are also way more *.lad files in the repository now for various protocol transaction, including supplementary services, roaming calls, etc. 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

RFC extend osmo_signal infrastructure

by Daniel Willmann

Hello list, I would like to be able to send a TRAP over the control interface for certain signals. For this it would be nice if the signals have a text representation of their name as is the case with the (rate) counters. I want to propose a different API where you register the signals (and maybe even the subsystems) and provide a name for them. The function register_signal would then return the numeric representation of the signal. The performance hit would only be during registering, not during dispatch. The callback function would still be called with the numeric representation in order to avoid resolving the name to the number every time. Inside the callback you would have to resolve the name of the signal to the actual number, but using static variables you'll only have to do it the first time: void signal_cb(unsigned int subsysnum, unsigned int signalnum, void *signal_data, void *handler_data) { static unsigned int foosig, barsig; if (foosig == 0) { foosig = osmo_signal_get_by_name("foo"); } if (barsig == 0) { barsig = osmo_signal_get_by_name("bar"); } switch (signalnum) { case foosig: do_stuff; break; case barsig: do_other_stuff; break; } } The functions that dispatch the signals would have to do something similar. Ideas? Is this too complex? Do we gain enough from registering signals at runtime or should we rather keep the enums and add a value_string for the name/description? Regards, Daniel Willmann

13 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC