From holger at freyther.de Mon Sep 1 18:45:02 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 1 Sep 2014 20:45:02 +0200 Subject: [PATCH] Add subscriber delete command In-Reply-To: <1409523195-15851-1-git-send-email-meskio@sindominio.net> References: <20140831104256.GE4032@xiaoyu.lan> <1409523195-15851-1-git-send-email-meskio@sindominio.net> Message-ID: <20140901184502.GT4032@xiaoyu.lan> On Sun, Aug 31, 2014 at 05:13:15PM -0500, Ruben Pollan wrote: > + if (subscr->use_count != 1) { > + vty_out(vty, "Removing active subscriber%s", VTY_NEWLINE); > + } You could write abort() as well. You should return CMD_ERROR or such as you can't remove an active subscriber. > + # Delte it Delete > + # Now it should not be there anymore > + res = self.vty.command('show subscriber imsi '+imsi) > + self.assert_(res != '% No subscriber found for imsi '+imsi) good! From meskio at sindominio.net Tue Sep 2 19:07:25 2014 From: meskio at sindominio.net (Ruben Pollan) Date: Tue, 02 Sep 2014 14:07:25 -0500 Subject: [PATCH] Add subscriber delete command In-Reply-To: <20140901184502.GT4032@xiaoyu.lan> References: <20140831104256.GE4032@xiaoyu.lan> <1409523195-15851-1-git-send-email-meskio@sindominio.net> <20140901184502.GT4032@xiaoyu.lan> Message-ID: <20140902190725.3558.9243@KingMob> Quoting Holger Hans Peter Freyther (2014-09-01 13:45:02) > On Sun, Aug 31, 2014 at 05:13:15PM -0500, Ruben Pollan wrote: > > > + if (subscr->use_count != 1) { > > + vty_out(vty, "Removing active subscriber%s", VTY_NEWLINE); > > + } > > You could write abort() as well. You should return CMD_ERROR or > such as you can't remove an active subscriber. This code is basically copied from openbsc/src/libmsc/ctrl_commands.c where is doing: if (subscr->use_count != 1) { LOGP(DCTRL, LOGL_NOTICE, "Going to remove active subscriber.\n"); was_used = 1; } rc = db_subscriber_delete(subscr); In the ctrl commands interface even if is in use it keeps trying to delete it. Maybe I'm missing something and the two interfaces should behave differently, or it's a bug on the ctrl interface. > > + # Delte it > > Delete Ok. -- Ruben Pollan | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: signature URL: From holger at freyther.de Tue Sep 23 14:37:13 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 23 Sep 2014 16:37:13 +0200 Subject: [PATCH] Add subscriber delete command In-Reply-To: <20140902190725.3558.9243@KingMob> References: <20140831104256.GE4032@xiaoyu.lan> <1409523195-15851-1-git-send-email-meskio@sindominio.net> <20140901184502.GT4032@xiaoyu.lan> <20140902190725.3558.9243@KingMob> Message-ID: <20140923143713.GF25866@xiaoyu.lan> On Tue, Sep 02, 2014 at 02:07:25PM -0500, Ruben Pollan wrote: > This code is basically copied from openbsc/src/libmsc/ctrl_commands.c where is > doing: You are right! my bad! > > Delete > Could you please rebase and send an updated patch? thanks holger From meskio at sindominio.net Thu Sep 25 01:50:13 2014 From: meskio at sindominio.net (Ruben Pollan) Date: Wed, 24 Sep 2014 20:50:13 -0500 Subject: [PATCH] Add subscriber delete command In-Reply-To: <20140923143713.GF25866@xiaoyu.lan> References: <20140923143713.GF25866@xiaoyu.lan> Message-ID: <1411609813-25640-1-git-send-email-meskio@sindominio.net> --- openbsc/src/libmsc/vty_interface_layer3.c | 34 ++++++++++++++++++++++++++++++- openbsc/tests/vty_test_runner.py | 10 ++++++++- 2 files changed, 42 insertions(+), 2 deletions(-) diff --git a/openbsc/src/libmsc/vty_interface_layer3.c b/openbsc/src/libmsc/vty_interface_layer3.c index 064eca9..8890099 100644 --- a/openbsc/src/libmsc/vty_interface_layer3.c +++ b/openbsc/src/libmsc/vty_interface_layer3.c @@ -465,7 +465,38 @@ DEFUN(subscriber_ussd_notify, return CMD_SUCCESS; } -DEFUN(ena_subscr_authorizde, +DEFUN(ena_subscr_delete, + ena_subscr_delete_cmd, + "subscriber " SUBSCR_TYPES " ID delete", + SUBSCR_HELP "Delete subscriber in HLR\n") +{ + int rc; + struct gsm_network *gsmnet = gsmnet_from_vty(vty); + struct gsm_subscriber *subscr = + get_subscr_by_argv(gsmnet, argv[0], argv[1]); + + if (!subscr) { + vty_out(vty, "%% No subscriber found for %s %s%s", + argv[0], argv[1], VTY_NEWLINE); + return CMD_WARNING; + } + + if (subscr->use_count != 1) { + vty_out(vty, "Removing active subscriber%s", VTY_NEWLINE); + } + + rc = db_subscriber_delete(subscr); + subscr_put(subscr); + + if (rc != 0) { + vty_out(vty, "Failed to remove subscriber%s", VTY_NEWLINE); + return CMD_WARNING; + } + + return CMD_SUCCESS; +} + +DEFUN(ena_subscr_authorized, ena_subscr_authorized_cmd, "subscriber " SUBSCR_TYPES " ID authorized (0|1)", SUBSCR_HELP "(De-)Authorize subscriber in HLR\n" @@ -982,6 +1013,7 @@ int bsc_vty_init_extra(void) install_element_ve(&show_stats_cmd); install_element_ve(&show_smsqueue_cmd); + install_element(ENABLE_NODE, &ena_subscr_delete_cmd); install_element(ENABLE_NODE, &ena_subscr_name_cmd); install_element(ENABLE_NODE, &ena_subscr_extension_cmd); install_element(ENABLE_NODE, &ena_subscr_authorized_cmd); diff --git a/openbsc/tests/vty_test_runner.py b/openbsc/tests/vty_test_runner.py index db8294d..ece9ac5 100644 --- a/openbsc/tests/vty_test_runner.py +++ b/openbsc/tests/vty_test_runner.py @@ -247,7 +247,7 @@ class TestVTYNITB(TestVTYGenericBSC): if classNum != 10: self.assertEquals(res.find("rach access-control-class " + str(classNum) + " barred"), -1) - def testSubscriberCreate(self): + def testSubscriberCreateDelete(self): self.vty.enable() imsi = "204300854013739" @@ -263,6 +263,14 @@ class TestVTYNITB(TestVTYGenericBSC): res = self.vty.command('show subscriber imsi '+imsi) self.assert_(res.find(" IMSI: "+imsi) > 0) + # Delete it + res = self.vty.command('subscriber delete imsi '+imsi) + self.assert_(res != "") + + # Now it should not be there anymore + res = self.vty.command('show subscriber imsi '+imsi) + self.assert_(res != '% No subscriber found for imsi '+imsi) + def testShowPagingGroup(self): res = self.vty.command("show paging-group 255 1234567") self.assertEqual(res, "% can't find BTS 255") -- 2.1.0 From holger at freyther.de Mon Sep 1 18:43:47 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 1 Sep 2014 20:43:47 +0200 Subject: Can't build debian packages of libosmocore In-Reply-To: <54038D59.7080407@autistici.org> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> Message-ID: <20140901184347.GS4032@xiaoyu.lan> On Sun, Aug 31, 2014 at 04:02:17PM -0500, Ciaby wrote: Hi! > > So, it looks like it's trying to build a libosmogsm6 package, but > > only libosmogsm5.1.0 gets built. I looked around, and the only > > reference I found is in src/gsm/Makefile.am, and it's correct > > (6:0:1). What am I doing wrong? :) > This is a tentative patch to fix the issue. It works for me, > libosmogsm6 and libosmoctrl0 are built successfully, however I'm not > sure if that's the right thing to do. can you try to use the -M option? It will show plain renames. > --- a/src/gsm/Makefile.am > +++ b/src/gsm/Makefile.am > @@ -1,6 +1,6 @@ > # This is _NOT_ the library release version, it's an API version. > # Please read Chapter 6 "Library interface versions" of the libtool documentation before making any modification > -LIBVERSION=6:0:1 > +LIBVERSION=6:0:0 that is odd. What build issue do you get without the versioning? From ciaby at autistici.org Tue Sep 2 17:46:14 2014 From: ciaby at autistici.org (Ciaby) Date: Tue, 02 Sep 2014 12:46:14 -0500 Subject: Can't build debian packages of libosmocore In-Reply-To: <20140901184347.GS4032@xiaoyu.lan> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> Message-ID: <54060266.1060300@autistici.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/01/2014 01:43 PM, Holger Hans Peter Freyther wrote: > On Sun, Aug 31, 2014 at 04:02:17PM -0500, Ciaby wrote: > > Hi! > >>> So, it looks like it's trying to build a libosmogsm6 package, >>> but only libosmogsm5.1.0 gets built. I looked around, and the >>> only reference I found is in src/gsm/Makefile.am, and it's >>> correct (6:0:1). What am I doing wrong? :) >> This is a tentative patch to fix the issue. It works for me, >> libosmogsm6 and libosmoctrl0 are built successfully, however I'm >> not sure if that's the right thing to do. > > > can you try to use the -M option? It will show plain renames. Ok, will do. >> --- a/src/gsm/Makefile.am +++ b/src/gsm/Makefile.am @@ -1,6 +1,6 >> @@ # This is _NOT_ the library release version, it's an API >> version. # Please read Chapter 6 "Library interface versions" of >> the libtool documentation before making any modification >> -LIBVERSION=6:0:1 +LIBVERSION=6:0:0 > > that is odd. What build issue do you get without the versioning? libosmogsm gets built as libosmogsm.so.5.1.0, which of course doesn't work if you try to package libosmogsm6. Also, libosmoctrl is missing libosmoctrl0.install in debian/ and the package declaration in debian/rules. My build box is Ubuntu 12.04, 64-bit, all packages updated. This is the updated patch. Cheers Ciaby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREKAAYFAlQGAlwACgkQC30ZhxNccpERYAD+J0WCn/Oo01sVsVmz3Dq+f0cK r9eTGhhfEi2ZVCVXGlwA/1tv0Wl53be5R5UKGNF01OJ0Jp7xXBErJ5PLV88guTJ2 =qGdK -----END PGP SIGNATURE----- From ciaby at autistici.org Tue Sep 2 17:56:20 2014 From: ciaby at autistici.org (Ciaby) Date: Tue, 02 Sep 2014 12:56:20 -0500 Subject: Can't build debian packages of libosmocore In-Reply-To: <54060266.1060300@autistici.org> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> <54060266.1060300@autistici.org> Message-ID: <540604C4.4050304@autistici.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/02/2014 12:46 PM, Ciaby wrote: [...] > This is the updated patch. Ops, wrong patch :) Cheers Ciaby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREKAAYFAlQGBLoACgkQC30ZhxNccpHc8AEAhXc4BIfNFLNzLzhi0U00hOJk yh210vyL8RZ28XhjeB0BAJkntG4W4QwnTPndniPW6IjXHq1hKkAiusUtLfpQoMUM =dn6b -----END PGP SIGNATURE----- From holger at freyther.de Wed Sep 3 06:13:14 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 3 Sep 2014 08:13:14 +0200 Subject: Can't build debian packages of libosmocore In-Reply-To: <54060266.1060300@autistici.org> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> <54060266.1060300@autistici.org> Message-ID: <20140903061314.GB4637@xiaoyu.lan> On Tue, Sep 02, 2014 at 12:46:14PM -0500, Ciaby wrote: > >> -LIBVERSION=6:0:1 +LIBVERSION=6:0:0 > > > > that is odd. What build issue do you get without the versioning? > libosmogsm gets built as libosmogsm.so.5.1.0, which of course doesn't > work if you try to package libosmogsm6. Also, libosmoctrl is missing > libosmoctrl0.install in debian/ and the package declaration in > debian/rules. 5 vs. 6 and missing libosmoctrl is obvious. But why doesn't 6.0.1 as version work? I would be a bit surprised if that doesn't work. $ dpkg -S /usr/lib/liblwres.so.90.0.7 liblwres90: /usr/lib/liblwres.so.90.0.7 I will probably just build the package and then drop that hunk. holger From ciaby at autistici.org Wed Sep 3 09:21:13 2014 From: ciaby at autistici.org (Ciaby) Date: Wed, 03 Sep 2014 04:21:13 -0500 Subject: Can't build debian packages of libosmocore In-Reply-To: <20140903061314.GB4637@xiaoyu.lan> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> <54060266.1060300@autistici.org> <20140903061314.GB4637@xiaoyu.lan> Message-ID: <5406DD89.703@autistici.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/03/2014 01:13 AM, Holger Hans Peter Freyther wrote: [...] > 5 vs. 6 and missing libosmoctrl is obvious. But why doesn't 6.0.1 > as version work? I would be a bit surprised if that doesn't work. > > $ dpkg -S /usr/lib/liblwres.so.90.0.7 liblwres90: > /usr/lib/liblwres.so.90.0.7 > > I will probably just build the package and then drop that hunk. I know, it doesn't make sense... but that's what I got out of building it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it? Cheers Ciaby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREKAAYFAlQG3YQACgkQC30ZhxNccpHiQQEAgoVeNL22rMwHDpPXB67Ih4SK 5rzM97TkWpKDhJfmEaAA/2G6fIsncEpJIcy5V0WYvFOo5hC7u1k4tUZFbAz6WkhI =ba7Y -----END PGP SIGNATURE----- From holger at freyther.de Wed Sep 3 13:25:27 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 3 Sep 2014 15:25:27 +0200 Subject: Can't build debian packages of libosmocore In-Reply-To: <5406DD89.703@autistici.org> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> <54060266.1060300@autistici.org> <20140903061314.GB4637@xiaoyu.lan> <5406DD89.703@autistici.org> Message-ID: <20140903132527.GC4637@xiaoyu.lan> On Wed, Sep 03, 2014 at 04:21:13AM -0500, Ciaby wrote: > > I will probably just build the package and then drop that hunk. > I know, it doesn't make sense... but that's what I got out of building > it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it? yes, it is odd. 6:0:1 gives me a so where the major version is 5 something :) There seems to be a similar issue with the libosmocore library as well. Did you see the warning generated by lintian? From vasil_vel at abv.bg Wed Sep 3 15:57:50 2014 From: vasil_vel at abv.bg (Vasil Velichkov) Date: Wed, 03 Sep 2014 18:57:50 +0300 Subject: Can't build debian packages of libosmocore In-Reply-To: <20140903132527.GC4637@xiaoyu.lan> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> <54060266.1060300@autistici.org> <20140903061314.GB4637@xiaoyu.lan> <5406DD89.703@autistici.org> <20140903132527.GC4637@xiaoyu.lan> Message-ID: <54073A7E.9090904@abv.bg> Hi Holger, Ciaby, On 3.09.2014 16:25, Holger Hans Peter Freyther wrote: > On Wed, Sep 03, 2014 at 04:21:13AM -0500, Ciaby wrote: > >> I know, it doesn't make sense... but that's what I got out of building >> it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it? > yes, it is odd. 6:0:1 gives me a so where the major version is 5 > something :) > > There seems to be a similar issue with the libosmocore library as > well. Did you see the warning generated by lintian? > > It is normal that 6:0:1 gives a so with major version 5, because 6:0:1 means that the library supports interfaces 5 and 6 See http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html So, libtool library versions are described by three integers: current The most recent interface number that this library implements. revision The implementation number of the current interface. age The difference between the newest and oldest interfaces that this library implements. In other words, the library implements all the interface numbers in the range from number current - age to current. Vasil From ciaby at autistici.org Wed Sep 3 23:01:31 2014 From: ciaby at autistici.org (Ciaby) Date: Wed, 03 Sep 2014 18:01:31 -0500 Subject: Can't build debian packages of libosmocore In-Reply-To: <54073A7E.9090904@abv.bg> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> <54060266.1060300@autistici.org> <20140903061314.GB4637@xiaoyu.lan> <5406DD89.703@autistici.org> <20140903132527.GC4637@xiaoyu.lan> <54073A7E.9090904@abv.bg> Message-ID: <54079DCB.6050403@autistici.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/03/2014 10:57 AM, Vasil Velichkov wrote: > Hi Holger, Ciaby, > > On 3.09.2014 16:25, Holger Hans Peter Freyther wrote: >> On Wed, Sep 03, 2014 at 04:21:13AM -0500, Ciaby wrote: >> >>> I know, it doesn't make sense... but that's what I got out of >>> building it with 6.0.1 as version. 6.0.0 works fine. Can you >>> reproduce it? >> yes, it is odd. 6:0:1 gives me a so where the major version is 5 >> something :) >> >> There seems to be a similar issue with the libosmocore library >> as well. Did you see the warning generated by lintian? >> >> > It is normal that 6:0:1 gives a so with major version 5, because > 6:0:1 means that the library supports interfaces 5 and 6 Ok, that's what I found as well. So, what's the solution here? Keep packaging it as 5, or move to 6-only? Cheers Ciaby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREKAAYFAlQHncYACgkQC30ZhxNccpGegQD/fI5xgA9cwvJnm6BGpyKEKDpm GwKSBGTShyfOkL5Xa4oBAKu9L8gLjn+sGCfWdcVwTcJrCbV1oGFT09s6FQsszMji =UV8T -----END PGP SIGNATURE----- From holger at freyther.de Thu Sep 4 06:10:19 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 4 Sep 2014 08:10:19 +0200 Subject: Can't build debian packages of libosmocore In-Reply-To: <54079DCB.6050403@autistici.org> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> <54060266.1060300@autistici.org> <20140903061314.GB4637@xiaoyu.lan> <5406DD89.703@autistici.org> <20140903132527.GC4637@xiaoyu.lan> <54073A7E.9090904@abv.bg> <54079DCB.6050403@autistici.org> Message-ID: <20140904061019.GI4637@xiaoyu.lan> On Wed, Sep 03, 2014 at 06:01:31PM -0500, Ciaby wrote: > Ok, that's what I found as well. So, what's the solution here? > Keep packaging it as 5, or move to 6-only? -#define OSMO_NUM_DLIB 7 +#define DLCTRL -8 +#define OSMO_NUM_DLIB 8 might break ABI, so let's stick with 6:0:0. Could you updated your patch to address the libosmocore4 warning as well? thanks holger From pablo at gnumonks.org Thu Sep 4 09:35:07 2014 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Thu, 4 Sep 2014 11:35:07 +0200 Subject: Can't build debian packages of libosmocore In-Reply-To: <54073A7E.9090904@abv.bg> References: <5403809E.1090804@autistici.org> <54038D59.7080407@autistici.org> <20140901184347.GS4032@xiaoyu.lan> <54060266.1060300@autistici.org> <20140903061314.GB4637@xiaoyu.lan> <5406DD89.703@autistici.org> <20140903132527.GC4637@xiaoyu.lan> <54073A7E.9090904@abv.bg> Message-ID: <20140904093507.GA9111@salvia> On Wed, Sep 03, 2014 at 06:57:50PM +0300, Vasil Velichkov wrote: > Hi Holger, Ciaby, > > On 3.09.2014 16:25, Holger Hans Peter Freyther wrote: > >On Wed, Sep 03, 2014 at 04:21:13AM -0500, Ciaby wrote: > > > >>I know, it doesn't make sense... but that's what I got out of building > >>it with 6.0.1 as version. 6.0.0 works fine. Can you reproduce it? > >yes, it is odd. 6:0:1 gives me a so where the major version is 5 > >something :) > > > >There seems to be a similar issue with the libosmocore library as > >well. Did you see the warning generated by lintian? > > > > > It is normal that 6:0:1 gives a so with major version 5, because > 6:0:1 means that the library supports interfaces 5 and 6 > > See http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html > > So, libtool library versions are described by three integers: > current > The most recent interface number that this library implements. > revision > The implementation number of the current interface. > age > The difference between the newest and oldest interfaces that > this library implements. > In other words, the library implements all the interface > numbers in the range from number current - age to current. Right. A new library version that still supports the previous interfaces needs to bump current and age, if the base is 6:0:0, then the update needs to be 7:0:1. If you remove interfaces you don't want anymore, ie. you break backward compatibility, you have to reset age and bump current, ie. 7:0:0 From alexander.chemeris at gmail.com Mon Sep 1 04:25:47 2014 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 1 Sep 2014 00:25:47 -0400 Subject: Osmocom meetup in Boston Message-ID: Hi all, I plan to setup a meetup about Osmocom in Boston closer to the end of Sept. If you're interested - please sign up for it here, to help us gauge the interest: http://www.meetup.com/Open-source-telecom/ The plan is to have this as a more or less regular meeting around open-source solutions for telecom, particularly Osmocom, OpenBTS and OpenLTE, but including projects like Freeswitch, Clearwater, etc. These projects are interesting to me personally and after the first meeting the list might be shrunk or expanded based on the interest from other participants. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo at gnumonks.org Mon Sep 1 07:34:07 2014 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Mon, 1 Sep 2014 09:34:07 +0200 Subject: [PATCH openbsc] configure: fix unrecognized option --enable-external-tests Message-ID: <1409556847-20398-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso ./configure --help indicates: --enable-external-tests Include the VTY/CTRL tests in make check [default=no] but ./configure ... --enable-external-tests configure: WARNING: unrecognized options: --enable-external-tests the name of the option seems to be --enable-ext-tests. --- openbsc/configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/configure.ac b/openbsc/configure.ac index 0777c0d..40ee444 100644 --- a/openbsc/configure.ac +++ b/openbsc/configure.ac @@ -141,7 +141,7 @@ AC_ARG_ENABLE([vty_tests], [Include the VTY/CTRL tests in make check (deprecated) [default=no]]), [enable_ext_tests="$enableval"],[enable_ext_tests="no"]) -AC_ARG_ENABLE([ext_tests], +AC_ARG_ENABLE([external_tests], AC_HELP_STRING([--enable-external-tests], [Include the VTY/CTRL tests in make check [default=no]]), [enable_ext_tests="$enableval"],[enable_ext_tests="no"]) -- 1.7.10.4 From holger at freyther.de Mon Sep 1 16:36:03 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 1 Sep 2014 18:36:03 +0200 Subject: [PATCH openbsc] configure: fix unrecognized option --enable-external-tests In-Reply-To: <1409556847-20398-1-git-send-email-pablo@gnumonks.org> References: <1409556847-20398-1-git-send-email-pablo@gnumonks.org> Message-ID: <20140901163603.GK4032@xiaoyu.lan> On Mon, Sep 01, 2014 at 09:34:07AM +0200, pablo at gnumonks.org wrote: > From: Pablo Neira Ayuso oops! thanks! From jerlbeck at sysmocom.de Mon Sep 1 09:30:57 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Mon, 1 Sep 2014 11:30:57 +0200 Subject: [PATCH] gprs: Fix and check BVCI in BSSGP STATUS messages Message-ID: <1409563857-2784-1-git-send-email-jerlbeck@sysmocom.de> Currently the BVCI is not set in all invocations to bssgp_tx_status() when the cause is UNKNOWN_BVCI. This patch adds the argument where it is missing. It also adds a check for compliance (GSM 08.18, 10.4.14.1) to bssgp_tx_status() to emit errors when the following requirement is not fulfilled: The BVCI must be included if (and only if) the cause is either "BVCI blocked" or "BVCI unknown". Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 2 +- src/gb/gprs_bssgp_util.c | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index 5ef1887..b8c6c74 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -998,7 +998,7 @@ int bssgp_rcvmsg(struct msgb *msg) LOGP(DBSSGP, LOGL_NOTICE, "NSEI=%u/BVCI=%u Rejecting PDU " "type %u for unknown BVCI\n", msgb_nsei(msg), ns_bvci, pdu_type); - return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, NULL, msg); + return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, &ns_bvci, msg); } if (bctx) { diff --git a/src/gb/gprs_bssgp_util.c b/src/gb/gprs_bssgp_util.c index ae4647e..261e0b0 100644 --- a/src/gb/gprs_bssgp_util.c +++ b/src/gb/gprs_bssgp_util.c @@ -99,6 +99,20 @@ int bssgp_tx_status(uint8_t cause, uint16_t *bvci, struct msgb *orig_msg) struct bssgp_normal_hdr *bgph = (struct bssgp_normal_hdr *) msgb_put(msg, sizeof(*bgph)); + /* GSM 08.18, 10.4.14.1: The BVCI must be included if (and only if) the + cause is either "BVCI blocked" or "BVCI unknown" */ + if (cause == BSSGP_CAUSE_UNKNOWN_BVCI || cause == BSSGP_CAUSE_BVCI_BLOCKED) { + if (bvci == NULL) + LOGP(DBSSGP, LOGL_ERROR, "BSSGP Tx STATUS, cause=%s: " + "missing conditional BVCI\n", + bssgp_cause_str(cause)); + } else { + if (bvci != NULL) + LOGP(DBSSGP, LOGL_ERROR, "BSSGP Tx STATUS, cause=%s: " + "unexpected conditional BVCI\n", + bssgp_cause_str(cause)); + } + LOGP(DBSSGP, LOGL_NOTICE, "BSSGP BVCI=%u Tx STATUS, cause=%s\n", bvci ? *bvci : 0, bssgp_cause_str(cause)); msgb_nsei(msg) = msgb_nsei(orig_msg); -- 1.9.1 From dwillmann at sysmocom.de Thu Sep 4 15:20:52 2014 From: dwillmann at sysmocom.de (Daniel Willmann) Date: Thu, 4 Sep 2014 17:20:52 +0200 Subject: [openbsc 1/2] gprs_sgsn.h: Add two macros to log details of MM/PDP contexts Message-ID: <5af7979f7bc45ce7aa2249cf812998aaa564b6d4.1409844053.git.daniel@totalueberwachung.de> --- openbsc/include/openbsc/gprs_sgsn.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/openbsc/include/openbsc/gprs_sgsn.h b/openbsc/include/openbsc/gprs_sgsn.h index 6e7c677..6a02637 100644 --- a/openbsc/include/openbsc/gprs_sgsn.h +++ b/openbsc/include/openbsc/gprs_sgsn.h @@ -113,6 +113,9 @@ struct sgsn_mm_ctx { uint8_t t3370_id_type; }; +#define LOGMMCTXP(level, mm, fmt, args...) \ + LOGP(DMM, level, "MM(imsi=%s p-tmsi=0x%08x tlli=0x%08x) " fmt, (mm)->imsi, (mm)->p_tmsi, (mm)->tlli, ## args) + /* look-up a SGSN MM context based on TLLI + RAI */ struct sgsn_mm_ctx *sgsn_mm_ctx_by_tlli(uint32_t tlli, const struct gprs_ra_id *raid); @@ -176,6 +179,8 @@ struct sgsn_pdp_ctx { unsigned int num_T_exp; /* number of consecutive T expirations */ }; +#define LOGPDPCTXP(level, pdp, fmt, args...) \ + LOGP(DGPRS, level, "PDP(imsi=%s ti=%u) " fmt, (pdp)->mm->imsi, (pdp)->ti, ## args) /* look up PDP context by MM context and NSAPI */ struct sgsn_pdp_ctx *sgsn_pdp_ctx_by_nsapi(const struct sgsn_mm_ctx *mm, -- 1.8.4.2 From dwillmann at sysmocom.de Thu Sep 4 15:20:53 2014 From: dwillmann at sysmocom.de (Daniel Willmann) Date: Thu, 4 Sep 2014 17:20:53 +0200 Subject: [openbsc 2/2] gprs: Improve loglevels and log messages for SGSN In-Reply-To: <5af7979f7bc45ce7aa2249cf812998aaa564b6d4.1409844053.git.daniel@totalueberwachung.de> References: <5af7979f7bc45ce7aa2249cf812998aaa564b6d4.1409844053.git.daniel@totalueberwachung.de> Message-ID: Many log levels were DEBUG without any good reason. Also where possible the details of the MM or PDP context are now logged with LOGMM/PDPCTXP. --- openbsc/src/gprs/gprs_gmm.c | 107 ++++++++++++++++++++--------------------- openbsc/src/gprs/gprs_llc.c | 6 +-- openbsc/src/gprs/gprs_sgsn.c | 4 +- openbsc/src/gprs/sgsn_libgtp.c | 10 ++-- 4 files changed, 63 insertions(+), 64 deletions(-) diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index fa5e82d..a4305e8 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -352,7 +352,7 @@ static int gsm48_tx_gmm_att_ack(struct sgsn_mm_ctx *mm) uint8_t *ptsig; #endif - DEBUGP(DMM, "<- GPRS ATTACH ACCEPT (new P-TMSI=0x%08x)\n", mm->p_tmsi); + LOGMMCTXP(LOGL_INFO, mm, "<- GPRS ATTACH ACCEPT (new P-TMSI=0x%08x)\n", mm->p_tmsi); mmctx2msgid(msg, mm); @@ -396,7 +396,7 @@ static int _tx_gmm_att_rej(struct msgb *msg, uint8_t gmm_cause) { struct gsm48_hdr *gh; - DEBUGP(DMM, "<- GPRS ATTACH REJECT\n"); + LOGP(DMM, LOGL_NOTICE, "<- GPRS ATTACH REJECT: %s\n", get_value_string(gmm_cause_names, gmm_cause)); gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh) + 1); gh->proto_discr = GSM48_PDISC_MM_GPRS; @@ -426,7 +426,7 @@ static int gsm48_tx_gmm_det_ack(struct sgsn_mm_ctx *mm, uint8_t force_stby) struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; - DEBUGP(DMM, "<- GPRS DETACH ACCEPT\n"); + LOGMMCTXP(LOGL_INFO, mm, "<- GPRS DETACH ACCEPT\n"); mmctx2msgid(msg, mm); @@ -444,7 +444,7 @@ static int gsm48_tx_gmm_id_req(struct sgsn_mm_ctx *mm, uint8_t id_type) struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; - DEBUGP(DMM, "<- GPRS IDENTITY REQUEST: mi_type=%02x\n", id_type); + LOGMMCTXP(LOGL_DEBUG, mm, "<- GPRS IDENTITY REQUEST: mi_type=%02x\n", id_type); mmctx2msgid(msg, mm); @@ -467,7 +467,7 @@ static int gsm48_tx_gmm_auth_ciph_req(struct sgsn_mm_ctx *mm, uint8_t *rand, struct gsm48_auth_ciph_req *acreq; uint8_t *m_rand, *m_cksn; - DEBUGP(DMM, "<- GPRS AUTH AND CIPHERING REQ (rand = %s)\n", + LOGMMCTXP(LOGL_INFO, mm, "<- GPRS AUTH AND CIPHERING REQ (rand = %s)\n", osmo_hexdump(rand, 16)); mmctx2msgid(msg, mm); @@ -507,7 +507,7 @@ static int gsm48_tx_gmm_auth_ciph_rej(struct sgsn_mm_ctx *mm) struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; - DEBUGP(DMM, "<- GPRS AUTH AND CIPH REJECT\n"); + LOGMMCTXP(LOGL_NOTICE, mm, "<- GPRS AUTH AND CIPH REJECT\n"); mmctx2msgid(msg, mm); @@ -582,11 +582,11 @@ static int gsm48_rx_gmm_id_resp(struct sgsn_mm_ctx *ctx, struct msgb *msg) char mi_string[GSM48_MI_SIZE]; gsm48_mi_to_string(mi_string, sizeof(mi_string), &gh->data[1], gh->data[0]); - DEBUGP(DMM, "-> GMM IDENTITY RESPONSE: mi_type=0x%02x MI(%s) ", + LOGMMCTXP(LOGL_DEBUG, ctx, "-> GMM IDENTITY RESPONSE: mi_type=0x%02x MI(%s)\n", mi_type, mi_string); if (!ctx) { - DEBUGP(DMM, "from unknown TLLI 0x%08x?!?\n", msgb_tlli(msg)); + DEBUGP(DMM, "from unknown TLLI 0x%08x?!? This should not happen\n", msgb_tlli(msg)); return -EINVAL; } @@ -603,9 +603,9 @@ static int gsm48_rx_gmm_id_resp(struct sgsn_mm_ctx *ctx, struct msgb *msg) struct sgsn_mm_ctx *ictx; ictx = sgsn_mm_ctx_by_imsi(mi_string); if (ictx) { - DEBUGP(DMM, "Deleting old MM Context for same IMSI " - "p_tmsi_old=0x%08x, p_tmsi_new=0x%08x\n", - ictx->p_tmsi, ctx->p_tmsi); + LOGMMCTXP(LOGL_NOTICE, ctx, "Deleting old MM Context for same IMSI " + "p_tmsi_old=0x%08x\n", + ictx->p_tmsi); gprs_llgmm_assign(ictx->llme, ictx->tlli, 0xffffffff, GPRS_ALGO_GEA0, NULL); /* FIXME: this is a hard free, we don't @@ -623,7 +623,6 @@ static int gsm48_rx_gmm_id_resp(struct sgsn_mm_ctx *ctx, struct msgb *msg) break; } - DEBUGPC(DMM, "\n"); /* Check if we can let the mobile station enter */ return gsm48_gmm_authorize(ctx, ctx->t3350_mode); } @@ -641,7 +640,7 @@ static int gsm48_rx_gmm_att_req(struct sgsn_mm_ctx *ctx, struct msgb *msg, struct gprs_ra_id ra_id; uint16_t cid; - DEBUGP(DMM, "-> GMM ATTACH REQUEST "); + LOGP(DMM, LOGL_INFO, "-> GMM ATTACH REQUEST "); /* As per TS 04.08 Chapter 4.7.1.4, the attach request arrives either * with a foreign TLLI (P-TMSI that was allocated to the MS before), @@ -686,6 +685,8 @@ static int gsm48_rx_gmm_att_req(struct sgsn_mm_ctx *ctx, struct msgb *msg, goto err_inval; cur += ms_ra_acc_cap_len; + LOGPC(DMM, LOGL_INFO, "\n"); + /* Optional: Old P-TMSI Signature, Requested READY timer, TMSI Status */ switch (mi_type) { @@ -704,7 +705,7 @@ static int gsm48_rx_gmm_att_req(struct sgsn_mm_ctx *ctx, struct msgb *msg, if (strncmp(mccmnc, mi_string, 5) && (sgsn->cfg.acl_enabled && !sgsn_acl_lookup(mi_string))) { - LOGP(DMM, LOGL_INFO, "Rejecting ATTACH REQUESET IMSI=%s\n", + LOGP(DMM, LOGL_NOTICE, "Rejecting ATTACH REQUEST IMSI=%s\n", mi_string); return gsm48_tx_gmm_att_rej_oldmsg(msg, GMM_CAUSE_GPRS_NOTALLOWED); @@ -764,11 +765,10 @@ static int gsm48_rx_gmm_att_req(struct sgsn_mm_ctx *ctx, struct msgb *msg, gprs_llgmm_assign(ctx->llme, ctx->tlli, ctx->tlli_new, GPRS_ALGO_GEA0, NULL); - DEBUGPC(DMM, "\n"); return gsm48_gmm_authorize(ctx, GMM_T3350_MODE_ATT); err_inval: - DEBUGPC(DMM, "\n"); + LOGPC(DMM, LOGL_INFO, "\n"); return gsm48_tx_gmm_att_rej_oldmsg(msg, GMM_CAUSE_SEM_INCORR_MSG); } @@ -785,7 +785,7 @@ static int gsm48_rx_gmm_det_req(struct sgsn_mm_ctx *ctx, struct msgb *msg) /* FIXME: In 24.008 there is an optional P-TMSI and P-TMSI signature IE */ - DEBUGP(DMM, "-> GMM DETACH REQUEST TLLI=0x%08x type=%s %s\n", + LOGMMCTXP(LOGL_INFO, ctx, "-> GMM DETACH REQUEST TLLI=0x%08x type=%s %s\n", msgb_tlli(msg), get_value_string(gprs_det_t_mo_strs, detach_type), power_off ? "Power-off" : ""); @@ -794,7 +794,7 @@ static int gsm48_rx_gmm_det_req(struct sgsn_mm_ctx *ctx, struct msgb *msg) /* delete all existing PDP contexts for this MS */ llist_for_each_entry_safe(pdp, pdp2, &ctx->pdp_list, list) { - LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + LOGMMCTXP(LOGL_NOTICE, ctx, "Dropping PDP context for NSAPI=%u " "due to GPRS DETACH REQUEST\n", pdp->nsapi); sgsn_delete_pdp_ctx(pdp); /* FIXME: the callback wants to transmit a DEACT PDP CTX ACK, @@ -819,7 +819,7 @@ static int gsm48_tx_gmm_ra_upd_ack(struct sgsn_mm_ctx *mm) struct gsm48_ra_upd_ack *rua; uint8_t *mid; - DEBUGP(DMM, "<- ROUTING AREA UPDATE ACCEPT\n"); + LOGMMCTXP(LOGL_INFO, mm, "<- ROUTING AREA UPDATE ACCEPT\n"); mmctx2msgid(msg, mm); @@ -860,7 +860,7 @@ static int gsm48_tx_gmm_ra_upd_rej(struct msgb *old_msg, uint8_t cause) struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh; - DEBUGP(DMM, "<- ROUTING AREA UPDATE REJECT\n"); + LOGP(DMM, LOGL_NOTICE, "<- ROUTING AREA UPDATE REJECT\n"); gmm_copy_id(msg, old_msg); @@ -888,14 +888,14 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) { if (pdp->nsapi < 8) { if (!(pdp_status[0] & (1 << pdp->nsapi))) { - LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + LOGMMCTXP(LOGL_NOTICE, mmctx, "Dropping PDP context for NSAPI=%u " "due to PDP CTX STATUS IE= 0x%02x%02x\n", pdp->nsapi, pdp_status[1], pdp_status[0]); sgsn_delete_pdp_ctx(pdp); } } else { if (!(pdp_status[1] & (1 << (pdp->nsapi - 8)))) { - LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + LOGMMCTXP(LOGL_NOTICE, mmctx, "Dropping PDP context for NSAPI=%u " "due to PDP CTX STATUS IE= 0x%02x%02x\n", pdp->nsapi, pdp_status[1], pdp_status[0]); sgsn_delete_pdp_ctx(pdp); @@ -918,7 +918,7 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, /* Update Type 10.5.5.18 */ upd_type = *cur++ & 0x0f; - DEBUGP(DMM, "-> GMM RA UPDATE REQUEST type=\"%s\" ", + LOGP(DMM, LOGL_INFO, "-> GMM RA UPDATE REQUEST type=\"%s\"\n", get_value_string(gprs_upd_t_strs, upd_type)); /* Old routing area identification 10.5.5.15 */ @@ -939,7 +939,7 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, switch (upd_type) { case GPRS_UPD_T_RA_LA: case GPRS_UPD_T_RA_LA_IMSI_ATT: - DEBUGPC(DMM, " unsupported in Mode III, is your SI13 corrupt?\n"); + LOGP(DMM, LOGL_NOTICE, "Update type %i unsupported in Mode III, is your SI13 corrupt?\n", upd_type); return gsm48_tx_gmm_ra_upd_rej(msg, GMM_CAUSE_PROTO_ERR_UNSPEC); break; case GPRS_UPD_T_RA: @@ -952,10 +952,9 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, if (!mmctx || mmctx->mm_state == GMM_DEREGISTERED) { /* send a XID reset to re-set all LLC sequence numbers * in the MS */ - DEBUGPC(DMM, " LLC XID RESET "); + LOGP(DMM, LOGL_NOTICE, "LLC XID RESET\n"); gprs_llgmm_reset(llme); /* The MS has to perform GPRS attach */ - DEBUGPC(DMM, " REJECT\n"); /* Device is still IMSI atached for CS but initiate GPRS ATTACH */ return gsm48_tx_gmm_ra_upd_rej(msg, GMM_CAUSE_MS_ID_NOT_DERIVED); } @@ -974,7 +973,6 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, rate_ctr_inc(&mmctx->ctrg->ctr[GMM_CTR_RA_UPDATE]); - DEBUGPC(DMM, " ACCEPT\n"); #ifdef PTMSI_ALLOC mmctx->p_tmsi_old = mmctx->p_tmsi; mmctx->p_tmsi = sgsn_alloc_ptmsi(); @@ -1008,7 +1006,7 @@ static int gsm48_rx_gmm_status(struct sgsn_mm_ctx *mmctx, struct msgb *msg) { struct gsm48_hdr *gh = msgb_l3(msg); - DEBUGP(DMM, "-> GPRS MM STATUS (cause: %s)\n", + LOGMMCTXP(LOGL_INFO, mmctx, "-> GPRS MM STATUS (cause: %s)\n", get_value_string(gmm_cause_names, gh->data[0])); return 0; @@ -1038,6 +1036,7 @@ static int gsm0408_rcv_gmm(struct sgsn_mm_ctx *mmctx, struct msgb *msg, case GSM48_MT_GMM_ATTACH_REQ: rc = gsm48_rx_gmm_att_req(mmctx, msg, llme); break; + /* For all the following types mmctx can not be NULL */ case GSM48_MT_GMM_ID_RESP: rc = gsm48_rx_gmm_id_resp(mmctx, msg); break; @@ -1049,7 +1048,7 @@ static int gsm0408_rcv_gmm(struct sgsn_mm_ctx *mmctx, struct msgb *msg, break; case GSM48_MT_GMM_ATTACH_COMPL: /* only in case SGSN offered new P-TMSI */ - DEBUGP(DMM, "-> ATTACH COMPLETE\n"); + LOGMMCTXP(LOGL_INFO, mmctx, "-> ATTACH COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); mmctx->p_tmsi_old = 0; /* Unassign the old TLLI */ @@ -1060,7 +1059,7 @@ static int gsm0408_rcv_gmm(struct sgsn_mm_ctx *mmctx, struct msgb *msg, break; case GSM48_MT_GMM_RA_UPD_COMPL: /* only in case SGSN offered new P-TMSI */ - DEBUGP(DMM, "-> ROUTEING AREA UPDATE COMPLETE\n"); + LOGMMCTXP(LOGL_INFO, mmctx, "-> ROUTEING AREA UPDATE COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); mmctx->p_tmsi_old = 0; /* Unassign the old TLLI */ @@ -1070,7 +1069,7 @@ static int gsm0408_rcv_gmm(struct sgsn_mm_ctx *mmctx, struct msgb *msg, rc = 0; break; case GSM48_MT_GMM_PTMSI_REALL_COMPL: - DEBUGP(DMM, "-> PTMSI REALLLICATION COMPLETE\n"); + LOGMMCTXP(LOGL_INFO, mmctx, "-> PTMSI REALLLICATION COMPLETE\n"); mmctx_timer_stop(mmctx, 3350); mmctx->p_tmsi_old = 0; /* Unassign the old TLLI */ @@ -1082,7 +1081,7 @@ static int gsm0408_rcv_gmm(struct sgsn_mm_ctx *mmctx, struct msgb *msg, rc = gsm48_rx_gmm_auth_ciph_resp(mmctx, msg); break; default: - DEBUGP(DMM, "Unknown GSM 04.08 GMM msg type 0x%02x\n", + LOGMMCTXP(LOGL_NOTICE, mmctx, "Unknown GSM 04.08 GMM msg type 0x%02x\n", gh->msg_type); rc = gsm48_tx_gmm_status(mmctx, GMM_CAUSE_MSGT_NOTEXIST_NOTIMPL); break; @@ -1100,7 +1099,7 @@ static void mmctx_timer_cb(void *_mm) switch (mm->T) { case 3350: /* waiting for ATTACH COMPLETE */ if (mm->num_T_exp >= 5) { - LOGP(DMM, LOGL_NOTICE, "T3350 expired >= 5 times\n"); + LOGMMCTXP(LOGL_NOTICE, mm, "T3350 expired >= 5 times\n"); mm->mm_state = GMM_DEREGISTERED; /* FIXME: should we return some error? */ break; @@ -1121,7 +1120,7 @@ static void mmctx_timer_cb(void *_mm) break; case 3360: /* waiting for AUTH AND CIPH RESP */ if (mm->num_T_exp >= 5) { - LOGP(DMM, LOGL_NOTICE, "T3360 expired >= 5 times\n"); + LOGMMCTXP(LOGL_NOTICE, mm, "T3360 expired >= 5 times\n"); mm->mm_state = GMM_DEREGISTERED; break; } @@ -1130,7 +1129,7 @@ static void mmctx_timer_cb(void *_mm) break; case 3370: /* waiting for IDENTITY RESPONSE */ if (mm->num_T_exp >= 5) { - LOGP(DMM, LOGL_NOTICE, "T3370 expired >= 5 times\n"); + LOGMMCTXP(LOGL_NOTICE, mm, "T3370 expired >= 5 times\n"); gsm48_tx_gmm_att_rej(mm, GMM_CAUSE_MS_ID_NOT_DERIVED); mm->mm_state = GMM_DEREGISTERED; break; @@ -1140,7 +1139,7 @@ static void mmctx_timer_cb(void *_mm) osmo_timer_schedule(&mm->timer, GSM0408_T3370_SECS, 0); break; default: - LOGP(DMM, LOGL_ERROR, "timer expired in unknown mode %u\n", + LOGMMCTXP(LOGL_ERROR, mm, "timer expired in unknown mode %u\n", mm->T); } } @@ -1195,7 +1194,7 @@ int gsm48_tx_gsm_act_pdp_acc(struct sgsn_pdp_ctx *pdp) struct gsm48_hdr *gh; uint8_t transaction_id = pdp->ti ^ 0x8; /* flip */ - DEBUGP(DMM, "<- ACTIVATE PDP CONTEXT ACK\n"); + LOGPDPCTXP(LOGL_INFO, pdp, "<- ACTIVATE PDP CONTEXT ACK\n"); mmctx2msgid(msg, pdp->mm); @@ -1239,7 +1238,7 @@ int gsm48_tx_gsm_act_pdp_rej(struct sgsn_mm_ctx *mm, uint8_t tid, struct gsm48_hdr *gh; uint8_t transaction_id = tid ^ 0x8; /* flip */ - DEBUGP(DMM, "<- ACTIVATE PDP CONTEXT REJ(cause=%u)\n", cause); + LOGMMCTXP(LOGL_NOTICE, mm, "<- ACTIVATE PDP CONTEXT REJ(cause=%u)\n", cause); mmctx2msgid(msg, mm); @@ -1262,7 +1261,7 @@ static int _gsm48_tx_gsm_deact_pdp_req(struct sgsn_mm_ctx *mm, uint8_t tid, struct gsm48_hdr *gh; uint8_t transaction_id = tid ^ 0x8; /* flip */ - DEBUGP(DMM, "<- DEACTIVATE PDP CONTEXT REQ\n"); + LOGMMCTXP(LOGL_INFO, mm, "<- DEACTIVATE PDP CONTEXT REQ\n"); mmctx2msgid(msg, mm); @@ -1288,7 +1287,7 @@ static int _gsm48_tx_gsm_deact_pdp_acc(struct sgsn_mm_ctx *mm, uint8_t tid) struct gsm48_hdr *gh; uint8_t transaction_id = tid ^ 0x8; /* flip */ - DEBUGP(DMM, "<- DEACTIVATE PDP CONTEXT ACK\n"); + LOGMMCTXP(LOGL_INFO, mm, "<- DEACTIVATE PDP CONTEXT ACK\n"); mmctx2msgid(msg, mm); @@ -1316,7 +1315,7 @@ static int gsm48_rx_gsm_act_pdp_req(struct sgsn_mm_ctx *mmctx, struct sgsn_ggsn_ctx *ggsn; struct sgsn_pdp_ctx *pdp; - DEBUGP(DMM, "-> ACTIVATE PDP CONTEXT REQ: SAPI=%u NSAPI=%u ", + LOGMMCTXP(LOGL_INFO, mmctx, "-> ACTIVATE PDP CONTEXT REQ: SAPI=%u NSAPI=%u ", act_req->req_llc_sapi, act_req->req_nsapi); /* FIXME: length checks! */ @@ -1364,7 +1363,7 @@ static int gsm48_rx_gsm_act_pdp_req(struct sgsn_mm_ctx *mmctx, break; } - DEBUGPC(DMM, "\n"); + LOGPC(DMM, LOGL_INFO, "\n"); /* put the non-TLV elements in the TLV parser structure to * pass them on to the SGSN / GTP code */ @@ -1429,12 +1428,12 @@ static int gsm48_rx_gsm_deact_pdp_req(struct sgsn_mm_ctx *mm, struct msgb *msg) uint8_t transaction_id = (gh->proto_discr >> 4); struct sgsn_pdp_ctx *pdp; - DEBUGP(DMM, "-> DEACTIVATE PDP CONTEXT REQ (cause: %s)\n", + LOGMMCTXP(LOGL_INFO, mm, "-> DEACTIVATE PDP CONTEXT REQ (cause: %s)\n", get_value_string(gsm_cause_names, gh->data[0])); pdp = sgsn_pdp_ctx_by_tid(mm, transaction_id); if (!pdp) { - LOGP(DMM, LOGL_NOTICE, "Deactivate PDP Context Request for " + LOGMMCTXP(LOGL_NOTICE, mm, "Deactivate PDP Context Request for " "non-existing PDP Context (IMSI=%s, TI=%u)\n", mm->imsi, transaction_id); return _gsm48_tx_gsm_deact_pdp_acc(mm, transaction_id); @@ -1450,11 +1449,11 @@ static int gsm48_rx_gsm_deact_pdp_ack(struct sgsn_mm_ctx *mm, struct msgb *msg) uint8_t transaction_id = (gh->proto_discr >> 4); struct sgsn_pdp_ctx *pdp; - DEBUGP(DMM, "-> DEACTIVATE PDP CONTEXT ACK\n"); + LOGMMCTXP(LOGL_INFO, mm, "-> DEACTIVATE PDP CONTEXT ACK\n"); pdp = sgsn_pdp_ctx_by_tid(mm, transaction_id); if (!pdp) { - LOGP(DMM, LOGL_NOTICE, "Deactivate PDP Context Accept for " + LOGMMCTXP(LOGL_NOTICE, mm, "Deactivate PDP Context Accept for " "non-existing PDP Context (IMSI=%s, TI=%u)\n", mm->imsi, transaction_id); return 0; @@ -1467,7 +1466,7 @@ static int gsm48_rx_gsm_status(struct sgsn_mm_ctx *ctx, struct msgb *msg) { struct gsm48_hdr *gh = msgb_l3(msg); - DEBUGP(DMM, "-> GPRS SM STATUS (cause: %s)\n", + LOGMMCTXP(LOGL_INFO, ctx, "-> GPRS SM STATUS (cause: %s)\n", get_value_string(gsm_cause_names, gh->data[0])); return 0; @@ -1482,7 +1481,7 @@ static void pdpctx_timer_cb(void *_pdp) switch (pdp->T) { case 3395: /* waiting for PDP CTX DEACT ACK */ if (pdp->num_T_exp >= 4) { - LOGP(DMM, LOGL_NOTICE, "T3395 expired >= 5 times\n"); + LOGPDPCTXP(LOGL_NOTICE, pdp, "T3395 expired >= 5 times\n"); pdp->state = PDP_STATE_INACTIVE; sgsn_delete_pdp_ctx(pdp); break; @@ -1491,7 +1490,7 @@ static void pdpctx_timer_cb(void *_pdp) osmo_timer_schedule(&pdp->timer, GSM0408_T3395_SECS, 0); break; default: - LOGP(DMM, LOGL_ERROR, "timer expired in unknown mode %u\n", + LOGPDPCTXP(LOGL_ERROR, pdp, "timer expired in unknown mode %u\n", pdp->T); } } @@ -1528,12 +1527,12 @@ static int gsm0408_rcv_gsm(struct sgsn_mm_ctx *mmctx, struct msgb *msg, case GSM48_MT_GSM_REQ_PDP_ACT_REJ: case GSM48_MT_GSM_ACT_AA_PDP_REQ: case GSM48_MT_GSM_DEACT_AA_PDP_REQ: - DEBUGP(DMM, "Unimplemented GSM 04.08 GSM msg type 0x%02x\n", + LOGMMCTXP(LOGL_NOTICE, mmctx, "Unimplemented GSM 04.08 GSM msg type 0x%02x\n", gh->msg_type); rc = gsm48_tx_sm_status(mmctx, GSM_CAUSE_MSGT_NOTEXIST_NOTIMPL); break; default: - DEBUGP(DMM, "Unknown GSM 04.08 GSM msg type 0x%02x\n", + LOGMMCTXP(LOGL_NOTICE, mmctx, "Unknown GSM 04.08 GSM msg type 0x%02x\n", gh->msg_type); rc = gsm48_tx_sm_status(mmctx, GSM_CAUSE_MSGT_NOTEXIST_NOTIMPL); break; @@ -1570,7 +1569,7 @@ int gsm0408_gprs_rcvmsg(struct msgb *msg, struct gprs_llc_llme *llme) rc = gsm0408_rcv_gsm(mmctx, msg, llme); break; default: - DEBUGP(DMM, "Unknown GSM 04.08 discriminator 0x%02x\n", + LOGP(DMM, LOGL_NOTICE, "Unknown GSM 04.08 discriminator 0x%02x\n", pdisc); /* FIXME: return status message */ break; @@ -1591,7 +1590,7 @@ int gprs_gmm_rx_suspend(struct gprs_ra_id *raid, uint32_t tlli) } if (mmctx->mm_state != GMM_REGISTERED_NORMAL) { - LOGP(DMM, LOGL_NOTICE, "SUSPEND request while state " + LOGMMCTXP(LOGL_NOTICE, mmctx, "SUSPEND request while state " "!= REGISTERED (TLLI=%08x)\n", tlli); return -EINVAL; } @@ -1616,7 +1615,7 @@ int gprs_gmm_rx_resume(struct gprs_ra_id *raid, uint32_t tlli, } if (mmctx->mm_state != GMM_REGISTERED_SUSPENDED) { - LOGP(DMM, LOGL_NOTICE, "RESUME request while state " + LOGMMCTXP(LOGL_NOTICE, mmctx, "RESUME request while state " "!= SUSPENDED (TLLI=%08x)\n", tlli); /* FIXME: should we not simply ignore it? */ return -EINVAL; diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index e6b1f07..f085ce7 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -45,7 +45,7 @@ static inline uint32_t tlli_foreign2local(uint32_t tlli) if (gprs_tlli_type(tlli) == TLLI_FOREIGN) { new_tlli = tlli | 0x40000000; - DEBUGP(DLLC, "TLLI 0x%08x is foreign, converting to " + LOGP(DLLC, LOGL_NOTICE, "TLLI 0x%08x is foreign, converting to " "local TLLI 0x%08x\n", tlli, new_tlli); } else new_tlli = tlli; @@ -195,7 +195,7 @@ static struct gprs_llc_lle *lle_for_rx_by_tlli_sapi(const uint32_t tlli, struct gprs_llc_llme *llme; /* FIXME: don't use the TLLI but the 0xFFFF unassigned? */ llme = llme_alloc(tlli); - LOGP(DLLC, LOGL_DEBUG, "LLC RX: unknown TLLI 0x%08x, " + LOGP(DLLC, LOGL_NOTICE, "LLC RX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", tlli); lle = &llme->lle[sapi]; return lle; @@ -357,7 +357,7 @@ int gprs_llc_tx_ui(struct msgb *msg, uint8_t sapi, int command, lle = lle_by_tlli_sapi(tlli_foreign2local(msgb_tlli(msg)), sapi); if (!lle) { struct gprs_llc_llme *llme; - LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " + LOGP(DLLC, LOGL_NOTICE, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; diff --git a/openbsc/src/gprs/gprs_sgsn.c b/openbsc/src/gprs/gprs_sgsn.c index f92b2de..0c15619 100644 --- a/openbsc/src/gprs/gprs_sgsn.c +++ b/openbsc/src/gprs/gprs_sgsn.c @@ -254,7 +254,7 @@ void sgsn_pdp_ctx_free(struct sgsn_pdp_ctx *pdp) * sgsn_libgtp:cb_data_ind() */ if (pdp->lib) { struct pdp_t *lib = pdp->lib; - LOGP(DGPRS, LOGL_NOTICE, "freeing PDP context that still " + LOGPDPCTXP(LOGL_NOTICE, pdp, "freeing PDP context that still " "has a libgtp handle attached to it, this shouldn't " "happen!\n"); osmo_generate_backtrace(); @@ -376,7 +376,7 @@ static void drop_one_pdp(struct sgsn_pdp_ctx *pdp) gsm48_tx_gsm_deact_pdp_req(pdp, GSM_CAUSE_NET_FAIL); else { /* FIXME: GPRS paging in case MS is SUSPENDED */ - LOGP(DGPRS, LOGL_NOTICE, "Hard-dropping PDP ctx due to GGSN " + LOGPDPCTXP(LOGL_NOTICE, pdp, "Hard-dropping PDP ctx due to GGSN " "recovery\n"); /* FIXME: how to tell this to libgtp? */ sgsn_pdp_ctx_free(pdp); diff --git a/openbsc/src/gprs/sgsn_libgtp.c b/openbsc/src/gprs/sgsn_libgtp.c index 1a7f078..44e94b3 100644 --- a/openbsc/src/gprs/sgsn_libgtp.c +++ b/openbsc/src/gprs/sgsn_libgtp.c @@ -209,7 +209,7 @@ struct sgsn_pdp_ctx *sgsn_create_pdp_ctx(struct sgsn_ggsn_ctx *ggsn, /* SGSN wants to delete a PDP context */ int sgsn_delete_pdp_ctx(struct sgsn_pdp_ctx *pctx) { - LOGP(DGPRS, LOGL_ERROR, "Delete PDP Context\n"); + LOGPDPCTXP(LOGL_ERROR, pctx, "Delete PDP Context\n"); /* FIXME: decide if we need teardown or not ! */ return gtp_delete_context_req(pctx->ggsn->gsn, pctx->lib, pctx, 1); @@ -260,7 +260,7 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) struct sgsn_pdp_ctx *pctx = cbp; uint8_t reject_cause; - DEBUGP(DGPRS, "Received CREATE PDP CTX CONF, cause=%d(%s)\n", + LOGPDPCTXP(LOGL_INFO, pctx, "Received CREATE PDP CTX CONF, cause=%d(%s)\n", cause, get_value_string(gtp_cause_strs, cause)); /* Check for cause value if it was really successful */ @@ -316,7 +316,7 @@ static int delete_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) struct sgsn_pdp_ctx *pctx = cbp; int rc; - DEBUGP(DGPRS, "Received DELETE PDP CTX CONF, cause=%d(%s)\n", + LOGPDPCTXP(LOGL_INFO, pctx, "Received DELETE PDP CTX CONF, cause=%d(%s)\n", cause, get_value_string(gtp_cause_strs, cause)); /* Deactivate the SNDCP layer */ @@ -338,7 +338,7 @@ static int delete_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) static int echo_conf(struct pdp_t *pdp, void *cbp, int recovery) { if (recovery < 0) { - DEBUGP(DGPRS, "GTP Echo Request timed out\n"); + LOGP(DGPRS, LOGL_NOTICE, "GTP Echo Request timed out\n"); /* FIXME: if version == 1, retry with version 0 */ } else { DEBUGP(DGPRS, "GTP Rx Echo Response\n"); @@ -353,7 +353,7 @@ static int cb_recovery(struct sockaddr_in *peer, uint8_t recovery) ggsn = sgsn_ggsn_ctx_by_addr(&peer->sin_addr); if (!ggsn) { - DEBUGP(DGPRS, "Received Recovery IE for unknown GGSN\n"); + LOGP(DGPRS, LOGL_NOTICE, "Received Recovery IE for unknown GGSN\n"); return -EINVAL; } -- 1.8.4.2 From laforge at gnumonks.org Mon Sep 8 13:11:35 2014 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Sep 2014 21:11:35 +0800 Subject: [openbsc 1/2] gprs_sgsn.h: Add two macros to log details of MM/PDP contexts In-Reply-To: <5af7979f7bc45ce7aa2249cf812998aaa564b6d4.1409844053.git.daniel@totalueberwachung.de> References: <5af7979f7bc45ce7aa2249cf812998aaa564b6d4.1409844053.git.daniel@totalueberwachung.de> Message-ID: <20140908131135.GH6932@nataraja> Hi Daniel, in order to reduce the line length a bit, I would sugegst to change > + LOGP(DMM, level, "MM(imsi=%s p-tmsi=0x%08x tlli=0x%08x) " fmt, (mm)->imsi, (mm)->p_tmsi, (mm)->tlli, ## args) to > + LOGP(DMM, level, "MM(%s/%08x/%08x) " fmt, (mm)->imsi, (mm)->p_tmsi, (mm)->tlli, ## args) or even leave the TLLI away, as I presume if you use the mm-context TLLI (and not the TLLI that was read from the currently processed message), then it will be a quite predictable derivate of the P-TMSI anyway. > + LOGP(DGPRS, level, "PDP(imsi=%s ti=%u) " fmt, (pdp)->mm->imsi, (pdp)->ti, ## args) here also one could change it to > + LOGP(DGPRS, level, "PDP(%s/%u) " fmt, (pdp)->mm->imsi, (pdp)->ti, ## args) to save some characers in line length, which a) make it more difficult to read the log messages on screens of limited widdth b) reduce the log file size as it accumulates over time. Apart from that the patches should be merged, from my point of view. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ricardohassa at googlemail.com Fri Sep 5 00:28:18 2014 From: ricardohassa at googlemail.com (Ricardo Hassa) Date: Fri, 5 Sep 2014 02:28:18 +0200 Subject: Buying a NanoBTS (Siemens BS-11, IP.Access...) / Network in a Box (UltraWAVE...)... Message-ID: Hello, anyone can sell me a NanoBTS (Siemens BS-11 etc...) / Network in a Box (UltraWAVE...) or other bts hardware (RangeNetworks, Ip.Access...) that works with OpenBSC? contact me at: ricardohassa [ at ] googlemail.com I am living in germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From choukoumoun at gmail.com Mon Sep 8 10:53:40 2014 From: choukoumoun at gmail.com (alc00ptane) Date: Mon, 08 Sep 2014 12:53:40 +0200 Subject: Buying a NanoBTS In-Reply-To: References: <540D6FAD.3000507@gmail.com> Message-ID: <540D8AB4.4060106@gmail.com> Hello, anyone can sell me a NanoBTS ? Thanks. Choukoumoun. From perper at o2.pl Fri Sep 5 13:41:16 2014 From: perper at o2.pl (Perper) Date: Fri, 05 Sep 2014 15:41:16 +0200 Subject: Training sequences of ARFCNs different than C0 Message-ID: <5409BD7C.9050003@o2.pl> Hi All, I've started implementing reception of multiple channels of a BTS as part of my gr-gsm project and I encountered little problem. C0 channel (most probably) uses different training sequence than the rest of ARFCNs from Cell Allocation. I'm not sure that this is the case. But if I compute cross correlation I always get the strongest peak for a different training sequence. The training seqence number used on C0 is usually equal to BCC (BTS Color Code) that is transmitted in SCH bursts (I've never seen different situation in the wild). I can also find training sequence code of C0 transmitted on BCCH inside of Channel Description in System Information Type 4 messages. Where BTSes transmit training sequence (/sequences) of ARFCNs other than C0? Best Regards, Piotr Krysik From laforge at gnumonks.org Mon Sep 8 13:02:56 2014 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Sep 2014 21:02:56 +0800 Subject: Training sequences of ARFCNs different than C0 In-Reply-To: <5409BD7C.9050003@o2.pl> References: <5409BD7C.9050003@o2.pl> Message-ID: <20140908130256.GE6932@nataraja> Hi Piotr, good to hear from you again :) On Fri, Sep 05, 2014 at 03:41:16PM +0200, Perper wrote: > Where BTSes transmit training sequence (/sequences) of > ARFCNs other than C0? This should be part of the Channel Description IE of the IMMEDIATE ASSIGNMENT of the specific logical channel on the AGCH in the downlink CCCH. Indeed, each logical channel can have a different training sequence and they do not need to match the BCCH one. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From perper at o2.pl Mon Sep 8 19:24:13 2014 From: perper at o2.pl (Perper) Date: Mon, 08 Sep 2014 21:24:13 +0200 Subject: Training sequences of ARFCNs different than C0 In-Reply-To: <20140908130256.GE6932@nataraja> References: <5409BD7C.9050003@o2.pl> <20140908130256.GE6932@nataraja> Message-ID: <540E025D.6010406@o2.pl> Hi Harald, W dniu 08.09.2014 o 15:02, Harald Welte pisze: > Hi Piotr, > > good to hear from you again :) I'm just trying to complete some of the TODO's that I left ;). On the sidenote: osmocom is great! Thanks to your efforts mobile communication is not an unreachable mystery it once was. > On Fri, Sep 05, 2014 at 03:41:16PM +0200, Perper wrote: >> Where BTSes transmit training sequence (/sequences) of >> ARFCNs other than C0? > This should be part of the Channel Description IE of the IMMEDIATE > ASSIGNMENT of the specific logical channel on the AGCH in the downlink > CCCH. Indeed, each logical channel can have a different training > sequence and they do not need to match the BCCH one. > Thanks for the answer! I will experiment with autodetection of the sequence used and/or reconfiguration based on information transmitted on AGCH. Regards, Piotr Krysik From can_ni at hotmail.it Fri Sep 5 16:35:55 2014 From: can_ni at hotmail.it (calogero cannizzaro) Date: Fri, 5 Sep 2014 18:35:55 +0200 Subject: GPRS core network simulation Message-ID: I everybody, I?m a new subscriber. I have a question for you : 1. Can i use FakeBTS to simulate a gprs core network , using osmoNITB, osmoSGSN and openGGSN, without BTS hardware? 2. If not, can i simulate the core network without BTS? Many Thanks Best regards. C.Cannizzaro -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Sep 8 13:07:09 2014 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Sep 2014 21:07:09 +0800 Subject: GPRS core network simulation In-Reply-To: References: Message-ID: <20140908130709.GG6932@nataraja> Hi Calogero, * what is the goal / use case of your simulation? * what exactly do you need to simulate? * what is the input/output of the simulation? In general, the vaious Osmo-* implementations are not designed for simulation buy for actual network operation. So you will likely need to implement quite a lot in order to use it in a simulation context. The most important question is, that you need code that will behave as actual handsets on a network, and code to manage all those virtual handsets, tell them what they should be doing, etc. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From can_ni at hotmail.it Tue Sep 9 12:19:13 2014 From: can_ni at hotmail.it (Calogero Cannizzaro) Date: Tue, 9 Sep 2014 14:19:13 +0200 Subject: GPRS core network simulation Message-ID: Hi mister Harald,? thank you very much for your answer. I am an engineering student and I have started to work on my thesis.? I would like to perform a GPRS core network completely using virtual machine (virtual box based) and use it to prove that an operator can manage M2M traffic just using standard hardware, virtual machine and open source components (osmocom project ).? At this moment i deployed 4 virtual machine, one for each osmo component (osmoNITB, openGGSN, osmoSGSN) on the fourth VM I want to run the fakeBTS because?I don't have a bts. I would like to simulate it as if there are some M2M devices generate request(attach, pdp context for example). When I try the communication between NITB and fakeBTS there are some error Messages related to RSL. Then there isn't communication between NITB-fakeBTS and SGSN-GGSN. Do you detect any configuration error?? Thank you. Best regard Calo -------- Original message -------- Subject: Re: GPRS core network simulation From: Harald Welte To: calogero cannizzaro CC: "openbsc at lists.osmocom.org" Hi Calogero, * what is the goal / use case of your simulation? * what exactly do you need to simulate? * what is the input/output of the simulation? In general, the vaious Osmo-* implementations are not designed for simulation buy for actual network operation.? So you will likely need to implement quite a lot in order to use it in a simulation context.? The most important question is, that you need code that will behave as actual handsets on a network, and code to manage all those virtual handsets, tell them what they should be doing, etc. -- - Harald Welte ?? http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." ????????????????????????????????????????????????? (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Sep 11 04:46:07 2014 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Sep 2014 12:46:07 +0800 Subject: GPRS core network simulation In-Reply-To: References: Message-ID: <20140911044607.GM20345@nataraja> Hi Calogero, On Tue, Sep 09, 2014 at 02:19:13PM +0200, Calogero Cannizzaro wrote: > At this moment i deployed 4 virtual machine, one for each osmo > component (osmoNITB, openGGSN, osmoSGSN) on the fourth VM I want to > run the fakeBTS because?I don't have a bts. You wouldn't just need a virtual BTS, but also a virtual PCU and many virtual GPRS capable MS. Yes, this can be done, but it would be several man-months of software development even for an experienced developer who is already familiar with the specifications. So unless the topic of developing software for such virtual BTS, PCU and GPRS-MS is the core of your thesis, I don't think this is a good idea. Regards, -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From can_ni at hotmail.it Thu Sep 11 17:02:01 2014 From: can_ni at hotmail.it (calogero cannizzaro) Date: Thu, 11 Sep 2014 19:02:01 +0200 Subject: GPRS core network simulation In-Reply-To: <20140911044607.GM20345@nataraja> References: , <20140911044607.GM20345@nataraja> Message-ID: Hi mister Harald, I give you more details about what I'm doing. I'm sorry for my inexperience. I have built the following configuration (each component it's a virtual machine): -------------------- | OsmoNITB | ------------------- | 192.168.30.2 | | | 192.168.60.1 192.168.10.2 192.168.10.1 ----------------- -------------------- ------------------ | FakeBTS | <---------------------> | OsmoSGSN | <-----------------> | OpenGGSN | ----> INTERNET ----------------- -------------------- ------------------ 192.168.20.1 192.168.20.2 OpenGGSN runs by using this configuration file: # TAG: fg # Include this flag if process is to run in the foreground # #fg # TAG: debug # Include this flag to include debug information. #debug # TAG: conf # Configuration file to use. This file is the configuration file, # so changing this parameter in the configuration file does not make # sense. Use it on the command line instead. # TAG: pidfile # File to store information about the process id of the program. # The program must have write access to this file/directory. #pidfile /var/run/ggsn.pid # TAG: statedir # Directory to use for nonvolatile storage. # The program must have write access to this directory. #statedir /var/lib/ggsn/ # TAG: listen # Specifies the local IP address to listen to listen 192.168.10.1 # TAG: net # IP network address of external packet data network # Used to set up network interface. #net 192.168.0.0/24 # TAG: ipup # Script executed after network interface has been brought up. # Executed with the following parameters: #ipup /etc/ggsn/ip-up # TAG: ipdown # Script executed after network interface has been taken down. # Executed with the following parameters: #ipdown /etc/ggsn/ip-down # TAG: dynip # Dynamic IP address pool. # Used for allocation of dynamic IP address when address is not given # by HLR. # If this option is not given then the net option is used as a substitute. dynip 192.168.0.0/24 # TAG: statip # Use of this tag is currently UNSUPPORTED # Static IP address pool. # Used for allocation of static IP address by means of HLR. #statip 192.168.1.0/24 # TAG: pcodns1 # Protocol configuration option domain name system server 1. #pcodns1 0.0.0.0 # TAG: pcodns2 # Protocol configuration option domain name system server 2. #pcodns2 0.0.0.0 # TAG: timelimit # Exit after timelim OsmoSGSN runs by using this configuration file: Osmocom SGSN configuration ! ! line vty no login ! sgsn gtp local-ip 192.168.10.2 ggsn 0 remote-ip 192.168.10.1 ggsn 0 gtp-version 1 ! ns timer tns-block 3 timer tns-block-retries 3 timer tns-reset 3 timer tns-reset-retries 3 timer tns-test 30 timer tns-alive 3 timer tns-alive-retries 10 encapsulation udp local-ip 192.168.0.128 encapsulation udp local-port 23000 encapsulation framerelay-gre enabled 0 ! bssgp OsmoNITB runs by using the nanoBTS configuration file, configured for gprs support : ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 short name OpenBSC long name OpenBSC auth policy closed location updating reject cause 13 encryption a5 0 neci 1 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 4 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 bts 0 type nanobts band DCS1800 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 gprs mode gprs gprs routing area 0 gprs cell bvci 2 gprs nsei 101 gprs nsvc 0 nsvci 101 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 192.168.20.2 trx 0 rf_locked 0 arfcn 514 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F timeslot 3 phys_chan_config TCH/F timeslot 4 phys_chan_config TCH/F timeslot 5 phys_chan_config TCH/F timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config PDCH Finally, according to this guide: http://openbsc.osmocom.org/trac/wiki/simulation , I installed smalltalk interpreter on fakeBTS VM, and then i tried to run the Smalltalk script to request a channel. This is what happens: OsmoSGSN and OpenGGSN run but there isn't messages exchange. OsmoNITB runs and receive messages from fakeBTS but I read this error: <0004> abis_rsl.c:2050 unknown RSL message discriminator 0x01 > <0019> input/ipaccess.c:458 Bad signalling message,sign_link returned error Furthermore there isn't communication toward OsmoSGSN. I would like to achieve a simple communication among this components. For example ,running a script on fakeBTS to generate a PDP context request or attach request, I would like to see the request toward OsmoNITB, OsmoSGSN and finally OpenGGSN, and the response go back. My questions are: 1. Is the network configuration correct? 2. Are the configuration file correct? 3. How can I fix the RSL error message?t 4. Does a script to generate a PDP context request or attach request exist in FakeBTS package? If not, do you think that it's possible to write it in a short time? Best regards and thanks for help. Calogero > Date: Thu, 11 Sep 2014 12:46:07 +0800 > From: laforge at gnumonks.org > To: can_ni at hotmail.it > Subject: Re: GPRS core network simulation > CC: openbsc at lists.osmocom.org > > Hi Calogero, > > On Tue, Sep 09, 2014 at 02:19:13PM +0200, Calogero Cannizzaro wrote: > > At this moment i deployed 4 virtual machine, one for each osmo > > component (osmoNITB, openGGSN, osmoSGSN) on the fourth VM I want to > > run the fakeBTS because I don't have a bts. > > You wouldn't just need a virtual BTS, but also a virtual PCU and many > virtual GPRS capable MS. Yes, this can be done, but it would be several > man-months of software development even for an experienced developer who > is already familiar with the specifications. > > So unless the topic of developing software for such virtual > BTS, PCU and GPRS-MS is the core of your thesis, I don't think this is a > good idea. > > Regards, > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricardohassa at googlemail.com Sat Sep 6 11:52:33 2014 From: ricardohassa at googlemail.com (Ricardo Hassa) Date: Sat, 6 Sep 2014 13:52:33 +0200 Subject: Buying GSM Hardware Message-ID: Hi, anyone can sell me working bts hardware that works with openBTS or similar? I am living in Germany -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Sep 8 13:04:24 2014 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Sep 2014 21:04:24 +0800 Subject: Buying GSM Hardware In-Reply-To: References: Message-ID: <20140908130424.GF6932@nataraja> Hi Ricardo, I think posting once is sufficient, and if nobody responds I suspect nobody rally has any surplus equipent that they want to sell at this point, sorry. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jerlbeck at sysmocom.de Wed Sep 10 09:41:26 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Wed, 10 Sep 2014 11:41:26 +0200 Subject: [PATCH] gprs: Fix bssgp_rcvmsg to handle signalling msgs with BVCI IE Message-ID: <1410342086-17215-1-git-send-email-jerlbeck@sysmocom.de> Currently BSSGP messages with an NS BVCI of 0 (signalling) are discarded if they aren't RESET messages. Thus valid signalling messages (e.g. BLOCK) are not handled properly, because the BVCI IE is ignored if it present. Instead a STATUS message referring to BVCI 0 (instead of the BVCI used in the BLOCK message) is returned. This patch changes the implementation to use the BVCI contained in the BVCI IE if that is present in a signalling message. It fixes BSSGP BLOCK/UNBLOCK for the osmo-sgsn. Note that signalling messages without an BVCI IE (e.g. SUSPEND/RESUME) are still rejected. Ticket: OW#1205 Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index b8c6c74..0e9fd38 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -976,6 +976,7 @@ int bssgp_rcvmsg(struct msgb *msg) struct bssgp_bvc_ctx *bctx; uint8_t pdu_type = bgph->pdu_type; uint16_t ns_bvci = msgb_bvci(msg); + uint16_t bvci = ns_bvci; int data_len; int rc = 0; @@ -991,14 +992,17 @@ int bssgp_rcvmsg(struct msgb *msg) rc = bssgp_tlv_parse(&tp, budh->data, data_len); } + if (bvci == BVCI_SIGNALLING && TLVP_PRESENT(&tp, BSSGP_IE_BVCI)) + bvci = ntohs(*(uint16_t *)TLVP_VAL(&tp, BSSGP_IE_BVCI)); + /* look-up or create the BTS context for this BVC */ - bctx = btsctx_by_bvci_nsei(ns_bvci, msgb_nsei(msg)); + bctx = btsctx_by_bvci_nsei(bvci, msgb_nsei(msg)); /* Only a RESET PDU can create a new BVC context */ if (!bctx && pdu_type != BSSGP_PDUT_BVC_RESET) { LOGP(DBSSGP, LOGL_NOTICE, "NSEI=%u/BVCI=%u Rejecting PDU " - "type %u for unknown BVCI\n", msgb_nsei(msg), ns_bvci, + "type %u for unknown BVCI\n", msgb_nsei(msg), bvci, pdu_type); - return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, &ns_bvci, msg); + return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, &bvci, msg); } if (bctx) { -- 1.9.1 From laforge at gnumonks.org Thu Sep 11 05:39:40 2014 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Sep 2014 13:39:40 +0800 Subject: libosmo{core,vty,codec,ctrl,vty} GPL v2 vs v3 In-Reply-To: <533327E6.8090700@steve-m.de> References: <53330DB4.1070308@fairwaves.co> <533327E6.8090700@steve-m.de> Message-ID: <20140911053940.GN20345@nataraja> Hi Steve and Max, sorry for catching up that late. It is only now in my holidays that I finally am able to find some time to read through the osmocom mailing lists again. On Wed, Mar 26, 2014 at 08:17:58PM +0100, Steve Markgraf wrote: > On 26.03.2014 18:26, Max.Suraev at fairwaves.co wrote: > > I've just noticed (yepp, I'm very observant :) that COPYING in > > libosmocore is GPLv2. Is there any particular reason we still do > > not use GPLv3? libosmocore was started as a GPLv2+ project, in order to ensure maximum compatibility to a variety of applications. Some free software applications out there are still GPLv2, and we want them to be able to use libosmocore. * libosmocodec is pure GPLv2+ * libosmoctrl is pure GPLv2+ * libosmovty is pure GPLv2+ > Good point, git grep "either version 3" actually shows that there are > quite some files that are GPLv3+, so the compiled and linked binaries > already make use of the "or any later version" of the other GPLv2+ > licensed files. This is actually a problem, and one that needs fixing. 1) libosmogb Most of the hits are in libosmogb, as the libosmogb code was first developed as part of (AGPLv3+) OpenBSC/OsmoSGSN and then migrated to libosmocore.git reporitory to be also used from osmo-pcu, not just from the SGSN side. The majority of the osmo-pcu codebase appears to be GPLv2+, so linking with a GPLv3+ libosmogb is fine. However, an AGPL libosmogb would not be suitable. I've reviewed the copyright ownership /authorship situation of libosmogb and see if we can make sure that all authors agree to a GPLv3+ licensing of it. Based on the review, we have the following copyright holders: * Harald Welte * Holger Freyther * sysmocom (Jacob, Holger?) * Andreas Eversberg Holger/Andreas: * Would you agree to license libosmogb under GPLv2+ or GPLv3+? * Do you have any preference regarding v2+ or v3+? 2) libosmocore: strrb.c / loggingrb.c These are the only two files of libosmocore, which claim to be GPLv3+. I would personally consider this a mistake at the time, but I've included Katerina in the Cc. Holger/Katerina: * Do you remember how and why this code states it is GPLv3+ instead of the usual GPLv2+ in libosmocore? * Was this intentional or a mistake? * Irrespective of the past, would you agree to license strrb/loggingrb under GPLv2+? If yes, I will commit the related code change 3) libosmogsm: gsm0411_smc.c und gsm0411_smr.c This is due to jolly first writing them as part of osmoocomBB and then later moving them to libosmocore. Jolly: Can you please confirm if you are willing to license them under GPLv2+ instead of GPLv3+ as indicated in the source code? 4) libosmogsm: the imported milenage code. it is GPLv2 or BSD, so we have to use it under BSD license. This should be indicated somewhere explicitly. > So replacing COPYING with GPLv3 definitely would make sense imho. See above, the devil is in the details, it's not that simple. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Max.Suraev at fairwaves.co Thu Sep 11 08:47:49 2014 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Thu, 11 Sep 2014 12:47:49 +0400 Subject: libosmo{core,vty,codec,ctrl,vty} GPL v2 vs v3 In-Reply-To: <20140911053940.GN20345@nataraja> References: <53330DB4.1070308@fairwaves.co> <533327E6.8090700@steve-m.de> <20140911053940.GN20345@nataraja> Message-ID: <541161B5.7010208@fairwaves.co> 11.09.2014 09:39, Harald Welte ?????: > libosmocore was started as a GPLv2+ project, in order to ensure maximum > compatibility to a variety of applications. Some free software > applications out there are still GPLv2, and we want them to be able to > use libosmocore. > Out of curiosity - could you name those projects? I though all the users of libosmocore are osmocom's own projects which are v2+ at least. -- best regards, Max, http://fairwaves.co From andreas at eversberg.eu Fri Sep 12 03:54:43 2014 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 12 Sep 2014 05:54:43 +0200 Subject: libosmo{core,vty,codec,ctrl,vty} GPL v2 vs v3 In-Reply-To: <20140911053940.GN20345@nataraja> References: <53330DB4.1070308@fairwaves.co> <533327E6.8090700@steve-m.de> <20140911053940.GN20345@nataraja> Message-ID: <54126E83.6070604@eversberg.eu> Harald Welte wrote: > Holger/Andreas: > * Would you agree to license libosmogb under GPLv2+ or GPLv3+? > * Do you have any preference regarding v2+ or v3+? i agree and i have no preference. From dchardware at gmail.com Sun Sep 14 09:12:48 2014 From: dchardware at gmail.com (Sipos Csaba) Date: Sun, 14 Sep 2014 11:12:48 +0200 Subject: What branch to use with B200? In-Reply-To: References: Message-ID: <1786783961.20140914111248@freemail.hu> Dear list, It seems that after the last 2-3 weeks massive committing storm, I lost the ability to compile an interworking version of OpenBSC/Osmo-BTS/Osmo-PCU because the Osmo-PCU and the Osmo-BTS cannot connect anymore. According to the wiki, I need to use "jolly/multi-trx" for Osmo-Abis and "jolly/trx" for Osmo-BTS, and "jolly/testing" with OpenBSC. Previously this setup was working, but now Osmo-BTS tells the PCU socket is not connected, while the PCU is running with the correct config on the same PC. I also wanted to try "201409-trx" branch (moved back to master with osmo-abis and openbsc for this one, otherwise I got errors during the configuration phase), but I got compilation errors with Osmo-BTS at RSL.c If someone can point me in the right direction which branches should I use to get an interworking copy with a B200, that would be awesome. I am also happy to try the new branch "201409-trx" if someone can tell me which branches to use for that too. Thanks! Csaba From snehasish.kar at vehere.com Mon Sep 15 09:19:57 2014 From: snehasish.kar at vehere.com (Snehasish Kar (Vehere)) Date: Mon, 15 Sep 2014 14:49:57 +0530 Subject: RRlp protocol implementation Message-ID: Dear Sir I am trying to use the RRLP protocol implemented in openbsc, till now i am able to send the rrlp request and activate the phone gps(ms-based mode) but i am not getting any reply from the phone's side neither any location error or any location. So please suggest me what to do in this case. Thanks & Regards Snehasish -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Sep 15 12:01:00 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Sep 2014 14:01:00 +0200 Subject: RRlp protocol implementation In-Reply-To: References: Message-ID: <20140915120100.GG21491@xiaoyu.lan> On Mon, Sep 15, 2014 at 02:49:57PM +0530, Snehasish Kar (Vehere) wrote: > Dear Sir Good Morning, > I am trying to use the RRLP protocol implemented in openbsc, till now i am > able to send the rrlp request and activate the phone gps(ms-based mode) but > i am not getting any reply from the phone's side neither any location error > or any location. So please suggest me what to do in this case. folks didn't answer you the first time, they are unlikely to answer you now. Many people (including myself) don't want to support a company like yours. Please do not send any more emails to this list. holger From admin at manateeshome.com Mon Sep 15 16:13:28 2014 From: admin at manateeshome.com (admin at manateeshome.com) Date: Mon, 15 Sep 2014 16:13:28 +0000 Subject: osmo-sgsn crash report Message-ID: <55c0810e16c85e62f8b7fe19e4e337fb@webmail.mananet.net> Hello, I've been working with my nanoBTS units again. But I've noticed some crashes while using GPRS data. I am currently using the newest git repo for everything. And a nanoBTS 1900 and an iPhone. Attached is the log of the crash. Please let me know if you need more information. Regards, Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sgsncrash.txt URL: From holger at freyther.de Mon Sep 15 16:19:44 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Sep 2014 18:19:44 +0200 Subject: osmo-sgsn crash report In-Reply-To: <55c0810e16c85e62f8b7fe19e4e337fb@webmail.mananet.net> References: <55c0810e16c85e62f8b7fe19e4e337fb@webmail.mananet.net> Message-ID: <20140915161944.GD3506@xiaoyu.lan> On Mon, Sep 15, 2014 at 04:13:28PM +0000, admin at manateeshome.com wrote: Hi! > osmo-sgsn: > > <000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52 > <000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52 > <000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 > <000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 > <0010> gprs_ns.c:545 NSEI=101 Tns-alive expired more then 10 times, blocking NS-VC > <000f> sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 > <0010> gprs_ns.c:624 All NS-VCs for NSEI 101 are either dead or blocked! > > Program received signal SIGABRT, Aborted. > 0x00007ffff69b3445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 it is a known crash with a double free in the defragmentation code (not freeing will most likely lead to a leak). Are you willing to sponsor the necessary code-review to make that issue go away? > Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31357:WARN:BH_TRX_ROUTER_TR:rm_s_data_queue_entry.c#195:Pool 2 nearly full > Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31663:WARN:BH_TRX_ROUTER_TR:igki_sig.c#741:Pool 2 nearly full GPRS with the nanoBTS is not very stable. They have known memory leaks in all versions of their firmware. holger From admin at manateeshome.com Mon Sep 15 16:39:25 2014 From: admin at manateeshome.com (admin at manateeshome.com) Date: Mon, 15 Sep 2014 16:39:25 +0000 Subject: osmo-sgsn crash report In-Reply-To: <20140915161944.GD3506@xiaoyu.lan> References: <55c0810e16c85e62f8b7fe19e4e337fb@webmail.mananet.net> <20140915161944.GD3506@xiaoyu.lan> Message-ID: <4badf4b547c9775c469d338b36212d45@webmail.mananet.net> On Tue, Sep 16, 2014 at 01:20 AM, Holger Hans Peter Freyther wrote:On Mon, Sep 15, 2014 at 04:13:28PM +0000, admin at manateeshome.com (mailto:admin at manateeshome.com) wrote: Hi! osmo-sgsn: sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52 sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=52 sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 gprs_ns.c:545 NSEI=101 Tns-alive expired more then 10 times, blocking NS-VC sgsn_libgtp.c:432 GTP DATA IND from GGSN, length=1171 gprs_ns.c:624 All NS-VCs for NSEI 101 are either dead or blocked! Program received signal SIGABRT, Aborted. 0x00007ffff69b3445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 it is a known crash with a double free in the defragmentation code (not freeing will most likely lead to a leak). Are you willing to sponsor the necessary code-review to make that issue go away? I wish I could, but I am not accustomed to debugging code in linux. I looked over the surrounding code for a bit but it was difficult for me to get down to it without knowing how those are supposed to work... Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31357:WARN:BH_TRX_ROUTER_TR:rm_s_data_queue_entry.c#195:Pool 2 nearly full Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=31663:WARN:BH_TRX_ROUTER_TR:igki_sig.c#741:Pool 2 nearly full GPRS with the nanoBTS is not very stable. They have known memory leaks in all versions of their firmware. If thats the case, how are commercial operators coping with those crashes? Worst I've ever seen is the BTS crashing in 10 minutes of operation with a single iPhone connected. I don't think thats even close to production level? Regards, Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at manateeshome.com Mon Sep 15 17:03:00 2014 From: admin at manateeshome.com (admin at manateeshome.com) Date: Mon, 15 Sep 2014 17:03:00 +0000 Subject: TIP: Working with nanoBTS behind NAT Message-ID: I wrote a short post about using nanoBTS behind NAT and getting proper connection. http://manatails.net/blog/2014/09/setting-arbitary-destination-ip-for-rtp-packets/ As OpenBSC does not natively support NAT like Asterisk does, One needs to use a simple hack to manually tell the BSC about the connection information. Regards, Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at mail.bakerhouse01.com Wed Sep 17 22:43:11 2014 From: john at mail.bakerhouse01.com (John Baker) Date: Wed, 17 Sep 2014 18:43:11 -0400 Subject: OpenBSC running on an Odroid-XU Message-ID: <541A0E7F.3060100@mail.bakerhouse01.com> Hi, I have an Odroid-XU I have setup with Debian Wheezy and a USRP B200. After building the UHD drivers from source, I followed the "network from scratch" page. I also configured and built osmo-trx with the --with-neon-vfpv4 option. Things are running OK, a whole lot better than my attempt with OpenBTS actually. I"m able to connect to the network with my Samsung S4 phone, but after an hour or so of the BTS running, I get a UHD recieved time out error (see below). I wonder what could be causing this? I have the B200 plugged into the USB 3.0 port, along with external power. Thanks in advance for any help. root at odroid-wheezy:~# osmo-trx linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.007.002-94-ge56809a0 Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Samples-per-Symbol...... 1 External Reference...... Disabled C0 Filler Table......... Disabled Diversity............... Disabled Tuning offset........... 0 -- Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex... done -- Loading FPGA image: /usr/local/share/uhd/images/usrp_b200_fpga.bin... done -- Operating over USB 3. -- Detecting internal GPSDO.... No GPSDO found -- not found -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32.000000 MHz -- Actually got clock rate 32.000000 MHz -- Performing timer loopback test... pass -- Asking for clock rate 26.000000 MHz -- Actually got clock rate 26.000000 MHz -- Performing timer loopback test... pass -- Setting B200 1 SPS -- Transceiver active with 1 channel(s) ALERT 3030074464 23:06:10.4 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.5 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.6 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.7 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.8 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:10.9 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.0 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.1 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.2 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.3 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.4 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.5 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.6 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.7 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:11.9 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.0 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.1 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.2 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.3 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.4 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.5 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.6 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.7 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.8 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:12.9 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.0 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.1 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.2 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.3 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.4 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.5 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.6 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.7 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.8 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:13.9 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:14.0 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:14.1 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out ALERT 3030074464 23:06:14.2 UHDDevice.cpp:832:check_rx_md_err: UHD: Receive timed out terminate called after throwing an instance of 'uhd::assertion_error' what(): AssertionError: accum_timeout < _timeout in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool) at /root/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:232 From tom at tsou.cc Thu Sep 18 15:23:56 2014 From: tom at tsou.cc (Tom Tsou) Date: Thu, 18 Sep 2014 11:23:56 -0400 Subject: OpenBSC running on an Odroid-XU In-Reply-To: <541A0E7F.3060100@mail.bakerhouse01.com> References: <541A0E7F.3060100@mail.bakerhouse01.com> Message-ID: On Wed, Sep 17, 2014 at 6:43 PM, John Baker wrote: > I have an Odroid-XU I have setup with Debian Wheezy and a USRP B200. After > building the UHD drivers from source, I followed the "network from scratch" > page. I also configured and built osmo-trx with the --with-neon-vfpv4 > option. Things are running OK, a whole lot better than my attempt with > OpenBTS actually. I"m able to connect to the network with my Samsung S4 > phone, but after an hour or so of the BTS running, I get a UHD recieved time > out error (see below). I wonder what could be causing this? I have the B200 > plugged into the USB 3.0 port, along with external power. Is there any any specific activity that occurs at the time? or is the system completely idle during the timeout? -TT From kunal.dawn1991 at gmail.com Mon Sep 22 09:56:31 2014 From: kunal.dawn1991 at gmail.com (Kunal Dawn) Date: Mon, 22 Sep 2014 15:26:31 +0530 Subject: Support for integrating RRLP with openbsc Message-ID: Hello everyone I am new to openbsc, and trying to implement my own mobile network for my masters project. Till now everything has gone well and my network is working gud. But the issue is when I am trying to implement rrlp with openbsc. I have set the rrlp mode to ms-based, but there is no response from the phone on sending the request. I have checked that the request is going to the phone with the help of wireshark. So please anyone help me with this, that should i use E-OTD or ms-assisted method for getting the response from the phone. Thanking you in anticipation Kunal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerlbeck at sysmocom.de Tue Sep 23 11:28:21 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Tue, 23 Sep 2014 13:28:21 +0200 Subject: [PATCH 1/4] gprs: Fix and check BVCI in BSSGP STATUS messages Message-ID: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> Currently the BVCI is not set in all invocations to bssgp_tx_status() when the cause is UNKNOWN_BVCI. This patch adds the argument where it is missing. It also adds a check for compliance (GSM 08.18, 10.4.14.1) to bssgp_tx_status() to emit errors when the following requirement is not fulfilled: The BVCI must be included if (and only if) the cause is either "BVCI blocked" or "BVCI unknown". Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 2 +- src/gb/gprs_bssgp_util.c | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index 5ef1887..b8c6c74 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -998,7 +998,7 @@ int bssgp_rcvmsg(struct msgb *msg) LOGP(DBSSGP, LOGL_NOTICE, "NSEI=%u/BVCI=%u Rejecting PDU " "type %u for unknown BVCI\n", msgb_nsei(msg), ns_bvci, pdu_type); - return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, NULL, msg); + return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, &ns_bvci, msg); } if (bctx) { diff --git a/src/gb/gprs_bssgp_util.c b/src/gb/gprs_bssgp_util.c index ae4647e..261e0b0 100644 --- a/src/gb/gprs_bssgp_util.c +++ b/src/gb/gprs_bssgp_util.c @@ -99,6 +99,20 @@ int bssgp_tx_status(uint8_t cause, uint16_t *bvci, struct msgb *orig_msg) struct bssgp_normal_hdr *bgph = (struct bssgp_normal_hdr *) msgb_put(msg, sizeof(*bgph)); + /* GSM 08.18, 10.4.14.1: The BVCI must be included if (and only if) the + cause is either "BVCI blocked" or "BVCI unknown" */ + if (cause == BSSGP_CAUSE_UNKNOWN_BVCI || cause == BSSGP_CAUSE_BVCI_BLOCKED) { + if (bvci == NULL) + LOGP(DBSSGP, LOGL_ERROR, "BSSGP Tx STATUS, cause=%s: " + "missing conditional BVCI\n", + bssgp_cause_str(cause)); + } else { + if (bvci != NULL) + LOGP(DBSSGP, LOGL_ERROR, "BSSGP Tx STATUS, cause=%s: " + "unexpected conditional BVCI\n", + bssgp_cause_str(cause)); + } + LOGP(DBSSGP, LOGL_NOTICE, "BSSGP BVCI=%u Tx STATUS, cause=%s\n", bvci ? *bvci : 0, bssgp_cause_str(cause)); msgb_nsei(msg) = msgb_nsei(orig_msg); -- 1.9.1 From jerlbeck at sysmocom.de Tue Sep 23 11:28:22 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Tue, 23 Sep 2014 13:28:22 +0200 Subject: [PATCH 2/4] gprs: Fix bssgp_rcvmsg to handle signalling msgs with BVCI IE In-Reply-To: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> References: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> Message-ID: <1411471704-13911-2-git-send-email-jerlbeck@sysmocom.de> Currently BSSGP messages with an NS BVCI of 0 (signalling) are discarded if they aren't RESET messages. Thus valid signalling messages (e.g. BLOCK) are not handled properly, because the BVCI IE is ignored if it present. Instead a STATUS message referring to BVCI 0 (instead of the BVCI used in the BLOCK message) is returned. This patch changes the implementation to use the BVCI contained in the BVCI IE if that is present in a signalling message. It fixes BSSGP BLOCK/UNBLOCK for the osmo-sgsn. Note that signalling messages without an BVCI IE (e.g. SUSPEND/RESUME) are still rejected. Ticket: OW#1205 Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index b8c6c74..0e9fd38 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -976,6 +976,7 @@ int bssgp_rcvmsg(struct msgb *msg) struct bssgp_bvc_ctx *bctx; uint8_t pdu_type = bgph->pdu_type; uint16_t ns_bvci = msgb_bvci(msg); + uint16_t bvci = ns_bvci; int data_len; int rc = 0; @@ -991,14 +992,17 @@ int bssgp_rcvmsg(struct msgb *msg) rc = bssgp_tlv_parse(&tp, budh->data, data_len); } + if (bvci == BVCI_SIGNALLING && TLVP_PRESENT(&tp, BSSGP_IE_BVCI)) + bvci = ntohs(*(uint16_t *)TLVP_VAL(&tp, BSSGP_IE_BVCI)); + /* look-up or create the BTS context for this BVC */ - bctx = btsctx_by_bvci_nsei(ns_bvci, msgb_nsei(msg)); + bctx = btsctx_by_bvci_nsei(bvci, msgb_nsei(msg)); /* Only a RESET PDU can create a new BVC context */ if (!bctx && pdu_type != BSSGP_PDUT_BVC_RESET) { LOGP(DBSSGP, LOGL_NOTICE, "NSEI=%u/BVCI=%u Rejecting PDU " - "type %u for unknown BVCI\n", msgb_nsei(msg), ns_bvci, + "type %u for unknown BVCI\n", msgb_nsei(msg), bvci, pdu_type); - return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, &ns_bvci, msg); + return bssgp_tx_status(BSSGP_CAUSE_UNKNOWN_BVCI, &bvci, msg); } if (bctx) { -- 1.9.1 From holger at freyther.de Tue Sep 23 14:29:26 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 23 Sep 2014 16:29:26 +0200 Subject: [PATCH 2/4] gprs: Fix bssgp_rcvmsg to handle signalling msgs with BVCI IE In-Reply-To: <1411471704-13911-2-git-send-email-jerlbeck@sysmocom.de> References: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> <1411471704-13911-2-git-send-email-jerlbeck@sysmocom.de> Message-ID: <20140923142926.GA4298@xiaoyu.lan> On Tue, Sep 23, 2014 at 01:28:22PM +0200, Jacob Erlbeck wrote: > Currently BSSGP messages with an NS BVCI of 0 (signalling) are > discarded if they aren't RESET messages. Thus valid signalling > messages (e.g. BLOCK) are not handled properly, because the BVCI IE > is ignored if it present. Instead a STATUS message referring to BVCI ^^^^^ "if present"? From jerlbeck at sysmocom.de Tue Sep 23 11:28:23 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Tue, 23 Sep 2014 13:28:23 +0200 Subject: [PATCH 3/4] gprs: Don't discard SUSPEND/RESUME in bssgp_rcvmsg (TODO) In-Reply-To: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> References: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> Message-ID: <1411471704-13911-3-git-send-email-jerlbeck@sysmocom.de> Currently sending SUSPEND/RESUME messages to this function (like it is done in the osmo-sgsn) results in STATUS messages complaining about an unknown BVCI. The reason is, that these messages rely on a TLLI/RAI pair to identify the context and do not contain an explicit BVCI. This patch modifies bssgp_rcvmsg() to only complain about and unknown BVCI if one is given but a matching context is not found (except for RESET messages). The ctx argument is removed from the functions handling SUSPEND and RESUME since it will always be NULL then. TODO: - test cases - end-to-end test Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp.c | 43 +++++++++++++++++++++++++------------------ 1 file changed, 25 insertions(+), 18 deletions(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index 0e9fd38..eee638c 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -398,32 +398,32 @@ static int bssgp_rx_ul_ud(struct msgb *msg, struct tlv_parsed *tp, return bssgp_prim_cb(&gbp.oph, NULL); } -static int bssgp_rx_suspend(struct msgb *msg, struct tlv_parsed *tp, - struct bssgp_bvc_ctx *ctx) +static int bssgp_rx_suspend(struct msgb *msg, struct tlv_parsed *tp) { struct osmo_bssgp_prim gbp; struct gprs_ra_id raid; uint32_t tlli; + uint16_t ns_bvci = msgb_bvci(msg); int rc; if (!TLVP_PRESENT(tp, BSSGP_IE_TLLI) || !TLVP_PRESENT(tp, BSSGP_IE_ROUTEING_AREA)) { LOGP(DBSSGP, LOGL_ERROR, "BSSGP BVCI=%u Rx SUSPEND " - "missing mandatory IE\n", ctx->bvci); + "missing mandatory IE\n", ns_bvci); return bssgp_tx_status(BSSGP_CAUSE_MISSING_MAND_IE, NULL, msg); } tlli = ntohl(*(uint32_t *)TLVP_VAL(tp, BSSGP_IE_TLLI)); DEBUGP(DBSSGP, "BSSGP BVCI=%u TLLI=0x%08x Rx SUSPEND\n", - ctx->bvci, tlli); + ns_bvci, tlli); gsm48_parse_ra(&raid, TLVP_VAL(tp, BSSGP_IE_ROUTEING_AREA)); /* Inform GMM about the SUSPEND request */ memset(&gbp, 0, sizeof(gbp)); gbp.nsei = msgb_nsei(msg); - gbp.bvci = ctx->bvci; + gbp.bvci = ns_bvci; gbp.tlli = tlli; gbp.ra_id = &raid; osmo_prim_init(&gbp.oph, SAP_BSSGP_GMM, PRIM_BSSGP_GMM_SUSPEND, @@ -438,34 +438,34 @@ static int bssgp_rx_suspend(struct msgb *msg, struct tlv_parsed *tp, return 0; } -static int bssgp_rx_resume(struct msgb *msg, struct tlv_parsed *tp, - struct bssgp_bvc_ctx *ctx) +static int bssgp_rx_resume(struct msgb *msg, struct tlv_parsed *tp) { struct osmo_bssgp_prim gbp; struct gprs_ra_id raid; uint32_t tlli; uint8_t suspend_ref; + uint16_t ns_bvci = msgb_bvci(msg); int rc; if (!TLVP_PRESENT(tp, BSSGP_IE_TLLI) || !TLVP_PRESENT(tp, BSSGP_IE_ROUTEING_AREA) || !TLVP_PRESENT(tp, BSSGP_IE_SUSPEND_REF_NR)) { LOGP(DBSSGP, LOGL_ERROR, "BSSGP BVCI=%u Rx RESUME " - "missing mandatory IE\n", ctx->bvci); + "missing mandatory IE\n", ns_bvci); return bssgp_tx_status(BSSGP_CAUSE_MISSING_MAND_IE, NULL, msg); } tlli = ntohl(*(uint32_t *)TLVP_VAL(tp, BSSGP_IE_TLLI)); suspend_ref = *TLVP_VAL(tp, BSSGP_IE_SUSPEND_REF_NR); - DEBUGP(DBSSGP, "BSSGP BVCI=%u TLLI=0x%08x Rx RESUME\n", ctx->bvci, tlli); + DEBUGP(DBSSGP, "BSSGP BVCI=%u TLLI=0x%08x Rx RESUME\n", ns_bvci, tlli); gsm48_parse_ra(&raid, TLVP_VAL(tp, BSSGP_IE_ROUTEING_AREA)); /* Inform GMM about the RESUME request */ memset(&gbp, 0, sizeof(gbp)); gbp.nsei = msgb_nsei(msg); - gbp.bvci = ctx->bvci; + gbp.bvci = ns_bvci; gbp.tlli = tlli; gbp.ra_id = &raid; gbp.u.resume.suspend_ref = suspend_ref; @@ -885,23 +885,26 @@ static int bssgp_rx_sign(struct msgb *msg, struct tlv_parsed *tp, uint8_t pdu_type = bgph->pdu_type; int rc = 0; uint16_t ns_bvci = msgb_bvci(msg); + uint16_t bvci = bctx ? bctx->bvci : ns_bvci; switch (bgph->pdu_type) { case BSSGP_PDUT_SUSPEND: /* MS wants to suspend */ - rc = bssgp_rx_suspend(msg, tp, bctx); + rc = bssgp_rx_suspend(msg, tp); break; case BSSGP_PDUT_RESUME: /* MS wants to resume */ - rc = bssgp_rx_resume(msg, tp, bctx); + rc = bssgp_rx_resume(msg, tp); break; case BSSGP_PDUT_FLUSH_LL_ACK: /* BSS informs us it has performed LL FLUSH */ - DEBUGP(DBSSGP, "BSSGP Rx BVCI=%u FLUSH LL ACK\n", bctx->bvci); + DEBUGP(DBSSGP, "BSSGP Rx BVCI=%u FLUSH LL ACK\n", bvci); /* FIXME: send NM_FLUSH_LL.res to NM */ break; case BSSGP_PDUT_LLC_DISCARD: /* BSS informs that some LLC PDU's have been discarded */ + if (!bctx) + goto err_no_bvci; rc = bssgp_rx_llc_disc(msg, tp, bctx); break; case BSSGP_PDUT_BVC_BLOCK: @@ -935,7 +938,7 @@ static int bssgp_rx_sign(struct msgb *msg, struct tlv_parsed *tp, break; case BSSGP_PDUT_STATUS: /* Some exception has occurred */ - DEBUGP(DBSSGP, "BSSGP BVCI=%u Rx BVC STATUS\n", bctx->bvci); + DEBUGP(DBSSGP, "BSSGP BVCI=%u Rx BVC STATUS\n", bvci); /* FIXME: send NM_STATUS.ind to NM */ break; /* those only exist in the SGSN -> BSS direction */ @@ -950,18 +953,20 @@ static int bssgp_rx_sign(struct msgb *msg, struct tlv_parsed *tp, case BSSGP_PDUT_BVC_UNBLOCK_ACK: case BSSGP_PDUT_SGSN_INVOKE_TRACE: DEBUGP(DBSSGP, "BSSGP BVCI=%u Rx PDU type 0x%02x only exists " - "in DL\n", bctx->bvci, pdu_type); + "in DL\n", bvci, pdu_type); bssgp_tx_status(BSSGP_CAUSE_PROTO_ERR_UNSPEC, NULL, msg); rc = -EINVAL; break; default: DEBUGP(DBSSGP, "BSSGP BVCI=%u Rx PDU type 0x%02x unknown\n", - bctx->bvci, pdu_type); + bvci, pdu_type); rc = bssgp_tx_status(BSSGP_CAUSE_PROTO_ERR_UNSPEC, NULL, msg); break; } return rc; +err_no_bvci: + LOGP(DBSSGP, LOGL_ERROR, "BSSGP missing mandatory BVCI\n"); err_mand_ie: return bssgp_tx_status(BSSGP_CAUSE_MISSING_MAND_IE, NULL, msg); } @@ -997,8 +1002,10 @@ int bssgp_rcvmsg(struct msgb *msg) /* look-up or create the BTS context for this BVC */ bctx = btsctx_by_bvci_nsei(bvci, msgb_nsei(msg)); - /* Only a RESET PDU can create a new BVC context */ - if (!bctx && pdu_type != BSSGP_PDUT_BVC_RESET) { + /* Only a RESET PDU can create a new BVC context, + * otherwise it must be registered if a BVCI is given */ + if (!bctx && bvci != BVCI_SIGNALLING && + pdu_type != BSSGP_PDUT_BVC_RESET) { LOGP(DBSSGP, LOGL_NOTICE, "NSEI=%u/BVCI=%u Rejecting PDU " "type %u for unknown BVCI\n", msgb_nsei(msg), bvci, pdu_type); -- 1.9.1 From jerlbeck at sysmocom.de Tue Sep 23 11:45:43 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Tue, 23 Sep 2014 13:45:43 +0200 Subject: [PATCH 3/4] gprs: Don't discard SUSPEND/RESUME in bssgp_rcvmsg (TODO) In-Reply-To: <1411471704-13911-3-git-send-email-jerlbeck@sysmocom.de> References: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> <1411471704-13911-3-git-send-email-jerlbeck@sysmocom.de> Message-ID: <54215D67.3090607@sysmocom.de> Oops, I didn't intend to send this one, but comments are welcome anyway. Jacob On 23.09.2014 13:28, Jacob Erlbeck wrote: > Currently sending SUSPEND/RESUME messages to this function (like it > is done in the osmo-sgsn) results in STATUS messages complaining > about an unknown BVCI. The reason is, that these messages rely on a > TLLI/RAI pair to identify the context and do not contain an explicit > BVCI. > > This patch modifies bssgp_rcvmsg() to only complain about and unknown > BVCI if one is given but a matching context is not found (except for > RESET messages). The ctx argument is removed from the functions > handling SUSPEND and RESUME since it will always be NULL then. > > TODO: > - test cases > - end-to-end test > > Sponsored-by: On-Waves ehf -- - Jacob Erlbeck http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From jerlbeck at sysmocom.de Tue Sep 23 11:28:24 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Tue, 23 Sep 2014 13:28:24 +0200 Subject: [PATCH 4/4] gprs: Set bssgph field in bssgp_msgb_alloc() In-Reply-To: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> References: <1411471704-13911-1-git-send-email-jerlbeck@sysmocom.de> Message-ID: <1411471704-13911-4-git-send-email-jerlbeck@sysmocom.de> Currently the bssgph field is not set when using the bssgp_tx_* functions. This hinders unit testing of generated messages. This patch initializes the bssgph field directly after allocation a new bssgp msgb in bssgp_msgb_alloc() so that it is set by default. Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp_util.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/gb/gprs_bssgp_util.c b/src/gb/gprs_bssgp_util.c index 261e0b0..604764c 100644 --- a/src/gb/gprs_bssgp_util.c +++ b/src/gb/gprs_bssgp_util.c @@ -70,7 +70,9 @@ const char *bssgp_cause_str(enum gprs_bssgp_cause cause) struct msgb *bssgp_msgb_alloc(void) { - return msgb_alloc_headroom(4096, 128, "BSSGP"); + struct msgb *msg = msgb_alloc_headroom(4096, 128, "BSSGP"); + msgb_bssgph(msg) = msg->data; + return msg; } /* Transmit a simple response such as BLOCK/UNBLOCK/RESET ACK/NACK */ -- 1.9.1