November 2013 - OpenBSC - lists.osmocom.org

[PATCH 1/8] mgcp: Rename for_each_line to for_each_non_empty_line
by Jacob Erlbeck 30 Nov '13

30 Nov '13

The implementation of for_each_line is based on strtok() and skips any sequence of CR and LF. Thus empty lines are never detected. There exists code which tests for an empty line to detect the beginning of the SDP part which is dead code currently (the parser works nevertheless due to other reasons). So the semantics of this macro have been misunderstood at least once. This patch renames the macro to reflect the semantics more precisely. Sponsored-by: On-Waves ehf --- openbsc/src/libmgcp/mgcp_protocol.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/openbsc/src/libmgcp/mgcp_protocol.c b/openbsc/src/libmgcp/mgcp_protocol.c index 7096495..c040ab1 100644 --- a/openbsc/src/libmgcp/mgcp_protocol.c +++ b/openbsc/src/libmgcp/mgcp_protocol.c @@ -36,7 +36,7 @@ #include <openbsc/mgcp.h> #include <openbsc/mgcp_internal.h> -#define for_each_line(line, save) \ +#define for_each_non_empty_line(line, save) \ for (line = strtok_r(NULL, "\r\n", &save); line;\ line = strtok_r(NULL, "\r\n", &save)) @@ -527,7 +527,7 @@ static struct msgb *handle_create_con(struct mgcp_parse_data *p) return create_err_response(NULL, 510, "CRCX", p->trans); /* parse CallID C: and LocalParameters L: */ - for_each_line(line, p->save) { + for_each_non_empty_line(line, p->save) { switch (line[0]) { case 'L': local_options = (const char *) line + 3; @@ -652,7 +652,7 @@ static struct msgb *handle_modify_con(struct mgcp_parse_data *p) return create_err_response(endp, 400, "MDCX", p->trans); } - for_each_line(line, p->save) { + for_each_non_empty_line(line, p->save) { switch (line[0]) { case 'C': { if (verify_call_id(endp, line + 3) != 0) @@ -771,7 +771,7 @@ static struct msgb *handle_delete_con(struct mgcp_parse_data *p) return create_err_response(endp, 400, "DLCX", p->trans); } - for_each_line(line, p->save) { + for_each_non_empty_line(line, p->save) { switch (line[0]) { case 'C': if (verify_call_id(endp, line + 3) != 0) @@ -873,7 +873,7 @@ static struct msgb *handle_noti_req(struct mgcp_parse_data *p) if (p->found != 0) return create_err_response(NULL, 400, "RQNT", p->trans); - for_each_line(line, p->save) { + for_each_non_empty_line(line, p->save) { switch (line[0]) { case 'S': tone = extract_tone(line); @@ -1218,7 +1218,7 @@ int mgcp_parse_stats(struct msgb *msg, uint32_t *ps, uint32_t *os, return -1; /* this can only parse the message that is created above... */ - for_each_line(line, save) { + for_each_non_empty_line(line, save) { switch (line[0]) { case 'P': rc = sscanf(line, "P: PS=%u, OS=%u, PR=%u, OR=%u, PL=%d, JI=%u", -- 1.7.9.5

2 16

Creating a graphic of Osmocom GSM projects.
by Andrew Back 28 Nov '13

28 Nov '13

Hello, I'm working on producing a graphic which shows Osmocom projects that can be used in a production GSM network, along with related projects that are used together with these. I'd also like to show these in the context of legacy networks, e.g. with existing BSC and MSC etc. First, I need to be sure I have the complete list: — Osmocom * BSC (or much more): OpenBSC (osmo-bsc or NITB) * BTS: OsmoBTS + sysmoBTS or osmo-trx/UmTRX in Fairwaves solution * PCU: osmo-pcu * SGSN: OsmoSGSN * GGSN: OpenGGSN * ??: cellmgr_ng (what would be the best use cases to show? E.g. as in bsc_nat diagram) * ??: bsc_nat (show as in diagram on wiki? Perhaps with fewer elements...) * ??: osmo-gbproxy Not sure about the status of osmocom-lcs? — Ecosystem (supporting projects) * Linux Call Router * FreeSWITCH * Telscale SS7 card (for interfacing with legacy networks) — Legacy * nanoBTS and others * BSC * MSC * ... ? The idea would be to try and show as many use cases as is reasonably possible and without making the graphic a mess. I'd appreciate any comments and suggestions folks may have. Cheers, Andrew -- Andrew Back http://carrierdetect.com

2 1

[PATCH 1/4] rtp: Fixed size check in padded RTP packets
by Jacob Erlbeck 25 Nov '13

25 Nov '13

This patch fixes a corner case (padding 1, payload size incl padding 0) which is not being detected correctly. Sponsored-by: On-Waves ehf --- openbsc/src/libtrau/rtp_proxy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 0074b4a..4278fc6 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -151,7 +151,7 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data) } } if (rtph->padding) { - if (payload_len < 0) { + if (payload_len < 1) { DEBUGPC(DLMUX, "received RTP frame too short for " "padding length\n"); return -EINVAL; -- 1.7.9.5

3 16

Hard reset NanoBTS after forgetting static IP
by Luca Bongiorni 22 Nov '13

22 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey there, I have come across a nanoBTS 165AU but since is used and not tested from the previous owner, I guess it has set a static IP. After turned on is booting (RED light) and then remains (ORANGE not flashing) even if the eth is connected to the router. At the moment I am trying with ipaccess-find and BtsInstaller to find in on my LAN . Unfortunately it is not answering and is not even getting an IP from the router by the DHCP daemon. Two possibilities, I have thought: - - an hw/sw issue; - - a Static IP is set. Supposing that is the 2nd possibility, I was thinking: - - to change private class of my LAN, to see if it changes something; - - to make an hard reset of the bts. Do you know if it possible to reset in someway? Ever happened this issue to you guys? Suggestions or insults are welcome. Thanks in advance. Cheers, Luca P.S.: I don't recall exactly, but one time I heard that is possible to reset by short-circuiting some pins of the LAN/48VDC eth connector. Is it right?! -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSE682AAoJEPLE1Qsi6ZiTuKkQAJaYGFTgMF5XlWuZuCI1eSvU lVCvpdB+fDRY7o6iut3y0fGlS1ZOIS8X93c7/T0XKUvSJaZ2ARIGjqi81A4XlkAK pdFvBNPKixYATYZYhP3nIggC1QGK9fuWQSUKVEGgnswsXt0VaJKdEwgn0CX7ttku uoh6FM3vtp30drB4t9oe0bW9M9qzGz6yyw+8asaqQBs8bafOHm4+S4kJsN6lYmPU wY/s8ctzqZerNI0MwBVASZCFldsyWe0NuduquYZlwg4god996srFNkVQL+o9nrmF vmPb896DTsCdivwqs+UyaZOgp1mKxjtfco275pVATG4qSAgz/JYQBxWK6fWQr+Zv PIzQvFLME1kh/29nUihxw93mzju5Rz1naTosx5+Fs7jPjCFocqD5Var3hkU4iu78 kNALJNx6UGOdfbqcInO30ltSm21HH1QBJnIoZf6MblELvHcvHbBNyPB8zM13suoS y3/oD/wcXefQaMaSa5HFc30ydJHBWS+adNlVp3fdYYArZaVkFxaVjJx8fW1juPVx 54aco5j7/tZD5tfg9FCOTHqmAiOVDqjs7nZrOpsRdkdPJHq2uHbGmHGqyhZlVWNv B+9/eiOdQyKZ5R+3vvRrmhBe9g2a28xtRI7N8KxwCov0wbA6R0h8l2UtGza6NTcn EUdW3ptIWP216tSFdVTs =9Ctc -----END PGP SIGNATURE-----

8 12

OsmoBTS without HW
by TAMASKOVIC, Dominik 22 Nov '13

22 Nov '13

Hi, I am working on my Diploma thesis , which topic is GPRS Emulation software. This project is based on your OsmoBTS project . The idea is to delete/replace the hw-related primitives and features and redirect the whole traffic to the osmocomBB with modifications – this is the work of my colleague . 1st point: My intention is to implement gprs part only. I have analyzed the BTS codes(especially Master, Jolly/l1sap_parts and Jolly/Trx ), i dont know which one will be most suitable to use, but I think the jolly/trx or jolly/l1sap_parts common part will be probably best choise . It implements more common functions in l1sap interface compared to the Master code . Am I right ? 2nd point: I have analyzed the common code, and it is look like the main logic of the PCU(from the BTS side) is implemented in pcu_sock.c and l1sap.c , where the l1sap implements the message parsing and sending to the l1_if of the BTS , and also initializes gsmtap messages . So what I want to do is to create another socket application to connect with osmocomBB(with additional gprs implementation) , which will send/receive the BTS messages from l1sap through our custom "l1 interface" to the osmocomBB phone("how simple") . The PCU part looks, that would not need any intervention. What do you think ? The hardest part will be to achieve , the application will be able to run witout HW (in the case of TRX branch , the bts will be able to connect to "transmiter" ). Since i am now standing on the crossroad, i need advice to make the right discision . Any suggestions and comments are highly appreciated. Best Regards, Dominik Tamaskovic

2 1

Huawei "CAMEL" in between USAU and SCP
by Dmitri Soloviev 19 Nov '13

19 Nov '13

Hi list I'm hacking a protocol that runs inside Huawei SCP, in between USAU (signaling gateway within IN) and SCP node itself. There is a small file at my disposal (few megs), to study. Unfortunately there is no way to run a trace at the other side of USAU in parallel, so need to guess about fields. Here is the typical IDP found with my guestimations 000000a7 - packet length 0000feab - packet ID 00a1 - length of remained portion 1000 - (***) protocol type, 0x1000 is similar to CAMEL, other protocols are {0100,0200,0300,0400,0500,0600,1000,1200,1300,1400,1500,1700} 01d6f100 - transaction ID 01d6f100 01ff - msg type and direction, 01FF - IDP, where FF means that it goes from gsmSCP to gsmSCP, response is 0100 0000010000000000 - something unknown, some messages may have non-zero values here 8c - length 30 81 - tag+len, something like IDP args 89 8001 01 82 08 84 90 xxxxxxxxxxxx - A pty, MSISDN 83 08 84 13 xxxxxxxxxxxx - B pty, MSISDN 85 01 0a 88 04 00000000 8a 04 84 13 xxxx - E.164 country code bb 05 80038090a3 9c 01 0c 9f32 08 xxxxxxxxxxxxxxxx - IMSI (A) bf33 02 8000 bf34 - a tag that assumes no length/value 22 02 0159 80 08 1000000000000000 81 08 91 xxxxxxxxxxxxxxx - GT of MSC(ssf) a3 09 8007 xxxxxxxxxxxxxx location number ? bf35 03 830111 9f36 05 207a77c430 9f37 08 91 xxxxxxxxxxxxxx - GT of MSC(ssf) 9f39 08 xxxxxxxxxxxxxxxx - some number in unknown format (neither E.164 nor E.212) a-pty MSISDN may be alternatively coded with 9F38 tag The most tricky thing is to decode another protocol types (marked with *** above) that are not so obvious My final goal is to decode both CAP portion and amount of credit available Is there anybody who faced similar task or who can provide additional traces.. or can even make some traces? An ideal case is to perform SS7 and USAU trace in parallel. Or even has some papers on this topic Regards, Dmitri Soloviev

2 1

[PATCH] Use generic libosmocom auth API.
by Max 19 Nov '13

19 Nov '13

--- openbsc/src/libmsc/auth.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/openbsc/src/libmsc/auth.c b/openbsc/src/libmsc/auth.c index 10d8edf..ed25495 100644 --- a/openbsc/src/libmsc/auth.c +++ b/openbsc/src/libmsc/auth.c @@ -24,8 +24,7 @@ #include <openbsc/debug.h> #include <openbsc/auth.h> #include <openbsc/gsm_data.h> - -#include <osmocom/gsm/comp128.h> +#include <osmocom/crypt/auth.h> #include <stdlib.h> @@ -53,6 +52,13 @@ _use_xor(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) static int _use_comp128_v1(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) { + static struct osmo_sub_auth_data auth = { + .type = OSMO_AUTH_TYPE_GSM, + .algo = OSMO_AUTH_ALG_COMP128v1 + }; + struct osmo_auth_vector _vec; + struct osmo_auth_vector *vec = &_vec; + if (ainfo->a3a8_ki_len != A38_COMP128_KEY_LEN) { LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n", ainfo->a3a8_ki_len, @@ -60,9 +66,13 @@ _use_comp128_v1(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) return -1; } - comp128(ainfo->a3a8_ki, atuple->rand, atuple->sres, atuple->kc); + memcpy(auth.u.gsm.ki, ainfo->a3a8_ki, sizeof(auth.u.gsm.ki)); - return 0; + int r = osmo_auth_gen_vec(vec, &auth, atuple->rand); + memcpy(atuple->sres, vec->sres, 4); + memcpy(atuple->kc, vec->kc, 8); + + return r; } /* Return values -- 1.8.3.2 --------------060000020105010100080006--

1 0

[PATCH] Use generic osmocom auth api instead of direct call to comp128.
by Max 19 Nov '13

19 Nov '13

--- openbsc/src/libmsc/auth.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/openbsc/src/libmsc/auth.c b/openbsc/src/libmsc/auth.c index 10d8edf..33d4a3a 100644 --- a/openbsc/src/libmsc/auth.c +++ b/openbsc/src/libmsc/auth.c @@ -24,8 +24,7 @@ #include <openbsc/debug.h> #include <openbsc/auth.h> #include <openbsc/gsm_data.h> - -#include <osmocom/gsm/comp128.h> +#include <osmocom/crypt/auth.h> #include <stdlib.h> @@ -60,9 +59,17 @@ _use_comp128_v1(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) return -1; } - comp128(ainfo->a3a8_ki, atuple->rand, atuple->sres, atuple->kc); - - return 0; + static struct osmo_sub_auth_data auth = { + .type = OSMO_AUTH_TYPE_GSM, + .algo = OSMO_AUTH_ALG_COMP128v1 + }; + memcpy(auth.u.gsm.ki, ainfo->a3a8_ki, sizeof(auth.u.gsm.ki)); + struct osmo_auth_vector _vec; + struct osmo_auth_vector *vec = &_vec; + int r = osmo_auth_gen_vec(vec, &auth, atuple->rand); + memcpy(atuple->sres, vec->sres, 4); + memcpy(atuple->kc, vec->kc, 8); + return r; } /* Return values -- 1.8.3.2 --------------070009030406090002040109--

1 0

Meet us at AfricaCom
by Alexander Chemeris 14 Nov '13

14 Nov '13

Hi all, Fairwaves team is in Cape Town at AfricaCom from today to Thursday. Drop me an SMS to +7(915)330-7626 and we would be happy to arrange a meeting. Fairwaves is a complete solution provider and "just a BTS" vendor. We provide turn-key GSM networks with VoIP backhaul, as well as BTS/BSC for existing GSM networks extension. Our partnerships with the leading VoIP providers allows us to provide your subscribers with the lowest calling rates. Voice and SMS programming platform we offer, allows you to implement complex value added services simpler, than with Twilio. PS Read about the exciting project we're doing in Mexico with the Rhizomatica.org team: https://fairwaves.ru/wp/telecom-revolution-starts-in-yaviche-mexico/ -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

7 12

Re: Meet us at AfricaCom
by Roelf Diedericks 14 Nov '13

14 Nov '13

I met with Alexander today at AfricaCom, and as an interested user of OsmoCOM and the proud owner of a SysmoBTS I can say that the email was certainly of interest to me. It is a very small community, and whilst commercial spamming shouldn't be allowed, I do feel that for the very small special interest group we all participate in, some relaxed attitude may be warranted. The list is currently unobtrusive and if it ever gets as busy as LKML, I'm sure we can do some benevolent dicatatoring. If it were Huawei spamming the list about the conference, then I'd agree, but the Fairwaves guys have generously opened up their hardware designs as well. I don't think it gets more open than that... Regards, Roelf.

1 0