From holger at freyther.de Sun Mar 10 17:05:05 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 10 Mar 2013 18:05:05 +0100 Subject: neighbour cells In-Reply-To: <4F4DE00E.3010509@eversberg.eu> References: <4F4DE00E.3010509@eversberg.eu> Message-ID: <20130310170505.GH18290@xiaoyu.lan> On Wed, Feb 29, 2012 at 09:21:34AM +0100, jolly wrote: > hi, Hi jolly, > i have tested it with several configurations. i would like to commit it > to master. any suggestions? Do you remember your test setup and the results of it? There appears to be an issue with iPhone4s and iPhone5 phones (and PCS). It appears to me that there are at least three issues with the generation: * The SI1 rest_octets indicated DCS while PCS was used (this is fixed) * The Ext-Ind claims that SI2 carries the complete BA even if SI2ter/2bis are scheduled. * The BA-Ind is the same for SDCCH/BCCH. We should use 0/1. Could you have a look at it? thanks holger From andreas at eversberg.eu Mon Mar 11 06:50:43 2013 From: andreas at eversberg.eu (jolly) Date: Mon, 11 Mar 2013 07:50:43 +0100 Subject: neighbour cells In-Reply-To: <20130310170505.GH18290@xiaoyu.lan> References: <4F4DE00E.3010509@eversberg.eu> <20130310170505.GH18290@xiaoyu.lan> Message-ID: <513D7EC3.9030304@eversberg.eu> Holger Hans Peter Freyther wrote: > * The SI1 rest_octets indicated DCS while PCS was used (this is fixed) > yes, i missed that. but IIRC, it must be set on non-PCS cells (i.a. 850 or 900) to indicate whether neighbor ARFCN of 512... refer to PCS. on a PCS BTS it should be ignored by MS. you should check if there the network that has all PCS or all DCS BTS and then set this bit or not. even on GSM 900 cells this bit must be set, if there is/are all PCS BTS. if there are both PCS and DCS BTS, there should be a warning, because this is not allowed. > * The Ext-Ind claims that SI2 carries the complete BA even if SI2ter/2bis > are scheduled. > look at generate_si2bis: (si5bis respectively) if (n) ... si2->bcch_frequency_list[0] |= 0x20; si2b->bcch_frequency_list[0] |= 0x20; if there are frequencies defined in si2bis, the EXT-IND is set on both (si2 and si2bis) lists. if not, the si2bis is removed and not transmitted. > * The BA-Ind is the same for SDCCH/BCCH. We should use 0/1. > if both lists differ, it makes sense to have different BA-IND. currently there is no difference, but it is not wrong to set BA-IND on SI5*. From holger at freyther.de Mon Mar 11 13:56:22 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 11 Mar 2013 14:56:22 +0100 Subject: neighbour cells In-Reply-To: <513D7EC3.9030304@eversberg.eu> References: <4F4DE00E.3010509@eversberg.eu> <20130310170505.GH18290@xiaoyu.lan> <513D7EC3.9030304@eversberg.eu> Message-ID: <20130311135622.GP18290@xiaoyu.lan> On Mon, Mar 11, 2013 at 07:50:43AM +0100, jolly wrote: > yes, i missed that. but IIRC, it must be set on non-PCS cells (i.a. 850 > or 900) to indicate whether neighbor ARFCN of 512... refer to PCS. on a > PCS BTS it should be ignored by MS. right, as PCS/DCS is not allowed I take a look during the SI generation and check if that bts is a DCS/PCS unit and set the indicator. In terms of VTY we need to add consistency checks at the time of a 'write' call and after loading. But this is not limited to the DCS/PCS code. > if (n) > ... > si2->bcch_frequency_list[0] |= 0x20; > si2b->bcch_frequency_list[0] |= 0x20; > > if there are frequencies defined in si2bis, the EXT-IND is set on both > (si2 and si2bis) lists. if not, the si2bis is removed and not transmitted. true. I was confused and thought EXT-IND is set for SI2ter as well. But this is signalled in the SI3 rest octets. SI5ter doesn't appear to be signalled at all. greetings from Iceland holger From zero-kelvin at gmx.de Tue Mar 5 22:48:42 2013 From: zero-kelvin at gmx.de (dexter) Date: Tue, 05 Mar 2013 23:48:42 +0100 Subject: Osmocom Berlin User Group meeting In-Reply-To: <20120818115942.GV29525@prithivi.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> Message-ID: <5136764A.5040903@gmx.de> Hi folks. This is the announcement for the next Osmocom Berlin meeting. Mar 6, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Regards, Philipp Maier From zero-kelvin at gmx.de Tue Mar 19 22:47:33 2013 From: zero-kelvin at gmx.de (dexter) Date: Tue, 19 Mar 2013 23:47:33 +0100 Subject: Osmocom Berlin User Group meeting In-Reply-To: <20120818115942.GV29525@prithivi.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> Message-ID: <5148EB05.2080000@gmx.de> Hi folks. This is the announcement for the next Osmocom Berlin meeting. Mar 20, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Regards, Philipp Maier From peter at stuge.se Tue Mar 19 23:51:52 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 20 Mar 2013 00:51:52 +0100 Subject: Osmocom Berlin User Group meeting In-Reply-To: <5148EB05.2080000@gmx.de> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <5148EB05.2080000@gmx.de> Message-ID: <20130319235152.20844.qmail@stuge.se> dexter wrote: > This is the announcement for the next Osmocom Berlin meeting. > > Mar 20, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin > > There is no formal presentation scheduled for this meeting. There might be talk about the EasterHegg test network and I'll report on my visit to the OHM2013 terrain. //Peter From alexander.chemeris at gmail.com Wed Mar 20 05:26:27 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 20 Mar 2013 09:26:27 +0400 Subject: Osmocom Berlin User Group meeting In-Reply-To: <20130319235152.20844.qmail@stuge.se> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <5148EB05.2080000@gmx.de> <20130319235152.20844.qmail@stuge.se> Message-ID: On Wed, Mar 20, 2013 at 3:51 AM, Peter Stuge wrote: > dexter wrote: >> This is the announcement for the next Osmocom Berlin meeting. >> >> Mar 20, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin >> >> There is no formal presentation scheduled for this meeting. > > There might be talk about the EasterHegg test network > and I'll report on my visit to the OHM2013 terrain. Please share this information with non-Berliners too! -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From zero-kelvin at gmx.de Sat Mar 30 20:54:05 2013 From: zero-kelvin at gmx.de (dexter) Date: Sat, 30 Mar 2013 21:54:05 +0100 Subject: Osmocom Berlin User Group meeting In-Reply-To: <20120818115942.GV29525@prithivi.gnumonks.org> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> Message-ID: <515750ED.4020007@gmx.de> Hi folks. This is the announcement for the next Osmocom Berlin meeting. Apr 03, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Regards, Philipp Maier From alberto at computer.org Sat Mar 30 21:50:23 2013 From: alberto at computer.org (Alberto Fabiano) Date: Sat, 30 Mar 2013 18:50:23 -0300 Subject: Osmocom Berlin User Group meeting In-Reply-To: <515750ED.4020007@gmx.de> References: <502d01a9.mirider@mirider.augusta.de> <20120818115942.GV29525@prithivi.gnumonks.org> <515750ED.4020007@gmx.de> Message-ID: Hi Folks, [2] Please share this information with non-Berliners too! If possible, or course... [ ]s -- Alberto Fabiano ||| alberto at computer.org -.. .- -. -.- .- -.--.. .. -.-. --. .. ... - ?Security is an illusion. Paranoia is our profession."-- Strategic Air command. -. .. ... - -- .. -. ...- . -. - .. - .- "The best way to predict the future is to invent it." --Alan Kay On Sat, Mar 30, 2013 at 5:54 PM, dexter wrote: > Hi folks. > > > This is the announcement for the next Osmocom Berlin meeting. > > Apr 03, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin > > > There is no formal presentation scheduled for this meeting. > > If you are interested to show up, feel free to do so. There is no > registration required. The meeting is free as in "free beer", despite > no actual free beer being around. > > Regards, > Philipp Maier > > > From kat.obsc at gmail.com Fri Mar 1 18:43:33 2013 From: kat.obsc at gmail.com (Katerina Barone-Adesi) Date: Fri, 1 Mar 2013 18:43:33 +0000 Subject: [PATCH] Changed assert to ASSERT In-Reply-To: <20130227142138.GC11463@xiaoyu.lan> References: <20130227142138.GC11463@xiaoyu.lan> Message-ID: <1362163413-9435-1-git-send-email-kat.obsc@gmail.com> Rationale: zecke pointed out that the tests should unconditionally assert, regardless of debug settings. --- include/osmocom/core/utils.h | 7 +++ tests/lapd/lapd_test.c | 8 +-- tests/loggingrb/loggingrb_test.c | 3 +- tests/strrb/strrb_test.c | 126 +++++++++++++++++++-------------------- 4 files changed, 72 insertions(+), 72 deletions(-) diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..4790386 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -51,6 +51,13 @@ do { \ rem -= ret; \ } while (0) +#define ASSERT(exp) \ + if (!(exp)) { \ + printf("Assert failed %s %s:%d\n", #exp, __FILE__, __LINE__); \ + abort(); \ + } + + /*! @} */ #endif diff --git a/tests/lapd/lapd_test.c b/tests/lapd/lapd_test.c index acd3cad..65206ed 100644 --- a/tests/lapd/lapd_test.c +++ b/tests/lapd/lapd_test.c @@ -21,6 +21,7 @@ #include #include +#include #include #include @@ -34,13 +35,6 @@ abort(); \ } -#define ASSERT(exp) \ - if (!(exp)) { \ - printf("Assert failed %s %s:%d\n", #exp, __FILE__, __LINE__); \ - abort(); \ - } - - static struct log_info info = {}; struct lapdm_polling_state { diff --git a/tests/loggingrb/loggingrb_test.c b/tests/loggingrb/loggingrb_test.c index 1ab5212..7c08a7f 100644 --- a/tests/loggingrb/loggingrb_test.c +++ b/tests/loggingrb/loggingrb_test.c @@ -18,7 +18,6 @@ * along with this program. If not, see . * */ -#include #include #include @@ -77,7 +76,7 @@ int main(int argc, char **argv) DEBUGP(DMM, "You should not see this\n"); fprintf(stderr, ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 0)); fprintf(stderr, ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 1)); - assert(!ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 2)); + ASSERT(!ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 2)); return 0; } diff --git a/tests/strrb/strrb_test.c b/tests/strrb/strrb_test.c index abe649f..6dcf8e0 100644 --- a/tests/strrb/strrb_test.c +++ b/tests/strrb/strrb_test.c @@ -18,12 +18,12 @@ */ #include -#include #include #include #include #include +#include struct osmo_strrb *rb0, *rb1, *rb2, *rb3, *rb4, *rb5; @@ -77,98 +77,98 @@ void free_rbs(void) void test_offset_valid(void) { - assert(_osmo_strrb_is_bufindex_valid(rb1, 0)); - assert(!_osmo_strrb_is_bufindex_valid(rb1, 1)); - assert(!_osmo_strrb_is_bufindex_valid(rb1, 2)); + ASSERT(_osmo_strrb_is_bufindex_valid(rb1, 0)); + ASSERT(!_osmo_strrb_is_bufindex_valid(rb1, 1)); + ASSERT(!_osmo_strrb_is_bufindex_valid(rb1, 2)); - assert(!_osmo_strrb_is_bufindex_valid(rb3, 0)); - assert(_osmo_strrb_is_bufindex_valid(rb3, 1)); - assert(_osmo_strrb_is_bufindex_valid(rb3, 2)); + ASSERT(!_osmo_strrb_is_bufindex_valid(rb3, 0)); + ASSERT(_osmo_strrb_is_bufindex_valid(rb3, 1)); + ASSERT(_osmo_strrb_is_bufindex_valid(rb3, 2)); - assert(_osmo_strrb_is_bufindex_valid(rb4, 0)); - assert(!_osmo_strrb_is_bufindex_valid(rb4, 1)); - assert(_osmo_strrb_is_bufindex_valid(rb4, 2)); + ASSERT(_osmo_strrb_is_bufindex_valid(rb4, 0)); + ASSERT(!_osmo_strrb_is_bufindex_valid(rb4, 1)); + ASSERT(_osmo_strrb_is_bufindex_valid(rb4, 2)); - assert(_osmo_strrb_is_bufindex_valid(rb5, 0)); - assert(_osmo_strrb_is_bufindex_valid(rb5, 1)); - assert(!_osmo_strrb_is_bufindex_valid(rb5, 2)); + ASSERT(_osmo_strrb_is_bufindex_valid(rb5, 0)); + ASSERT(_osmo_strrb_is_bufindex_valid(rb5, 1)); + ASSERT(!_osmo_strrb_is_bufindex_valid(rb5, 2)); } void test_elems(void) { - assert(osmo_strrb_elements(rb0) == 0); - assert(osmo_strrb_elements(rb1) == 1); - assert(osmo_strrb_elements(rb2) == 2); - assert(osmo_strrb_elements(rb3) == 2); + ASSERT(osmo_strrb_elements(rb0) == 0); + ASSERT(osmo_strrb_elements(rb1) == 1); + ASSERT(osmo_strrb_elements(rb2) == 2); + ASSERT(osmo_strrb_elements(rb3) == 2); } void test_getn(void) { - assert(!osmo_strrb_get_nth(rb0, 0)); - assert(!strcmp(STR0, osmo_strrb_get_nth(rb2, 0))); - assert(!strcmp(STR1, osmo_strrb_get_nth(rb2, 1))); - assert(!strcmp(STR1, osmo_strrb_get_nth(rb3, 0))); - assert(!strcmp(STR2, osmo_strrb_get_nth(rb3, 1))); - assert(!osmo_strrb_get_nth(rb3, 2)); + ASSERT(!osmo_strrb_get_nth(rb0, 0)); + ASSERT(!strcmp(STR0, osmo_strrb_get_nth(rb2, 0))); + ASSERT(!strcmp(STR1, osmo_strrb_get_nth(rb2, 1))); + ASSERT(!strcmp(STR1, osmo_strrb_get_nth(rb3, 0))); + ASSERT(!strcmp(STR2, osmo_strrb_get_nth(rb3, 1))); + ASSERT(!osmo_strrb_get_nth(rb3, 2)); } void test_getn_wrap(void) { - assert(!strcmp(STR2, osmo_strrb_get_nth(rb4, 0))); - assert(!strcmp(STR3, osmo_strrb_get_nth(rb4, 1))); + ASSERT(!strcmp(STR2, osmo_strrb_get_nth(rb4, 0))); + ASSERT(!strcmp(STR3, osmo_strrb_get_nth(rb4, 1))); - assert(!strcmp(STR3, osmo_strrb_get_nth(rb5, 0))); - assert(!strcmp(STR4, osmo_strrb_get_nth(rb5, 1))); + ASSERT(!strcmp(STR3, osmo_strrb_get_nth(rb5, 0))); + ASSERT(!strcmp(STR4, osmo_strrb_get_nth(rb5, 1))); } void test_add(void) { struct osmo_strrb *rb = osmo_strrb_create(NULL, 4); - assert(rb->start == 0); - assert(rb->end == 0); + ASSERT(rb->start == 0); + ASSERT(rb->end == 0); osmo_strrb_add(rb, "a"); osmo_strrb_add(rb, "b"); osmo_strrb_add(rb, "c"); - assert(rb->start == 0); - assert(rb->end == 3); - assert(osmo_strrb_elements(rb) == 3); + ASSERT(rb->start == 0); + ASSERT(rb->end == 3); + ASSERT(osmo_strrb_elements(rb) == 3); osmo_strrb_add(rb, "d"); - assert(rb->start == 1); - assert(rb->end == 0); - assert(osmo_strrb_elements(rb) == 3); - assert(!strcmp("b", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("c", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 2))); + ASSERT(rb->start == 1); + ASSERT(rb->end == 0); + ASSERT(osmo_strrb_elements(rb) == 3); + ASSERT(!strcmp("b", osmo_strrb_get_nth(rb, 0))); + ASSERT(!strcmp("c", osmo_strrb_get_nth(rb, 1))); + ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "e"); - assert(rb->start == 2); - assert(rb->end == 1); - assert(!strcmp("c", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 2))); + ASSERT(rb->start == 2); + ASSERT(rb->end == 1); + ASSERT(!strcmp("c", osmo_strrb_get_nth(rb, 0))); + ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 1))); + ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "f"); - assert(rb->start == 3); - assert(rb->end == 2); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 2))); + ASSERT(rb->start == 3); + ASSERT(rb->end == 2); + ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 0))); + ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 1))); + ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "g"); - assert(rb->start == 0); - assert(rb->end == 3); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("g", osmo_strrb_get_nth(rb, 2))); + ASSERT(rb->start == 0); + ASSERT(rb->end == 3); + ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 0))); + ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 1))); + ASSERT(!strcmp("g", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "h"); - assert(rb->start == 1); - assert(rb->end == 0); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("g", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("h", osmo_strrb_get_nth(rb, 2))); + ASSERT(rb->start == 1); + ASSERT(rb->end == 0); + ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 0))); + ASSERT(!strcmp("g", osmo_strrb_get_nth(rb, 1))); + ASSERT(!strcmp("h", osmo_strrb_get_nth(rb, 2))); talloc_free(rb); } @@ -184,8 +184,8 @@ void test_long_msg(void) tests1 = malloc(test_size); tests2 = malloc(test_size); /* Be certain allocating memory worked before continuing */ - assert(tests1); - assert(tests2); + ASSERT(tests1); + ASSERT(tests2); for (i = 0; i < RB_MAX_MESSAGE_SIZE; i += 2) { tests1[i] = 'a'; @@ -201,9 +201,9 @@ void test_long_msg(void) free(tests1); rb_content = osmo_strrb_get_nth(rb, 0); - assert(!strncmp(tests2, rb_content, RB_MAX_MESSAGE_SIZE - 1)); - assert(!rb_content[RB_MAX_MESSAGE_SIZE - 1]); - assert(strlen(rb_content) == RB_MAX_MESSAGE_SIZE - 1); + ASSERT(!strncmp(tests2, rb_content, RB_MAX_MESSAGE_SIZE - 1)); + ASSERT(!rb_content[RB_MAX_MESSAGE_SIZE - 1]); + ASSERT(strlen(rb_content) == RB_MAX_MESSAGE_SIZE - 1); free(tests2); talloc_free(rb); -- 1.8.1.2 From holger at freyther.de Sat Mar 2 21:16:18 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 2 Mar 2013 22:16:18 +0100 Subject: [PATCH] Changed assert to ASSERT In-Reply-To: <1362163413-9435-1-git-send-email-kat.obsc@gmail.com> References: <20130227142138.GC11463@xiaoyu.lan> <1362163413-9435-1-git-send-email-kat.obsc@gmail.com> Message-ID: <20130302211618.GB14045@xiaoyu.lan> On Fri, Mar 01, 2013 at 06:43:33PM +0000, Katerina Barone-Adesi wrote: Dear Katerina, > Rationale: zecke pointed out that the tests should unconditionally > assert, regardless of debug settings. > --- a/include/osmocom/core/utils.h > +++ b/include/osmocom/core/utils.h > +#define ASSERT(exp) \ it is good thinking to share the code between multiple users (e.g. in OpenBSC I have a bit of copy and paste for the assertion/testing macros) that we could clean up. One thing we have to be careful with is to not pollute the global namespace, e.g. with something as generic as 'ASSERT' we either need to find another name or prefix it with OSMO_. kind regards holger From kat.obsc at gmail.com Sun Mar 3 10:36:52 2013 From: kat.obsc at gmail.com (Katerina Barone-Adesi) Date: Sun, 3 Mar 2013 10:36:52 +0000 Subject: [PATCH] Changed assert to OSMO_ASSERT In-Reply-To: <20130302211618.GB14045@xiaoyu.lan> References: <20130302211618.GB14045@xiaoyu.lan> Message-ID: <1362307012-2277-1-git-send-email-kat.obsc@gmail.com> Rationale: zecke pointed out that the tests should unconditionally assert, regardless of debug settings. This uses the OSMO_ prefix as it's in the global namespace. --- include/osmocom/core/utils.h | 7 +++ tests/lapd/lapd_test.c | 62 +++++++++---------- tests/loggingrb/loggingrb_test.c | 3 +- tests/strrb/strrb_test.c | 126 +++++++++++++++++++-------------------- 4 files changed, 100 insertions(+), 98 deletions(-) diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..8f7bee3 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -51,6 +51,13 @@ do { \ rem -= ret; \ } while (0) +#define OSMO_ASSERT(exp) \ + if (!(exp)) { \ + printf("Assert failed %s %s:%d\n", #exp, __FILE__, __LINE__); \ + abort(); \ + } + + /*! @} */ #endif diff --git a/tests/lapd/lapd_test.c b/tests/lapd/lapd_test.c index acd3cad..a60c45d 100644 --- a/tests/lapd/lapd_test.c +++ b/tests/lapd/lapd_test.c @@ -21,6 +21,7 @@ #include #include +#include #include #include @@ -34,13 +35,6 @@ abort(); \ } -#define ASSERT(exp) \ - if (!(exp)) { \ - printf("Assert failed %s %s:%d\n", #exp, __FILE__, __LINE__); \ - abort(); \ - } - - static struct log_info info = {}; struct lapdm_polling_state { @@ -101,9 +95,9 @@ static struct msgb *create_mm_id_req(void) msg = msgb_from_array(mm, sizeof(mm)); msg->l2h = msg->data + 3; - ASSERT(msgb_l2len(msg) == 12); + OSMO_ASSERT(msgb_l2len(msg) == 12); msg->l3h = msg->l2h + 6; - ASSERT(msgb_l3len(msg) == 6); + OSMO_ASSERT(msgb_l3len(msg) == 6); return msg; } @@ -113,7 +107,7 @@ static struct msgb *create_empty_msg(void) struct msgb *msg; msg = msgb_from_array(NULL, 0); - ASSERT(msgb_l3len(msg) == 0); + OSMO_ASSERT(msgb_l3len(msg) == 0); rsl_rll_push_l3(msg, RSL_MT_DATA_REQ, 0, 0, 1); return msg; } @@ -155,7 +149,7 @@ static int send(struct msgb *in_msg, struct lapdm_channel *chan) pp.u.data.link_id = 0; /* feed into the LAPDm code of libosmogsm */ rc = lapdm_phsap_up(&pp.oph, &chan->lapdm_dcch); - ASSERT(rc == 0 || rc == -EBUSY); + OSMO_ASSERT(rc == 0 || rc == -EBUSY); return 0; } @@ -172,12 +166,14 @@ static int bts_to_ms_tx_cb(struct msgb *in_msg, struct lapdm_entity *le, void *_ if (state->bts_read == 0) { printf("BTS: Verifying CM request.\n"); - ASSERT(msgb_l3len(in_msg) == ARRAY_SIZE(cm_padded)); - ASSERT(memcmp(in_msg->l3h, cm_padded, ARRAY_SIZE(cm_padded)) == 0); + OSMO_ASSERT(msgb_l3len(in_msg) == ARRAY_SIZE(cm_padded)); + OSMO_ASSERT(memcmp(in_msg->l3h, cm_padded, + ARRAY_SIZE(cm_padded)) == 0); } else if (state->bts_read == 1) { printf("BTS: Verifying dummy message.\n"); - ASSERT(msgb_l3len(in_msg) == ARRAY_SIZE(dummy1)); - ASSERT(memcmp(in_msg->l3h, dummy1, ARRAY_SIZE(dummy1)) == 0); + OSMO_ASSERT(msgb_l3len(in_msg) == ARRAY_SIZE(dummy1)); + OSMO_ASSERT(memcmp(in_msg->l3h, dummy1, + ARRAY_SIZE(dummy1)) == 0); } else { printf("BTS: Do not know to verify: %d\n", state->bts_read); } @@ -210,23 +206,23 @@ static int ms_to_bts_tx_cb(struct msgb *msg, struct lapdm_entity *le, void *_ctx struct abis_rsl_rll_hdr hdr; printf("MS: Verifying incoming primitive.\n"); - ASSERT(msg->len == sizeof(struct abis_rsl_rll_hdr) + 3); + OSMO_ASSERT(msg->len == sizeof(struct abis_rsl_rll_hdr) + 3); /* verify the header */ memset(&hdr, 0, sizeof(hdr)); rsl_init_rll_hdr(&hdr, RSL_MT_EST_CONF); hdr.c.msg_discr |= ABIS_RSL_MDISC_TRANSP; - ASSERT(memcmp(msg->data, &hdr, sizeof(hdr)) == 0); + OSMO_ASSERT(memcmp(msg->data, &hdr, sizeof(hdr)) == 0); /* Verify the added RSL_IE_L3_INFO but we have a bug here */ - ASSERT(msg->data[6] == RSL_IE_L3_INFO); + OSMO_ASSERT(msg->data[6] == RSL_IE_L3_INFO); #warning "RSL_IE_L3_INFO 16 bit length is wrong" /* ASSERT(msg->data[7] == 0x0 && msg->data[8] == 0x9c); */ /* this should be 0x0 and 0x0... but we have a bug */ } else if (state->ms_read == 1) { printf("MS: Verifying incoming MM message: %d\n", msgb_l3len(msg)); - ASSERT(msgb_l3len(msg) == 3); - ASSERT(memcmp(msg->l3h, &mm[12], msgb_l3len(msg)) == 0); + OSMO_ASSERT(msgb_l3len(msg) == 3); + OSMO_ASSERT(memcmp(msg->l3h, &mm[12], msgb_l3len(msg)) == 0); } else { printf("MS: Do not know to verify: %d\n", state->ms_read); } @@ -274,13 +270,13 @@ static void test_lapdm_polling() /* 2. Poll on the BTS for sending out a confirmation */ printf("\nConfirming\n"); - ASSERT(test_state.bts_read == 1) + OSMO_ASSERT(test_state.bts_read == 1); rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); CHECK_RC(rc); - ASSERT(pp.oph.msg->data == pp.oph.msg->l2h); + OSMO_ASSERT(pp.oph.msg->data == pp.oph.msg->l2h); send(pp.oph.msg, &ms_to_bts_channel); msgb_free(pp.oph.msg); - ASSERT(test_state.ms_read == 1); + OSMO_ASSERT(test_state.ms_read == 1); /* 3. Send some data to the MS */ printf("\nSending back to MS\n"); @@ -289,35 +285,35 @@ static void test_lapdm_polling() CHECK_RC(rc); send(pp.oph.msg, &ms_to_bts_channel); msgb_free(pp.oph.msg); - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(test_state.ms_read == 2); /* verify that there is nothing more to poll */ rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); - ASSERT(rc < 0); + OSMO_ASSERT(rc < 0); /* 3. And back to the BTS */ printf("\nSending back to BTS\n"); - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(test_state.ms_read == 2); lapdm_rslms_recvmsg(create_dummy_data_req(), &ms_to_bts_channel); /* 4. And back to the MS, but let's move data/l2h apart */ - ASSERT(test_state.bts_read == 2) - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(test_state.bts_read == 2); + OSMO_ASSERT(test_state.ms_read == 2); rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); CHECK_RC(rc); send(pp.oph.msg, &ms_to_bts_channel); - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(test_state.ms_read == 2); msgb_free(pp.oph.msg); /* verify that there is nothing more to poll */ rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); - ASSERT(rc < 0); + OSMO_ASSERT(rc < 0); /* check sending an empty L3 message fails */ rc = lapdm_rslms_recvmsg(create_empty_msg(), &bts_to_ms_channel); - ASSERT(rc == -1); - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(rc == -1); + OSMO_ASSERT(test_state.ms_read == 2); /* clean up */ lapdm_channel_exit(&bts_to_ms_channel); @@ -346,7 +342,7 @@ static void test_lapdm_early_release() /* Send the release request */ rc = lapdm_rslms_recvmsg(create_rel_req(), &bts_to_ms_channel); - ASSERT(rc == -EINVAL); + OSMO_ASSERT(rc == -EINVAL); /* clean up */ lapdm_channel_exit(&bts_to_ms_channel); diff --git a/tests/loggingrb/loggingrb_test.c b/tests/loggingrb/loggingrb_test.c index 1ab5212..9957b53 100644 --- a/tests/loggingrb/loggingrb_test.c +++ b/tests/loggingrb/loggingrb_test.c @@ -18,7 +18,6 @@ * along with this program. If not, see . * */ -#include #include #include @@ -77,7 +76,7 @@ int main(int argc, char **argv) DEBUGP(DMM, "You should not see this\n"); fprintf(stderr, ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 0)); fprintf(stderr, ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 1)); - assert(!ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 2)); + OSMO_ASSERT(!ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 2)); return 0; } diff --git a/tests/strrb/strrb_test.c b/tests/strrb/strrb_test.c index abe649f..6140ac9 100644 --- a/tests/strrb/strrb_test.c +++ b/tests/strrb/strrb_test.c @@ -18,12 +18,12 @@ */ #include -#include #include #include #include #include +#include struct osmo_strrb *rb0, *rb1, *rb2, *rb3, *rb4, *rb5; @@ -77,98 +77,98 @@ void free_rbs(void) void test_offset_valid(void) { - assert(_osmo_strrb_is_bufindex_valid(rb1, 0)); - assert(!_osmo_strrb_is_bufindex_valid(rb1, 1)); - assert(!_osmo_strrb_is_bufindex_valid(rb1, 2)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb1, 0)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb1, 1)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb1, 2)); - assert(!_osmo_strrb_is_bufindex_valid(rb3, 0)); - assert(_osmo_strrb_is_bufindex_valid(rb3, 1)); - assert(_osmo_strrb_is_bufindex_valid(rb3, 2)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb3, 0)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb3, 1)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb3, 2)); - assert(_osmo_strrb_is_bufindex_valid(rb4, 0)); - assert(!_osmo_strrb_is_bufindex_valid(rb4, 1)); - assert(_osmo_strrb_is_bufindex_valid(rb4, 2)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb4, 0)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb4, 1)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb4, 2)); - assert(_osmo_strrb_is_bufindex_valid(rb5, 0)); - assert(_osmo_strrb_is_bufindex_valid(rb5, 1)); - assert(!_osmo_strrb_is_bufindex_valid(rb5, 2)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb5, 0)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb5, 1)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb5, 2)); } void test_elems(void) { - assert(osmo_strrb_elements(rb0) == 0); - assert(osmo_strrb_elements(rb1) == 1); - assert(osmo_strrb_elements(rb2) == 2); - assert(osmo_strrb_elements(rb3) == 2); + OSMO_ASSERT(osmo_strrb_elements(rb0) == 0); + OSMO_ASSERT(osmo_strrb_elements(rb1) == 1); + OSMO_ASSERT(osmo_strrb_elements(rb2) == 2); + OSMO_ASSERT(osmo_strrb_elements(rb3) == 2); } void test_getn(void) { - assert(!osmo_strrb_get_nth(rb0, 0)); - assert(!strcmp(STR0, osmo_strrb_get_nth(rb2, 0))); - assert(!strcmp(STR1, osmo_strrb_get_nth(rb2, 1))); - assert(!strcmp(STR1, osmo_strrb_get_nth(rb3, 0))); - assert(!strcmp(STR2, osmo_strrb_get_nth(rb3, 1))); - assert(!osmo_strrb_get_nth(rb3, 2)); + OSMO_ASSERT(!osmo_strrb_get_nth(rb0, 0)); + OSMO_ASSERT(!strcmp(STR0, osmo_strrb_get_nth(rb2, 0))); + OSMO_ASSERT(!strcmp(STR1, osmo_strrb_get_nth(rb2, 1))); + OSMO_ASSERT(!strcmp(STR1, osmo_strrb_get_nth(rb3, 0))); + OSMO_ASSERT(!strcmp(STR2, osmo_strrb_get_nth(rb3, 1))); + OSMO_ASSERT(!osmo_strrb_get_nth(rb3, 2)); } void test_getn_wrap(void) { - assert(!strcmp(STR2, osmo_strrb_get_nth(rb4, 0))); - assert(!strcmp(STR3, osmo_strrb_get_nth(rb4, 1))); + OSMO_ASSERT(!strcmp(STR2, osmo_strrb_get_nth(rb4, 0))); + OSMO_ASSERT(!strcmp(STR3, osmo_strrb_get_nth(rb4, 1))); - assert(!strcmp(STR3, osmo_strrb_get_nth(rb5, 0))); - assert(!strcmp(STR4, osmo_strrb_get_nth(rb5, 1))); + OSMO_ASSERT(!strcmp(STR3, osmo_strrb_get_nth(rb5, 0))); + OSMO_ASSERT(!strcmp(STR4, osmo_strrb_get_nth(rb5, 1))); } void test_add(void) { struct osmo_strrb *rb = osmo_strrb_create(NULL, 4); - assert(rb->start == 0); - assert(rb->end == 0); + OSMO_ASSERT(rb->start == 0); + OSMO_ASSERT(rb->end == 0); osmo_strrb_add(rb, "a"); osmo_strrb_add(rb, "b"); osmo_strrb_add(rb, "c"); - assert(rb->start == 0); - assert(rb->end == 3); - assert(osmo_strrb_elements(rb) == 3); + OSMO_ASSERT(rb->start == 0); + OSMO_ASSERT(rb->end == 3); + OSMO_ASSERT(osmo_strrb_elements(rb) == 3); osmo_strrb_add(rb, "d"); - assert(rb->start == 1); - assert(rb->end == 0); - assert(osmo_strrb_elements(rb) == 3); - assert(!strcmp("b", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("c", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 1); + OSMO_ASSERT(rb->end == 0); + OSMO_ASSERT(osmo_strrb_elements(rb) == 3); + OSMO_ASSERT(!strcmp("b", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("c", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "e"); - assert(rb->start == 2); - assert(rb->end == 1); - assert(!strcmp("c", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 2); + OSMO_ASSERT(rb->end == 1); + OSMO_ASSERT(!strcmp("c", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "f"); - assert(rb->start == 3); - assert(rb->end == 2); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 3); + OSMO_ASSERT(rb->end == 2); + OSMO_ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "g"); - assert(rb->start == 0); - assert(rb->end == 3); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("g", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 0); + OSMO_ASSERT(rb->end == 3); + OSMO_ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("g", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "h"); - assert(rb->start == 1); - assert(rb->end == 0); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("g", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("h", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 1); + OSMO_ASSERT(rb->end == 0); + OSMO_ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("g", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("h", osmo_strrb_get_nth(rb, 2))); talloc_free(rb); } @@ -184,8 +184,8 @@ void test_long_msg(void) tests1 = malloc(test_size); tests2 = malloc(test_size); /* Be certain allocating memory worked before continuing */ - assert(tests1); - assert(tests2); + OSMO_ASSERT(tests1); + OSMO_ASSERT(tests2); for (i = 0; i < RB_MAX_MESSAGE_SIZE; i += 2) { tests1[i] = 'a'; @@ -201,9 +201,9 @@ void test_long_msg(void) free(tests1); rb_content = osmo_strrb_get_nth(rb, 0); - assert(!strncmp(tests2, rb_content, RB_MAX_MESSAGE_SIZE - 1)); - assert(!rb_content[RB_MAX_MESSAGE_SIZE - 1]); - assert(strlen(rb_content) == RB_MAX_MESSAGE_SIZE - 1); + OSMO_ASSERT(!strncmp(tests2, rb_content, RB_MAX_MESSAGE_SIZE - 1)); + OSMO_ASSERT(!rb_content[RB_MAX_MESSAGE_SIZE - 1]); + OSMO_ASSERT(strlen(rb_content) == RB_MAX_MESSAGE_SIZE - 1); free(tests2); talloc_free(rb); -- 1.8.1.2 From laforge at gnumonks.org Sun Mar 3 15:05:02 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Mar 2013 15:05:02 +0000 Subject: [PATCH] Changed assert to OSMO_ASSERT In-Reply-To: <1362307012-2277-1-git-send-email-kat.obsc@gmail.com> References: <20130302211618.GB14045@xiaoyu.lan> <1362307012-2277-1-git-send-email-kat.obsc@gmail.com> Message-ID: <20130303150502.GV4393@prithivi.gnumonks.org> Hi Katerina, On Sun, Mar 03, 2013 at 10:36:52AM +0000, Katerina Barone-Adesi wrote: > Rationale: zecke pointed out that the tests should unconditionally > assert, regardless of debug settings. > This uses the OSMO_ prefix as it's in the global namespace. Two more ideas: * since it is an error condition, fprintf(stderr). * it might make sense to also write it to the osmocom logging, using LOGL_FATAL / DLGLOBAL * while at it, we might also print a backtrace by means of osmo_backtrace(). What do you think? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sun Mar 3 17:15:04 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 3 Mar 2013 18:15:04 +0100 Subject: [PATCH] Changed assert to OSMO_ASSERT In-Reply-To: <20130303150502.GV4393@prithivi.gnumonks.org> References: <20130302211618.GB14045@xiaoyu.lan> <1362307012-2277-1-git-send-email-kat.obsc@gmail.com> <20130303150502.GV4393@prithivi.gnumonks.org> Message-ID: <20130303171504.GL14045@xiaoyu.lan> On Sun, Mar 03, 2013 at 03:05:02PM +0000, Harald Welte wrote: Hi, > Two more ideas: > > * since it is an error condition, fprintf(stderr). > * it might make sense to also write it to the osmocom logging, > using LOGL_FATAL / DLGLOBAL > * while at it, we might also print a backtrace by means of > osmo_backtrace(). > > What do you think? the current usage will be inside the regression/unit testing, e.g. not having a dependency on the logging framework is quite nice to have. For osmo_backtrace and frpintf would be nice. I think the value of osmo_backtrace will be a bit limited as we will have no symbol name for the test function (but this could come from the fprintf). cheers holger From kat.obsc at gmail.com Mon Mar 11 09:36:32 2013 From: kat.obsc at gmail.com (Katerina Barone-Adesi) Date: Mon, 11 Mar 2013 09:36:32 +0000 Subject: [PATCH] OSMO_ASSERT, for assertions in test cases. In-Reply-To: <20130303171504.GL14045@xiaoyu.lan> References: <20130303171504.GL14045@xiaoyu.lan> Message-ID: <1362994592-20782-1-git-send-email-kat.obsc@gmail.com> Rationale: zecke pointed out that the tests should unconditionally assert, regardless of debug settings. This uses the OSMO_ prefix as it's in the global namespace. It shows a backtrace, and uses fprintf(stderr, ...) --- include/osmocom/core/utils.h | 8 +++ tests/lapd/lapd_test.c | 62 +++++++++---------- tests/loggingrb/loggingrb_test.c | 3 +- tests/strrb/strrb_test.c | 126 +++++++++++++++++++-------------------- 4 files changed, 101 insertions(+), 98 deletions(-) diff --git a/include/osmocom/core/utils.h b/include/osmocom/core/utils.h index 03861d7..f8e6fc9 100644 --- a/include/osmocom/core/utils.h +++ b/include/osmocom/core/utils.h @@ -51,6 +51,14 @@ do { \ rem -= ret; \ } while (0) +#define OSMO_ASSERT(exp) \ + if (!(exp)) { \ + fprintf(stderr, "Assert failed %s %s:%d\n", #exp, __FILE__, __LINE__); \ + osmo_generate_backtrace(); \ + abort(); \ + } + + /*! @} */ #endif diff --git a/tests/lapd/lapd_test.c b/tests/lapd/lapd_test.c index acd3cad..a60c45d 100644 --- a/tests/lapd/lapd_test.c +++ b/tests/lapd/lapd_test.c @@ -21,6 +21,7 @@ #include #include +#include #include #include @@ -34,13 +35,6 @@ abort(); \ } -#define ASSERT(exp) \ - if (!(exp)) { \ - printf("Assert failed %s %s:%d\n", #exp, __FILE__, __LINE__); \ - abort(); \ - } - - static struct log_info info = {}; struct lapdm_polling_state { @@ -101,9 +95,9 @@ static struct msgb *create_mm_id_req(void) msg = msgb_from_array(mm, sizeof(mm)); msg->l2h = msg->data + 3; - ASSERT(msgb_l2len(msg) == 12); + OSMO_ASSERT(msgb_l2len(msg) == 12); msg->l3h = msg->l2h + 6; - ASSERT(msgb_l3len(msg) == 6); + OSMO_ASSERT(msgb_l3len(msg) == 6); return msg; } @@ -113,7 +107,7 @@ static struct msgb *create_empty_msg(void) struct msgb *msg; msg = msgb_from_array(NULL, 0); - ASSERT(msgb_l3len(msg) == 0); + OSMO_ASSERT(msgb_l3len(msg) == 0); rsl_rll_push_l3(msg, RSL_MT_DATA_REQ, 0, 0, 1); return msg; } @@ -155,7 +149,7 @@ static int send(struct msgb *in_msg, struct lapdm_channel *chan) pp.u.data.link_id = 0; /* feed into the LAPDm code of libosmogsm */ rc = lapdm_phsap_up(&pp.oph, &chan->lapdm_dcch); - ASSERT(rc == 0 || rc == -EBUSY); + OSMO_ASSERT(rc == 0 || rc == -EBUSY); return 0; } @@ -172,12 +166,14 @@ static int bts_to_ms_tx_cb(struct msgb *in_msg, struct lapdm_entity *le, void *_ if (state->bts_read == 0) { printf("BTS: Verifying CM request.\n"); - ASSERT(msgb_l3len(in_msg) == ARRAY_SIZE(cm_padded)); - ASSERT(memcmp(in_msg->l3h, cm_padded, ARRAY_SIZE(cm_padded)) == 0); + OSMO_ASSERT(msgb_l3len(in_msg) == ARRAY_SIZE(cm_padded)); + OSMO_ASSERT(memcmp(in_msg->l3h, cm_padded, + ARRAY_SIZE(cm_padded)) == 0); } else if (state->bts_read == 1) { printf("BTS: Verifying dummy message.\n"); - ASSERT(msgb_l3len(in_msg) == ARRAY_SIZE(dummy1)); - ASSERT(memcmp(in_msg->l3h, dummy1, ARRAY_SIZE(dummy1)) == 0); + OSMO_ASSERT(msgb_l3len(in_msg) == ARRAY_SIZE(dummy1)); + OSMO_ASSERT(memcmp(in_msg->l3h, dummy1, + ARRAY_SIZE(dummy1)) == 0); } else { printf("BTS: Do not know to verify: %d\n", state->bts_read); } @@ -210,23 +206,23 @@ static int ms_to_bts_tx_cb(struct msgb *msg, struct lapdm_entity *le, void *_ctx struct abis_rsl_rll_hdr hdr; printf("MS: Verifying incoming primitive.\n"); - ASSERT(msg->len == sizeof(struct abis_rsl_rll_hdr) + 3); + OSMO_ASSERT(msg->len == sizeof(struct abis_rsl_rll_hdr) + 3); /* verify the header */ memset(&hdr, 0, sizeof(hdr)); rsl_init_rll_hdr(&hdr, RSL_MT_EST_CONF); hdr.c.msg_discr |= ABIS_RSL_MDISC_TRANSP; - ASSERT(memcmp(msg->data, &hdr, sizeof(hdr)) == 0); + OSMO_ASSERT(memcmp(msg->data, &hdr, sizeof(hdr)) == 0); /* Verify the added RSL_IE_L3_INFO but we have a bug here */ - ASSERT(msg->data[6] == RSL_IE_L3_INFO); + OSMO_ASSERT(msg->data[6] == RSL_IE_L3_INFO); #warning "RSL_IE_L3_INFO 16 bit length is wrong" /* ASSERT(msg->data[7] == 0x0 && msg->data[8] == 0x9c); */ /* this should be 0x0 and 0x0... but we have a bug */ } else if (state->ms_read == 1) { printf("MS: Verifying incoming MM message: %d\n", msgb_l3len(msg)); - ASSERT(msgb_l3len(msg) == 3); - ASSERT(memcmp(msg->l3h, &mm[12], msgb_l3len(msg)) == 0); + OSMO_ASSERT(msgb_l3len(msg) == 3); + OSMO_ASSERT(memcmp(msg->l3h, &mm[12], msgb_l3len(msg)) == 0); } else { printf("MS: Do not know to verify: %d\n", state->ms_read); } @@ -274,13 +270,13 @@ static void test_lapdm_polling() /* 2. Poll on the BTS for sending out a confirmation */ printf("\nConfirming\n"); - ASSERT(test_state.bts_read == 1) + OSMO_ASSERT(test_state.bts_read == 1); rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); CHECK_RC(rc); - ASSERT(pp.oph.msg->data == pp.oph.msg->l2h); + OSMO_ASSERT(pp.oph.msg->data == pp.oph.msg->l2h); send(pp.oph.msg, &ms_to_bts_channel); msgb_free(pp.oph.msg); - ASSERT(test_state.ms_read == 1); + OSMO_ASSERT(test_state.ms_read == 1); /* 3. Send some data to the MS */ printf("\nSending back to MS\n"); @@ -289,35 +285,35 @@ static void test_lapdm_polling() CHECK_RC(rc); send(pp.oph.msg, &ms_to_bts_channel); msgb_free(pp.oph.msg); - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(test_state.ms_read == 2); /* verify that there is nothing more to poll */ rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); - ASSERT(rc < 0); + OSMO_ASSERT(rc < 0); /* 3. And back to the BTS */ printf("\nSending back to BTS\n"); - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(test_state.ms_read == 2); lapdm_rslms_recvmsg(create_dummy_data_req(), &ms_to_bts_channel); /* 4. And back to the MS, but let's move data/l2h apart */ - ASSERT(test_state.bts_read == 2) - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(test_state.bts_read == 2); + OSMO_ASSERT(test_state.ms_read == 2); rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); CHECK_RC(rc); send(pp.oph.msg, &ms_to_bts_channel); - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(test_state.ms_read == 2); msgb_free(pp.oph.msg); /* verify that there is nothing more to poll */ rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); - ASSERT(rc < 0); + OSMO_ASSERT(rc < 0); /* check sending an empty L3 message fails */ rc = lapdm_rslms_recvmsg(create_empty_msg(), &bts_to_ms_channel); - ASSERT(rc == -1); - ASSERT(test_state.ms_read == 2); + OSMO_ASSERT(rc == -1); + OSMO_ASSERT(test_state.ms_read == 2); /* clean up */ lapdm_channel_exit(&bts_to_ms_channel); @@ -346,7 +342,7 @@ static void test_lapdm_early_release() /* Send the release request */ rc = lapdm_rslms_recvmsg(create_rel_req(), &bts_to_ms_channel); - ASSERT(rc == -EINVAL); + OSMO_ASSERT(rc == -EINVAL); /* clean up */ lapdm_channel_exit(&bts_to_ms_channel); diff --git a/tests/loggingrb/loggingrb_test.c b/tests/loggingrb/loggingrb_test.c index 1ab5212..9957b53 100644 --- a/tests/loggingrb/loggingrb_test.c +++ b/tests/loggingrb/loggingrb_test.c @@ -18,7 +18,6 @@ * along with this program. If not, see . * */ -#include #include #include @@ -77,7 +76,7 @@ int main(int argc, char **argv) DEBUGP(DMM, "You should not see this\n"); fprintf(stderr, ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 0)); fprintf(stderr, ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 1)); - assert(!ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 2)); + OSMO_ASSERT(!ringbuffer_get_nth(ringbuf_target->tgt_rbvty.rb, 2)); return 0; } diff --git a/tests/strrb/strrb_test.c b/tests/strrb/strrb_test.c index abe649f..6140ac9 100644 --- a/tests/strrb/strrb_test.c +++ b/tests/strrb/strrb_test.c @@ -18,12 +18,12 @@ */ #include -#include #include #include #include #include +#include struct osmo_strrb *rb0, *rb1, *rb2, *rb3, *rb4, *rb5; @@ -77,98 +77,98 @@ void free_rbs(void) void test_offset_valid(void) { - assert(_osmo_strrb_is_bufindex_valid(rb1, 0)); - assert(!_osmo_strrb_is_bufindex_valid(rb1, 1)); - assert(!_osmo_strrb_is_bufindex_valid(rb1, 2)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb1, 0)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb1, 1)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb1, 2)); - assert(!_osmo_strrb_is_bufindex_valid(rb3, 0)); - assert(_osmo_strrb_is_bufindex_valid(rb3, 1)); - assert(_osmo_strrb_is_bufindex_valid(rb3, 2)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb3, 0)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb3, 1)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb3, 2)); - assert(_osmo_strrb_is_bufindex_valid(rb4, 0)); - assert(!_osmo_strrb_is_bufindex_valid(rb4, 1)); - assert(_osmo_strrb_is_bufindex_valid(rb4, 2)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb4, 0)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb4, 1)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb4, 2)); - assert(_osmo_strrb_is_bufindex_valid(rb5, 0)); - assert(_osmo_strrb_is_bufindex_valid(rb5, 1)); - assert(!_osmo_strrb_is_bufindex_valid(rb5, 2)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb5, 0)); + OSMO_ASSERT(_osmo_strrb_is_bufindex_valid(rb5, 1)); + OSMO_ASSERT(!_osmo_strrb_is_bufindex_valid(rb5, 2)); } void test_elems(void) { - assert(osmo_strrb_elements(rb0) == 0); - assert(osmo_strrb_elements(rb1) == 1); - assert(osmo_strrb_elements(rb2) == 2); - assert(osmo_strrb_elements(rb3) == 2); + OSMO_ASSERT(osmo_strrb_elements(rb0) == 0); + OSMO_ASSERT(osmo_strrb_elements(rb1) == 1); + OSMO_ASSERT(osmo_strrb_elements(rb2) == 2); + OSMO_ASSERT(osmo_strrb_elements(rb3) == 2); } void test_getn(void) { - assert(!osmo_strrb_get_nth(rb0, 0)); - assert(!strcmp(STR0, osmo_strrb_get_nth(rb2, 0))); - assert(!strcmp(STR1, osmo_strrb_get_nth(rb2, 1))); - assert(!strcmp(STR1, osmo_strrb_get_nth(rb3, 0))); - assert(!strcmp(STR2, osmo_strrb_get_nth(rb3, 1))); - assert(!osmo_strrb_get_nth(rb3, 2)); + OSMO_ASSERT(!osmo_strrb_get_nth(rb0, 0)); + OSMO_ASSERT(!strcmp(STR0, osmo_strrb_get_nth(rb2, 0))); + OSMO_ASSERT(!strcmp(STR1, osmo_strrb_get_nth(rb2, 1))); + OSMO_ASSERT(!strcmp(STR1, osmo_strrb_get_nth(rb3, 0))); + OSMO_ASSERT(!strcmp(STR2, osmo_strrb_get_nth(rb3, 1))); + OSMO_ASSERT(!osmo_strrb_get_nth(rb3, 2)); } void test_getn_wrap(void) { - assert(!strcmp(STR2, osmo_strrb_get_nth(rb4, 0))); - assert(!strcmp(STR3, osmo_strrb_get_nth(rb4, 1))); + OSMO_ASSERT(!strcmp(STR2, osmo_strrb_get_nth(rb4, 0))); + OSMO_ASSERT(!strcmp(STR3, osmo_strrb_get_nth(rb4, 1))); - assert(!strcmp(STR3, osmo_strrb_get_nth(rb5, 0))); - assert(!strcmp(STR4, osmo_strrb_get_nth(rb5, 1))); + OSMO_ASSERT(!strcmp(STR3, osmo_strrb_get_nth(rb5, 0))); + OSMO_ASSERT(!strcmp(STR4, osmo_strrb_get_nth(rb5, 1))); } void test_add(void) { struct osmo_strrb *rb = osmo_strrb_create(NULL, 4); - assert(rb->start == 0); - assert(rb->end == 0); + OSMO_ASSERT(rb->start == 0); + OSMO_ASSERT(rb->end == 0); osmo_strrb_add(rb, "a"); osmo_strrb_add(rb, "b"); osmo_strrb_add(rb, "c"); - assert(rb->start == 0); - assert(rb->end == 3); - assert(osmo_strrb_elements(rb) == 3); + OSMO_ASSERT(rb->start == 0); + OSMO_ASSERT(rb->end == 3); + OSMO_ASSERT(osmo_strrb_elements(rb) == 3); osmo_strrb_add(rb, "d"); - assert(rb->start == 1); - assert(rb->end == 0); - assert(osmo_strrb_elements(rb) == 3); - assert(!strcmp("b", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("c", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 1); + OSMO_ASSERT(rb->end == 0); + OSMO_ASSERT(osmo_strrb_elements(rb) == 3); + OSMO_ASSERT(!strcmp("b", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("c", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "e"); - assert(rb->start == 2); - assert(rb->end == 1); - assert(!strcmp("c", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 2); + OSMO_ASSERT(rb->end == 1); + OSMO_ASSERT(!strcmp("c", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "f"); - assert(rb->start == 3); - assert(rb->end == 2); - assert(!strcmp("d", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 3); + OSMO_ASSERT(rb->end == 2); + OSMO_ASSERT(!strcmp("d", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "g"); - assert(rb->start == 0); - assert(rb->end == 3); - assert(!strcmp("e", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("g", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 0); + OSMO_ASSERT(rb->end == 3); + OSMO_ASSERT(!strcmp("e", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("g", osmo_strrb_get_nth(rb, 2))); osmo_strrb_add(rb, "h"); - assert(rb->start == 1); - assert(rb->end == 0); - assert(!strcmp("f", osmo_strrb_get_nth(rb, 0))); - assert(!strcmp("g", osmo_strrb_get_nth(rb, 1))); - assert(!strcmp("h", osmo_strrb_get_nth(rb, 2))); + OSMO_ASSERT(rb->start == 1); + OSMO_ASSERT(rb->end == 0); + OSMO_ASSERT(!strcmp("f", osmo_strrb_get_nth(rb, 0))); + OSMO_ASSERT(!strcmp("g", osmo_strrb_get_nth(rb, 1))); + OSMO_ASSERT(!strcmp("h", osmo_strrb_get_nth(rb, 2))); talloc_free(rb); } @@ -184,8 +184,8 @@ void test_long_msg(void) tests1 = malloc(test_size); tests2 = malloc(test_size); /* Be certain allocating memory worked before continuing */ - assert(tests1); - assert(tests2); + OSMO_ASSERT(tests1); + OSMO_ASSERT(tests2); for (i = 0; i < RB_MAX_MESSAGE_SIZE; i += 2) { tests1[i] = 'a'; @@ -201,9 +201,9 @@ void test_long_msg(void) free(tests1); rb_content = osmo_strrb_get_nth(rb, 0); - assert(!strncmp(tests2, rb_content, RB_MAX_MESSAGE_SIZE - 1)); - assert(!rb_content[RB_MAX_MESSAGE_SIZE - 1]); - assert(strlen(rb_content) == RB_MAX_MESSAGE_SIZE - 1); + OSMO_ASSERT(!strncmp(tests2, rb_content, RB_MAX_MESSAGE_SIZE - 1)); + OSMO_ASSERT(!rb_content[RB_MAX_MESSAGE_SIZE - 1]); + OSMO_ASSERT(strlen(rb_content) == RB_MAX_MESSAGE_SIZE - 1); free(tests2); talloc_free(rb); -- 1.8.1.4 From laforge at gnumonks.org Mon Mar 11 10:34:03 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 11 Mar 2013 11:34:03 +0100 Subject: [PATCH] OSMO_ASSERT, for assertions in test cases. In-Reply-To: <1362994592-20782-1-git-send-email-kat.obsc@gmail.com> References: <20130303171504.GL14045@xiaoyu.lan> <1362994592-20782-1-git-send-email-kat.obsc@gmail.com> Message-ID: <20130311103403.GJ6508@prithivi.gnumonks.org> Hi Katerina, On Mon, Mar 11, 2013 at 09:36:32AM +0000, Katerina Barone-Adesi wrote: > Rationale: zecke pointed out that the tests should unconditionally > assert, regardless of debug settings. this looks fine now to me. Holger: Are you going to merge it? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Fri Mar 1 06:14:49 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 1 Mar 2013 07:14:49 +0100 Subject: Fwd: ASN1C In-Reply-To: References: Message-ID: <20130301061450.16079.qmail@stuge.se> Ivan Mikey wrote: > /osmo-tcap-map/test$ make > cc -lasn1c -losmo-asn1-map -losmo-asn1-tcap -lm -o gprs_update gprs_update.o Libraries need to follow objects that call them. //Peter From 246tnt at gmail.com Fri Mar 1 15:38:45 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 1 Mar 2013 16:38:45 +0100 Subject: Fwd: ASN1C In-Reply-To: <20130301061450.16079.qmail@stuge.se> References: <20130301061450.16079.qmail@stuge.se> Message-ID: On Fri, Mar 1, 2013 at 7:14 AM, Peter Stuge wrote: > Ivan Mikey wrote: >> /osmo-tcap-map/test$ make >> cc -lasn1c -losmo-asn1-map -losmo-asn1-tcap -lm -o gprs_update gprs_update.o > > Libraries need to follow objects that call them. Which is _really_ annoying that Ubuntu linker now enforce that, because in the default 'make rules' (i.e. when you let makefile figure things out), it places ldflags before the objet files and so things break. Cheers, Sylvain From alexander.huemer at xx.vu Fri Mar 1 20:27:25 2013 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Fri, 1 Mar 2013 21:27:25 +0100 Subject: Fwd: ASN1C In-Reply-To: References: <20130301061450.16079.qmail@stuge.se> Message-ID: <20130301202723.GA15877@de.xx.vu> On Fri, Mar 01, 2013 at 04:38:45PM +0100, Sylvain Munaut wrote: > On Fri, Mar 1, 2013 at 7:14 AM, Peter Stuge wrote: > > Ivan Mikey wrote: > >> /osmo-tcap-map/test$ make > >> cc -lasn1c -losmo-asn1-map -losmo-asn1-tcap -lm -o gprs_update gprs_update.o > > > > Libraries need to follow objects that call them. > > Which is _really_ annoying that Ubuntu linker now enforce that, > because in the default 'make rules' (i.e. when you let makefile figure > things out), it places ldflags before the objet files and so things > break. In plain Makefiles the variable to place '-lfoo' flags is LDLIBS, then it works even on Ubuntu. See e.g. [1]. Kind regards, -Alexander Huemer [1] http://cgit.osmocom.org/cgit/osmo-tetra/commit/?id=a4bdfabbbbd90f7a7887e434c84a05d6caab2d12 From 246tnt at gmail.com Sat Mar 2 09:51:02 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 2 Mar 2013 10:51:02 +0100 Subject: Fwd: ASN1C In-Reply-To: <20130301202723.GA15877@de.xx.vu> References: <20130301061450.16079.qmail@stuge.se> <20130301202723.GA15877@de.xx.vu> Message-ID: Hi, > In plain Makefiles the variable to place '-lfoo' flags is LDLIBS, then > it works even on Ubuntu. See e.g. [1]. Oh, nice, I didn't know that. Cheers, Sylvain From laforge at gnumonks.org Fri Mar 1 10:21:39 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 1 Mar 2013 11:21:39 +0100 Subject: Fwd: ASN1C In-Reply-To: References: Message-ID: <20130301102139.GJ13404@prithivi.gnumonks.org> Hi Ivan, > libosmo-asn1-map > libosmo-asn1-tcap > libosmo-tcap > libsu > osmo-tcap-map There is a reason that those projects don't have any wiki pages or a dedicated mailing list: All of the projects you refer to are incomplete and inactive/stalled for a long time. Please do not expect any type of feedback from our side. If you feel like picking up the work and contributing: Be my guest. But as indicated, you will be on your own. > asn1c > libasn1c Those two are just minor extended/modified versions from Lev Walkin's asn1c. 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 sergei at oleinikov.com Fri Mar 1 18:23:04 2013 From: sergei at oleinikov.com (Sergei Oleinikov) Date: Fri, 01 Mar 2013 20:23:04 +0200 Subject: MGW_NAT In-Reply-To: <20130301102139.GJ13404@prithivi.gnumonks.org> References: <20130301102139.GJ13404@prithivi.gnumonks.org> Message-ID: <1362162184.25504.11.camel@segamza> Hi All, where i can get header file map.hrl ? it isn't present neither there nor there. Thanks in advance ! >>=== building mgw_nat and its dependencies === >> >>{{{ >>cd ~/osmo-erlang/mgw_nat >>rebar get-deps >>rebar compile >>}}} >>some error will occur regarding src/tcap_map_patch.erl due to missing map.hrl file >>{{{ >>mv deps/osmo_map/src/map.hrl deps/osmo_map/include/ >>rebar compile >>}}} Br, Sergei -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Mar 3 12:43:39 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Mar 2013 13:43:39 +0100 Subject: MGW_NAT In-Reply-To: <1362162184.25504.11.camel@segamza> References: <20130301102139.GJ13404@prithivi.gnumonks.org> <1362162184.25504.11.camel@segamza> Message-ID: <20130303124339.GN4393@prithivi.gnumonks.org> Hi Sergei, On Fri, Mar 01, 2013 at 08:23:04PM +0200, Sergei Oleinikov wrote: > where i can get header file map.hrl ? > it isn't present neither there nor there. erlangs asn1ct will produce map.hrl and map.erl out of the map.set.asn1 Normally, it gets compiled automatically, but then ends up in the asn1/ subdirectory (of osmo_map.git) instead of the include/ directory, where it should be. Somebody with Erlang skills should probably fix rebar to do this properly. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kat.obsc at gmail.com Fri Mar 1 18:31:38 2013 From: kat.obsc at gmail.com (Katerina Barone-Adesi) Date: Fri, 1 Mar 2013 18:31:38 +0000 Subject: [PATCH] Stub changes for vty documentation Message-ID: <1362162698-8554-1-git-send-email-kat.obsc@gmail.com> contrib/dump_all_data.py showed several (null) documentation messages. This patch aims to show what needs to be documented. Please do not apply this patch as-is: this is stub documentation, which needs to be edited by someone familiar with the particular VTY commands. --- openbsc/src/libbsc/bsc_vty.c | 4 ++-- openbsc/src/libmgcp/mgcp_vty.c | 4 ++-- openbsc/src/libmsc/vty_interface_layer3.c | 6 ++++-- openbsc/src/osmo-bsc/osmo_bsc_vty.c | 7 ++++--- 4 files changed, 12 insertions(+), 9 deletions(-) diff --git a/openbsc/src/libbsc/bsc_vty.c b/openbsc/src/libbsc/bsc_vty.c index ec92c18..29ec065 100644 --- a/openbsc/src/libbsc/bsc_vty.c +++ b/openbsc/src/libbsc/bsc_vty.c @@ -2644,7 +2644,7 @@ DEFUN(cfg_ts, DEFUN(cfg_ts_pchan, cfg_ts_pchan_cmd, "phys_chan_config PCHAN", /* dynamically generated! */ - "Physical Channel configuration (TCH/SDCCH/...)") + "Physical Channel configuration (TCH/SDCCH/...)\n" "PCHAN\n") { struct gsm_bts_trx_ts *ts = vty->index; int pchanc; @@ -2663,7 +2663,7 @@ DEFUN(cfg_ts_pchan, DEFUN_HIDDEN(cfg_ts_pchan_compat, cfg_ts_pchan_compat_cmd, "phys_chan_config PCHAN", - "Physical Channel configuration (TCH/SDCCH/...)") + "Physical Channel configuration (TCH/SDCCH/...)\n" "PCHAN\n") { struct gsm_bts_trx_ts *ts = vty->index; int pchanc; diff --git a/openbsc/src/libmgcp/mgcp_vty.c b/openbsc/src/libmgcp/mgcp_vty.c index 88d793f..9e3051d 100644 --- a/openbsc/src/libmgcp/mgcp_vty.c +++ b/openbsc/src/libmgcp/mgcp_vty.c @@ -327,7 +327,7 @@ ALIAS_DEPRECATED(cfg_mgcp_rtp_ip_dscp, cfg_mgcp_rtp_ip_tos_cmd, DEFUN(cfg_mgcp_sdp_fmtp_extra, cfg_mgcp_sdp_fmtp_extra_cmd, "sdp audio fmtp-extra .NAME", - "Add extra fmtp for the SDP file\n") + "Add extra fmtp for the SDP file\n" "Audio\n" "Fmtp-extra\n" "Name\n") { char *txt = argv_concat(argv, argc, 0); if (!txt) @@ -508,7 +508,7 @@ static int config_write_trunk(struct vty *vty) DEFUN(cfg_trunk_sdp_fmtp_extra, cfg_trunk_sdp_fmtp_extra_cmd, "sdp audio fmtp-extra .NAME", - "Add extra fmtp for the SDP file\n") + "Add extra fmtp for the SDP file\n" "Audio\n" "Fmtp-extra\n" "Name\n") { struct mgcp_trunk_config *trunk = vty->index; char *txt = argv_concat(argv, argc, 0); diff --git a/openbsc/src/libmsc/vty_interface_layer3.c b/openbsc/src/libmsc/vty_interface_layer3.c index 441ee1e..efd1e9b 100644 --- a/openbsc/src/libmsc/vty_interface_layer3.c +++ b/openbsc/src/libmsc/vty_interface_layer3.c @@ -231,7 +231,7 @@ DEFUN(subscriber_send_pending_sms, DEFUN(subscriber_send_sms, subscriber_send_sms_cmd, "subscriber " SUBSCR_TYPES " ID sms sender " SUBSCR_TYPES " SENDER_ID send .LINE", - SUBSCR_HELP "SMS Operations\n" "Send SMS\n" "Actual SMS Text") + SUBSCR_HELP "SMS Operations\n" SUBSCR_HELP "Actual SMS Text\n" "LINE\n") { struct gsm_network *gsmnet = gsmnet_from_vty(vty); struct gsm_subscriber *subscr = get_subscr_by_argv(gsmnet, argv[0], argv[1]); @@ -911,11 +911,13 @@ DEFUN(mnccint_def_codec_h, return CMD_SUCCESS; } +#define OBSOLETE_MSG "Obsolete\n" /* this is just for backwards compatibility as the sms code moved into * libosmocore and old config files no longer parse... */ DEFUN_DEPRECATED(log_level_sms, log_level_sms_cmd, "logging level sms (everything|debug|info|notice|error|fatal)", - ".HIDDEN") + ".HIDDEN\n" OBSOLETE_MSG OBSOLETE_MSG OBSOLETE_MSG OBSOLETE_MSG + OBSOLETE_MSG OBSOLETE_MSG OBSOLETE_MSG OBSOLETE_MSG) { vty_out(vty, "%% 'logging level sms' is now called 'logging level " "lsms', please update your config %s", VTY_NEWLINE); diff --git a/openbsc/src/osmo-bsc/osmo_bsc_vty.c b/openbsc/src/osmo-bsc/osmo_bsc_vty.c index fb38848..ff235e7 100644 --- a/openbsc/src/osmo-bsc/osmo_bsc_vty.c +++ b/openbsc/src/osmo-bsc/osmo_bsc_vty.c @@ -180,7 +180,7 @@ static int config_write_bsc(struct vty *vty) DEFUN(cfg_net_bsc_token, cfg_net_bsc_token_cmd, "token TOKEN", - "A token for the BSC to be sent to the MSC") + "A token for the BSC to be sent to the MSC\n" "A token\n") { struct osmo_msc_data *data = osmo_msc_data(vty); @@ -335,7 +335,8 @@ DEFUN(cfg_net_msc_no_dest, DEFUN(cfg_net_msc_ping_time, cfg_net_msc_ping_time_cmd, "timeout-ping NR", - "Set the PING interval, negative for not sending PING") + "Set the PING interval, negative for not sending PING.\n" + "Timeout in seconds\n") { struct osmo_msc_data *data = osmo_msc_data(vty); data->ping_timeout = atoi(argv[0]); @@ -345,7 +346,7 @@ DEFUN(cfg_net_msc_ping_time, DEFUN(cfg_net_msc_pong_time, cfg_net_msc_pong_time_cmd, "timeout-pong NR", - "Set the time to wait for a PONG.") + "Set the time to wait for a PONG.\n" "Timeout in seconds\n") { struct osmo_msc_data *data = osmo_msc_data(vty); data->pong_timeout = atoi(argv[0]); -- 1.8.1.2 From holger at freyther.de Sun Mar 3 08:50:29 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 3 Mar 2013 09:50:29 +0100 Subject: [PATCH] Stub changes for vty documentation In-Reply-To: <1362162698-8554-1-git-send-email-kat.obsc@gmail.com> References: <1362162698-8554-1-git-send-email-kat.obsc@gmail.com> Message-ID: <20130303085029.GC14045@xiaoyu.lan> On Fri, Mar 01, 2013 at 06:31:38PM +0000, Katerina Barone-Adesi wrote: thanks, I have re-worded some the messages and pushed the change. holger From laforge at gnumonks.org Sun Mar 3 12:46:34 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Mar 2013 13:46:34 +0100 Subject: [PATCH] Stub changes for vty documentation In-Reply-To: <1362162698-8554-1-git-send-email-kat.obsc@gmail.com> References: <1362162698-8554-1-git-send-email-kat.obsc@gmail.com> Message-ID: <20130303124634.GO4393@prithivi.gnumonks.org> Hi Katerina, thanks for your cleanup patches. However: On Fri, Mar 01, 2013 at 06:31:38PM +0000, Katerina Barone-Adesi wrote: > "phys_chan_config PCHAN", /* dynamically generated! */ > - "Physical Channel configuration (TCH/SDCCH/...)") > + "Physical Channel configuration (TCH/SDCCH/...)\n" "PCHAN\n") Does this matter at all? The strings are overridden in bsc_vty_init() with dynamically generated option lists by means of vty_cmd_string_from_valstr(). Maybe I'm missing something, but the "PCHAN" you are adding should never even show up on the VTY. 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 kat.obsc at gmail.com Sun Mar 3 07:15:24 2013 From: kat.obsc at gmail.com (Katerina Barone-Adesi) Date: Sun, 3 Mar 2013 07:15:24 +0000 Subject: [PATCH] VTY enable then write crashed gproxy; this patch fixes it. Message-ID: <1362294924-19744-1-git-send-email-kat.obsc@gmail.com> The previous code made gprs_categories have 18 entries, rather than the 3 a glance would suggest. The first 15 were all-0, as per implicit initialization of static objects in the c standard. This caused problems for code in libosmocore which expected actual data. There are three potential solutions: a) Define a new enum for gprs_categories b) Change libosmocore to not crash on all-zero input categories. c) Simply use log_info, which has a superset of the information. This patch implements c, the simplest. sgsn_main.c had a similar problem; it implicitly had 20 categories. (see readelf -s gprs/osmo-sgsn | grep gprs_categories). --- openbsc/src/gprs/gb_proxy_main.c | 28 ++---------------- openbsc/src/gprs/sgsn_main.c | 62 ++-------------------------------------- 2 files changed, 4 insertions(+), 86 deletions(-) diff --git a/openbsc/src/gprs/gb_proxy_main.c b/openbsc/src/gprs/gb_proxy_main.c index b5b11fd..0a96527 100644 --- a/openbsc/src/gprs/gb_proxy_main.c +++ b/openbsc/src/gprs/gb_proxy_main.c @@ -200,30 +200,6 @@ static struct vty_app_info vty_info = { .is_config_node = bsc_vty_is_config_node, }; -/* default categories */ -static struct log_info_cat gprs_categories[] = { - [DGPRS] = { - .name = "DGPRS", - .description = "GPRS Packet Service", - .enabled = 1, .loglevel = LOGL_DEBUG, - }, - [DNS] = { - .name = "DNS", - .description = "GPRS Network Service (NS)", - .enabled = 1, .loglevel = LOGL_INFO, - }, - [DBSSGP] = { - .name = "DBSSGP", - .description = "GPRS BSS Gateway Protocol (BSSGP)", - .enabled = 1, .loglevel = LOGL_DEBUG, - }, -}; - -static const struct log_info gprs_log_info = { - .filter_fn = gprs_log_filter_fn, - .cat = gprs_categories, - .num_cat = ARRAY_SIZE(gprs_categories), -}; int main(int argc, char **argv) { @@ -239,11 +215,11 @@ int main(int argc, char **argv) signal(SIGUSR2, &signal_handler); osmo_init_ignore_signals(); - osmo_init_logging(&gprs_log_info); + osmo_init_logging(&log_info); vty_info.copyright = openbsc_copyright; vty_init(&vty_info); - logging_vty_add_cmds(&gprs_log_info); + logging_vty_add_cmds(&log_info); gbproxy_vty_init(); handle_options(argc, argv); diff --git a/openbsc/src/gprs/sgsn_main.c b/openbsc/src/gprs/sgsn_main.c index 08e0a85..e5161b4 100644 --- a/openbsc/src/gprs/sgsn_main.c +++ b/openbsc/src/gprs/sgsn_main.c @@ -227,64 +227,6 @@ static void handle_options(int argc, char **argv) } } -/* default categories */ -static struct log_info_cat gprs_categories[] = { - [DMM] = { - .name = "DMM", - .description = "Layer3 Mobility Management (MM)", - .color = "\033[1;33m", - .enabled = 1, .loglevel = LOGL_NOTICE, - }, - [DPAG] = { - .name = "DPAG", - .description = "Paging Subsystem", - .color = "\033[1;38m", - .enabled = 1, .loglevel = LOGL_NOTICE, - }, - [DMEAS] = { - .name = "DMEAS", - .description = "Radio Measurement Processing", - .enabled = 0, .loglevel = LOGL_NOTICE, - }, - [DREF] = { - .name = "DREF", - .description = "Reference Counting", - .enabled = 0, .loglevel = LOGL_NOTICE, - }, - [DGPRS] = { - .name = "DGPRS", - .description = "GPRS Packet Service", - .enabled = 1, .loglevel = LOGL_DEBUG, - }, - [DNS] = { - .name = "DNS", - .description = "GPRS Network Service (NS)", - .enabled = 1, .loglevel = LOGL_INFO, - }, - [DBSSGP] = { - .name = "DBSSGP", - .description = "GPRS BSS Gateway Protocol (BSSGP)", - .enabled = 1, .loglevel = LOGL_DEBUG, - }, - [DLLC] = { - .name = "DLLC", - .description = "GPRS Logical Link Control Protocol (LLC)", - .enabled = 1, .loglevel = LOGL_DEBUG, - }, - [DSNDCP] = { - .name = "DSNDCP", - .description = "GPRS Sub-Network Dependent Control Protocol (SNDCP)", - .enabled = 1, .loglevel = LOGL_DEBUG, - }, -}; - -static const struct log_info gprs_log_info = { - .filter_fn = gprs_log_filter_fn, - .cat = gprs_categories, - .num_cat = ARRAY_SIZE(gprs_categories), -}; - - int main(int argc, char **argv) { struct gsm_network dummy_network; @@ -299,11 +241,11 @@ int main(int argc, char **argv) signal(SIGUSR2, &signal_handler); osmo_init_ignore_signals(); - osmo_init_logging(&gprs_log_info); + osmo_init_logging(&log_info); vty_info.copyright = openbsc_copyright; vty_init(&vty_info); - logging_vty_add_cmds(&gprs_log_info); + logging_vty_add_cmds(&log_info); sgsn_vty_init(); handle_options(argc, argv); -- 1.8.1.2 From holger at freyther.de Sun Mar 3 11:17:58 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 3 Mar 2013 12:17:58 +0100 Subject: [PATCH] VTY enable then write crashed gproxy; this patch fixes it. In-Reply-To: <1362294924-19744-1-git-send-email-kat.obsc@gmail.com> References: <1362294924-19744-1-git-send-email-kat.obsc@gmail.com> Message-ID: <20130303111758.GJ14045@xiaoyu.lan> On Sun, Mar 03, 2013 at 07:15:24AM +0000, Katerina Barone-Adesi wrote: Hi, > This patch implements c, the simplest. I agree that c) is the best approach. I looked through the commits and LaF0rge changed it from c) to the code as it is now in commit revision: 11461a64574314fbc4747fe6251ca000fdd56b75. LaF0rge do you remember why you used a custom array instead of the commong log_info? thanks holger From laforge at gnumonks.org Sun Mar 3 15:00:48 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Mar 2013 15:00:48 +0000 Subject: [PATCH] VTY enable then write crashed gproxy; this patch fixes it. In-Reply-To: <20130303111758.GJ14045@xiaoyu.lan> References: <1362294924-19744-1-git-send-email-kat.obsc@gmail.com> <20130303111758.GJ14045@xiaoyu.lan> Message-ID: <20130303150048.GU4393@prithivi.gnumonks.org> Hi Holger and others, On Sun, Mar 03, 2013 at 12:17:58PM +0100, Holger Hans Peter Freyther wrote: > LaF0rge do you remember why you used a custom array instead of the > commong log_info? I think it was my futile attempt at making the unused categories disappear from the "log level ", as explained in my other mail. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Mar 3 12:50:27 2013 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Mar 2013 13:50:27 +0100 Subject: [PATCH] VTY enable then write crashed gproxy; this patch fixes it. In-Reply-To: <1362294924-19744-1-git-send-email-kat.obsc@gmail.com> References: <1362294924-19744-1-git-send-email-kat.obsc@gmail.com> Message-ID: <20130303125027.GP4393@prithivi.gnumonks.org> Hi Katerina, On Sun, Mar 03, 2013 at 07:15:24AM +0000, Katerina Barone-Adesi wrote: > The previous code made gprs_categories have 18 entries, > rather than the 3 a glance would suggest. The first 15 were all-0, > as per implicit initialization of static objects in the c standard. > This caused problems for code in libosmocore which expected actual data. > There are three potential solutions: > a) Define a new enum for gprs_categories > b) Change libosmocore to not crash on all-zero input categories. > c) Simply use log_info, which has a superset of the information. > This patch implements c, the simplest. > sgsn_main.c had a similar problem; it implicitly had 20 categories. > (see readelf -s gprs/osmo-sgsn | grep gprs_categories). I was aware of the problem, but never found time for a proper solution. In general, I prefer to have one enum and not program-specific enums, as we tend to move code from one executable to another over tiem and I would like to avoid clashes. The probelm with the current attempt of registering the full log_info is that if you type "logging level " in the SGSN, it will show you a long list of categories that make absolutely no sense in the context of the SGSN. There is no call control, rsl or lapdm in the context of GPRS. One idea might be to have another member of the struct that allows them to be globally disabled/invisible. This way the SGSN startup code could specify which log categories are actually used, and the VTY strings would be generated only for that sub-set of categories. I'm open for other ideas, too... 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 holger at freyther.de Sun Mar 3 17:22:58 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 3 Mar 2013 18:22:58 +0100 Subject: [PATCH] VTY enable then write crashed gproxy; this patch fixes it. In-Reply-To: <20130303125027.GP4393@prithivi.gnumonks.org> References: <1362294924-19744-1-git-send-email-kat.obsc@gmail.com> <20130303125027.GP4393@prithivi.gnumonks.org> Message-ID: <20130303172258.GM14045@xiaoyu.lan> On Sun, Mar 03, 2013 at 01:50:27PM +0100, Harald Welte wrote: > One idea might be to have another member of the struct that allows them > to be globally disabled/invisible. This way the SGSN startup code could > specify which log categories are actually used, and the VTY strings > would be generated only for that sub-set of categories. We are currently using a uint8_t for 'enabled' in the logging category struct. We could use some bits for SYS_ENABLED/SYS_DISABLED to either disable (my preference) or enable categories. The logging_vty.c code could take this into account. The danger is that we disable something that should be enabled. From laforge at gnumonks.org Fri Mar 8 15:39:42 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 8 Mar 2013 15:39:42 +0000 Subject: [osmo-bts] Review of jolly/trx jolly/l1sap Message-ID: <20130308153942.GP6508@prithivi.gnumonks.org> Hi Andreas, I've found some time to review the trx and l1sap branches you have created in the osmo-bts.git repository. Let me start by mentioning that I support and encourage your work. However, I think we have to set some general rules before we can merge the code. For us, the most important factor is that we do not loose features or introduce regressions with more or less every new commit to osmo-bts. Furthermore, we would like to stay with 'one commit, one feature/fix'. I understand your primary goal ist go generalize some code and then create a working solution for the OpenBTS or OsmocomBB based transceiver. However, for the way to get the changes are integrated is to first introduce all the infrastructure/core changes while keeping osmo-bts-sysmo functional and that with all existing features. Once those core/infrastructure changes are merged, we can easily include support the extra code for the osmo-bts-trx and in fact even do all development commits to master, as long as they don't touch the core code. Looking at your commits: http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=a82995738303d75647aa064bd52cccaf76d249ef is fine, as it just removes old code. http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=9be2099855532cff4313e132375c63c71fa8c0ff looks fine to me, too, we should be able to merge that. My only comment would be: Are you sure this should not be configured via OML from the BSC? I think TS 12.21 Chapter 9.4.14 should be the proper way to configure it. Do you agree? If yes, please use OML configuration and remove the VTY option. http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=7322254e68b7d5ebf1098a902d99bc0e5965e2f4 seems fine to me. Can you pleaes confirm from your side that it _should_ not alter/remove any existing code/behavior, but just introduce that L1SAP intermediate interface? Have you tested it with osmo-bts-sysmo? http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=1c3712962195d1988c2937481c98592d2705464f seems to not just remove the direct handling of primitives, but also add some code, particularly the gsmtap_ip command line argument. Can you please split that in a separate patch? Also, have you tested osmo-bts-sysmo after this commit? 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 andreas at eversberg.eu Sun Mar 10 11:41:10 2013 From: andreas at eversberg.eu (jolly) Date: Sun, 10 Mar 2013 12:41:10 +0100 Subject: [osmo-bts] Review of jolly/trx jolly/l1sap In-Reply-To: <20130308153942.GP6508@prithivi.gnumonks.org> References: <20130308153942.GP6508@prithivi.gnumonks.org> Message-ID: <513C7156.1040705@eversberg.eu> hi harald, > http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=9be2099855532cff4313e132375c63c71fa8c0ff > looks fine to me, too, we should be able to merge that. My only comment > would be: Are you sure this should not be configured via OML from the > BSC? I think TS 12.21 Chapter 9.4.14 should be the proper way to > configure it. Do you agree? If yes, please use OML configuration and > remove the VTY option. > yes, i did not noticed that there is an OML IE for that. the specs leave open how to measure link at BTS side, so I decided to use same algorithm as the MS uses. (the MS gets initial value for radio link timeout via system information message.) i have just improved this patch (see jolly/trx branch). additionally I added an option to openbsc to configure radio link timeout via VTY. this value is sent down to BTS (via OML) also. (see jolly/testing branch of openbsc) > http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=7322254e68b7d5ebf1098a902d99bc0e5965e2f4 > seems fine to me. Can you pleaes confirm from your side that it > _should_ not alter/remove any existing code/behavior, but just introduce > that L1SAP intermediate interface? Have you tested it with > osmo-bts-sysmo? > i have tested everything with osmo-bts-sysmo - at least with TCH/F call. the behavior was the same. > http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=1c3712962195d1988c2937481c98592d2705464f > seems to not just remove the direct handling of primitives, but also add > some code, particularly the gsmtap_ip command line argument. Can you > please split that in a separate patch? Also, have you tested > osmo-bts-sysmo after this commit? > as above, i tested TCH/F calls with osmo-bts-sysmo. because gsmtap is now provided at common part, and because each application (osmo-bts-sysmo in this case) handles gsmtap command line option itself (there is no option handling at common part), i added the command line options, so this patch does not remove any feature. i can split it of course. i think that my branches are still quite experimental and not really made for merging yet. once i am done with the trx stuff, i would like to test osmo-bts-sysmo again with all voice codecs and then create a new branch to rebase everything onto the current master. regards, andreas From laforge at gnumonks.org Mon Mar 11 10:54:29 2013 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 11 Mar 2013 11:54:29 +0100 Subject: [osmo-bts] Review of jolly/trx jolly/l1sap In-Reply-To: <513C7156.1040705@eversberg.eu> References: <20130308153942.GP6508@prithivi.gnumonks.org> <513C7156.1040705@eversberg.eu> Message-ID: <20130311105429.GK6508@prithivi.gnumonks.org> Hi Andreas, On Sun, Mar 10, 2013 at 12:41:10PM +0100, jolly wrote: > hi harald, > > http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=9be2099855532cff4313e132375c63c71fa8c0ff > > looks fine to me, too, we should be able to merge that. My only comment > > would be: Are you sure this should not be configured via OML from the > > BSC? I think TS 12.21 Chapter 9.4.14 should be the proper way to > > configure it. Do you agree? If yes, please use OML configuration and > > remove the VTY option. > > > yes, i did not noticed that there is an OML IE for that. the specs leave > open how to measure link at BTS side, so I decided to use same algorithm > as the MS uses. (the MS gets initial value for radio link timeout via > system information message.) i have just improved this patch (see > jolly/trx branch). Please note that the NM_ATT_CONN_FAIL_CRIT does not _have_ to be the radio link timeout, i.e. just blindly dereferencing its value is wrong in two parts: 1) it may be that the value part is not even two bytes long 2) it may be that the val[0] != 0x01, i.e. not RADIO_LINK_TIMEOUT Please see my improved version of the patch in osmo-bts master as commit 294fd1b650e4482775fdd604288fc928e66ef81c. > i think that my branches are still quite experimental and not really > made for merging yet. I would like to avoid keeping the l1sap in a separate branch for too long time as it will start to clash with other work that is being done. So independent of the 'trx' branch, it would be good if we could get the l1sap part into a state where you consider it worth merging at some not too distant future. Thanks for offering to test + rebase everything once you're done, though. 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 andreas at eversberg.eu Mon Mar 11 18:41:12 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 11 Mar 2013 19:41:12 +0100 Subject: [osmo-bts] Review of jolly/trx jolly/l1sap In-Reply-To: <20130311105429.GK6508@prithivi.gnumonks.org> References: <20130308153942.GP6508@prithivi.gnumonks.org> <513C7156.1040705@eversberg.eu> <20130311105429.GK6508@prithivi.gnumonks.org> Message-ID: <513E2548.3060109@eversberg.eu> Harald Welte wrote: > So independent of the 'trx' branch, it would be good if we could get the > l1sap part into a state where you consider it worth merging at some > not too distant future. i can rebase the jolly/l1sap branch on top of master. also i can apply all common/sysmo fixes from jolly/trx branch to the l1sap branch. the l1sap branch will then have a clean set of patches. i will test full rate and half rate (amr) calls with sysmo-bts. i can rebase the trx branch on top of the cleaned l1sap branch. after that, the branches at origin need to be removed and pushed again. i like to know if this is a good way to do it. (i don't want to create even more branches.) From holger at freyther.de Tue Mar 12 07:54:13 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 12 Mar 2013 08:54:13 +0100 Subject: [osmo-bts] Review of jolly/trx jolly/l1sap In-Reply-To: <513E2548.3060109@eversberg.eu> References: <20130308153942.GP6508@prithivi.gnumonks.org> <513C7156.1040705@eversberg.eu> <20130311105429.GK6508@prithivi.gnumonks.org> <513E2548.3060109@eversberg.eu> Message-ID: <20130312075413.GQ18290@xiaoyu.lan> On Mon, Mar 11, 2013 at 07:41:12PM +0100, Andreas Eversberg wrote: Hi, > Harald Welte wrote: > >So independent of the 'trx' branch, it would be good if we could get the > >l1sap part into a state where you consider it worth merging at some > >not too distant future. I would like to test the sapi queuing first. The integration process on my side is a bit longish as it goes through a multi hour stress test with the modem bank. holger From andreas at eversberg.eu Sun Mar 10 15:13:50 2013 From: andreas at eversberg.eu (jolly) Date: Sun, 10 Mar 2013 16:13:50 +0100 Subject: rtp handling for all speech codecs Message-ID: <513CA32E.7010401@eversberg.eu> hi, long time ago i had these patches at a seperate "rtpmux" branch. now i added them to a new branch (jolly/trx). they are very well tested now, and i think they should get merged after some review. it is my aim to support all speech codecs at osmo-nitb (built-in call handling, as well as MNCC socket interface). these patches are essential for patches that will follow during next weeks. http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=f029472c1e439ee6c2519ce1b67807d4249ab55b Adding traffic forwarding via RTP to remote application Instead of forwarding traffic through MNCC interface, traffic can now be forwarded to a given RTP destination. A special MNCC message is used for that. The traffic can still be forwarded through MNCC interface when this special MNCC message is not used. It also works with E1 based BTSs. In conjunction with LCR's "rtp-bridge" feature, the RTP traffic can be directly exchanged with a remote SIP endpoint, so that the traffic is not forwarded by LCR itself. This way the performance of handling traffic only depends on OpenBSC and the remote SIP endpoint. Also the traffic is exchanged with the SIP endpoint without transcoding, to have maximum performance. http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=eb333169ae035946a4ae50ff56b0f948fc5de12a Adding handling of BFI (Bad Frame Indicatior) of received TRAU frames If a bad TRAU frame is received, it is forwarded to MNCC application as GSM_TCHF_BAD_FRAME. The application can now handle the GAP of missing audio. (e.g. with extrapolation) If TRAU frames are forwarded via RTP, bad frames are dropped, but frame counter and timestamp of RTP sender state is increased. http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=7fb2bf09ec2855dd6e7b164d98b8ccf5cace46ba Allow dynamic RTP payload types between application and MNCC interface Since EFR/AMR/HR codecs use dynamic RTP payload, the payload type can be set. If it is set, the frame type must be set also, so OpenBSC knows what frame types are received via RTP. This modification only affects traffic beween application and MNCC interface, not the RTP traffic between OpenBSC and BTS. http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=42eb7251b96581e2f9f9af38fcb0ba08a137e97f Fixed delay problems, if RTP stream jitters too much The RTP stream is generated or forwarded by OpenBSC to nanoBTS. Due to switching of streams (hold/retrieve call), packet loss or even stalling of sender's process, the time stamp must be corrected. If outdated packets are received, they get dropped. http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=ee20ef2691fb20b3a94c7e734cc4c65bebee6d17 Finished support for all codecs (RTP bridge and MNCC interface) The code is not yet tested. AMR rate is currently fixed to 5.9k. http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=5140fa39898d159be5a6e621ead2ffe885b6174e Fixed problem of mute audio on some calls When reading from RTP socket, the first read() may fail right after connecting to remote socket. Subsequent read() will work as it should. I have not checked why this read fails, but I don't see any reason why we should stop reading, just because one read() fails at the beginning. http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=82e1a17ecb71233a0ea87d692f695e3cd493d2dc Fix: TCHH/HR payloads are 15 bytes (ToC + 14 bytes of speech data) note: this last fix can be applied to the patches above, rather than merged seperately. any suggestions? andreas From holger at freyther.de Sun Mar 10 17:12:41 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 10 Mar 2013 18:12:41 +0100 Subject: rtp handling for all speech codecs In-Reply-To: <513CA32E.7010401@eversberg.eu> References: <513CA32E.7010401@eversberg.eu> Message-ID: <20130310171241.GI18290@xiaoyu.lan> On Sun, Mar 10, 2013 at 04:13:50PM +0100, jolly wrote: > long time ago i had these patches at a seperate "rtpmux" branch. now i > added them to a new branch (jolly/trx). they are very well tested now, > and i think they should get merged after some review. it is my aim to > support all speech codecs at osmo-nitb (built-in call handling, as well > as MNCC socket interface). these patches are essential for patches that > will follow during next weeks. What is the test setup and what is the result of testing? From holger at freyther.de Sun Mar 10 17:31:07 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 10 Mar 2013 18:31:07 +0100 Subject: rtp handling for all speech codecs In-Reply-To: <513CA32E.7010401@eversberg.eu> References: <513CA32E.7010401@eversberg.eu> Message-ID: <20130310173107.GJ18290@xiaoyu.lan> On Sun, Mar 10, 2013 at 04:13:50PM +0100, jolly wrote: > http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/testing&id=f029472c1e439ee6c2519ce1b67807d4249ab55b * One should increase the version number of the MNCC protocol when adding new commands * callref_keep.. maybe callref_orig or callref_kept * the printf for 32 vs. 33 can be fixed right now * msg_type == GSM_TCHF_FRAME || msg_type == GSM_TCHF_FRAME_EFR... maybe introduce a helper function is_audio_type(msg_type) + if (!trans->conn) { + LOGP(DMNCC, LOGL_NOTICE, "TCH frame for trans without conn\n"); + return 0; + } + if (trans->conn->lchan->type != GSM_LCHAN_TCH_F) { At least with the BSC part it is possible to have subscriber connection with no lchan associated. You might want to add another null check for the lchan here. From andreas at eversberg.eu Mon Mar 11 07:24:10 2013 From: andreas at eversberg.eu (jolly) Date: Mon, 11 Mar 2013 08:24:10 +0100 Subject: rtp handling for all speech codecs In-Reply-To: <20130310173107.GJ18290@xiaoyu.lan> References: <513CA32E.7010401@eversberg.eu> <20130310173107.GJ18290@xiaoyu.lan> Message-ID: <513D869A.2010804@eversberg.eu> Holger Hans Peter Freyther wrote: > * callref_keep.. maybe callref_orig or callref_kept > * the printf for 32 vs. 33 can be fixed right now > * msg_type == GSM_TCHF_FRAME || msg_type == GSM_TCHF_FRAME_EFR... > maybe introduce a helper function is_audio_type(msg_type) > > + if (!trans->conn) { > + LOGP(DMNCC, LOGL_NOTICE, "TCH frame for trans without conn\n"); > + return 0; > + } > + if (trans->conn->lchan->type != GSM_LCHAN_TCH_F) { > > At least with the BSC part it is possible to have subscriber connection > with no lchan associated. You might want to add another null check for > the lchan here. > hi holger, just pushed two patches to jolly/testing branch. regards, andreas From holger at freyther.de Mon Mar 11 00:07:50 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 11 Mar 2013 01:07:50 +0100 Subject: Leak/Double-free handling in SGSN Message-ID: <20130311000750.GN18290@xiaoyu.lan> Hi, I was discussing this crash[1] with Jan at the 29C3 and recently in Iceland. On top of that Katarina pointed me to the best practises[2] of talloc. In general I disagree with them[3] but they provide a nice solution for the SGSN/MSGB ownership issue. Methods that send a msgb should create a new local context and attach it to a global context for all local contexts (so we see them in the leak report). This would probably be done with a helper function in libosmocore. Once the msgb is created, we will steal it into the local context. Then we pass it down the rabbit hole. Once it is reaching the write_queue it is stolen back (or into a write queue context). The initial caller will free his local context. And now there are three options: a.) The msgb has made it into the write_queue. b.) The msgb has been already deleted due to an error c.) The msgb is still in the local context and will be freed. Using the talloc_steal and the local context will make sure we do not leak and do not double free. We can (and should) add a warning to see under which circumstances the msgb has not been freed. I think the implementation of this will be about 10-15 lines of code (probably too optimistic). comments? holger [1] http://openbsc.osmocom.org/trac/ticket/55 [2] http://talloc.samba.org/talloc/doc/html/libtalloc__bestpractices.html [3] Most of our functions only allocate one object. There is no point in having a hierachy of ROOT -> SingleObject. This indirection is wasteful in most cases. From holger at freyther.de Tue Mar 26 20:26:50 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 26 Mar 2013 21:26:50 +0100 Subject: Leak/Double-free handling in SGSN In-Reply-To: <20130311000750.GN18290@xiaoyu.lan> References: <20130311000750.GN18290@xiaoyu.lan> Message-ID: <20130326202650.GA6293@xiaoyu.lan> On Mon, Mar 11, 2013 at 01:07:50AM +0100, Holger Hans Peter Freyther wrote: > Hi, > > I was discussing this crash[1] with Jan at the 29C3 and recently in > Iceland. On top of that Katarina pointed me to the best practises[2] > of talloc. In general I disagree with them[3] but they provide a nice > solution for the SGSN/MSGB ownership issue. Hi, so attached is a proof of concept. This has only been compile tested. In theory the code should now: 1.) Place the msgb in the write_queue when it will be stolen back into the msgb context (it could be moved into a write queue context) 2.) Delete the msgb in case of error on the way down there.. 3.) Catch all and the msgb is still in the local_ctx and we just free it. Please comment. holger -------------- next part -------------- A non-text attachment was scrubbed... Name: libosmocore_steal.diff Type: text/x-diff Size: 736 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sgsn_steal.diff Type: text/x-diff Size: 1171 bytes Desc: not available URL: From holger at freyther.de Tue Mar 12 08:08:21 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 12 Mar 2013 09:08:21 +0100 Subject: lchan->s and integer overflow Message-ID: <20130312080821.GR18290@xiaoyu.lan> Dear Jolly, from a quick look it appears to be that a very long running connection could overflow lchan->s to a negative number. Could you either make this code robust or explain why it is not needed? E.g. if we assume that this happens once per multiframe the counter will overflow within 1.3 hours? holger From andreas at eversberg.eu Tue Mar 12 09:13:01 2013 From: andreas at eversberg.eu (jolly) Date: Tue, 12 Mar 2013 10:13:01 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130312080821.GR18290@xiaoyu.lan> References: <20130312080821.GR18290@xiaoyu.lan> Message-ID: <513EF19D.1070206@eversberg.eu> Holger Hans Peter Freyther wrote: > Dear Jolly, > > from a quick look it appears to be that a very long running connection > could overflow lchan->s to a negative number. Could you either make this > code robust or explain why it is not needed? E.g. if we assume that this > happens once per multiframe the counter will overflow within 1.3 hours? > > holger > hi holger, lchan->s must never raise above btsb->radio_link_timeout. look at the commit: + /* count up radio link counter S */ + lchan->s += 2; + if (lchan->s > btsb->radio_link_timeout) + lchan->s = btsb->radio_link_timeout; if there would be no limit, a loss of link might also take hours until detected. have i overseen something? regards, andreas From holger at freyther.de Tue Mar 12 12:24:44 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 12 Mar 2013 13:24:44 +0100 Subject: lchan->s and integer overflow In-Reply-To: <513EF19D.1070206@eversberg.eu> References: <20130312080821.GR18290@xiaoyu.lan> <513EF19D.1070206@eversberg.eu> Message-ID: <20130312122444.GE17522@xiaoyu.lan> On Tue, Mar 12, 2013 at 10:13:01AM +0100, jolly wrote: dear jolly, > + /* count up radio link counter S */ > + lchan->s += 2; > + if (lchan->s > btsb->radio_link_timeout) > + lchan->s = btsb->radio_link_timeout; that is what I was missing when browsing the code in gtik. I think there is a small glitch the other way around. a.) We get criteria value == 0 through OML (for whatever reason) + btsb->radio_link_timeout = val[1] b.) lchan_activate sets lchan->s == 0 + lchan->s = btsb->radio_link_timeout; c.) lchan->s -= 1 + /* count down radio link counter S */ + lchan->s--; d.) if (lchan->s == 0) Will not be true as the lchan->s is -1. Is it intended that setting a '0' will disable the link failure checking? kind regards holger From holger at freyther.de Wed Mar 13 07:23:07 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 13 Mar 2013 08:23:07 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130312122444.GE17522@xiaoyu.lan> References: <20130312080821.GR18290@xiaoyu.lan> <513EF19D.1070206@eversberg.eu> <20130312122444.GE17522@xiaoyu.lan> Message-ID: <20130313072307.GC17148@xiaoyu.lan> On Tue, Mar 12, 2013 at 01:24:44PM +0100, Holger Hans Peter Freyther wrote: Good Morning, > that is what I was missing when browsing the code in gtik. I think > there is a small glitch the other way around. > > a.) We get criteria value == 0 through OML (for whatever reason) > > + btsb->radio_link_timeout = val[1] > > b.) lchan_activate sets lchan->s == 0 > > + lchan->s = btsb->radio_link_timeout; > > c.) lchan->s -= 1 > > + /* count down radio link counter S */ > + lchan->s--; > > d.) if (lchan->s == 0) > > Will not be true as the lchan->s is -1. Is it intended that setting a > '0' will disable the link failure checking? the easiest way to avoid the problem of the number to leave the range of 0 to radio_link_timeout is to use the OSMO_MAX and OSMO_MIN (now that these macros are fixed). Underflow: lchan->s = OSMO_MAX(lchan->s - 1, 0); Overflow: lchan->s = OSMO_MIN(lchan->s + 2, btsb->radio_link_timeout); E.g. the following code (I only compiled it): diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index df660c5..16375ef 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -684,7 +684,7 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *d /* process radio link timeout coniter S */ if (data_ind->msgUnitParam.u8Size == 0) { /* count down radio link counter S */ - lchan->s--; + lchan->s = OSMO_MAX(lchan->s - 1, 0); DEBUGP(DMEAS, "counting down radio link counter S=%d\n", lchan->s); if (lchan->s == 0) @@ -694,9 +694,7 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *d } if (lchan->s < btsb->radio_link_timeout) { /* count up radio link counter S */ - lchan->s += 2; - if (lchan->s > btsb->radio_link_timeout) - lchan->s = btsb->radio_link_timeout; + lchan->s = OSMO_MIN(lchan->s + 2, btsb->radio_link_timeout); DEBUGP(DMEAS, "counting up radio link counter S=%d\n", lchan->s); } From peter at stuge.se Wed Mar 13 16:02:02 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 13 Mar 2013 17:02:02 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130313072307.GC17148@xiaoyu.lan> References: <20130312080821.GR18290@xiaoyu.lan> <513EF19D.1070206@eversberg.eu> <20130312122444.GE17522@xiaoyu.lan> <20130313072307.GC17148@xiaoyu.lan> Message-ID: <20130313160202.32546.qmail@stuge.se> Holger Hans Peter Freyther wrote: > the easiest way to avoid the problem of the number to leave the range > of 0 to radio_link_timeout is to use the OSMO_MAX and OSMO_MIN (now > that these macros are fixed). > > Underflow: > lchan->s = OSMO_MAX(lchan->s - 1, 0); It avoids the problem, but why is it safe? The mere possibility that the counter can become negative suggests an imbalance somewhere in the code - but I don't know if that's the case, which is why I ask. //Peter From holger at freyther.de Wed Mar 13 16:49:15 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 13 Mar 2013 17:49:15 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130313160202.32546.qmail@stuge.se> References: <20130312080821.GR18290@xiaoyu.lan> <513EF19D.1070206@eversberg.eu> <20130312122444.GE17522@xiaoyu.lan> <20130313072307.GC17148@xiaoyu.lan> <20130313160202.32546.qmail@stuge.se> Message-ID: <20130313164915.GP17148@xiaoyu.lan> On Wed, Mar 13, 2013 at 05:02:02PM +0100, Peter Stuge wrote: > It avoids the problem, but why is it safe? > > The mere possibility that the counter can become negative suggests > an imbalance somewhere in the code - but I don't know if that's the > case, which is why I ask. Exactly, the point is that the current code is broken. And in general using OSMO_MIN/OSMO_MAX is better than hand rolling code. And if a range is from a to b it is better to clamp it on both sides that just one. For this specific issue. I wouldn't mind making the value '0' illegal, GSM 12.21 doesn't specify the legal range and as '0' and '1' will behave the same with the fixed code it does make sense to forbid '0'. Anyway, the current code is broken so Andreas please fix it ASAP. holger From alexander.huemer at xx.vu Tue Mar 12 09:25:09 2013 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Tue, 12 Mar 2013 10:25:09 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130312080821.GR18290@xiaoyu.lan> References: <20130312080821.GR18290@xiaoyu.lan> Message-ID: <20130312092509.GA11450@yade.xx.vu> On Tue, Mar 12, 2013 at 09:08:21AM +0100, Holger Hans Peter Freyther wrote: > from a quick look it appears to be that a very long running connection > could overflow lchan->s to a negative number. Could you either make this > code robust or explain why it is not needed? E.g. if we assume that this > happens once per multiframe the counter will overflow within 1.3 > hours? clang lately got a nice feature for integer over/under-flow detection[1] during runtime, but of course it makes the resulting code extremely slow. I am not sure if it is usable in this case. Kind regards, -Alexander Huemer [1] http://blog.regehr.org/archives/905 From holger at freyther.de Tue Mar 12 12:42:25 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 12 Mar 2013 13:42:25 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130312092509.GA11450@yade.xx.vu> References: <20130312080821.GR18290@xiaoyu.lan> <20130312092509.GA11450@yade.xx.vu> Message-ID: <20130312124225.GF17522@xiaoyu.lan> On Tue, Mar 12, 2013 at 10:25:09AM +0100, Alexander Huemer wrote: > clang lately got a nice feature for integer over/under-flow detection[1] > during runtime, but of course it makes the resulting code extremely > slow. I am not sure if it is usable in this case. Ah nice. I started to use clang3.3 over the weekend for -fsanitize=address, didn't know about the integer instrumentation. thank you for the pointer holger From andreas at eversberg.eu Wed Mar 13 16:47:26 2013 From: andreas at eversberg.eu (jolly) Date: Wed, 13 Mar 2013 17:47:26 +0100 Subject: lchan->s and integer overflow Message-ID: <5140AD9E.2070905@eversberg.eu> hi, (somehow i already sent this patch to the list. but it seems to be gone.) this patch should fix the underrun problem. it will only send radio link failure to bsc one and then stop processing timeout counter. regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-Stop-RADIO-LINK-TIMEOUT-couter-S-from-counting-i.patch URL: From jolly at eversberg.eu Wed Mar 13 09:26:48 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Wed, 13 Mar 2013 10:26:48 +0100 Subject: [PATCH] Fix: Stop RADIO LINK TIMEOUT couter S from counting, if it has reached 0 Message-ID: In case that the counter S reached 0 (or have been initialized with 0 value at start of lchan), it will stay 0. Subsequent received good and bad SACCH frames must not cause to trigger radio link failure again. Once the BSC has been indicated about link failure, it will close channel. --- src/osmo-bts-sysmo/l1_if.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index df660c5..5728df0 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -681,8 +681,11 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i switch (data_ind->sapi) { case GsmL1_Sapi_Sacch: - /* process radio link timeout coniter S */ + /* process radio link timeout counter S */ if (data_ind->msgUnitParam.u8Size == 0) { + /* if link loss criterion already reached */ + if (lchan->s == 0) + break; /* count down radio link counter S */ lchan->s--; DEBUGP(DMEAS, "counting down radio link counter S=%d\n", @@ -692,7 +695,7 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i RSL_ERR_RADIO_LINK_FAIL); break; } - if (lchan->s < btsb->radio_link_timeout) { + if (lchan->s > 0 && lchan->s < btsb->radio_link_timeout) { /* count up radio link counter S */ lchan->s += 2; if (lchan->s > btsb->radio_link_timeout) -- 1.7.3.4 --------------030009070902010606020306-- From holger at freyther.de Wed Mar 13 21:30:31 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 13 Mar 2013 22:30:31 +0100 Subject: lchan->s and integer overflow In-Reply-To: <5140AD9E.2070905@eversberg.eu> References: <5140AD9E.2070905@eversberg.eu> Message-ID: <20130313213031.GR17148@xiaoyu.lan> On Wed, Mar 13, 2013 at 05:47:26PM +0100, jolly wrote: Dear jolly, > this patch should fix the underrun problem. it will only send radio link > failure to bsc one and then stop processing timeout counter. is the semantic of btsb->link_time_out == 0 == disabled something from the specification or something the implementor has decided)? Either way is fine, I would just have the commit message reflect that. thank you for the fix kind regards holger PS: So before and after the patch it appears possible that the connection failure is sent more than once? (e.g. if the BSC doesn't release the channel within 3 SACCH frames?). Is that intended? In both cases it is fine, it is just that the commit message should reflect the decision you took. From andreas at eversberg.eu Thu Mar 14 06:47:25 2013 From: andreas at eversberg.eu (jolly) Date: Thu, 14 Mar 2013 07:47:25 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130313213031.GR17148@xiaoyu.lan> References: <5140AD9E.2070905@eversberg.eu> <20130313213031.GR17148@xiaoyu.lan> Message-ID: <5141727D.6040006@eversberg.eu> Holger Hans Peter Freyther wrote: > I would just have the commit message reflect that. > hi holger, i just added the new commit message. also i do a check, if the received value from BSC is correct. regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-Stop-RADIO-LINK-TIMEOUT-couter-S-from-counting-i.patch URL: From jolly at eversberg.eu Thu Mar 14 06:25:56 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Thu, 14 Mar 2013 07:25:56 +0100 Subject: [PATCH] Fix: Stop RADIO LINK TIMEOUT couter S from counting, if it has reached 0 Message-ID: In case that the counter S reached 0, it will stay 0. Subsequent received good and bad SACCH frames must not cause to trigger radio link failure again. Once the BSC has been indicated about link failure, it will release channel. This patch will ensure that the link failure is indicated only once. But even if the link failure would be sent multiple times, the BSC should ignore it. The BSC releases the channel and may only reuse it after confirm from BTS. (There cannot be any link failure indications after confirm of channel release.) The minimum timeout value is 4, as defined in TS 05.08, so if the BSC sends an attribute with a value < 4, this (wrong) value is ignored and the default value of 32 is used. --- src/common/oml.c | 6 +++--- src/osmo-bts-sysmo/l1_if.c | 7 +++++-- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/common/oml.c b/src/common/oml.c index 4e2dead..afedefd 100644 --- a/src/common/oml.c +++ b/src/common/oml.c @@ -447,10 +447,10 @@ static int oml_rx_set_bts_attr(struct gsm_bts *bts, struct msgb *msg) /* 9.4.14 Connection Failure Criterion */ if (TLVP_PRESENT(&tp, NM_ATT_CONN_FAIL_CRIT) && - (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) >= 2) && - *TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT) == 0x01) { + (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) >= 2)) { const uint8_t *val = TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT); - btsb->radio_link_timeout = val[1]; + if (val[0] == 0x01 && val[1] >= 4) + btsb->radio_link_timeout = val[1]; } /* if val[0] != 0x01: can be 'operator dependent' and needs to * be parsed by bts driver */ diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index df660c5..5728df0 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -681,8 +681,11 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i switch (data_ind->sapi) { case GsmL1_Sapi_Sacch: - /* process radio link timeout coniter S */ + /* process radio link timeout counter S */ if (data_ind->msgUnitParam.u8Size == 0) { + /* if link loss criterion already reached */ + if (lchan->s == 0) + break; /* count down radio link counter S */ lchan->s--; DEBUGP(DMEAS, "counting down radio link counter S=%d\n", @@ -692,7 +695,7 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i RSL_ERR_RADIO_LINK_FAIL); break; } - if (lchan->s < btsb->radio_link_timeout) { + if (lchan->s > 0 && lchan->s < btsb->radio_link_timeout) { /* count up radio link counter S */ lchan->s += 2; if (lchan->s > btsb->radio_link_timeout) -- 1.7.3.4 --------------050806080900000401040704-- From holger at freyther.de Thu Mar 14 08:06:45 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 14 Mar 2013 09:06:45 +0100 Subject: lchan->s and integer overflow In-Reply-To: <5141727D.6040006@eversberg.eu> References: <5140AD9E.2070905@eversberg.eu> <20130313213031.GR17148@xiaoyu.lan> <5141727D.6040006@eversberg.eu> Message-ID: <20130314080645.GV17148@xiaoyu.lan> On Thu, Mar 14, 2013 at 07:47:25AM +0100, jolly wrote: > Holger Hans Peter Freyther wrote: Hi, this must be frustrating for you, but it really is for me as well. I take absolutely no joy in pointing out these issues. I would prefer to work on my code but it is something that will bite us in a commercial setup so I a have to be the PITA here. > /* 9.4.14 Connection Failure Criterion */ > if (TLVP_PRESENT(&tp, NM_ATT_CONN_FAIL_CRIT) && > - (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) >= 2) && > - *TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT) == 0x01) { > + (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) >= 2)) { > const uint8_t *val = TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT); > - btsb->radio_link_timeout = val[1]; > + if (val[0] == 0x01 && val[1] >= 4) > + btsb->radio_link_timeout = val[1]; > } Here you point out that the range of 4 to UINT8_MAX is coming from the specification. Which is very good. The way it is done is a violation of the principle of least surprise though. If a BSC sends the value '2' it doesn't make sense that '32' is used. The configurator/implementor certainly wanted to have a low value. IMHO the right thing to do is to NACK the set bts attributes with a descriptive error message. The same goes for the conn fail crit being present but not of the type we support. holger PS: the lchan->s handling is fine. The switch/case has grown to a state I would move the link failure handling to a new helper function though, this way one could even write a unit test for the handling... > switch (data_ind->sapi) { > case GsmL1_Sapi_Sacch: > - /* process radio link timeout coniter S */ > + /* process radio link timeout counter S */ From andreas at eversberg.eu Thu Mar 14 10:45:42 2013 From: andreas at eversberg.eu (jolly) Date: Thu, 14 Mar 2013 11:45:42 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130314080645.GV17148@xiaoyu.lan> References: <5140AD9E.2070905@eversberg.eu> <20130313213031.GR17148@xiaoyu.lan> <5141727D.6040006@eversberg.eu> <20130314080645.GV17148@xiaoyu.lan> Message-ID: <5141AA56.1020102@eversberg.eu> Holger Hans Peter Freyther wrote: > Here you point out that the range of 4 to UINT8_MAX is coming from the > specification. Which is very good. The way it is done is a violation of > the principle of least surprise though. If a BSC sends the value '2' it > doesn't make sense that '32' is used. The configurator/implementor > certainly wanted to have a low value. > > IMHO the right thing to do is to NACK the set bts attributes with > a descriptive error message. The same goes for the conn fail crit > being present but not of the type we support. > hi holger, the range is actually 4..64, so i send a NACK now, if the given attribute is not is that range. also the counting of S value is moved to a seperate function. check out the attached patch. regards, andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-Stop-RADIO-LINK-TIMEOUT-couter-S-from-counting-i.patch URL: From jolly at eversberg.eu Thu Mar 14 10:38:11 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Thu, 14 Mar 2013 11:38:11 +0100 Subject: [PATCH] Fix: Stop RADIO LINK TIMEOUT couter S from counting, if it has reached 0 Message-ID: In case that the counter S reached 0, it will stay 0. Subsequent received good and bad SACCH frames must not cause to trigger radio link failure again. Once the BSC has been indicated about link failure, it will release channel. The counting of S has been moved to a seperate function. This patch will ensure that the link failure is indicated only once. But even if the link failure would be sent multiple times, the BSC should ignore it. The BSC releases the channel and may only reuse it after confirm from BTS. (There cannot be any link failure indications after confirm of channel release.) The allowed timeout value range is 4..64, as defined in TS 05.08, so if the BSC sends an attribute with value out of range or other failure criterion, the Set BTS Attributes message is NACKed. --- src/common/oml.c | 12 ++++++++-- src/osmo-bts-sysmo/l1_if.c | 50 +++++++++++++++++++++++++++---------------- 2 files changed, 40 insertions(+), 22 deletions(-) diff --git a/src/common/oml.c b/src/common/oml.c index 4e2dead..bf90ff1 100644 --- a/src/common/oml.c +++ b/src/common/oml.c @@ -446,10 +446,16 @@ static int oml_rx_set_bts_attr(struct gsm_bts *bts, struct msgb *msg) btsb->interference.intave = *TLVP_VAL(&tp, NM_ATT_INTAVE_PARAM); /* 9.4.14 Connection Failure Criterion */ - if (TLVP_PRESENT(&tp, NM_ATT_CONN_FAIL_CRIT) && - (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) >= 2) && - *TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT) == 0x01) { + if (TLVP_PRESENT(&tp, NM_ATT_CONN_FAIL_CRIT)) { const uint8_t *val = TLVP_VAL(&tp, NM_ATT_CONN_FAIL_CRIT); + + if (TLVP_LEN(&tp, NM_ATT_CONN_FAIL_CRIT) < 2 + || val[0] != 0x01 || val[1] < 4 || val[1] > 64) { + LOGP(DOML, LOGL_NOTICE, "Given Conn. Failure Criterion " + "not supported. Please use critetion 0x01 with " + "RADIO_LINK_TIMEOUT value of 4..64\n"); + return oml_fom_ack_nack(msg, NM_NACK_PARAM_RANGE); + } btsb->radio_link_timeout = val[1]; } /* if val[0] != 0x01: can be 'operator dependent' and needs to diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index df660c5..bdba4c2 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -647,11 +647,39 @@ static int process_meas_res(struct gsm_lchan *lchan, GsmL1_MeasParam_t *m) return lchan_new_ul_meas(lchan, &ulm); } +/* process radio link timeout counter S */ +static void radio_link_timeout(struct gsm_lchan *lchan, int bad_frame) +{ + struct gsm_bts_role_bts *btsb = lchan->ts->trx->bts->role; + + /* if link loss criterion already reached */ + if (lchan->s == 0) + return; + + if (bad_frame) { + /* count down radio link counter S */ + lchan->s--; + DEBUGP(DMEAS, "counting down radio link counter S=%d\n", + lchan->s); + if (lchan->s == 0) + rsl_tx_conn_fail(lchan, RSL_ERR_RADIO_LINK_FAIL); + return; + } + + if (lchan->s < btsb->radio_link_timeout) { + /* count up radio link counter S */ + lchan->s += 2; + if (lchan->s > btsb->radio_link_timeout) + lchan->s = btsb->radio_link_timeout; + DEBUGP(DMEAS, "counting up radio link counter S=%d\n", + lchan->s); + } +} + static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_ind, struct msgb *l1p_msg) { struct gsm_bts_trx *trx = fl1->priv; - struct gsm_bts_role_bts *btsb = trx->bts->role; struct osmo_phsap_prim pp; struct gsm_lchan *lchan; struct lapdm_entity *le; @@ -681,25 +709,9 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i switch (data_ind->sapi) { case GsmL1_Sapi_Sacch: - /* process radio link timeout coniter S */ - if (data_ind->msgUnitParam.u8Size == 0) { - /* count down radio link counter S */ - lchan->s--; - DEBUGP(DMEAS, "counting down radio link counter S=%d\n", - lchan->s); - if (lchan->s == 0) - rsl_tx_conn_fail(lchan, - RSL_ERR_RADIO_LINK_FAIL); + radio_link_timeout(lchan, (data_ind->msgUnitParam.u8Size == 0)); + if (data_ind->msgUnitParam.u8Size == 0) break; - } - if (lchan->s < btsb->radio_link_timeout) { - /* count up radio link counter S */ - lchan->s += 2; - if (lchan->s > btsb->radio_link_timeout) - lchan->s = btsb->radio_link_timeout; - DEBUGP(DMEAS, "counting up radio link counter S=%d\n", - lchan->s); - } /* save the SACCH L1 header in the lchan struct for RSL MEAS RES */ if (data_ind->msgUnitParam.u8Size < 2) { LOGP(DL1C, LOGL_NOTICE, "SACCH with size %u<2 !?!\n", -- 1.7.3.4 --------------050705040601090706090209-- From holger at freyther.de Fri Mar 15 20:17:34 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 15 Mar 2013 21:17:34 +0100 Subject: lchan->s and integer overflow In-Reply-To: <5141AA56.1020102@eversberg.eu> References: <5140AD9E.2070905@eversberg.eu> <20130313213031.GR17148@xiaoyu.lan> <5141727D.6040006@eversberg.eu> <20130314080645.GV17148@xiaoyu.lan> <5141AA56.1020102@eversberg.eu> Message-ID: <20130315201734.GJ17148@xiaoyu.lan> On Thu, Mar 14, 2013 at 11:45:42AM +0100, jolly wrote: > the range is actually 4..64, so i send a NACK now, if the given > attribute is not is that range. also the counting of S value is moved to > a seperate function. check out the attached patch. thank you. this looks good. feel free to push it. holger From andreas at eversberg.eu Fri Mar 15 20:46:09 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Fri, 15 Mar 2013 21:46:09 +0100 Subject: lchan->s and integer overflow In-Reply-To: <20130315201734.GJ17148@xiaoyu.lan> References: <5140AD9E.2070905@eversberg.eu> <20130313213031.GR17148@xiaoyu.lan> <5141727D.6040006@eversberg.eu> <20130314080645.GV17148@xiaoyu.lan> <5141AA56.1020102@eversberg.eu> <20130315201734.GJ17148@xiaoyu.lan> Message-ID: <51438891.1020805@eversberg.eu> Holger Hans Peter Freyther wrote: > thank you. this looks good. feel free to push it. ok, pushed! From kat.obsc at gmail.com Tue Mar 12 10:21:44 2013 From: kat.obsc at gmail.com (Katerina Barone-Adesi) Date: Tue, 12 Mar 2013 10:21:44 +0000 Subject: [PATCH] Refactored tests to not ignore stderr. Message-ID: <1363083704-10714-1-git-send-email-kat.obsc@gmail.com> It's probably worth checking if the ussd stderr output is correct. --- tests/lapd/lapd_test.err | 4 ++++ tests/testsuite.at | 39 ++++++++++++++++++++++++++------------- tests/timer/timer_test.err | 6 ++++++ tests/ussd/ussd_test.err | 21 +++++++++++++++++++++ 4 files changed, 57 insertions(+), 13 deletions(-) create mode 100644 tests/lapd/lapd_test.err create mode 100644 tests/timer/timer_test.err create mode 100644 tests/ussd/ussd_test.err diff --git a/tests/lapd/lapd_test.err b/tests/lapd/lapd_test.err new file mode 100644 index 0000000..55bbd68 --- /dev/null +++ b/tests/lapd/lapd_test.err @@ -0,0 +1,4 @@ +<0001> lapd_core.c:886 Store content res. +<0001> lapd_core.c:1735 writing an empty message is not possible. +<0001> lapdm.c:1081 ((nil)) RLL Message 'REL_REQ' received without LAPDm context. (sapi 0) + \ No newline at end of file diff --git a/tests/testsuite.at b/tests/testsuite.at index 21fad1d..dc56517 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -6,7 +6,8 @@ AT_BANNER([Regression tests.]) AT_SETUP([a5]) AT_KEYWORDS([a5]) cat $abs_srcdir/a5/a5_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/a5/a5_test], [], [expout]) +cat $abs_srcdir/a5/a5_test.err > experr +AT_CHECK([$abs_top_builddir/tests/a5/a5_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([bssgp-fc]) @@ -19,13 +20,15 @@ AT_CLEANUP AT_SETUP([bits]) AT_KEYWORDS([bits]) cat $abs_srcdir/bits/bitrev_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/bits/bitrev_test], [], [expout]) +cat $abs_srcdir/bits/bitrev_test.err > experr +AT_CHECK([$abs_top_builddir/tests/bits/bitrev_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([conv]) AT_KEYWORDS([conv]) cat $abs_srcdir/conv/conv_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/conv/conv_test], [], [expout]) +cat $abs_srcdir/conv/conv_test.err > experr +AT_CHECK([$abs_top_builddir/tests/conv/conv_test], [], [expout], [experr]) AT_CLEANUP if ENABLE_MSGFILE @@ -33,56 +36,65 @@ AT_SETUP([msgfile]) AT_KEYWORDS([msgfile]) cp $abs_srcdir/msgfile/msgconfig.cfg . cat $abs_srcdir/msgfile/msgfile_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/msgfile/msgfile_test], [], [expout]) +cat $abs_srcdir/msgfile/msgfile_test.err > experr +AT_CHECK([$abs_top_builddir/tests/msgfile/msgfile_test], [], [expout], [experr]) AT_CLEANUP endif AT_SETUP([sms]) AT_KEYWORDS([sms]) cat $abs_srcdir/sms/sms_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/sms/sms_test], [], [expout]) +cat $abs_srcdir/sms/sms_test.err > experr +AT_CHECK([$abs_top_builddir/tests/sms/sms_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([smscb]) AT_KEYWORDS([smscb]) cat $abs_srcdir/smscb/smscb_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/smscb/smscb_test], [], [expout]) +cat $abs_srcdir/smscb/smscb_test.err > experr +AT_CHECK([$abs_top_builddir/tests/smscb/smscb_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([timer]) AT_KEYWORDS([timer]) cat $abs_srcdir/timer/timer_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/timer/timer_test -s 5], [], [expout], [ignore]) +cat $abs_srcdir/timer/timer_test.err > experr +AT_CHECK([$abs_top_builddir/tests/timer/timer_test -s 5], [], [expout], [experr]) AT_CLEANUP AT_SETUP([ussd]) AT_KEYWORDS([ussd]) cat $abs_srcdir/ussd/ussd_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/ussd/ussd_test], [], [expout], [ignore]) +cat $abs_srcdir/ussd/ussd_test.err > experr +AT_CHECK([$abs_top_builddir/tests/ussd/ussd_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([auth]) AT_KEYWORDS([auth]) cat $abs_srcdir/auth/milenage_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/auth/milenage_test], [], [expout], [ignore]) +cat $abs_srcdir/auth/milenage_test.err > experr +AT_CHECK([$abs_top_builddir/tests/auth/milenage_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([lapd]) AT_KEYWORDS([lapd]) cat $abs_srcdir/lapd/lapd_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/lapd/lapd_test], [], [expout], [ignore]) +cat $abs_srcdir/lapd/lapd_test.err > experr +AT_CHECK([$abs_top_builddir/tests/lapd/lapd_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([gsm0808]) AT_KEYWORDS([gsm0808]) cat $abs_srcdir/gsm0808/gsm0808_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/gsm0808/gsm0808_test], [], [expout], [ignore]) +cat $abs_srcdir/gsm0808/gsm0808_test.err > experr +AT_CHECK([$abs_top_builddir/tests/gsm0808/gsm0808_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([gsm0408]) AT_KEYWORDS([gsm0408]) cat $abs_srcdir/gsm0408/gsm0408_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/gsm0408/gsm0408_test], [], [expout], [ignore]) +cat $abs_srcdir/gsm0408/gsm0408_test.err > experr +AT_CHECK([$abs_top_builddir/tests/gsm0408/gsm0408_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([logging]) @@ -110,5 +122,6 @@ AT_CLEANUP AT_SETUP([strrb]) AT_KEYWORDS([strrb]) cat $abs_srcdir/strrb/strrb_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/strrb/strrb_test], [], [expout], [ignore]) +cat $abs_srcdir/strrb/strrb_test.err > experr +AT_CHECK([$abs_top_builddir/tests/strrb/strrb_test], [], [expout], [experr]) AT_CLEANUP diff --git a/tests/timer/timer_test.err b/tests/timer/timer_test.err new file mode 100644 index 0000000..946bf49 --- /dev/null +++ b/tests/timer/timer_test.err @@ -0,0 +1,6 @@ +added 1 timers in step 0 (expired=0) +added 2 timers in step 1 (expired=0) +added 4 timers in step 2 (expired=0) +added 8 timers in step 3 (expired=0) +added 16 timers in step 4 (expired=3) +Main timer has finished, please, wait a bit for the final report. diff --git a/tests/ussd/ussd_test.err b/tests/ussd/ussd_test.err new file mode 100644 index 0000000..774a357 --- /dev/null +++ b/tests/ussd/ussd_test.err @@ -0,0 +1,21 @@ +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. +<0000> gsm0480.c:299 Component does not fit. + \ No newline at end of file -- 1.8.1.4 From holger at freyther.de Tue Mar 12 12:43:56 2013 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 12 Mar 2013 13:43:56 +0100 Subject: [PATCH] Refactored tests to not ignore stderr. In-Reply-To: <1363083704-10714-1-git-send-email-kat.obsc@gmail.com> References: <1363083704-10714-1-git-send-email-kat.obsc@gmail.com> Message-ID: <20130312124356.GG17522@xiaoyu.lan> On Tue, Mar 12, 2013 at 10:21:44AM +0000, Katerina Barone-Adesi wrote: > +added 1 timers in step 0 (expired=0) > +added 2 timers in step 1 (expired=0) > +added 4 timers in step 2 (expired=0) > +added 8 timers in step 3 (expired=0) > +added 16 timers in step 4 (expired=3) > +Main timer has finished, please, wait a bit for the final report. this output can vary depending on the workload of the machine. This would make the test flaky. I am not sure what to do about it. If we change the output we might lose a valuable debug help. holger From kat.obsc at gmail.com Tue Mar 12 10:46:24 2013 From: kat.obsc at gmail.com (Katerina Barone-Adesi) Date: Tue, 12 Mar 2013 10:46:24 +0000 Subject: [PATCH] Modified openbsc tests to not ignore stderr Message-ID: <1363085184-11474-1-git-send-email-kat.obsc@gmail.com> The mgcp, bsc-nat, and abis tests are now rather fragile. It's probably worth checking that everything in their .err files should actually be there and is expected. --- openbsc/tests/abis/abis_test.err | 13 +++++++++++++ openbsc/tests/bsc-nat/bsc_nat_test.err | 6 ++++++ openbsc/tests/mgcp/mgcp_test.err | 25 +++++++++++++++++++++++++ openbsc/tests/testsuite.at | 24 ++++++++++++++++-------- 4 files changed, 60 insertions(+), 8 deletions(-) create mode 100644 openbsc/tests/abis/abis_test.err create mode 100644 openbsc/tests/bsc-nat/bsc_nat_test.err create mode 100644 openbsc/tests/mgcp/mgcp_test.err diff --git a/openbsc/tests/abis/abis_test.err b/openbsc/tests/abis/abis_test.err new file mode 100644 index 0000000..56a86f3 --- /dev/null +++ b/openbsc/tests/abis/abis_test.err @@ -0,0 +1,13 @@ +<0005> abis_nm.c:410 FILE_VERSION attribute identifier not found! +<0005> abis_nm.c:410 FILE_VERSION attribute identifier not found! +<0005> abis_nm.c:410 FILE_VERSION attribute identifier not found! +<0005> abis_nm.c:410 FILE_VERSION attribute identifier not found! +<0005> abis_nm.c:410 FILE_VERSION attribute identifier not found! +<0005> abis_nm.c:410 FILE_VERSION attribute identifier not found! +<0005> abis_nm.c:398 FILE_ID attribute identifier not found! +<0005> abis_nm.c:398 FILE_ID attribute identifier not found! +<0005> abis_nm.c:398 FILE_ID attribute identifier not found! +<0005> abis_nm.c:398 FILE_ID attribute identifier not found! +<0005> abis_nm.c:398 FILE_ID attribute identifier not found! +<0005> abis_nm.c:398 FILE_ID attribute identifier not found! + \ No newline at end of file diff --git a/openbsc/tests/bsc-nat/bsc_nat_test.err b/openbsc/tests/bsc-nat/bsc_nat_test.err new file mode 100644 index 0000000..2ba39cb --- /dev/null +++ b/openbsc/tests/bsc-nat/bsc_nat_test.err @@ -0,0 +1,6 @@ +<000b> ../../src/osmo-bsc_nat/bsc_mgcp_utils.c:317 Failed to find the connection. +<0014> ../../src/osmo-bsc_nat/bsc_nat_filter.c:189 Filtering 244052130421059 by nat imsi_deny on bsc nr: 0. +<0014> ../../src/osmo-bsc_nat/bsc_nat_filter.c:189 Filtering 244052130421059 by nat imsi_deny on bsc nr: 0. +<0014> ../../src/osmo-bsc_nat/bsc_nat_filter.c:178 Filtering 244052130421059 by imsi_deny on bsc nr: 0. +<0014> ../../src/osmo-bsc_nat/bsc_nat_filter.c:78 Duplicate entry for IMSI(12123124) +full talloc report on 'sccp' (total 1 bytes in 1 blocks) diff --git a/openbsc/tests/mgcp/mgcp_test.err b/openbsc/tests/mgcp/mgcp_test.err new file mode 100644 index 0000000..3ce9a3c --- /dev/null +++ b/openbsc/tests/mgcp/mgcp_test.err @@ -0,0 +1,25 @@ +<000b> mgcp_protocol.c:354 Unable to find Endpoint `ds/e1-2/1 at 172.16.6.66' +<000b> mgcp_protocol.c:354 Unable to find Endpoint `ds/e1-3/1 at 172.16.6.66' +<000b> mgcp_protocol.c:645 Endpoint is not holding a connection. 0x2 +<000b> mgcp_protocol.c:537 Unhandled option: 'v'/118 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'c'/99 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'm'/109 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'a'/97 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'v'/118 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'c'/99 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'm'/109 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'a'/97 on 0x1 +<000b> mgcp_protocol.c:228 msg too short: 2 +<000b> mgcp_protocol.c:377 MGCP status line too short. +<000b> mgcp_protocol.c:377 MGCP status line too short. +<000b> mgcp_protocol.c:377 MGCP status line too short. +<000b> mgcp_protocol.c:377 MGCP status line too short. +<000b> mgcp_protocol.c:537 Unhandled option: 'v'/118 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'c'/99 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'm'/109 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'a'/97 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'v'/118 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'c'/99 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'm'/109 on 0x1 +<000b> mgcp_protocol.c:537 Unhandled option: 'a'/97 on 0x1 + \ No newline at end of file diff --git a/openbsc/tests/testsuite.at b/openbsc/tests/testsuite.at index e649f03..b5b972e 100644 --- a/openbsc/tests/testsuite.at +++ b/openbsc/tests/testsuite.at @@ -4,31 +4,36 @@ AT_BANNER([Regression tests.]) AT_SETUP([gsm0408]) AT_KEYWORDS([gsm0408]) cat $abs_srcdir/gsm0408/gsm0408_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/gsm0408/gsm0408_test], [], [expout], [ignore]) +cat $abs_srcdir/gsm0408/gsm0408_test.err > experr +AT_CHECK([$abs_top_builddir/tests/gsm0408/gsm0408_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([db]) AT_KEYWORDS([db]) cat $abs_srcdir/db/db_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/db/db_test], [], [expout], [ignore]) +cat $abs_srcdir/db/db_test.err > experr +AT_CHECK([$abs_top_builddir/tests/db/db_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([channel]) AT_KEYWORDS([channel]) cat $abs_srcdir/channel/channel_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/channel/channel_test], [], [expout], [ignore]) +cat $abs_srcdir/channel/channel_test.err > experr +AT_CHECK([$abs_top_builddir/tests/channel/channel_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([mgcp]) AT_KEYWORDS([mgcp]) cat $abs_srcdir/mgcp/mgcp_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/mgcp/mgcp_test], [], [expout], [ignore]) +cat $abs_srcdir/mgcp/mgcp_test.err > experr +AT_CHECK([$abs_top_builddir/tests/mgcp/mgcp_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([gprs]) AT_KEYWORDS([gprs]) cat $abs_srcdir/gprs/gprs_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/gprs/gprs_test], [], [expout], [ignore]) +cat $abs_srcdir/gprs/gprs_test.err > experr +AT_CHECK([$abs_top_builddir/tests/gprs/gprs_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([bsc-nat]) @@ -37,17 +42,20 @@ AT_CHECK([test "$enable_nat_test" != no || exit 77]) cp $abs_srcdir/bsc-nat/barr.cfg . cp $abs_srcdir/bsc-nat/barr_dup.cfg . cat $abs_srcdir/bsc-nat/bsc_nat_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/bsc-nat/bsc_nat_test], [], [expout], [ignore]) +cat $abs_srcdir/bsc-nat/bsc_nat_test.err > experr +AT_CHECK([$abs_top_builddir/tests/bsc-nat/bsc_nat_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([si]) AT_KEYWORDS([si]) cat $abs_srcdir/si/si_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/si/si_test], [], [expout], [ignore]) +cat $abs_srcdir/si/si_test.err > experr +AT_CHECK([$abs_top_builddir/tests/si/si_test], [], [expout], [experr]) AT_CLEANUP AT_SETUP([abis]) AT_KEYWORDS([abis]) cat $abs_srcdir/abis/abis_test.ok > expout -AT_CHECK([$abs_top_builddir/tests/abis/abis_test], [], [expout], [ignore]) +cat $abs_srcdir/abis/abis_test.err > experr +AT_CHECK([$abs_top_builddir/tests/abis/abis_test], [], [expout], [experr]) AT_CLEANUP -- 1.8.1.4 From andreas at eversberg.eu Wed Mar 13 15:30:04 2013 From: andreas at eversberg.eu (jolly) Date: Wed, 13 Mar 2013 16:30:04 +0100 Subject: [osmo-bts] new cleaned version of l1sap slit of osmo-bts. Message-ID: <51409B7C.2070209@eversberg.eu> hi harald, i just pushed a new branch with the cleaned up l1sap split. regards, andreas From Philip.Schuetz at rwth-aachen.de Tue Mar 19 08:01:51 2013 From: Philip.Schuetz at rwth-aachen.de (=?iso-8859-1?Q?=22Philip_Kai_Stefan_Sch=FCtz=22?=) Date: Tue, 19 Mar 2013 09:01:51 +0100 Subject: Calls to non-existent extensions Message-ID: Hello, I am using a setup consisting of an ip.access nanoBTS (165) and the sysmocom sysmoBSC for detecting and analysing malware on mobile phones. So far, I sniff the IP traffic at the Uplink-Interface and the traffic between the nanoBTS and the sysmoBSC for SMS. Now I want to extend my project and detect calls. When analysing a pcap file I can easily find a call that has been connected by the BSC in the RSL protocol. However, if the call could not be connected (because the dialed number is not in the HLR), I can not find any sign of a connection between BTS and BSC whatsoever. When analysing a new malware, I don't know the number the malware dials, so I can't give the extension to a second phone. I thought the BTS transferred the dialed number to the BSC, the BSC knows the extension doesn't exist and refuses the connection. In which protocol can I find the attempt to connect and the dialed number? Another solution I thought of was using Asterisk with a softphone that all calls are routed to. Is that possible? Is there any way to use the sysmoBSC with an Asterisk server? I found lots of tutorials on how to use openBSC with Asterisk, but nothing on osmo-nitb+Asterisk and the sysmoBSC. Asterisk would run on a second machine connected to the sysmoBSC of course. Regards, Philip From dmi3sol at gmail.com Sat Mar 23 09:09:39 2013 From: dmi3sol at gmail.com (Dmitri Soloviev) Date: Sat, 23 Mar 2013 13:09:39 +0400 Subject: A scalabe solution to connect ip-based BSS to legacy GSM networks Message-ID: Hi we've got several requests to extend existing GSM networks with our radio equipment, where ip transport is appreciated. Please take a look at my vision of interfacing A-over-ip to a legacy GSM A-interface. Building blocks: 1. OpenBSC with ip.access-compatible A-over-ip interface 2. MGCP-controlled transcoder, built with Sangoma D-series cards. Can be assumed as a shared resource, available for several BSC instances. http://www.sangoma.com/assets/docs/datasheets/en/d500.pdf 3. TelscaleSS7card - a stand-alone signaling and media gateway, with 2 E1 and 2 Ethernet interfaces, running embedded linux on board. It converts A-over-ip to A-interface, acts as MGCP call agent for BTSs, transcoders and other telscaleSS7cards. A card is implemented in PCI form factor, but bus is used just to provide power supply. In other words, a card can act either as a combined SG+MG, converting A-over-ip into SS7 and RTP into E1 timeslot, or just a MG, converting RTP into E1, without any impact on the host system. When a [signaling gateway + call agent] detects ASSIGNMENT_REQUEST or HANDOVER_REQUEST, it stores cic value. As soon as ASSIGNMENT_COMPLETE or HO_REQ_ACK is detected, it builds RTP chain that unites BTS<->transcoder<->media_gateway. The chain is broken after the call is finished. Depending on the chosen cross plane, 4U 19" industrial PC can carry several BSC instances with transcoding, serving about 20 E1 interfaces (ea about 80 ARFCNs). Performance requirements for industrial PC cards are also negligible: computer will run OpenBSC and configure transcoder cards, being controlled by means of MGCP. Best Regards, Dmitri -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi3sol at gmail.com Mon Mar 25 09:34:29 2013 From: dmi3sol at gmail.com (Dmitri Soloviev) Date: Mon, 25 Mar 2013 13:34:29 +0400 Subject: A scalabe solution to connect ip-based BSS to legacy GSM networks In-Reply-To: References: Message-ID: This is just a proposal how a scalable cost-effective solution can look like. It is not implemented yet, but the goal is to work out a right approach. I developed quite similar things in 2003, when I interfaced ip.access BSC to S-12 and AXE-10. This is a piece of operator infrastructure, desired to be sold to MNO. In Russia it also assumes certification procedure, held by authorized center. On Mon, Mar 25, 2013 at 1:16 PM, John Wu wrote: > Hi Dmitri, > Have you developed the solution connect private GSM network to operator > core network? > But this should be allowed by the local operator, right? > > > On Sat, Mar 23, 2013 at 5:09 PM, Dmitri Soloviev wrote: > >> Hi >> >> we've got several requests to extend existing GSM networks with our radio >> equipment, where ip transport is appreciated. >> >> Please take a look at my vision of interfacing A-over-ip to a legacy GSM >> A-interface. >> >> Building blocks: >> >> 1. OpenBSC with ip.access-compatible A-over-ip interface >> >> 2. MGCP-controlled transcoder, built with Sangoma D-series cards. Can be >> assumed as a shared resource, available for several BSC instances. >> http://www.sangoma.com/assets/docs/datasheets/en/d500.pdf >> >> 3. TelscaleSS7card - a stand-alone signaling and media gateway, with 2 E1 >> and 2 Ethernet interfaces, running embedded linux on board. >> It converts A-over-ip to A-interface, acts as MGCP call agent for BTSs, >> transcoders and other telscaleSS7cards. A card is implemented in PCI form >> factor, but bus is used just to provide power supply. >> In other words, a card can act either as a combined SG+MG, converting >> A-over-ip into SS7 and RTP into E1 timeslot, or just a MG, converting RTP >> into E1, without any impact on the host system. >> >> >> When a [signaling gateway + call agent] detects ASSIGNMENT_REQUEST or >> HANDOVER_REQUEST, it stores cic value. As soon as ASSIGNMENT_COMPLETE or >> HO_REQ_ACK is detected, it builds RTP chain that unites >> BTS<->transcoder<->media_gateway. The chain is broken after the call is >> finished. >> >> Depending on the chosen cross plane, 4U 19" industrial PC can carry >> several BSC instances with transcoding, serving about 20 E1 interfaces (ea >> about 80 ARFCNs). Performance requirements for industrial PC cards are also >> negligible: computer will run OpenBSC and configure transcoder cards, being >> controlled by means of MGCP. >> >> >> >> Best Regards, >> Dmitri >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zielonka.markus at googlemail.com Wed Mar 27 08:41:08 2013 From: zielonka.markus at googlemail.com (Markus Zielonka) Date: Wed, 27 Mar 2013 09:41:08 +0100 Subject: Range Networks: Open Source Cellular Networks Message-ID: "Range Networks formally introduced today its executive management team to deliver a complete open source software version of the cellular system. Range Networks says it is the world?s leading provider of American-made commercial open source cellular systems and is slashing the cost to own and operate mobile networks." http://www.dailywireless.org/2013/03/26/range-networks-open-source-cellular-networks/ From risky at mail.ru Wed Mar 27 10:11:35 2013 From: risky at mail.ru (Sergey V. Efimov) Date: Wed, 27 Mar 2013 14:11:35 +0400 Subject: Problem with flashing BS-11 Message-ID: Hello All, Did anyone ever experienced such strange problems when downloading firmware into BS-11? === $ bs11_config bs11_config (C) 2009-2010 by Harald Welte and Dieter Spaar This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY LMT LOGON: ACK PHASE: 1 Software required Abis-link: Down <0005> abis_nm.c:1196 Software Load (BTS 0, File "BTSBMC76.SWI") Software Load Initiate ACK === ...and then nothing happens for hours. I.e., no progress percentage, segment acknowledges, etc. Does it mean that BTS is broken or something other? Regards, Sergey. From risky at mail.ru Wed Mar 27 10:25:39 2013 From: risky at mail.ru (Sergey V. Efimov) Date: Wed, 27 Mar 2013 14:25:39 +0400 Subject: Problem with flashing BS-11 References: Message-ID: <36B656AE-D8DD-4C61-8895-7AB5ADE30DCA@mail.ru> > Hello All, > > Did anyone ever experienced such strange problems when downloading firmware into BS-11? > > === > $ bs11_config > bs11_config (C) 2009-2010 by Harald Welte and Dieter Spaar > This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY > > LMT LOGON: ACK > > PHASE: 1 Software required Abis-link: Down > <0005> abis_nm.c:1196 Software Load (BTS 0, File "BTSBMC76.SWI") > Software Load Initiate ACK > > === > > ...and then nothing happens for hours. I.e., no progress percentage, segment acknowledges, etc. > > Does it mean that BTS is broken or something other? > > Regards, > Sergey. From laforge at gnumonks.org Fri Mar 29 15:37:35 2013 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 29 Mar 2013 16:37:35 +0100 Subject: NEWSDR'13 Workshop / OpenBSC / OsmocomBB Message-ID: <20130329153735.GQ11570@prithivi.gnumonks.org> Hi All, as I've just been made aware of by a business contact, there is a NEWSDR'13 workshop which, among other things, has OsmocomBB and OpenBSC on the list of topics: http://ecewp.ece.wpi.edu/wordpress/sdr-boston/newsdr-13/call-for-papers/ Did anyone ever hear of this workshop? Did the organizers ever make contact with us? I'm a bit surprised that somebody organizes a workshop with "our" projects on the agenda without even sending the CfP to us. Or maybe I just missed it? In case somebody is submitting a paper there: Please make sure to coordinate here in order to avoid different developers/contributors from submitting similar/related topics. 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 peter at stuge.se Sun Mar 31 15:10:42 2013 From: peter at stuge.se (Peter Stuge) Date: Sun, 31 Mar 2013 17:10:42 +0200 Subject: NEWSDR'13 Workshop / OpenBSC / OsmocomBB In-Reply-To: <20130329153735.GQ11570@prithivi.gnumonks.org> References: <20130329153735.GQ11570@prithivi.gnumonks.org> Message-ID: <20130331151042.13170.qmail@stuge.se> Harald Welte wrote: > Did anyone ever hear of this workshop? Not me. > I'm a bit surprised The SDR world seems full of surprises. //Peter From coxe at close-haul.com Sat Mar 30 13:27:38 2013 From: coxe at close-haul.com (Robin Coxe) Date: Sat, 30 Mar 2013 09:27:38 -0400 Subject: NEWSDR'13 Workshop / OpenBSC / OsmocomBB (Harald Welte) Message-ID: I've never heard of either this workshop or the SDR Boston Listserv and don't know any of the people on the organizing committee. One of the moderators of the mailing list, which I just joined, is an EE professor at Northeastern University, Miriam Lesser, who is well known in the FPGA community. Since I'm based in Boston, I'll plan to attend provided I'm not traveling for my day job. If anyone would like to participate by proxy, please let me know. [If I can get my act together in time, I may demo OpenBTS ported to a Xilinx Zynq using the new Close-Haul GAPfiller RF front end.] -Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailman at lists.osmocom.org Sun Mar 31 15:39:26 2013 From: mailman at lists.osmocom.org (mailman at lists.osmocom.org) Date: Sun, 31 Mar 2013 17:39:26 +0200 Subject: Bounce action notification Message-ID: This is a Mailman mailing list bounce action notice: List: OpenBSC Member: fabrice.poundeu at smail.inf.fh-bonn-rhein-sieg.de Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at lists.osmocom.org. -------------- next part -------------- An embedded message was scrubbed... From: Mail Delivery System Subject: Mail delivery failed: returning message to sender Date: Sun, 31 Mar 2013 17:38:13 +0200 Size: 3212 URL: From jolly at eversberg.eu Mon Mar 11 07:12:43 2013 From: jolly at eversberg.eu (Andreas Eversberg) Date: Mon, 11 Mar 2013 08:12:43 +0100 Subject: [PATCH 2/9] Use helper function to check if an MNCC frame is data (speech/traffic) Message-ID: Rename method mncc_rcv_tchf() to mncc_rcv_data(), because the check applies to all types of data frames, not only TCH/F data. --- openbsc/include/openbsc/mncc.h | 8 ++++++++ openbsc/src/libmsc/mncc_builtin.c | 22 ++++++++-------------- openbsc/src/libmsc/mncc_sock.c | 3 +-- 3 files changed, 17 insertions(+), 16 deletions(-) diff --git a/openbsc/include/openbsc/mncc.h b/openbsc/include/openbsc/mncc.h index c61f6b8..ffac7fd 100644 --- a/openbsc/include/openbsc/mncc.h +++ b/openbsc/include/openbsc/mncc.h @@ -191,4 +191,12 @@ int mncc_sock_from_cc(struct gsm_network *net, struct msgb *msg); int mncc_sock_init(struct gsm_network *gsmnet); +#define mncc_is_data_frame(msg_type) \ + (msg_type == GSM_TCHF_FRAME \ + || msg_type == GSM_TCHF_FRAME_EFR \ + || msg_type == GSM_TCHH_FRAME \ + || msg_type == GSM_TCH_FRAME_AMR \ + || msg_type == GSM_BAD_FRAME) + + #endif diff --git a/openbsc/src/libmsc/mncc_builtin.c b/openbsc/src/libmsc/mncc_builtin.c index be35454..a5a463b 100644 --- a/openbsc/src/libmsc/mncc_builtin.c +++ b/openbsc/src/libmsc/mncc_builtin.c @@ -273,8 +273,8 @@ static int mncc_rel_cnf(struct gsm_call *call, int msg_type, struct gsm_mncc *re return 0; } -/* receiving a TCH/F frame from the BSC code */ -static int mncc_rcv_tchf(struct gsm_call *call, int msg_type, +/* receiving a (speech) traffic frame from the BSC code */ +static int mncc_rcv_data(struct gsm_call *call, int msg_type, struct gsm_data_frame *dfr) { struct gsm_trans *remote_trans; @@ -339,16 +339,14 @@ int int_mncc_recv(struct gsm_network *net, struct msgb *msg) DEBUGP(DMNCC, "(call %x) Call created.\n", call->callref); } - switch (msg_type) { - case GSM_TCHF_FRAME: - case GSM_TCHF_FRAME_EFR: - break; - default: - DEBUGP(DMNCC, "(call %x) Received message %s\n", call->callref, - get_mncc_name(msg_type)); - break; + if (mncc_is_data_frame(msg_type)) { + rc = mncc_rcv_data(call, msg_type, arg); + goto out_free; } + DEBUGP(DMNCC, "(call %x) Received message %s\n", call->callref, + get_mncc_name(msg_type)); + switch(msg_type) { case MNCC_SETUP_IND: rc = mncc_setup_ind(call, msg_type, arg); @@ -408,10 +406,6 @@ int int_mncc_recv(struct gsm_network *net, struct msgb *msg) call->callref, data->cause.value); rc = mncc_tx_to_cc(net, MNCC_RETRIEVE_REJ, data); break; - case GSM_TCHF_FRAME: - case GSM_TCHF_FRAME_EFR: - rc = mncc_rcv_tchf(call, msg_type, arg); - break; default: LOGP(DMNCC, LOGL_NOTICE, "(call %x) Message unhandled\n", callref); break; diff --git a/openbsc/src/libmsc/mncc_sock.c b/openbsc/src/libmsc/mncc_sock.c index cf4bca8..dd0a44f 100644 --- a/openbsc/src/libmsc/mncc_sock.c +++ b/openbsc/src/libmsc/mncc_sock.c @@ -54,8 +54,7 @@ int mncc_sock_from_cc(struct gsm_network *net, struct msgb *msg) if (net->mncc_state->conn_bfd.fd < 0) { LOGP(DMNCC, LOGL_ERROR, "mncc_sock receives %s for external CC app " "but socket is gone\n", get_mncc_name(msg_type)); - if (msg_type != GSM_TCHF_FRAME && - msg_type != GSM_TCHF_FRAME_EFR) { + if (!mncc_is_data_frame(msg_type)) { /* release the request */ struct gsm_mncc mncc_out; memset(&mncc_out, 0, sizeof(mncc_out)); -- 1.8.1.5 --------------060708050209070502020504 Content-Type: text/x-diff; name="0006-Adding-traffic-forwarding-via-RTP-to-remote-applicat.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0006-Adding-traffic-forwarding-via-RTP-to-remote-applicat.pa"; filename*1="tch"