OpenBSC January 2014

openbsc@lists.osmocom.org

33 participants
51 discussions

by openbsc-bounces＠lists.osmocom.org

The OpenBSC(a)lists.osmocom.org mailing list has 3 request(s) waiting for your consideration at: https://lists.osmocom.org/mailman/admindb/openbsc Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: kheimerl(a)cs.berkeley.edu on Thu Jan 9 21:27:04 2014 Subject: OsmoBTS on RAD1 Cause: Message body is too big: 5402368 bytes with a limit of 400 KB From: kaber(a)trash.net on Sun Jan 12 20:39:11 2014 Subject: Re: [RFC] [ADMIN] Making lists subscriber-only? Cause: Too many recipients to the message From: holger(a)freyther.de on Sun Jan 12 20:55:56 2014 Subject: Re: [RFC] [ADMIN] Making lists subscriber-only? Cause: Too many recipients to the message

11 years, 5 months

abis_nm_pchan4chcomb API and return value

by Holger Hans Peter Freyther

Dear Harald, there is an open coverity issue in osmo-bts (CID 1040768) and it is about mixing enum types. enum abis_nm_chan_comb abis_nm_pchan4chcomb(uint8_t chcomb)

11 years, 5 months

RFC fix last coverity report with SI handling in osmo-bts

by Holger Hans Peter Freyther

Hi, the coverity tools points out that it might be possible to access the si.buf atfer _MAX_SYSINFO_TYPE and before < 32. Looking at the code I also notice that: osmo_rsl2sitype takes an uint8_t but makes no range checking, same goes for osmo_sitype2rsl. I plan to apply the below patch for osmo-bts. This would resolve the last open Coverity report for osmo-bts. It would be nice if we could add range checking to osmo_rsl2sitype or check it in common/rsl.c of osmo-bts. diff --git a/src/common/sysinfo.c b/src/common/sysinfo.c index 62d2af9..9e2d4bb 100644 --- a/src/common/sysinfo.c +++ b/src/common/sysinfo.c @@ -135,7 +135,7 @@ uint8_t *lchan_sacch_get(struct gsm_lchan *lchan, struct gsm_time *g_time) { uint32_t tmp; - for (tmp = lchan->si.last + 1; tmp != lchan->si.last; tmp = (tmp + 1) % 32) { + for (tmp = lchan->si.last + 1; tmp != lchan->si.last; tmp = (tmp + 1) % _MAX_SYSINFO_TYPE) { if (lchan->si.valid & (1 << tmp)) { lchan->si.last = tmp; return lchan->si.buf[tmp];

11 years, 5 months

Support for Flexi BTS

by Andreas Eversberg

hi, we managed to run a nokia flexi bts with openbsc. the bts type is "nokia-site". on channel request, the bts nacks the channel activation with cause 0x65 (protocol error, optional information element). by removing the Channel Identification IE from the channel activation message, everything worked, so we assume that this IE causes this error. we tried to modify it: - no zero-length Mobile Allocation included in Channel Identification IE - TLV instead of TV for Channel Description in Channel Identification IE - Channel Description in Channel Identification IE with type 0x62 instead of 0x64 all of these modifications result in the same error. so we came to the conclusion to remove the Channel Identification IE, since it is not really required. attached is the preview patch. does anyone have ABIS traces of a real network, to check how the IE is encoded there? is there any way to get more information from nokia bts why it rejects the channel when using this IE? regards, andreas

11 years, 5 months

[PATCH] nitb/vty: Add test for E1 input keep-alive

by Jacob Erlbeck

This test checks, whether the configuration of e1_line keepalive works. It does not check, whether keep-alive is correctly implemented by the drivers. If the e1_line keepalive command is not provided by the libosmo-abis, this test will be skipped. Sponsored-by: On-Waves ehf --- openbsc/tests/vty_test_runner.py | 55 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/openbsc/tests/vty_test_runner.py b/openbsc/tests/vty_test_runner.py index 08c94b1..16eb213 100644 --- a/openbsc/tests/vty_test_runner.py +++ b/openbsc/tests/vty_test_runner.py @@ -230,6 +230,61 @@ class TestVTYNITB(TestVTYGenericBSC): res = self.vty.command("show paging-group 0 1234567") self.assertEquals(res, "%Paging group for IMSI 1234567 on BTS #0 is 7") + def testE1InputKeepAlive(self): + self.vty.enable() + self.vty.command("configure terminal") + self.vty.command("e1_input") + + self.assertEquals(self.vty.node(), 'config-e1_input') + + # Check for keepalive command + res = self.vty.command("list") + if not res.find(' e1_line <0-255> keepalive\r') > 0: + print("Skipping the E1 input keep-alive test") + return + + # Test invalid input + self.vty.verify("e1_line 200 keepalive", ["% Line 200 doesn't exist"]) + self.vty.verify("e1_line 200 keepalive 1", ["% Command incomplete."]) + self.vty.verify("e1_line 200 keepalive 1 2", ["% Command incomplete."]) + self.vty.verify("no e1_line 200 keepalive 1 2 3", ["% Unknown command."]) + + # Setup driver + self.vty.verify("e1_line 201 driver misdn", ['']) + self.vty.verify("e1_line 202 driver misdn_lapd", ['']) + self.vty.verify("e1_line 204 driver ipa", ['']) + + # Test misdn + self.vty.verify("e1_line 201 keepalive", ["% Driver 'misdn' does not support keep alive"]) + res = self.vty.command("write terminal") + self.assert_(res.find("no e1_line 201 keepalive\r") > 0) + + self.vty.verify("no e1_line 201 keepalive", [""]) + + # Test misdn_lapd + self.vty.verify("e1_line 202 keepalive", ["% Driver 'misdn_lapd' does not support keep alive"]) + res = self.vty.command("write terminal") + self.assert_(res.find("no e1_line 202 keepalive\r") > 0) + + self.vty.verify("no e1_line 202 keepalive", [""]) + + # Test ipa + self.vty.verify("e1_line 204 keepalive", [""]) + res = self.vty.command("write terminal") + self.assert_(res.find("e1_line 204 keepalive\r") > 0) + + self.vty.verify("e1_line 204 keepalive 10 1 2", [""]) + res = self.vty.command("write terminal") + self.assert_(res.find("e1_line 204 keepalive 10 1 2\r") > 0) + + self.vty.verify("no e1_line 204 keepalive", [""]) + + # Check whether keep alive is disabled again on each line + res = self.vty.command("write terminal") + self.assert_(res.find("no e1_line 201 keepalive\r") > 0) + self.assert_(res.find("no e1_line 202 keepalive\r") > 0) + self.assert_(res.find("no e1_line 204 keepalive\r") > 0) + class TestVTYBSC(TestVTYGenericBSC): def vty_command(self): -- 1.7.9.5

11 years, 5 months

Potential bug in trx_if.c

by Kurtis Heimerl

Hey all, I've been working on getting the Range Networks RAD1 working with OsmoBTS. I *think* I've found a bug in trx_if.c. Basically, tsc checks the bsic variable and bsic checks the tsc variable. It *may* be intentional but I doubt that and I wanted to note it before I moved on. Patch is attached. Thanks!

11 years, 5 months

[PATCH] sms: Fix gsm_7bit legacy functions return value

by Jacob Erlbeck

The legacy 7bit conversion functions (those without the '_n_' in the name) gave wrong return values on 64 bit platforms due to unproper signed/unsigned conversions and the usage of SIZE_MAX. This patch fixes this by using a smaller max size (see GSM_7BIT_LEGACY_MAX_BUFFER_SIZE, currently set to 64k) for the legacy wrappers and by using unsigned int for max_septets. In addition, there are tests now that check the return values of legacy encoding and decoding. Sponsored-by: On-Waves ehf --- include/osmocom/gsm/gsm_utils.h | 3 +++ src/gsm/gsm_utils.c | 17 +++++++++++------ tests/sms/sms_test.c | 22 ++++++++++++++++++++++ 3 files changed, 36 insertions(+), 6 deletions(-) diff --git a/include/osmocom/gsm/gsm_utils.h b/include/osmocom/gsm/gsm_utils.h index f412e3e..02bfe4c 100644 --- a/include/osmocom/gsm/gsm_utils.h +++ b/include/osmocom/gsm/gsm_utils.h @@ -195,6 +195,9 @@ enum gsm_chan_t { }; /* Deprectated functions */ +/* Limit encoding and decoding to use no more than this amount of buffer bytes */ +#define GSM_7BIT_LEGACY_MAX_BUFFER_SIZE 0x10000 + int gsm_7bit_decode(char *decoded, const uint8_t *user_data, uint8_t length) OSMO_DEPRECATED("Use gsm_7bit_decode_n() instead"); int gsm_7bit_decode_ussd(char *decoded, const uint8_t *user_data, uint8_t length) OSMO_DEPRECATED("Use gsm_7bit_decode_n_ussd() instead"); int gsm_7bit_encode(uint8_t *result, const char *data) OSMO_DEPRECATED("Use gsm_7bit_encode_n() instead"); diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c index 5241c91..198ec69 100644 --- a/src/gsm/gsm_utils.c +++ b/src/gsm/gsm_utils.c @@ -273,7 +273,7 @@ int gsm_7bit_encode_n(uint8_t *result, size_t n, const char *data, int *octets) { int y = 0; int o; - int max_septets = n * 8 / 7; + size_t max_septets = n * 8 / 7; /* prepare for the worst case, every character expanding to two bytes */ uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t)); @@ -683,7 +683,8 @@ uint32_t gprs_tmsi2tlli(uint32_t p_tmsi, enum gprs_tlli_type type) int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t septet_l) { - gsm_7bit_decode_n(text, SIZE_MAX, user_data, septet_l); + gsm_7bit_decode_n(text, GSM_7BIT_LEGACY_MAX_BUFFER_SIZE, + user_data, septet_l); /* Mimic the original behaviour. */ return septet_l; @@ -691,21 +692,25 @@ int gsm_7bit_decode(char *text, const uint8_t *user_data, uint8_t septet_l) int gsm_7bit_decode_ussd(char *text, const uint8_t *user_data, uint8_t length) { - return gsm_7bit_decode_n_ussd(text, SIZE_MAX, user_data, length); + return gsm_7bit_decode_n_ussd(text, GSM_7BIT_LEGACY_MAX_BUFFER_SIZE, + user_data, length); } int gsm_7bit_encode(uint8_t *result, const char *data) { int out; - return gsm_7bit_encode_n(result, SIZE_MAX, data, &out); + return gsm_7bit_encode_n(result, GSM_7BIT_LEGACY_MAX_BUFFER_SIZE, + data, &out); } int gsm_7bit_encode_ussd(uint8_t *result, const char *data, int *octets) { - return gsm_7bit_encode_n_ussd(result, SIZE_MAX, data, octets); + return gsm_7bit_encode_n_ussd(result, GSM_7BIT_LEGACY_MAX_BUFFER_SIZE, + data, octets); } int gsm_7bit_encode_oct(uint8_t *result, const char *data, int *octets) { - return gsm_7bit_encode_n(result, SIZE_MAX, data, octets); + return gsm_7bit_encode_n(result, GSM_7BIT_LEGACY_MAX_BUFFER_SIZE, + data, octets); } diff --git a/tests/sms/sms_test.c b/tests/sms/sms_test.c index 2c9d8d8..755b321 100644 --- a/tests/sms/sms_test.c +++ b/tests/sms/sms_test.c @@ -280,6 +280,17 @@ int main(int argc, char** argv) /* test 7-bit encoding */ for (i = 0; i < ARRAY_SIZE(test_encode); ++i) { + /* Test legacy function (return value only) */ + septet_length = gsm_7bit_encode(coded, + (const char *) test_encode[i].input); + printf("Legacy encode case %d: " + "septet length %d (expected %d)\n" + , i + , septet_length, test_encode[i].expected_septet_length + ); + OSMO_ASSERT (septet_length == test_encode[i].expected_septet_length); + + /* Test new function */ memset(coded, 0x42, sizeof(coded)); septet_length = gsm_7bit_encode_n(coded, sizeof(coded), (const char *) test_encode[i].input, @@ -296,6 +307,7 @@ int main(int argc, char** argv) OSMO_ASSERT (octets_written == test_encode[i].expected_octet_length); OSMO_ASSERT (octets_written == computed_octet_length); OSMO_ASSERT (memcmp(coded, test_encode[i].expected, octets_written) == 0); + OSMO_ASSERT (septet_length == test_encode[i].expected_septet_length); /* check buffer limiting */ memset(coded, 0xaa, sizeof(coded)); @@ -357,6 +369,16 @@ int main(int argc, char** argv) /* test 7-bit decoding */ for (i = 0; i < ARRAY_SIZE(test_decode); ++i) { + /* Test legacy function (return value only) */ + if (!test_decode[i].ud_hdr_ind) { + nchars = gsm_7bit_decode(result, test_decode[i].input, + test_decode[i].expected_septet_length); + printf("Legacy decode case %d: " + "return value %d (expected %d)\n", + i, nchars, test_decode[i].expected_septet_length); + } + + /* Test new function */ memset(result, 0x42, sizeof(result)); nchars = gsm_7bit_decode_n_hdr(result, sizeof(result), test_decode[i].input, test_decode[i].expected_septet_length, test_decode[i].ud_hdr_ind); -- 1.7.9.5

11 years, 5 months

[PATCH] nitb: Set the DST field in generated MM info messages

by Jacob Erlbeck

Currently the NET_DST information element (see GSM 24.008) is not included in generated MM info messages even when the DST field in the timezone info has been set via the VTY or the control interface. This patch modifies gsm48_tx_mm_info() to append this information element if (and only if) a non-zero DST has been configured. The DST IE is not part of GSM 4.8. Therefore it will only be sent, if the DST offset is configured to a value != 0. Sponsored-by: On-Waves ehf --- openbsc/src/libmsc/gsm_04_08.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index 3cfc455..0d1ba7b 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -656,6 +656,7 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) struct tm* gmt_time; struct tm* local_time; int tzunits; + int dst = 0; msg->lchan = conn->lchan; @@ -749,6 +750,9 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) tzunits = tzunits + (bts->tz.mn/15); ptr8[7] = bcdify(tzunits); } + /* Convert DST value */ + if (bts->tz.dst >= 0 && bts->tz.dst <= 2) + dst = bts->tz.dst; } else { /* Need to get GSM offset and convert into 15 min units */ @@ -768,8 +772,19 @@ int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn) } else ptr8[7] = bcdify(tzunits); + + /* Does not support DST +2 */ + if (local_time->tm_isdst) + dst = 1; } +#ifdef GSM48_IE_NET_DST + ptr8 = msgb_put(msg, 3); + ptr8[0] = GSM48_IE_NET_DST; + ptr8[1] = 1; + ptr8[2] = dst; +#endif + DEBUGP(DMM, "-> MM INFO\n"); return gsm48_conn_sendmsg(msg, conn, NULL); -- 1.7.9.5

11 years, 5 months

Making jolly/testing ready to be merged?

by Holger Hans Peter Freyther

Dear Andreas, going through the patchset of jolly/testing in OpenBSC it would be nice to get most of the things merged (having TCH/H support for something like the 31C3 is a nice goal). I wanted to start with merging the Connection Failure Criteria code but I am confused about the conversion. When parsing the criteria value from from the VTY you divide by four and subtract (so 4 becomes 0). You ondo this when saving the config and patching it in the nanoBTS attribute array. Wouldn't it be more easy to not doing the conversion? holger

11 years, 5 months

OsmoDevCon 2014 / Date / Venue

by Harald Welte

Hi all, time is moving fast, and I want to start some initial discussion and planning for OsmoDevCon 2014. There are basically four questions which I'm raising below. Please provide your feedback to the osmocom-event-orga mailing list only, to avoid cross-posting over all the project lists. = Who? = My intention is to keep it an 'active developer/contributer only' event, like we had it before. I would also want to keep the group relatively small, to keep the 'Osmocom family' atmosphere. If desired, we could have one half or full day of public prsentations in a larger auditorium, but the developer meeting should be a close group, as known so far. = Where? = If we keep the number of attendees within the same range as this year, then I'm sure we could again hold it at the same venue. I know it is not perfect, but it is a place that we have access to, 24 hours per day, and free of cost for community projects like osmocom.org. If the community wants a larger event, then this is something that would require more funds and much more time organizing. And that is something that I personally could not offer to take care of, sorry. I'm happy to attend and support any larger events, but I'm unable to take care of fundraising and venue research. = When? = Q1/2014. In January, I'm not aware of any 'blocker' events. February, there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg March 17-21). Did I miss any other FOSS / mobile event that might clash in Q1? So my preference woudl be to do it either late January (23-26) or in February (6-9 or 13-16). Any preferences regarding preferred schedule? Once we have some concencus here on the list [and we want to do it in the same size / venue], I'll talk to IN-Berlin. = What? = I think that question is easy to answer, if we have the above three figured out... There's no shortage of topics, I suppose. You can start adding your suggestions to http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

11 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2014