OpenBSC

openbsc@lists.osmocom.org

4315 discussions

[PATCH openbsc] mgcp_osmux: available circuit IDs from 0 to 255, not from 0 to 128
by pablo＠gnumonks.org 15 Oct '15

15 Oct '15

From: Pablo Neira Ayuso <pablo(a)soleta.eu> Holger reports that the bitmap that accounts for available Osmux circuit IDs is limited to 128, when the maximum number of circuit IDs are determined by the uint8_t field in the header (ie. 256 circuits). --- @Holger: Will be revisiting libosmo-netif too, at quick glance I can see insufficient validation of several functions there that take this allocated ccid as input parameter. openbsc/src/libmgcp/mgcp_osmux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/libmgcp/mgcp_osmux.c b/openbsc/src/libmgcp/mgcp_osmux.c index 90b7368..d110f42 100644 --- a/openbsc/src/libmgcp/mgcp_osmux.c +++ b/openbsc/src/libmgcp/mgcp_osmux.c @@ -530,7 +530,7 @@ int osmux_send_dummy(struct mgcp_endpoint *endp) } /* bsc-nat allocates/releases the Osmux circuit ID */ -static uint8_t osmux_cid_bitmap[16]; +static uint8_t osmux_cid_bitmap[(OSMUX_CID_MAX + 1) / 8]; int osmux_get_cid(void) { -- 2.1.4

1 0

recent patch set with wrong From address dwilllmann@
by Neels Hofmeyr 14 Oct '15

14 Oct '15

Daniel, your from address had triple l's in them. Just saying in case some config needs fixing. I noticed because I was replying on a patch and got a bounce from sysmocom.de. ~Neels

1 0

Osmo-BTS-trx compilation Error
by Rehab Khan 13 Oct '15

13 Oct '15

Hello list, I have compiled OpenBSC stack following the link http://openbsc.osmocom.org/trac/wiki/network_from_scratch. Everything has been compiled and configured smoothly except osmo-bts.For installing osmo-bts,i git cloned master branch from https://github.com/osmocom/osmo-bts. Following the link, i did configure --enable-trx and when make osmo-bts, i am getting the following error: l1_if.c: In function ‘bts_model_l1sap_down’: l1_if.c:552:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’ l1_if.c:553:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’ l1_if.c:554:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’ l1_if.c:555:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’ l1_if.c:580:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’ l1_if.c:581:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’ l1_if.c:582:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’ l1_if.c:583:23: error: ‘struct amr_multirate_conf’ has no member named ‘mode’ make: *** [l1_if.o] Error 1 I have tried it with the change branch: jolly/trx and also tried to make osmo-bts-trx in the src directory of osmo-bts but same error persisits. Any help in this regard will be a worth. Thanks Best Regards

1 0

[openbsc 0/5] sgsn/gbproxy RAND_bytes() usage and test cases
by Daniel Willmann 13 Oct '15

13 Oct '15

From: Daniel Willmann <dwillmann(a)sysmocom.de> Hello, the following patches should complete the usage of RAND_bytes() for GPRS. Jacob improved the SGSN test case so it would extract the PTMSI from the LLC frames and use those in the response. This means the gprs_sgsn patch will not break the test anymore. Furthermore, I changed the gbproxy implementation and test case to use RAND_bytes() instead of rand_r(). The test case previously used rand_r() to (re-)set the seed value for TLLI/PTMSI allocation in order to get predictable results. With RAND_bytes() this is not possible. Instead the tests overrides that function, replacing it with a predictable sequence of random numbers. Regards Daniel Daniel Willmann (3): gprs: Use RAND_bytes for p-tmsi gbproxy/test: Add and call cleanup_test function gprs/gb_proxy: Use RAND_bytes for gbproxy TLLI/TMSI allocation Jacob Erlbeck (2): sgsn/test: Add and call cleanup_test function sgsn/test: Really parse received DL LLC messages openbsc/include/openbsc/gb_proxy.h | 4 - openbsc/src/gprs/Makefile.am | 7 +- openbsc/src/gprs/gb_proxy.c | 16 +- openbsc/src/gprs/gprs_sgsn.c | 6 +- openbsc/tests/gbproxy/Makefile.am | 4 +- openbsc/tests/gbproxy/gbproxy_test.c | 110 +++++--- openbsc/tests/gbproxy/gbproxy_test.ok | 514 +++++++++++++++++----------------- openbsc/tests/sgsn/Makefile.am | 2 + openbsc/tests/sgsn/sgsn_test.c | 133 +++++++-- 9 files changed, 464 insertions(+), 332 deletions(-) -- 2.1.4

2 6

[openbsc 0/4] Use RAND_bytes() instead of rand()
by Daniel Willmann 12 Oct '15

12 Oct '15

From: Daniel Willmann <dwillmann(a)sysmocom.de> The following patches uses RAND_bytes() from openssl instead of rand() to generate TMSI/P-TMSI and auth tuples. I didn't change the use of rand_r() in gb-proxy because the gbproxy test seems to depend on predictable randomness. Daniel Willmann (4): libmsc: Use RAND_bytes when choosing a tmsi gprs: Use RAND_bytes for p-tmsi libmsc: Use RAND_bytes to choose auth tuple libmsc: Use RAND_bytes to generate a token openbsc/configure.ac | 2 +- openbsc/src/gprs/gprs_sgsn.c | 4 +++- openbsc/src/libmsc/Makefile.am | 2 +- openbsc/src/libmsc/auth.c | 9 +++++++-- openbsc/src/libmsc/db.c | 12 ++++++++++-- openbsc/src/osmo-nitb/Makefile.am | 2 +- openbsc/tests/channel/Makefile.am | 2 +- openbsc/tests/db/Makefile.am | 2 +- 8 files changed, 25 insertions(+), 10 deletions(-) -- 2.1.4

3 7

[PATCH] gtp_duplicate(): comment, add todo.
by Neels Hofmeyr 12 Oct '15

12 Oct '15

--- gtp/gtp.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/gtp/gtp.c b/gtp/gtp.c index e6a610d..de6a7b4 100644 --- a/gtp/gtp.c +++ b/gtp/gtp.c @@ -614,6 +614,15 @@ int gtp_notification(struct gsn_t *gsn, int version, return 0; } +/* Look for a message in the response queue for the given peer and sequence + * number seq. If found, (re-)send the response message and return 0. Otherwise + * return nonzero. This allows catching duplicate messages. + * A response message stays in the response queue until it times out. + * So, for any number of identical requests within that timeout period, the + * same packet can be resent. + * TODO this only checks the peer and sequence number, and does not verify that + * the GTP request is identical to the previous one for this peer and sequence + * nr: a mere peer or seq glitch can cause leaks of previous responses. */ int gtp_duplicate(struct gsn_t *gsn, int version, struct sockaddr_in *peer, uint16_t seq) { @@ -873,7 +882,7 @@ int gtp_echo_ind(struct gsn_t *gsn, int version, struct sockaddr_in *peer, int fd, void *pack, unsigned len) { - /* Check if it was a duplicate request */ + /* Repeat previous response in case of duplicate request */ if (!gtp_duplicate(gsn, 0, peer, get_seq(pack))) return 0; @@ -1258,7 +1267,7 @@ int gtp_create_pdp_ind(struct gsn_t *gsn, int version, uint8_t linked_nsapi = 0; struct pdp_t *linked_pdp = NULL; - /* TODO describe what this is all about: */ + /* Repeat previous response in case of duplicate request */ if (!gtp_duplicate(gsn, version, peer, seq)) return 0; @@ -1955,10 +1964,9 @@ int gtp_update_pdp_ind(struct gsn_t *gsn, int version, uint64_t imsi; uint8_t nsapi; - /* Is this a duplicate ? */ - if (!gtp_duplicate(gsn, version, peer, seq)) { - return 0; /* We already sent of response once */ - } + /* Repeat previous response in case of duplicate request */ + if (!gtp_duplicate(gsn, version, peer, seq)) + return 0; /* Decode information elements */ if (gtpie_decaps(ie, version, pack + hlen, len - hlen)) { @@ -2432,10 +2440,9 @@ int gtp_delete_pdp_ind(struct gsn_t *gsn, int version, int n; int count = 0; - /* Is this a duplicate ? */ - if (!gtp_duplicate(gsn, version, peer, seq)) { - return 0; /* We already sent off response once */ - } + /* Repeat previous response in case of duplicate request */ + if (!gtp_duplicate(gsn, version, peer, seq)) + return 0; /* Find the linked context in question */ if (pdp_getgtp1(&linked_pdp, get_tei(pack))) { -- 2.1.4

1 1

Another openggsn cosmetic
by Neels Hofmeyr 12 Oct '15

12 Oct '15

Another addition to the neels/refactor branch, marking a possible problem in gtp.c. ~Neels

1 1

gtphub: End User Address IE
by Neels Hofmeyr 12 Oct '15

12 Oct '15

Hi, I just noticed that the GGSN returns its IP address in a GTP packet about PDP, in the "End User Address" IE (etsi/GSM/by_chapter/29.060.pdf 7.7.27). I'm asking myself whether this needs to be mapped by gtphub. 127.0.0.3 127.0.0.2 SGSN <-------- GTPHUB <--------- GGSN "127.0.0.2" "127.0.0.2" map this? ^ This sounds almost like no mapping is required, as if it tells the MS which IP address it has "as seen from outside": "The PDP Address shall be the address that this PDP context of the MS is identified with from the external packet data network." But I have no idea, really. Does anyone else? If not, we'll just have to see later... Thanks! ~Neels

1 0

next version of OAP patch
by Neels Hofmeyr 12 Oct '15

12 Oct '15

Hi openbsc, here is my improved version of the OAP aka SGSN-ID patch series. This series is pushed to the neels/sgsn-id-3 branch. This version is substantially simpler, because I decided against factoring out the IPA client. Instead, the gprs_gsup_client.c will directly call the OAP API to handle OAP messages. Factoring out the IPA client was not a requirement and taking too much time, and since the name will remain "GSUP client" (to avoid changing the VTY configuration names among other things), it does after all make sense to think of it as: "the GSUP client employs OAP to authenticate" instead of "GSUP and OAP are two separate clients on the IPA wire". The OAP spec has changed. Particularly instead of SRES and Kc, the challenge response now sends XRES only; and the spec now includes an AUTS request (not yet implemented). Going through the changes, I've made a few fixes (like wrong file header comments), and made some changes. The OAP API looks quite different, and now merely returns struct msgb* and lets the caller take care of sending. This time, OAP has its own separate testsuite tests/oap. I have further OAP tests in mind to add; particularly the complete SGSN registration test from the previous patch version is not yet included here. Anyway, the OAP API test has become more comprehensive. Some of the patch mods have come from comments by hfreyther and jerlbeck, other changes were obvious from reviewing the code. I think this time around the patch is much more mature. I hope you agree, if not I'll gladly improve it further, of course :) Thanks for your reviews! ~Neels

2 16

openggsn cosmetics
by Neels Hofmeyr 12 Oct '15

12 Oct '15

These patches fix some things that hurt my eyes. The renames from dublicate to duplicate may theoretically break API compat, but I could find no affected callers. These are not required, feel free to veto... ~Neels

2 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC