OpenBSC

openbsc@lists.osmocom.org

17 participants
4202 discussions

Re: PATCH/RFC use recvfrom with MSG_TRUNC as flag
by Dieter Spaar 23 Jul '10

23 Jul '10

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

2 1

PATCH/RFC use recvfrom with MSG_TRUNC as flag
by Holger Hans Peter Freyther 23 Jul '10

23 Jul '10

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

1 0

Problem to compile the last version of OpenBSC
by Luca Bertoncello 23 Jul '10

23 Jul '10

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

2 2

libosmocore now abort()s on msgb overflow/underflow
by Harald Welte 22 Jul '10

22 Jul '10

Hi! I've just committed a patch that will cause libosmocore to abort in case we try to msgb_put() beyond the end fo the buffer or msgb_push() ahead of the start. I hope we can uncover any hidden buffer under/overflows this way, if they exist. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

installing openbsc on opensuse
by jason mercury 22 Jul '10

22 Jul '10

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

2 1

Switch with PowerOverEthernet for a BaseStation
by Luca Bertoncello 21 Jul '10

21 Jul '10

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

4 6

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

20 Jul '10

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

1 0

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

19 Jul '10

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

1 0

Re: RFC about Osmcoom TCAP / MAP implementation
by mosbah abdelkader 19 Jul '10

19 Jul '10

Hello, Is the source code made public.

2 2

RFC about Osmcoom TCAP / MAP implementation
by Harald Welte 18 Jul '10

18 Jul '10

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

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC