OpenBSC

openbsc@lists.osmocom.org

20 participants
4286 discussions

IuPS and IuCS branches
by Neels Hofmeyr 28 Jan '16

28 Jan '16

Hey Daniel, we are working on our separate branches in openbsc: daniel/gprs-iu and neels/cscn. Merging them will be nontrivial, at least because I have moved gprs/sgsn_iu.c to new libiu/iu.c and include/.../iu.h. That's because some of the stuff there is useful outside of the gprs scope. Otherwise I've not changed the code much, you have at least a little, so before we potentially further complicate the changes, we may benefit from consolidating our branches, sooner rather than later... Though my cscn code doesn't do anything useful yet, it is in a separate new subdir, so merging it to master wouldn't break anything. Merging both our stuffs to master is what I would suggest. If you merge to master first I volunteer to rebase mine and take on the hard half of the merge myself. OTOH, if I'm faster ... ;) (More precisely, I'll bump this in at most two weeks, so plz go for it.) Opinions/strategies welcome! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

1 0

[PATCH] Fix error introduced in a15f05f1b43d8e85d9a3f72a0a
by suraev＠alumni.ntnu.no 28 Jan '16

28 Jan '16

From: Max <msuraev(a)sysmocom.de> Fix error creeped in while porting code from cpp refs. Add test case for code in question. Expand documentatin to clarify function use. --- src/bitvec.c | 24 +++++++++++++++++++----- tests/bitvec/bitvec_test.c | 15 +++++++++++++++ tests/bitvec/bitvec_test.ok | 12 ++++++++++++ 3 files changed, 46 insertions(+), 5 deletions(-) diff --git a/src/bitvec.c b/src/bitvec.c index f9341b7..b88afa6 100644 --- a/src/bitvec.c +++ b/src/bitvec.c @@ -138,6 +138,7 @@ unsigned int bitvec_get_nth_set_bit(const struct bitvec *bv, unsigned int n) * \param[in] bv bit vector on which to operate * \param[in] bitnr number of bit to be set * \param[in] bit value to which the bit is to be set + * \returns 0 on success, negative value on error */ int bitvec_set_bit_pos(struct bitvec *bv, unsigned int bitnr, enum bit_value bit) @@ -163,6 +164,7 @@ int bitvec_set_bit_pos(struct bitvec *bv, unsigned int bitnr, /*! \brief set the next bit inside a bitvec * \param[in] bv bit vector to be used * \param[in] bit value of the bit to be set + * \returns 0 on success, negative value on error */ int bitvec_set_bit(struct bitvec *bv, enum bit_value bit) { @@ -390,11 +392,18 @@ int bitvec_unhex(struct bitvec *bv, const char *src) if (sscanf(src + i, "%1x", &val) < 1) { return 1; } - bitvec_write_field(bv, write_index,val, 4); + bitvec_write_field(bv, write_index, val, 4); + write_index += 4; } return 0; } +/*! \brief read part of the vector + * \param[in] bv The boolean vector to work on + * \param[in] read_index Where reading supposed to start in the vector + * \param[in] len How many bits to read from vector + * \returns read bits or negative value on error + */ uint64_t bitvec_read_field(struct bitvec *bv, unsigned int read_index, unsigned int len) { unsigned int i; @@ -409,11 +418,16 @@ uint64_t bitvec_read_field(struct bitvec *bv, unsigned int read_index, unsigned ui |= ((uint64_t)1 << (len - i - 1)); bv->cur_bit++; } - read_index += len; + return ui; } - +/*! \brief write into the vector + * \param[in] bv The boolean vector to work on + * \param[in] write_index Where writing supposed to start in the vector + * \param[in] len How many bits to write + * \returns next write index or negative value on error + */ int bitvec_write_field(struct bitvec *bv, unsigned int write_index, uint64_t val, unsigned int len) { unsigned int i; @@ -427,8 +441,8 @@ int bitvec_write_field(struct bitvec *bv, unsigned int write_index, uint64_t val if (rc) return rc; } - write_index += len; - return 0; + + return write_index + len; } /*! @} */ diff --git a/tests/bitvec/bitvec_test.c b/tests/bitvec/bitvec_test.c index 624e334..dde8448 100644 --- a/tests/bitvec/bitvec_test.c +++ b/tests/bitvec/bitvec_test.c @@ -55,8 +55,23 @@ static void test_byte_ops() printf("=== end %s ===\n", __func__); } +static void test_unhex(char *hex) +{ + struct bitvec b; + uint8_t d[64] = {0}; + b.data = d; + b.data_len = sizeof(d); + b.cur_bit = 0; + printf("%d -=>\n", bitvec_unhex(&b, hex)); + printf("%s\n%s\n", osmo_hexdump_nospc(d, 64), osmo_hexdump_nospc(hex, 23)); +} + int main(int argc, char **argv) { test_byte_ops(); + test_unhex("48282407a6a074227201000b2b2b2b2b2b2b2b2b2b2b2b"); + test_unhex("47240c00400000000000000079eb2ac9402b2b2b2b2b2b"); + test_unhex("47283c367513ba333004242b2b2b2b2b2b2b2b2b2b2b2b"); + test_unhex("DEADFACE000000000000000000000000000000BEEFFEED"); return 0; } diff --git a/tests/bitvec/bitvec_test.ok b/tests/bitvec/bitvec_test.ok index 1f329af..17e8fd2 100644 --- a/tests/bitvec/bitvec_test.ok +++ b/tests/bitvec/bitvec_test.ok @@ -1,2 +1,14 @@ === start test_byte_ops === === end test_byte_ops === +1 -=> +48282407a6a074227201000b2b2b2b2b2b2b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000 +48282407a6a074227201000b2b2b2b2b2b2b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000 +1 -=> +47240c00400000000000000079eb2ac9402b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000 +47240c00400000000000000079eb2ac9402b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000 +1 -=> +47283c367513ba333004242b2b2b2b2b2b2b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000 +47283c367513ba333004242b2b2b2b2b2b2b2b2b2b2b2b0000000000000000000000000000000000000000000000000000000000000000000000000000000000 +1 -=> +deadface000000000000000000000000000000beeffeed0000000000000000000000000000000000000000000000000000000000000000000000000000000000 +deadface000000000000000000000000000000beeffeed0000000000000000000000000000000000000000000000000000000000000000000000000000000000 -- 2.5.0

3 2

Status Report on Osmocom's 3G Support
by Neels Hofmeyr 28 Jan '16

28 Jan '16

Hi list, it's time for a summary of our progress in the 3G realm. Just this minute, I have posted a blog entry that describes our aim as well as the current development status in abundant detail. At your convenience, see for yourself and visit: https://openbsc.osmocom.org/trac/blog/3G_2016_01 Happy hacking! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

1 0

const question
by Neels Hofmeyr 27 Jan '16

27 Jan '16

Hi, my attention was directed at the gprs_shift_v_fixed() function: int gprs_shift_v_fixed(uint8_t **data, size_t *data_len, size_t len, uint8_t **value) It advances the *data pointer and returns a *value pointer. So it could technically be consting much more aggressively. However, the compiler warnings confuse me. I've created this test code to illustrate; the ints should be treated read-only by func(): void func(const int **yyy) { (*yyy) ++; } int main(void) { int y[2] = {23, 42}; // mutable "by coincidence" int *yy = y; func(&yy); return *yy; // returns 42 } The idea is that yy is a pointer to a mutable int. func() expects a const int, but what harm could be done by passing a mutable-int pointer as an immutable-int pointer. Apparently this harm: check.c: In function ‘main’: check.c:10:14: warning: passing argument 1 of ‘func’ from incompatible pointer type func(&yy); ^ check.c:1:6: note: expected ‘const int **’ but argument is of type ‘int **’ void func(const int **yyy) Changing yy to a pointer-to-const-int clears the warning: const int *yy = y; func(&yy); I'm expecting the const to apply to the int pointed at, so I should be able to modify the pointer while the compiler shouldn't waste a thought at whether the int pointed at is const or not. func() is stricter, not less strict than y[]. To further illustrate, this would make the pointer address itself immutable, which is not what I want: int * const yy = y; I just want to declare the underlying int data to be unchangeable by func(), not caring whether the caller passes a const int or a mutable int buffer. Is the compiler merely nitpicking or am I getting something wrong fundamentally? Thanks! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

2 2

[PATCH 1/5] Ignore test binaries
by suraev＠alumni.ntnu.no 27 Jan '16

27 Jan '16

From: Max <msuraev(a)sysmocom.de> --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 598f88a..955634e 100644 --- a/.gitignore +++ b/.gitignore @@ -81,6 +81,9 @@ tests/strrb/strrb_test tests/vty/vty_test tests/gb/gprs_bssgp_test tests/smscb/gsm0341_test +tests/bitvec/bitvec_test +tests/gprs/gprs_test +tests/msgb/msgb_test utils/osmo-arfcn utils/osmo-auc-gen -- 2.5.0

4 15

[PATCH 1/2] Cleanup build
by suraev＠alumni.ntnu.no 27 Jan '16

27 Jan '16

From: Max <msuraev(a)sysmocom.de> Ignore cross-compilation bild byproducts. Enable subdir-objects to increase compatibility with newer automake. --- .gitignore | 2 ++ configure.ac | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 6cc9aa5..439f591 100644 --- a/.gitignore +++ b/.gitignore @@ -17,6 +17,8 @@ depcomp install-sh missing libtool +arm*linux*libtool +compile ltmain.sh core diff --git a/configure.ac b/configure.ac index 5274022..7a97954 100644 --- a/configure.ac +++ b/configure.ac @@ -3,7 +3,7 @@ AC_INIT([osmo-pcu], m4_esyscmd([./git-version-gen .tarball-version]), [osmocom-net-gprs(a)lists.osmocom.org]) -AM_INIT_AUTOMAKE([dist-bzip2]) +AM_INIT_AUTOMAKE([dist-bzip2 subdir-objects]) AC_CONFIG_TESTDIR(tests) dnl kernel style compile messages -- 2.5.0

2 2

Hardware question
by Ralph A. Schmid, dk5ras 27 Jan '16

27 Jan '16

Hi, My intention is setting up a small dedicated box with a PC and some RF hardware for GSM1800. The usage will be mainly SMS and EDGE. Is it still recommended using something like a nanoBTS, with the nitb setup? These are relative cheap, professionally designed. UmTRX looks great, but it is above the financial limit. It will be an experimental setup, but more for demonstrational purpose, so I love the idea of some nice looking plug and play box. It is not intended to extend it, no hand over, no roaming stuff, no interconnection other than IP and maybe SIP. For testing still I have my B210 and a BladeRF, but I do not want to waste such a versatile SDR for some stupid test BTS stuff :) Thanks for any input! Ralph. -- Ralph A. Schmid Mondstr. 10 90762 Fürth +49-171-3631223 ralph(a)schmid.xxx http://www.bclog.de/

3 3

[PATCH 1/2] Add missing build leftovers to .gitignore
by suraev＠alumni.ntnu.no 26 Jan '16

26 Jan '16

From: Max <msuraev(a)sysmocom.de> --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 6cc9aa5..46ddeb3 100644 --- a/.gitignore +++ b/.gitignore @@ -6,6 +6,7 @@ Makefile.in Makefile .deps +compile aclocal.m4 autom4te.cache config.log @@ -42,3 +43,5 @@ tests/codel/codel_test tests/emu/pcu_emu tests/testsuite tests/testsuite.log +tests/edge/EdgeTest +tests/llc/LlcTest -- 2.5.0

2 2

OAP depends on libgtp? (openbsc:6cacc56d)
by Neels Hofmeyr 26 Jan '16

26 Jan '16

Hi Alexander, about your commit on openbsc, merged as 6cacc56d: libgtp should not be a prerequisite for OAP. OAP is a rather simple protocol built on an IPA connection and doesn't really relate to GTP at all. So if your build of OAP was dependent on libgtp, that's a bug, and probably my fault. Could you please verify / indicate the failure you saw so we/I can fix it? Thanks! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

2 3

GSM demo licenses in Germany?
by Ralph A. Schmid, dk5ras 26 Jan '16

26 Jan '16

Hi, As there are some German GSM experimenters here, what happened to your demo licenses after the DECT guard band frequencies had been auctioned away to AFAIR Vodafone? What a stupid idea, they did not listen to the technicians and just had the $$$ signs in their eyes :( I got a reminder last week, my license would expire soon, and if I would like to renew it. So I answered intentionally unknowingly "yes, please do so". Let's see what they will do now :) The second possibility would be asking the management of a German provider if they would lend me one of their unused guard channels. Although I see there chances I really would hate pulling this wire... Ralph.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC