From Max.Suraev at fairwaves.co Mon Jun 1 13:31:48 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Mon, 01 Jun 2015 15:31:48 +0200 Subject: [PATCH] Use generic auth API In-Reply-To: References: <1413541198-18547-1-git-send-email-max.suraev@fairwaves.co> <5440EFFB.4060903@fairwaves.co> Message-ID: <556C5EC4.8000604@fairwaves.co> Pardon for delay - got deadline at my back :) I've just tried the patch from http://patchwork.ozlabs.org/patch/400499/ and it applies cleanly to the latest git, all the tests pass. Why do we need to rebase it? What kind of warnings/test failures have you hit with this patch? 17.05.2015 19:12, Holger Freyther ?????: > >> On 17 Oct 2014, at 12:31, ? wrote: > > > Dear Max, > >> Just realized that this long time ago published patch s not visible at patchwork. >> I'd appreciate help with testing it against sim cards using xor - don't have any at >> hands. > > okay this is still needed to be applied. Could you please re-base and re-send > the patch? sorry for the delay. > > holger > -- best regards, Max, http://fairwaves.co From Max.Suraev at fairwaves.co Mon Jun 1 13:58:11 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Mon, 01 Jun 2015 15:58:11 +0200 Subject: segfault on bssgp test In-Reply-To: <555F3139.4080206@fairwaves.co> References: <555F3139.4080206@fairwaves.co> Message-ID: <556C64F3.9040301@fairwaves.co> Pardon for multiple copies, but this is really curious: gbprocy test also fails for me during OpenBSC build at gbproxy_test.c:1922 which also contains following misterious comment: /* TODO: The following breaks with the current libosmocore, enable it * again (and remove the plain expect_msg), when the msgb_bssgph patch * is integrated */ What is the status of this "msgb_bssgph patch" patch? Is there patchwork link available? I suspect it's still unmerged because swapping the lines as instructed in comment still results in crash with the latest libosmocore from git. Commenting out both lines produce sane-looking output but the test expectedly fails due to mismatch with expected output. I wonder if should comment out the 2nd line until the libosmocore patch is merged or perhaps consider merging the necessary patch? 22.05.2015 15:38, ? ?????: > Hi. > > Anyone else experienced this with latest libosmocore from git? > > ./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test > stderr: > MESSAGE to 0x7f0000ff, msg length 12 > 02 00 81 01 01 82 0b 56 04 82 0b 55 > All NS-VCs for NSEI 2901 are either dead or blocked! > All NS-VCs for NSEI 2901 are either dead or blocked! > BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified > BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI > NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989 > Unable to resolve NSEI 4660 to NS-VC! > Assert failed rc >= 0 gb/gprs_bssgp_test.c:229 > /home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25: > 8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_ > bssgp_test > -- best regards, Max, http://fairwaves.co From holger at freyther.de Tue Jun 2 06:40:55 2015 From: holger at freyther.de (Holger Freyther) Date: Tue, 2 Jun 2015 08:40:55 +0200 Subject: [PATCH] libmsc: Improve 'max_power_red' VTY command. In-Reply-To: References: Message-ID: <0452E324-EBF6-4E69-B3BA-190D91A8D777@freyther.de> > On 30 May 2015, at 20:59, Alexander Chemeris wrote: Dear Alexander, > * Apply change even if the supplied value is higher than the 24dB maximum > suggested by the standard, just warn about this. > UmSITE and probably other SDR based BTS support much wider power > regulation range. this certainly makes sense. We need to check in osmo-bts that ?24 dB? in reduction does not exceed the maximum. > Changes: > * Apply change to the BTS over OML immediately. that is nice but there is a bigger picture. Do we really want/can/need change all VTY. We are certainly lacking in terms of live modification capabilities but this path to add them might not be the right one. You might want to change two parameters at once (switch the ARFCN and then use a higher output?). In the long-run I think we need to separate the running config from the one that can be configured and with an ?apply? you can then move the config around. I am hesitant to merge a hunk like this right now wihtout having a goal/target to improve the entire situation. > * Apply change even if the supplied value is odd, just warn that it is rounded. > Previously the value was not set at all, which may have lead to a situation when > a user thinks the BTS operating at low power, while it is running full power. No we should not round. We could change the VTY command to list 0|2|4.. 22|24|26.. as options or you find a way to describe the ?must be even? attribute with the VTY. holger From holger at freyther.de Tue Jun 2 06:45:04 2015 From: holger at freyther.de (Holger Freyther) Date: Tue, 2 Jun 2015 08:45:04 +0200 Subject: [PATCH 1/2] libbsc: Abstract out SIs update/generation for a BTS into a separate function. In-Reply-To: References: Message-ID: > On 30 May 2015, at 21:42, Alexander Chemeris wrote: Dear Alexander, > The code to do that doesn't belong to the control interface, so abstract it out > to a separate function gsm_bts_set_system_infos(). please send the patch inline so one can comment on it. I have applied it and fixed the wrong curly braces. Please attempt to obey the coding-style. thank you holger From holger at freyther.de Tue Jun 2 07:26:09 2015 From: holger at freyther.de (Holger Freyther) Date: Tue, 2 Jun 2015 09:26:09 +0200 Subject: [PATCH 2/2] libbsc: Update a BTS's SIs when ms_max_power is changed from VTY. In-Reply-To: References: Message-ID: <4CA5C18A-8CCB-4669-B686-C773515BC5C4@freyther.de> > On 30 May 2015, at 21:43, Alexander Chemeris wrote: > > Otherwise you have to restart BTS or at least break the RSL connection > to apply the change. Yes we certainly should apply modifications at runtime but probably not by adding auto-update to each command. When I change LAC/CI/ms_max_power I don?t want to update the SI three times. We really need to have a ?commit?/?apply? kind of command that applies OML and RSL modifications. holger From mike.mcternan at wavemobile.com Tue Jun 2 12:50:44 2015 From: mike.mcternan at wavemobile.com (Mike McTernan (wavemobile)) Date: Tue, 2 Jun 2015 12:50:44 +0000 Subject: libosmoabis depends on libosmovty Message-ID: Hi Folks, When I build OpenBsc, I find a number of cases where libosmovty isn't in the link, but is needed by libosmoabis (basically anywhere libosmoabis is linked, but vty isn't) e.g. /bin/ld: warning: libosmovty.so.1, needed by /.build/usr/local/lib/libosmoabis.so, not found (try using -rpath or -rpath-link) /.build/usr/local/lib/libosmoabis.so: undefined reference to `install_node' /.build/usr/local/lib/libosmoabis.so: undefined reference to `install_element_ve' /.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_out_rate_ctr_group' /.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_out' /.build/usr/local/lib/libosmoabis.so: undefined reference to `install_element' /.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_install_default' I'm not sure why/how I'm seeing this and others apparently aren't, but it looks legitimate. I've verified the configure script has [correctly] derived build configfrom the staged pkgconfig: LIBOSMOABIS_CFLAGS='-I/.build/usr/local/include/ ' LIBOSMOABIS_LIBS='-L/.build/usr/local/lib -losmoabis ' So I wonder if libosmoabis.pc.in should be updated to include vty, a bit like libosmogb.pc.in i.e. Signed-off-by: Michael McTernan --- libosmoabis.pc.in (revision 19495) +++ libosmoabis.pc.in (working copy) @@ -6,6 +6,6 @@ Name: A-bis Core Library Description: C Utility Library Version: @VERSION@ -Libs: -L${libdir} -losmoabis +Libs: -L${libdir} -losmoabis -losmovty Cflags: -I${includedir}/ Otherwise every user of libosmoabis has to remember to link with -losmovty as well. Kind Regards, Mike PS: I've stripped the very long full build paths from output - I don't really build in /.build! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.mcternan at wavemobile.com Tue Jun 2 13:48:49 2015 From: mike.mcternan at wavemobile.com (Mike McTernan (wavemobile)) Date: Tue, 2 Jun 2015 13:48:49 +0000 Subject: [PATCH 1/1] openbsc: Rename core_ncc to core_mnc Message-ID: Hi Folks, Struct osmo_msc_data contains int core_ncc, which is actually the MNC part of the PLMN, not to be confused with the Network Colour Code. The following patch renames this field for clarity and consistency with the standards. Please consider it for inclusion. Signed-off-by: Michael McTernan diff -Nrup openbsc.orig/openbsc/include/openbsc/osmo_msc_data.h openbsc/openbsc/include/openbsc/osmo_msc_data.h --- openbsc.orig/openbsc/include/openbsc/osmo_msc_data.h 2015-06-02 12:45:13.682136307 +0100 +++ openbsc/openbsc/include/openbsc/osmo_msc_data.h 2015-06-02 12:45:28.661356866 +0100 @@ -65,7 +65,7 @@ struct osmo_msc_data { struct osmo_timer_list pong_timer; int advanced_ping; struct bsc_msc_connection *msc_con; - int core_ncc; + int core_mnc; int core_mcc; int core_lac; int core_ci; diff -Nrup openbsc.orig/openbsc/src/osmo-bsc/osmo_bsc_api.c openbsc/openbsc/src/osmo-bsc/osmo_bsc_api.c --- openbsc.orig/openbsc/src/osmo-bsc/osmo_bsc_api.c 2015-06-02 12:45:13.679136263 +0100 +++ openbsc/openbsc/src/osmo-bsc/osmo_bsc_api.c 2015-06-02 12:45:28.664356910 +0100 @@ -53,8 +53,8 @@ static int complete_layer3(struct gsm_su static uint16_t get_network_code_for_msc(struct osmo_msc_data *msc) { - if (msc->core_ncc != -1) - return msc->core_ncc; + if (msc->core_mnc != -1) + return msc->core_mnc; return msc->network->network_code; } diff -Nrup openbsc.orig/openbsc/src/osmo-bsc/osmo_bsc_filter.c openbsc/openbsc/src/osmo-bsc/osmo_bsc_filter.c --- openbsc.orig/openbsc/src/osmo-bsc/osmo_bsc_filter.c 2015-06-02 12:45:13.679136263 +0100 +++ openbsc/openbsc/src/osmo-bsc/osmo_bsc_filter.c 2015-06-02 12:46:00.653828021 +0100 @@ -313,7 +313,7 @@ static int bsc_patch_mm_info(struct gsm_ static int has_core_identity(struct osmo_msc_data *msc) { - if (msc->core_ncc != -1) + if (msc->core_mnc != -1) return 1; if (msc->core_mcc != -1) return 1; diff -Nrup openbsc.orig/openbsc/src/osmo-bsc/osmo_bsc_msc.c openbsc/openbsc/src/osmo-bsc/osmo_bsc_msc.c --- openbsc.orig/openbsc/src/osmo-bsc/osmo_bsc_msc.c 2015-06-02 12:45:13.679136263 +0100 +++ openbsc/openbsc/src/osmo-bsc/osmo_bsc_msc.c 2015-06-02 12:45:28.664356910 +0100 @@ -522,7 +522,7 @@ struct osmo_msc_data *osmo_msc_data_allo INIT_LLIST_HEAD(&msc_data->dests); msc_data->ping_timeout = 20; msc_data->pong_timeout = 5; - msc_data->core_ncc = -1; + msc_data->core_mnc = -1; msc_data->core_mcc = -1; msc_data->core_ci = -1; msc_data->core_lac = -1; diff -Nrup openbsc.orig/openbsc/src/osmo-bsc/osmo_bsc_vty.c openbsc/openbsc/src/osmo-bsc/osmo_bsc_vty.c --- openbsc.orig/openbsc/src/osmo-bsc/osmo_bsc_vty.c 2015-06-02 12:45:13.679136263 +0100 +++ openbsc/openbsc/src/osmo-bsc/osmo_bsc_vty.c 2015-06-02 12:45:28.664356910 +0100 @@ -107,9 +107,9 @@ static void write_msc(struct vty *vty, s vty_out(vty, "msc %d%s", msc->nr, VTY_NEWLINE); if (msc->bsc_token) vty_out(vty, " token %s%s", msc->bsc_token, VTY_NEWLINE); - if (msc->core_ncc != -1) + if (msc->core_mnc != -1) vty_out(vty, " core-mobile-network-code %d%s", - msc->core_ncc, VTY_NEWLINE); + msc->core_mnc, VTY_NEWLINE); if (msc->core_mcc != -1) vty_out(vty, " core-mobile-country-code %d%s", msc->core_mcc, VTY_NEWLINE); @@ -234,10 +234,10 @@ DEFUN(cfg_net_bsc_token, DEFUN(cfg_net_bsc_ncc, cfg_net_bsc_ncc_cmd, "core-mobile-network-code <1-999>", - "Use this network code for the core network\n" "NCC value\n") + "Use this network code for the core network\n" "MNC value\n") { struct osmo_msc_data *data = osmo_msc_data(vty); - data->core_ncc = atoi(argv[0]); + data->core_mnc = atoi(argv[0]); return CMD_SUCCESS; } The same patch is attached, md5sum 2082d6b4b174236fcf3b84e548dcf2ad (in case it gets mangled by the mailer). Kind Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: rename-core_ncc-to-core_mnc.patch Type: application/octet-stream Size: 3334 bytes Desc: rename-core_ncc-to-core_mnc.patch URL: From holger at freyther.de Tue Jun 2 13:59:10 2015 From: holger at freyther.de (Holger Freyther) Date: Tue, 2 Jun 2015 15:59:10 +0200 Subject: libosmoabis depends on libosmovty In-Reply-To: References: Message-ID: > On 02 Jun 2015, at 14:50, Mike McTernan (wavemobile) wrote: > > Hi Folks, Hi! > When I build OpenBsc, I find a number of cases where libosmovty isn?t in the link, but is needed by libosmoabis (basically anywhere libosmoabis is linked, but vty isn?t) e.g. > > /bin/ld: warning: libosmovty.so.1, needed by /.build/usr/local/lib/libosmoabis.so, not found (try using -rpath or -rpath-link) > /.build/usr/local/lib/libosmoabis.so: undefined reference to `install_node? > -Libs: -L${libdir} -losmoabis > +Libs: -L${libdir} -losmoabis -losmovty When I grew up the rule was link to the libraries whose symbols you are using. In this case libosmo-abis does use libosmovty symbols and it does link to it. I assume that there is a NEEDED entry in the elf header of libosmo-abis. Which system do you compile it on? I think the above is kind of a work-around for another issue in the system. holger From mike.mcternan at wavemobile.com Tue Jun 2 14:44:14 2015 From: mike.mcternan at wavemobile.com (Mike McTernan (wavemobile)) Date: Tue, 2 Jun 2015 14:44:14 +0000 Subject: libosmoabis depends on libosmovty In-Reply-To: References: Message-ID: Hi Holger, > When I grew up the rule was link to the libraries whose symbols you are > using. In this case libosmo-abis does use libosmovty symbols and it does link > to it. Yes, here?s the link line for libosmoabis, showing the link of vty and dependent libs: /bin/sh ../libtool --tag=CC --mode=link arm-x-linux-gnueabi-gcc -Wall -I/.build/usr/local/include/ -I/.build/usr/local/include/ -I/.build/usr/local/include/ -D_REENTRANT -DORTP_INET6 -I /.build/usr/local/include -g -O2 -version-info 0:0:0 -o libosmotrau.la -rpath /usr/local/lib libosmotrau_la-osmo_ortp.lo -L/.build/usr/local/lib -losmocore -L/.build/usr/local/lib -losmogsm -L/.build/usr/local/lib -losmovty -L/.build/usr/local/lib -lortp -lpthread -lrt > I assume that there is a NEEDED entry in the elf header of libosmo-abis. Sure is: $ arm-x-linux-gnueabi-objdump -x libosmoabis.so | grep NEEDED NEEDED libosmocore.so.6 NEEDED libosmogsm.so.5 NEEDED libosmovty.so.1 NEEDED libgcc_s.so.1 NEEDED libc.so.6 > Which system do you compile it on? This is cross-compiling for arm, gcc from Sourcery CodeBench Lite 2012.09-104, 4.7.2. > I think the above is kind of a work-around for another issue in the system. I cross-compile and install to a stage using DESTDIR at the install step. This means that at link time the rpath, while correct for the final system, isn't valid (which is pretty much what the linker is hinting at in the warning). Also from 'man ld': "The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link" So rpath makes it work if building and installing either natively or to a mocked environment, but we become stuck if staging in a different directory. Passing the library itself uses different search rules, and so that works. I guess the other options are to hack with LDFLAGS and LIBS in the build, or set LD_RUN_PATH in the environment. I'll keep the patch locally for now I think though... Kind Regards, Mike From holger at freyther.de Tue Jun 2 14:46:08 2015 From: holger at freyther.de (Holger Freyther) Date: Tue, 2 Jun 2015 16:46:08 +0200 Subject: libosmoabis depends on libosmovty In-Reply-To: References: Message-ID: > On 02 Jun 2015, at 16:44, Mike McTernan (wavemobile) wrote: > > Hi Holger, Hi! >> Which system do you compile it on? > > This is cross-compiling for arm, gcc from Sourcery CodeBench Lite 2012.09-104, 4.7.2. > >> I think the above is kind of a work-around for another issue in the system. > > I cross-compile and install to a stage using DESTDIR at the install step. This means that at link time the rpath, while correct for the final system, isn't valid (which is pretty much what the linker is hinting at in the warning). Also from 'man ld?: yes, you then need to have -rpath-link in your LDFLAGS to help the linker find the temporary libosmovty.so holger From Max.Suraev at fairwaves.co Fri Jun 5 13:07:48 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Fri, 05 Jun 2015 15:07:48 +0200 Subject: segfault on bssgp test In-Reply-To: <556C64F3.9040301@fairwaves.co> References: <555F3139.4080206@fairwaves.co> <556C64F3.9040301@fairwaves.co> Message-ID: <55719F24.3050000@fairwaves.co> Another person reproduced this on ubuntu 15.04 x86_64. Have anyone else hit it recently? 01.06.2015 15:58, ? ?????: > Pardon for multiple copies, but this is really curious: gbprocy test also fails for > me during OpenBSC build at gbproxy_test.c:1922 which also contains following > misterious comment: > > /* TODO: The following breaks with the current libosmocore, enable it > * again (and remove the plain expect_msg), when the msgb_bssgph patch > * is integrated */ > > What is the status of this "msgb_bssgph patch" patch? Is there patchwork link available? > > I suspect it's still unmerged because swapping the lines as instructed in comment > still results in crash with the latest libosmocore from git. > > Commenting out both lines produce sane-looking output but the test expectedly fails > due to mismatch with expected output. > > I wonder if should comment out the 2nd line until the libosmocore patch is merged or > perhaps consider merging the necessary patch? > > 22.05.2015 15:38, ? ?????: >> Hi. >> >> Anyone else experienced this with latest libosmocore from git? >> >> ./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test >> stderr: >> MESSAGE to 0x7f0000ff, msg length 12 >> 02 00 81 01 01 82 0b 56 04 82 0b 55 >> All NS-VCs for NSEI 2901 are either dead or blocked! >> All NS-VCs for NSEI 2901 are either dead or blocked! >> BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified >> BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI >> NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989 >> Unable to resolve NSEI 4660 to NS-VC! >> Assert failed rc >= 0 gb/gprs_bssgp_test.c:229 >> /home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25: >> 8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_ >> bssgp_test >> > > -- best regards, Max, http://fairwaves.co From holger at freyther.de Fri Jun 5 15:36:37 2015 From: holger at freyther.de (Holger Freyther) Date: Fri, 5 Jun 2015 17:36:37 +0200 Subject: segfault on bssgp test In-Reply-To: <55719F24.3050000@fairwaves.co> References: <555F3139.4080206@fairwaves.co> <556C64F3.9040301@fairwaves.co> <55719F24.3050000@fairwaves.co> Message-ID: > On 05 Jun 2015, at 15:07, ? wrote: > > Another person reproduced this on ubuntu 15.04 x86_64. Have anyone else hit it recently? https://build.opensuse.org/package/live_build_log/home:zecke23:stp/libosmocore/xUbuntu_14.04/i586 hits something like this too. Try to understand the difference between debian and the ubuntu toolchain. E.g. does the overload of ?sendto? work with the gold linker? From Max.Suraev at fairwaves.co Fri Jun 5 16:05:30 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Fri, 05 Jun 2015 18:05:30 +0200 Subject: segfault on bssgp test In-Reply-To: References: <555F3139.4080206@fairwaves.co> <556C64F3.9040301@fairwaves.co> <55719F24.3050000@fairwaves.co> Message-ID: <5571C8CA.4030408@fairwaves.co> 05.06.2015 17:36, Holger Freyther ?????: > >> On 05 Jun 2015, at 15:07, ? wrote: >> >> Another person reproduced this on ubuntu 15.04 x86_64. Have anyone else hit it recently? > > > https://build.opensuse.org/package/live_build_log/home:zecke23:stp/libosmocore/xUbuntu_14.04/i586 > > hits something like this too. Try to understand the difference between debian > and the ubuntu toolchain. E.g. does the overload of ?sendto? work with the gold > linker? > Hmm.. so it works on Debian but not on Ubuntu? How do I check if gold is used as linker? -- best regards, Max, http://fairwaves.co From holger at freyther.de Fri Jun 5 16:19:33 2015 From: holger at freyther.de (Holger Freyther) Date: Fri, 5 Jun 2015 18:19:33 +0200 Subject: segfault on bssgp test In-Reply-To: <5571C8CA.4030408@fairwaves.co> References: <555F3139.4080206@fairwaves.co> <556C64F3.9040301@fairwaves.co> <55719F24.3050000@fairwaves.co> <5571C8CA.4030408@fairwaves.co> Message-ID: > On 05 Jun 2015, at 18:05, ? wrote: >> > > Hmm.. so it works on Debian but not on Ubuntu? How do I check if gold is used as linker? it is not only gold. My first suspicion would be to put a break point in sendto and see which is executed (the system one or the overload) From sipos.csaba at kvk.uni-obuda.hu Sun Jun 7 17:13:21 2015 From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba) Date: Sun, 7 Jun 2015 19:13:21 +0200 (CEST) Subject: IPAccess NanoBTS In-Reply-To: <246261887.5665560.1433696702221.JavaMail.root@kvk.uni-obuda.hu> Message-ID: <498727518.5665908.1433697201167.JavaMail.root@kvk.uni-obuda.hu> Dear list, I recently integrated nanoBTS under OpenBSC. They work fine, but I encountered the following limitations. 1. Dynamic PDCH/TCH switching is allowed to be configured, but not working. The timeslots are stuck in TCH/F mode and never converted to PDCH. Is there any trick I need to do other than setting the channel type to TCH/F_PDCH? 2. No matter what I do, the BTS only schedules one uplink timeslot. If I understand it correctly, the PCU implementation in this case is inside the NanoBTS. Is there a way to change for example an NVRAM parameter to allow a more balanced UL/DL timeslot ratio? 3. Multi-TRX setup: it is quite a limitation that you cannot use any timeslots as PDCH in a multi-TRX setup on the secondary or third carriers at all. I don't think there is any solution to that, but it worth noting. I hope someone can point me in the right direction with dyn PDCH switching and the single UL TS issue. Thanks! Regards, Csaba From holger at freyther.de Mon Jun 8 06:12:47 2015 From: holger at freyther.de (Holger Freyther) Date: Mon, 8 Jun 2015 08:12:47 +0200 Subject: Why isn't ARFCN 0 supported? In-Reply-To: References: Message-ID: <98ED51CA-499A-4FAE-8F5D-34F3E550CD0A@freyther.de> > On 10 Apr 2015, at 19:42, Mike McTernan (wavemobile) wrote: Hi, > Is the check "bts->c0->arfcn < 1" erroneous, or am I missing some history? no, it looks erroneous. > Also should it really check for the R-GSM 900 range, or should it be E-GSM (more common)? the ?biggest? band should be fine. The BTS can still OML NACK this ARFCN if it doesn?t support this specific sub-band. From holger at freyther.de Mon Jun 8 06:23:27 2015 From: holger at freyther.de (Holger Freyther) Date: Mon, 8 Jun 2015 08:23:27 +0200 Subject: IPAccess NanoBTS In-Reply-To: <498727518.5665908.1433697201167.JavaMail.root@kvk.uni-obuda.hu> References: <498727518.5665908.1433697201167.JavaMail.root@kvk.uni-obuda.hu> Message-ID: > On 07 Jun 2015, at 19:13, Sipos Csaba wrote: > > > 1. Dynamic PDCH/TCH switching is allowed to be configured, but not working. The timeslots are stuck in TCH/F mode and never converted to PDCH. Is there any trick I need to do other than setting the channel type to TCH/F_PDCH? no supported in master. Andreas has done some work on it but we had one negative results from a customer using that branch. > 2. No matter what I do, the BTS only schedules one uplink timeslot. If I understand it correctly, the PCU implementation in this case is inside the NanoBTS. Is there a way to change for example an NVRAM parameter to allow a more balanced UL/DL timeslot ratio? > 3. Multi-TRX setup: it is quite a limitation that you cannot use any timeslots as PDCH in a multi-TRX setup on the secondary or third carriers at all. I don't think there is any solution to that, but it worth noting. no idea, that is the issue with proprietary solutions. From jerlbeck at sysmocom.de Mon Jun 8 07:06:22 2015 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Mon, 08 Jun 2015 09:06:22 +0200 Subject: bssgp test In-Reply-To: <5571A0F9.7010404@fairwaves.co> References: <5571A0F9.7010404@fairwaves.co> Message-ID: <55753EEE.4010906@sysmocom.de> Hi On 05.06.2015 15:15, ? wrote: > Could you perhaps summarize what's happening around tests/gb/gprs_bssgp_test.c:229? The line before the failing test is rc = bssgp_tx_fc_bvc(&bctx, tag, bmax, rate, bmax_ms, rate_ms, NULL, NULL); The bssgp_tx_fc_bvc function will in general call gprs_ns_sendmsg -> gprs_ns_tx -> nsip_sendmsg -> sendto. The sendto function had been "replaced" by redefining it locally which worked at least with the default ld up to ubuntu 14.04. (see Holger's replies). The system's sendto will fail in the test, since the UDP socket has not been configured. The local replacement (see gprs_bbsgp_test.c:37) will call fprintf(stderr, "MESSAGE to 0x%08x, msg length %d\n%s\n", dest_host, len, osmo_hexdump(buf, len)); so you just need to look into the stderr output to see, whether this is a linker issue. If yes, the issue will appear in more test programs, since that pattern has been used many times. If there is no way to trick the linker to use the "old" behaviour, those test programs will have to be changed to use another mocking mechanism, e.g. by using the --wrap feature (if it is supported by the linker), see openbsc:openbsc/tests/sgsn/sgsn_test.c. HTH Jacob > > The test fails for me (and another person with ubuntu 15.04 x86_64) on OSMO_ASSERT(rc >> = 0); > > This is 100% reproducible but I don't know much about Gb part so I'm not sure how to > track this down properly. Any ideas/advices? > -- - Jacob Erlbeck http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From holger at freyther.de Wed Jun 10 18:11:58 2015 From: holger at freyther.de (Holger Freyther) Date: Wed, 10 Jun 2015 20:11:58 +0200 Subject: test Message-ID: From holger at freyther.de Thu Jun 11 08:19:22 2015 From: holger at freyther.de (Holger Freyther) Date: Thu, 11 Jun 2015 10:19:22 +0200 Subject: measurement report trap/JSON document Message-ID: <0B0B3786-0BDE-4DD7-8D9F-785267859A82@freyther.de> Hi, sorry for the delay from OsmoDevCon to now. Attached is what I proposed in a customer project a long time ago. The idea was to register for traps, version them with vX in the variable name and then send traps as JSON document. holger -------------- next part -------------- A non-text attachment was scrubbed... Name: Measurement_JSON.pdf Type: application/pdf Size: 60914 bytes Desc: not available URL: From holger at freyther.de Mon Jun 15 09:55:35 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jun 2015 11:55:35 +0200 Subject: [PATCH 1/8] nat: Add size check for the payload Message-ID: <1434362142-12650-1-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther The msgb will always have these bytes but it is better practice to verify that the message really has space for the two bytes. --- openbsc/src/osmo-bsc_nat/bsc_nat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 4357485..537001e 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -1185,7 +1185,7 @@ exit: send_reset_ack(bsc); } else if (parsed->ipa_proto == IPAC_PROTO_IPACCESS) { /* do we know who is handling this? */ - if (msg->l2h[0] == IPAC_MSGT_ID_RESP) { + if (msg->l2h[0] == IPAC_MSGT_ID_RESP && msgb_l2len(msg) > 2) { struct tlv_parsed tvp; int ret; ret = ipa_ccm_idtag_parse(&tvp, -- 2.3.5 From holger at freyther.de Mon Jun 15 09:55:36 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jun 2015 11:55:36 +0200 Subject: [PATCH 2/8] nat: Factor out the config by token search In-Reply-To: <1434362142-12650-1-git-send-email-holger@freyther.de> References: <1434362142-12650-1-git-send-email-holger@freyther.de> Message-ID: <1434362142-12650-2-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther In the upcoming authentication improvements it is nice to separate the finding of the config from the post-allow handling of it. --- openbsc/include/openbsc/bsc_nat.h | 1 + openbsc/src/osmo-bsc_nat/bsc_nat.c | 32 +++++++++++++------------------- openbsc/src/osmo-bsc_nat/bsc_nat_utils.c | 18 ++++++++++++++++++ 3 files changed, 32 insertions(+), 19 deletions(-) diff --git a/openbsc/include/openbsc/bsc_nat.h b/openbsc/include/openbsc/bsc_nat.h index ae940b3..6921441 100644 --- a/openbsc/include/openbsc/bsc_nat.h +++ b/openbsc/include/openbsc/bsc_nat.h @@ -319,6 +319,7 @@ struct bsc_nat_ussd_con { /* create and init the structures */ struct bsc_config *bsc_config_alloc(struct bsc_nat *nat, const char *token); struct bsc_config *bsc_config_num(struct bsc_nat *nat, int num); +struct bsc_config *bsc_config_by_token(struct bsc_nat *nat, const char *token, int len); void bsc_config_free(struct bsc_config *); void bsc_config_add_lac(struct bsc_config *cfg, int lac); void bsc_config_del_lac(struct bsc_config *cfg, int lac); diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 537001e..2f186b2 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -980,27 +980,21 @@ static void ipaccess_auth_bsc(struct tlv_parsed *tvp, struct bsc_connection *bsc return; } - llist_for_each_entry(conf, &bsc->nat->bsc_configs, entry) { - /* - * Add the '\0' of the token for the memcmp, the IPA messages - * for some reason added null termination. - */ - const int token_len = strlen(conf->token) + 1; - - if (token_len == len && memcmp(conf->token, token, token_len) == 0) { - rate_ctr_inc(&conf->stats.ctrg->ctr[BCFG_CTR_NET_RECONN]); - bsc->authenticated = 1; - bsc->cfg = conf; - osmo_timer_del(&bsc->id_timeout); - LOGP(DNAT, LOGL_NOTICE, "Authenticated bsc nr: %d on fd %d\n", - conf->nr, bsc->write_queue.bfd.fd); - start_ping_pong(bsc); - return; - } + conf = bsc_config_by_token(bsc->nat, token, len); + if (!conf) { + LOGP(DNAT, LOGL_ERROR, + "No bsc found for token '%s' on fd: %d.\n", token, + bsc->write_queue.bfd.fd); + return; } - LOGP(DNAT, LOGL_ERROR, "No bsc found for token '%s' on fd: %d.\n", token, - bsc->write_queue.bfd.fd); + rate_ctr_inc(&conf->stats.ctrg->ctr[BCFG_CTR_NET_RECONN]); + bsc->authenticated = 1; + bsc->cfg = conf; + osmo_timer_del(&bsc->id_timeout); + LOGP(DNAT, LOGL_NOTICE, "Authenticated bsc nr: %d on fd %d\n", + conf->nr, bsc->write_queue.bfd.fd); + start_ping_pong(bsc); } static void handle_con_stats(struct nat_sccp_connection *con) diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat_utils.c b/openbsc/src/osmo-bsc_nat/bsc_nat_utils.c index d95227d..d7ec545 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat_utils.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat_utils.c @@ -180,6 +180,24 @@ struct bsc_config *bsc_config_alloc(struct bsc_nat *nat, const char *token) return conf; } +struct bsc_config *bsc_config_by_token(struct bsc_nat *nat, const char *token, int len) +{ + struct bsc_config *conf; + + llist_for_each_entry(conf, &nat->bsc_configs, entry) { + /* + * Add the '\0' of the token for the memcmp, the IPA messages + * for some reason added null termination. + */ + const int token_len = strlen(conf->token) + 1; + + if (token_len == len && memcmp(conf->token, token, token_len) == 0) + return conf; + } + + return NULL; +} + void bsc_config_free(struct bsc_config *cfg) { llist_del(&cfg->entry); -- 2.3.5 From holger at freyther.de Mon Jun 15 09:55:38 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jun 2015 11:55:38 +0200 Subject: [PATCH 4/8] bsc/nat: Fix the structure of the identity request message In-Reply-To: <1434362142-12650-1-git-send-email-holger@freyther.de> References: <1434362142-12650-1-git-send-email-holger@freyther.de> Message-ID: <1434362142-12650-4-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther Unfortunately the basic structure of the response is broken. There is a two byte length followed by data. The concept of a 'tag' happens to be the first byte of the data. This means we want to write strlen of the token, then we want to write the NUL and then we need to account for the tag in front. Introduce a flag if the new or old format should be used. This will allow to have new BSCs talk to old NATs without an additional change. In the long run we can clean that up. --- openbsc/include/openbsc/bsc_msc.h | 2 +- openbsc/src/libbsc/bsc_msc.c | 17 +++++++++++++++-- openbsc/src/osmo-bsc/osmo_bsc_msc.c | 2 +- openbsc/src/osmo-bsc_nat/bsc_nat.c | 15 +++++++++++---- 4 files changed, 28 insertions(+), 8 deletions(-) diff --git a/openbsc/include/openbsc/bsc_msc.h b/openbsc/include/openbsc/bsc_msc.h index 763bae5..2eec163 100644 --- a/openbsc/include/openbsc/bsc_msc.h +++ b/openbsc/include/openbsc/bsc_msc.h @@ -60,6 +60,6 @@ void bsc_msc_schedule_connect(struct bsc_msc_connection *); void bsc_msc_lost(struct bsc_msc_connection *); -struct msgb *bsc_msc_id_get_resp(const char *token); +struct msgb *bsc_msc_id_get_resp(int fixed, const char *token); #endif diff --git a/openbsc/src/libbsc/bsc_msc.c b/openbsc/src/libbsc/bsc_msc.c index a24efab..fc4530c 100644 --- a/openbsc/src/libbsc/bsc_msc.c +++ b/openbsc/src/libbsc/bsc_msc.c @@ -276,7 +276,7 @@ void bsc_msc_schedule_connect(struct bsc_msc_connection *con) osmo_timer_schedule(&con->reconnect_timer, 5, 0); } -struct msgb *bsc_msc_id_get_resp(const char *token) +struct msgb *bsc_msc_id_get_resp(int fixed, const char *token) { struct msgb *msg; @@ -291,8 +291,21 @@ struct msgb *bsc_msc_id_get_resp(const char *token) return NULL; } + /* + * The situation is bizarre. The encoding doesn't follow the + * TLV structure. It is more like a LV and old versions had + * it wrong but we want new versions to old servers so we + * introduce the quirk here. + */ msg->l2h = msgb_v_put(msg, IPAC_MSGT_ID_RESP); - msgb_l16tv_put(msg, strlen(token) + 1, + if (fixed) { + msgb_put_u8(msg, 0); + msgb_put_u8(msg, strlen(token) + 2); + msgb_tv_fixed_put(msg, IPAC_IDTAG_UNITNAME, strlen(token) + 1, (uint8_t *) token); + } else { + msgb_l16tv_put(msg, strlen(token) + 1, IPAC_IDTAG_UNITNAME, (uint8_t *) token); + } + return msg; } diff --git a/openbsc/src/osmo-bsc/osmo_bsc_msc.c b/openbsc/src/osmo-bsc/osmo_bsc_msc.c index 129b23e..5127ca8 100644 --- a/openbsc/src/osmo-bsc/osmo_bsc_msc.c +++ b/openbsc/src/osmo-bsc/osmo_bsc_msc.c @@ -456,7 +456,7 @@ static void send_id_get_response(struct osmo_msc_data *data, int fd) struct msc_signal_data sig; struct msgb *msg; - msg = bsc_msc_id_get_resp(data->bsc_token); + msg = bsc_msc_id_get_resp(0, data->bsc_token); if (!msg) return; msc_queue_write(data->msc_con, msg, IPAC_PROTO_IPACCESS); diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 9216654..841262c 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -357,7 +357,7 @@ static void initialize_msc_if_needed(struct bsc_msc_connection *msc_con) static void send_id_get_response(struct bsc_msc_connection *msc_con) { - struct msgb *msg = bsc_msc_id_get_resp(nat->token); + struct msgb *msg = bsc_msc_id_get_resp(0, nat->token); if (!msg) return; @@ -960,7 +960,7 @@ static void ipaccess_auth_bsc(struct tlv_parsed *tvp, struct bsc_connection *bsc { struct bsc_config *conf; const char *token = (const char *) TLVP_VAL(tvp, IPAC_IDTAG_UNITNAME); - const int len = TLVP_LEN(tvp, IPAC_IDTAG_UNITNAME); + int len = TLVP_LEN(tvp, IPAC_IDTAG_UNITNAME); if (bsc->cfg) { LOGP(DNAT, LOGL_ERROR, "Reauth on fd %d bsc nr %d\n", @@ -980,11 +980,18 @@ static void ipaccess_auth_bsc(struct tlv_parsed *tvp, struct bsc_connection *bsc return; } + /* + * New systems have fixed the structure of the message but + * we need to support old ones too. + */ + if (len >= 2 && token[len - 2] == '\0') + len -= 1; + conf = bsc_config_by_token(bsc->nat, token, len); if (!conf) { LOGP(DNAT, LOGL_ERROR, - "No bsc found for token '%s' on fd: %d.\n", token, - bsc->write_queue.bfd.fd); + "No bsc found for token '%s' len %d on fd: %d.\n", token, + bsc->write_queue.bfd.fd, len); bsc_close_connection(bsc); return; } -- 2.3.5 From holger at freyther.de Mon Jun 15 09:55:39 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jun 2015 11:55:39 +0200 Subject: [PATCH 5/8] nat: Provide access to /dev/urandom for the code In-Reply-To: <1434362142-12650-1-git-send-email-holger@freyther.de> References: <1434362142-12650-1-git-send-email-holger@freyther.de> Message-ID: <1434362142-12650-5-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther Instead of doing open/read/close all the time, open the FD in the beginning and keep it open. To scare me even more I have seen /dev/urandom actually providing a short read and then blocking but it seems to be the best way to get the random byes we need for authentication. So one should/could run the cheap random generator on the system (e.g. haveged) or deal with the NAT process to block. --- openbsc/include/openbsc/bsc_nat.h | 3 +++ openbsc/src/osmo-bsc_nat/bsc_nat.c | 9 +++++++++ 2 files changed, 12 insertions(+) diff --git a/openbsc/include/openbsc/bsc_nat.h b/openbsc/include/openbsc/bsc_nat.h index 6921441..1035937 100644 --- a/openbsc/include/openbsc/bsc_nat.h +++ b/openbsc/include/openbsc/bsc_nat.h @@ -304,6 +304,9 @@ struct bsc_nat { /* control interface */ struct ctrl_handle *ctrl; + + /* for random values */ + int random_fd; }; struct bsc_nat_ussd_con { diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 841262c..82562ba 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -21,6 +21,8 @@ * */ #include +#include +#include #include #include #include @@ -31,6 +33,7 @@ #include #include #include +#include #define _GNU_SOURCE #include @@ -1534,6 +1537,12 @@ int main(int argc, char **argv) /* We need to add mode-set for amr codecs */ nat->sdp_ensure_amr_mode_set = 1; + nat->random_fd = open("/dev/random", O_RDONLY); + if (nat->random_fd < 0) { + fprintf(stderr, "Failed to open /dev/urandom.\n"); + return -5; + } + vty_info.copyright = openbsc_copyright; vty_init(&vty_info); logging_vty_add_cmds(&log_info); -- 2.3.5 From holger at freyther.de Mon Jun 15 09:55:40 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jun 2015 11:55:40 +0200 Subject: [PATCH 6/8] nat: Send 16 bytes of rand to the BSC and remember it In-Reply-To: <1434362142-12650-1-git-send-email-holger@freyther.de> References: <1434362142-12650-1-git-send-email-holger@freyther.de> Message-ID: <1434362142-12650-6-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther Generate 16 byte of random data to be used for A3A8 by the BSC in the response. We can't know which BSC it is at this point and I don't want to send another message once the token has been received so always send the data with an undefined code. The old BSCs don't parse the message and will happily ignore the RAND. /dev/urandom can give short reads on Linux so loop around it until the bytes have been read from the kernel. --- openbsc/include/openbsc/bsc_nat.h | 1 + openbsc/src/osmo-bsc_nat/bsc_nat.c | 40 +++++++++++++++++++++++++++++++++++--- 2 files changed, 38 insertions(+), 3 deletions(-) diff --git a/openbsc/include/openbsc/bsc_nat.h b/openbsc/include/openbsc/bsc_nat.h index 1035937..c313e52 100644 --- a/openbsc/include/openbsc/bsc_nat.h +++ b/openbsc/include/openbsc/bsc_nat.h @@ -84,6 +84,7 @@ struct bsc_connection { /* do we know anything about this BSC? */ int authenticated; + uint8_t last_rand[16]; /* the fd we use to communicate */ struct osmo_wqueue write_queue; diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 82562ba..254ea42 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -188,9 +188,9 @@ static void send_id_ack(struct bsc_connection *bsc) bsc_send_data(bsc, id_ack, sizeof(id_ack), IPAC_PROTO_IPACCESS); } -static void send_id_req(struct bsc_connection *bsc) +static void send_id_req(struct bsc_nat *nat, struct bsc_connection *bsc) { - static const uint8_t id_req[] = { + static const uint8_t s_id_req[] = { IPAC_MSGT_ID_GET, 0x01, IPAC_IDTAG_UNIT, 0x01, IPAC_IDTAG_MACADDR, @@ -202,7 +202,41 @@ static void send_id_req(struct bsc_connection *bsc) 0x01, IPAC_IDTAG_SERNR, }; + int toread, rounds; + uint8_t *mrand, *randoff; + uint8_t id_req[sizeof(s_id_req) + (2+16)]; + uint8_t *buf = &id_req[sizeof(s_id_req)]; + + /* copy the static data */ + memcpy(id_req, s_id_req, sizeof(s_id_req)); + + /* put the RAND with length, tag, value */ + buf = v_put(buf, 0x11); + buf = v_put(buf, 0x23); + mrand = bsc->last_rand; + randoff = mrand; + memset(randoff, 0, 16); + + for (toread = 16, rounds = 0; rounds < 5 && toread > 0; ++rounds) { + int rc = read(nat->random_fd, randoff, toread); + if (rc <= 0) + goto failed_random; + toread -= rc; + randoff += rc; + } + + if (toread != 0) + goto failed_random; + memcpy(buf, mrand, 16); + buf += 16; + bsc_send_data(bsc, id_req, sizeof(id_req), IPAC_PROTO_IPACCESS); + return; + +failed_random: + /* the timeout will trigger and close this connection */ + LOGP(DNAT, LOGL_ERROR, "Failed to read from urandom.\n"); + return; } static struct msgb *nat_create_rlsd(struct nat_sccp_connection *conn) @@ -1362,7 +1396,7 @@ static int ipaccess_listen_bsc_cb(struct osmo_fd *bfd, unsigned int what) bsc->last_id = 0; send_id_ack(bsc); - send_id_req(bsc); + send_id_req(nat, bsc); send_mgcp_reset(bsc); /* -- 2.3.5 From holger at freyther.de Mon Jun 15 09:55:41 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jun 2015 11:55:41 +0200 Subject: [PATCH 7/8] bsc: Check for the rand and then generate a res In-Reply-To: <1434362142-12650-1-git-send-email-holger@freyther.de> References: <1434362142-12650-1-git-send-email-holger@freyther.de> Message-ID: <1434362142-12650-7-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther Check if the NAT has sent 16 bytes of RAND and if a key has been configured in the system and then generate a result using milenage. The milenage res will be sent and noth the four byte GSM SRES derivation. --- openbsc/include/openbsc/bsc_msc.h | 2 +- openbsc/include/openbsc/osmo_msc_data.h | 3 ++ openbsc/src/libbsc/bsc_msc.c | 7 +++- openbsc/src/osmo-bsc/osmo_bsc_msc.c | 58 ++++++++++++++++++++++++++++++--- openbsc/src/osmo-bsc/osmo_bsc_vty.c | 29 +++++++++++++++++ openbsc/src/osmo-bsc_nat/bsc_nat.c | 2 +- 6 files changed, 94 insertions(+), 7 deletions(-) diff --git a/openbsc/include/openbsc/bsc_msc.h b/openbsc/include/openbsc/bsc_msc.h index 2eec163..39258d3 100644 --- a/openbsc/include/openbsc/bsc_msc.h +++ b/openbsc/include/openbsc/bsc_msc.h @@ -60,6 +60,6 @@ void bsc_msc_schedule_connect(struct bsc_msc_connection *); void bsc_msc_lost(struct bsc_msc_connection *); -struct msgb *bsc_msc_id_get_resp(int fixed, const char *token); +struct msgb *bsc_msc_id_get_resp(int fixed, const char *token, const uint8_t *res, int len); #endif diff --git a/openbsc/include/openbsc/osmo_msc_data.h b/openbsc/include/openbsc/osmo_msc_data.h index 2d863aa..ed38187 100644 --- a/openbsc/include/openbsc/osmo_msc_data.h +++ b/openbsc/include/openbsc/osmo_msc_data.h @@ -59,6 +59,9 @@ struct osmo_msc_data { /* Connection data */ char *bsc_token; + uint8_t bsc_key[16]; + uint8_t bsc_key_present; + int ping_timeout; int pong_timeout; struct osmo_timer_list ping_timer; diff --git a/openbsc/src/libbsc/bsc_msc.c b/openbsc/src/libbsc/bsc_msc.c index fc4530c..829ee2b 100644 --- a/openbsc/src/libbsc/bsc_msc.c +++ b/openbsc/src/libbsc/bsc_msc.c @@ -276,7 +276,7 @@ void bsc_msc_schedule_connect(struct bsc_msc_connection *con) osmo_timer_schedule(&con->reconnect_timer, 5, 0); } -struct msgb *bsc_msc_id_get_resp(int fixed, const char *token) +struct msgb *bsc_msc_id_get_resp(int fixed, const char *token, const uint8_t *res, int len) { struct msgb *msg; @@ -302,6 +302,11 @@ struct msgb *bsc_msc_id_get_resp(int fixed, const char *token) msgb_put_u8(msg, 0); msgb_put_u8(msg, strlen(token) + 2); msgb_tv_fixed_put(msg, IPAC_IDTAG_UNITNAME, strlen(token) + 1, (uint8_t *) token); + if (len > 0) { + msgb_put_u8(msg, 0); + msgb_put_u8(msg, len + 1); + msgb_tv_fixed_put(msg, 0x24, len, res); + } } else { msgb_l16tv_put(msg, strlen(token) + 1, IPAC_IDTAG_UNITNAME, (uint8_t *) token); diff --git a/openbsc/src/osmo-bsc/osmo_bsc_msc.c b/openbsc/src/osmo-bsc/osmo_bsc_msc.c index 5127ca8..773ee14 100644 --- a/openbsc/src/osmo-bsc/osmo_bsc_msc.c +++ b/openbsc/src/osmo-bsc/osmo_bsc_msc.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include @@ -44,7 +45,7 @@ static void initialize_if_needed(struct bsc_msc_connection *conn); static void send_lacs(struct gsm_network *net, struct bsc_msc_connection *conn); -static void send_id_get_response(struct osmo_msc_data *data, int fd); +static void send_id_get_response(struct osmo_msc_data *data, int fd, struct msgb *inp); static void send_ping(struct osmo_msc_data *data); static void schedule_ping_pong(struct osmo_msc_data *data); @@ -302,7 +303,7 @@ static int ipaccess_a_fd_cb(struct osmo_fd *bfd) if (msg->l2h[0] == IPAC_MSGT_ID_ACK) initialize_if_needed(data->msc_con); else if (msg->l2h[0] == IPAC_MSGT_ID_GET) { - send_id_get_response(data, bfd->fd); + send_id_get_response(data, bfd->fd, msg); } else if (msg->l2h[0] == IPAC_MSGT_PONG) { osmo_timer_del(&data->pong_timer); } @@ -451,12 +452,61 @@ static void initialize_if_needed(struct bsc_msc_connection *conn) } } -static void send_id_get_response(struct osmo_msc_data *data, int fd) +static int answer_challenge(struct osmo_msc_data *data, struct msgb *inp, struct osmo_auth_vector *vec) +{ + int ret; + struct tlv_parsed tvp; + const uint8_t *mrand; + uint8_t mrand_len; + struct osmo_sub_auth_data auth = { + .type = OSMO_AUTH_TYPE_GSM, + .algo = OSMO_AUTH_ALG_MILENAGE, + }; + + ret = ipa_ccm_idtag_parse_off(&tvp, + inp->l2h + 1, + msgb_l2len(inp) - 1, 1); + if (ret < 0) { + LOGP(DMSC, LOGL_ERROR, "ignoring IPA response " + "message with malformed TLVs: %s\n", osmo_hexdump(inp->l2h + 1, + msgb_l2len(inp) - 1)); + return 0; + } + + mrand = TLVP_VAL(&tvp, 0x23); + mrand_len = TLVP_LEN(&tvp, 0x23); + if (mrand_len != 16) { + LOGP(DMSC, LOGL_ERROR, + "RAND is not 16 bytes. Was %d\n", + mrand_len); + return 0; + } + + /* copy the key */ + memcpy(auth.u.umts.opc, data->bsc_key, 16); + memcpy(auth.u.umts.k, data->bsc_key, 16); + memset(auth.u.umts.amf, 0, 2); + auth.u.umts.sqn = 0; + + /* generate the result */ + memset(vec, 0, sizeof(*vec)); + osmo_auth_gen_vec(vec, &auth, mrand); + return 1; +} + + +static void send_id_get_response(struct osmo_msc_data *data, int fd, struct msgb *inp) { struct msc_signal_data sig; struct msgb *msg; + struct osmo_auth_vector vec; + int valid = 0; + + if (data->bsc_key_present) + valid = answer_challenge(data, inp, &vec); - msg = bsc_msc_id_get_resp(0, data->bsc_token); + msg = bsc_msc_id_get_resp(valid, data->bsc_token, + vec.res, valid ? vec.res_len : 0); if (!msg) return; msc_queue_write(data->msc_con, msg, IPAC_PROTO_IPACCESS); diff --git a/openbsc/src/osmo-bsc/osmo_bsc_vty.c b/openbsc/src/osmo-bsc/osmo_bsc_vty.c index 06ad77d..9a17cd0 100644 --- a/openbsc/src/osmo-bsc/osmo_bsc_vty.c +++ b/openbsc/src/osmo-bsc/osmo_bsc_vty.c @@ -107,6 +107,9 @@ static void write_msc(struct vty *vty, struct osmo_msc_data *msc) vty_out(vty, "msc %d%s", msc->nr, VTY_NEWLINE); if (msc->bsc_token) vty_out(vty, " token %s%s", msc->bsc_token, VTY_NEWLINE); + if (msc->bsc_key_present) + vty_out(vty, " auth-key %s%s", + osmo_hexdump(msc->bsc_key, sizeof(msc->bsc_key)), VTY_NEWLINE); if (msc->core_ncc != -1) vty_out(vty, " core-mobile-network-code %d%s", msc->core_ncc, VTY_NEWLINE); @@ -231,6 +234,30 @@ DEFUN(cfg_net_bsc_token, return CMD_SUCCESS; } +DEFUN(cfg_net_bsc_key, + cfg_net_bsc_key_cmd, + "auth-key KEY", + "Authentication (secret) key configuration\n" + "Security key\n") +{ + struct osmo_msc_data *data = osmo_msc_data(vty); + + osmo_hexparse(argv[0], data->bsc_key, sizeof(data->bsc_key)); + data->bsc_key_present = 1; + return CMD_SUCCESS; +} + +DEFUN(cfg_net_no_bsc_key, cfg_net_bsc_no_key_cmd, + "no auth-key", + NO_STR "Authentication (secret) key configuration\n") +{ + struct osmo_msc_data *data = osmo_msc_data(vty); + + memset(data->bsc_key, 0, sizeof(data->bsc_key)); + data->bsc_key_present = 0; + return CMD_SUCCESS; +} + DEFUN(cfg_net_bsc_ncc, cfg_net_bsc_ncc_cmd, "core-mobile-network-code <1-999>", @@ -871,6 +898,8 @@ int bsc_vty_init_extra(void) install_node(&msc_node, config_write_msc); vty_install_default(MSC_NODE); install_element(MSC_NODE, &cfg_net_bsc_token_cmd); + install_element(MSC_NODE, &cfg_net_bsc_key_cmd); + install_element(MSC_NODE, &cfg_net_bsc_no_key_cmd); install_element(MSC_NODE, &cfg_net_bsc_ncc_cmd); install_element(MSC_NODE, &cfg_net_bsc_mcc_cmd); install_element(MSC_NODE, &cfg_net_bsc_lac_cmd); diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 254ea42..9837709 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -394,7 +394,7 @@ static void initialize_msc_if_needed(struct bsc_msc_connection *msc_con) static void send_id_get_response(struct bsc_msc_connection *msc_con) { - struct msgb *msg = bsc_msc_id_get_resp(0, nat->token); + struct msgb *msg = bsc_msc_id_get_resp(0, nat->token, NULL, 0); if (!msg) return; -- 2.3.5 From holger at freyther.de Mon Jun 15 09:55:42 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jun 2015 11:55:42 +0200 Subject: [PATCH 8/8] nat: After we identified the bsc check the key In-Reply-To: <1434362142-12650-1-git-send-email-holger@freyther.de> References: <1434362142-12650-1-git-send-email-holger@freyther.de> Message-ID: <1434362142-12650-8-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther We are using the token to find the right bsc_config and then we can use the last_rand of the bsc_connection to calculate the expected result and try to compare it with a time constant(???) memcmp. --- openbsc/include/openbsc/bsc_nat.h | 2 ++ openbsc/src/osmo-bsc_nat/bsc_nat.c | 61 ++++++++++++++++++++++++++++++++-- openbsc/src/osmo-bsc_nat/bsc_nat_vty.c | 32 ++++++++++++++++-- 3 files changed, 91 insertions(+), 4 deletions(-) diff --git a/openbsc/include/openbsc/bsc_nat.h b/openbsc/include/openbsc/bsc_nat.h index c313e52..72773a9 100644 --- a/openbsc/include/openbsc/bsc_nat.h +++ b/openbsc/include/openbsc/bsc_nat.h @@ -148,6 +148,8 @@ enum bsc_cfg_ctr { struct bsc_config { struct llist_head entry; + uint8_t key[16]; + uint8_t key_present; char *token; int nr; diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 9837709..581193e 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -51,6 +51,8 @@ #include #include +#include + #include #include @@ -993,11 +995,57 @@ static void ipaccess_close_bsc(void *data) bsc_close_connection(conn); } +/* Wishful thinking to generate a constant time compare */ +static int constant_time_cmp(const uint8_t *exp, const uint8_t *rel, const int count) +{ + int x = 0, i; + + for (i = 0; i < count; ++i) + x |= exp[i] ^ rel[i]; + + return x != 0; +} + +static int verify_key(struct bsc_connection *conn, struct bsc_config *conf, const uint8_t *key, const int keylen) +{ + struct osmo_auth_vector vec; + + struct osmo_sub_auth_data auth = { + .type = OSMO_AUTH_TYPE_GSM, + .algo = OSMO_AUTH_ALG_MILENAGE, + }; + + /* expect a specific keylen */ + if (keylen != 8) { + LOGP(DNAT, LOGL_ERROR, "Key length is wrong: %d for bsc nr %d\n", + keylen, conf->nr); + return 0; + } + + memcpy(auth.u.umts.opc, conf->key, 16); + memcpy(auth.u.umts.k, conf->key, 16); + memset(auth.u.umts.amf, 0, 2); + auth.u.umts.sqn = 0; + + memset(&vec, 0, sizeof(vec)); + osmo_auth_gen_vec(&vec, &auth, conn->last_rand); + + if (vec.res_len != 8) { + LOGP(DNAT, LOGL_ERROR, "Res length is wrong: %d for bsc nr %d\n", + keylen, conf->nr); + return 0; + } + + return constant_time_cmp(vec.res, key, 8) == 0; +} + static void ipaccess_auth_bsc(struct tlv_parsed *tvp, struct bsc_connection *bsc) { struct bsc_config *conf; const char *token = (const char *) TLVP_VAL(tvp, IPAC_IDTAG_UNITNAME); int len = TLVP_LEN(tvp, IPAC_IDTAG_UNITNAME); + const uint8_t *xres = TLVP_VAL(tvp, 0x24); + const int xlen = TLVP_LEN(tvp, 0x24); if (bsc->cfg) { LOGP(DNAT, LOGL_ERROR, "Reauth on fd %d bsc nr %d\n", @@ -1033,6 +1081,15 @@ static void ipaccess_auth_bsc(struct tlv_parsed *tvp, struct bsc_connection *bsc return; } + /* We have set a key and expect it to be present */ + if (conf->key_present && !verify_key(bsc, conf, xres, xlen - 1)) { + LOGP(DNAT, LOGL_ERROR, + "Wrong key for bsc nr %d fd: %d.\n", conf->nr, + bsc->write_queue.bfd.fd); + bsc_close_connection(bsc); + return; + } + rate_ctr_inc(&conf->stats.ctrg->ctr[BCFG_CTR_NET_RECONN]); bsc->authenticated = 1; bsc->cfg = conf; @@ -1227,9 +1284,9 @@ exit: if (msg->l2h[0] == IPAC_MSGT_ID_RESP && msgb_l2len(msg) > 2) { struct tlv_parsed tvp; int ret; - ret = ipa_ccm_idtag_parse(&tvp, + ret = ipa_ccm_idtag_parse_off(&tvp, (unsigned char *) msg->l2h + 2, - msgb_l2len(msg) - 2); + msgb_l2len(msg) - 2, 0); if (ret < 0) { LOGP(DNAT, LOGL_ERROR, "ignoring IPA response " "message with malformed TLVs\n"); diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c b/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c index 821e522..981168c 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat_vty.c @@ -1,6 +1,6 @@ /* OpenBSC NAT interface to quagga VTY */ -/* (C) 2010-2013 by Holger Hans Peter Freyther - * (C) 2010-2013 by On-Waves +/* (C) 2010-2015 by Holger Hans Peter Freyther + * (C) 2010-2015 by On-Waves * All Rights Reserved * * This program is free software; you can redistribute it and/or modify @@ -151,6 +151,8 @@ static void config_write_bsc_single(struct vty *vty, struct bsc_config *bsc) { vty_out(vty, " bsc %u%s", bsc->nr, VTY_NEWLINE); vty_out(vty, " token %s%s", bsc->token, VTY_NEWLINE); + if (bsc->key_present) + vty_out(vty, " auth-key %s%s", osmo_hexdump(bsc->key, 16), VTY_NEWLINE); dump_lac(vty, &bsc->lac_list); if (bsc->description) vty_out(vty, " description %s%s", bsc->description, VTY_NEWLINE); @@ -814,6 +816,30 @@ DEFUN(cfg_bsc_token, cfg_bsc_token_cmd, "token TOKEN", return CMD_SUCCESS; } +DEFUN(cfg_bsc_auth_key, cfg_bsc_auth_key_cmd, + "auth-key KEY", + "Authentication (secret) key configuration\n" + "Non null security key\n") +{ + struct bsc_config *conf = vty->index; + + memset(conf->key, 0, sizeof(conf->key)); + osmo_hexparse(argv[0], conf->key, sizeof(conf->key)); + conf->key_present = 1; + return CMD_SUCCESS; +} + +DEFUN(cfg_bsc_no_auth_key, cfg_bsc_no_auth_key_cmd, + "no auth-key", + NO_STR "Authentication (secret) key configuration\n") +{ + struct bsc_config *conf = vty->index; + + memset(conf->key, 0, sizeof(conf->key)); + conf->key_present = 0; + return CMD_SUCCESS; +} + DEFUN(cfg_bsc_lac, cfg_bsc_lac_cmd, "location_area_code <0-65535>", "Add the Location Area Code (LAC) of this BSC\n" "LAC\n") { @@ -1202,6 +1228,8 @@ int bsc_nat_vty_init(struct bsc_nat *nat) install_node(&bsc_node, config_write_bsc); vty_install_default(NAT_BSC_NODE); install_element(NAT_BSC_NODE, &cfg_bsc_token_cmd); + install_element(NAT_BSC_NODE, &cfg_bsc_auth_key_cmd); + install_element(NAT_BSC_NODE, &cfg_bsc_no_auth_key_cmd); install_element(NAT_BSC_NODE, &cfg_bsc_lac_cmd); install_element(NAT_BSC_NODE, &cfg_bsc_no_lac_cmd); install_element(NAT_BSC_NODE, &cfg_bsc_paging_cmd); -- 2.3.5 From holger at freyther.de Mon Jun 15 09:55:37 2015 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 15 Jun 2015 11:55:37 +0200 Subject: [PATCH 3/8] nat: Close the connection after we couldn't find the user In-Reply-To: <1434362142-12650-1-git-send-email-holger@freyther.de> References: <1434362142-12650-1-git-send-email-holger@freyther.de> Message-ID: <1434362142-12650-3-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther In case the token was not correct, just close the connection. It is not clear that forcing a new TCP connection is going to give us any extra security here. But with the upcoming auth handling it does make sense to have both case look similar. --- openbsc/src/osmo-bsc_nat/bsc_nat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c index 2f186b2..9216654 100644 --- a/openbsc/src/osmo-bsc_nat/bsc_nat.c +++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c @@ -985,6 +985,7 @@ static void ipaccess_auth_bsc(struct tlv_parsed *tvp, struct bsc_connection *bsc LOGP(DNAT, LOGL_ERROR, "No bsc found for token '%s' on fd: %d.\n", token, bsc->write_queue.bfd.fd); + bsc_close_connection(bsc); return; } -- 2.3.5 From Alexander.Chemeris at fairwaves.co Mon Jun 15 19:01:08 2015 From: Alexander.Chemeris at fairwaves.co (Alexander Chemeris) Date: Mon, 15 Jun 2015 15:01:08 -0400 Subject: [PATCH 1/2] libbsc: Abstract out SIs update/generation for a BTS into a separate function. In-Reply-To: References: Message-ID: On Jun 2, 2015 8:45 AM, "Holger Freyther" wrote: > > > > On 30 May 2015, at 21:42, Alexander Chemeris < Alexander.Chemeris at fairwaves.co> wrote: > > Dear Alexander, > > > The code to do that doesn't belong to the control interface, so abstract it out > > to a separate function gsm_bts_set_system_infos(). > > please send the patch inline so one can comment on it. I have applied it and fixed > the wrong curly braces. Please attempt to obey the coding-style. Thank you. Will send in-line. Sorry for the coding style. Having switch between a few, I sometimes lose track of where I am. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Mon Jun 15 19:01:08 2015 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 15 Jun 2015 15:01:08 -0400 Subject: [PATCH 2/2] libbsc: Update a BTS's SIs when ms_max_power is changed from VTY. In-Reply-To: <4CA5C18A-8CCB-4669-B686-C773515BC5C4@freyther.de> References: <4CA5C18A-8CCB-4669-B686-C773515BC5C4@freyther.de> Message-ID: On Jun 2, 2015 9:26 AM, "Holger Freyther" wrote: > > > > On 30 May 2015, at 21:43, Alexander Chemeris < alexander.chemeris at gmail.com> wrote: > > > > Otherwise you have to restart BTS or at least break the RSL connection > > to apply the change. > > Yes we certainly should apply modifications at runtime but probably not by adding > auto-update to each command. When I change LAC/CI/ms_max_power I don?t want > to update the SI three times. > > We really need to have a ?commit?/?apply? kind of command that applies OML and > RSL modifications. I agree that transactional functionality would be nice and I had been thinking about this. But it's a big change which should be well planned and requires considerable effort to go through all commands and split configuration from application. One issue is that we'll need to create "shadow" registers for the non applied settings. E.g. in case of power control, the setting was actually applied at the BSC part of the control (it was using the setting variable directly), but was not propagated to the BTS party, which was really confusing from a user perspective. In short - I agree that such feature would be nice, but I don't think this is a showstopper for this patch, because it just makes things more consistent. Btw, control interface also applies the change immediately. Having vty and control to diverge is quite confusing. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Mon Jun 15 19:01:08 2015 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 15 Jun 2015 15:01:08 -0400 Subject: [PATCH] libmsc: Improve 'max_power_red' VTY command. In-Reply-To: <0452E324-EBF6-4E69-B3BA-190D91A8D777@freyther.de> References: <0452E324-EBF6-4E69-B3BA-190D91A8D777@freyther.de> Message-ID: On Jun 2, 2015 8:40 AM, "Holger Freyther" wrote: > > > > On 30 May 2015, at 20:59, Alexander Chemeris < alexander.chemeris at gmail.com> wrote: > > Dear Alexander, > > > > * Apply change even if the supplied value is higher than the 24dB maximum > > suggested by the standard, just warn about this. > > UmSITE and probably other SDR based BTS support much wider power > > regulation range. > > this certainly makes sense. We need to check in osmo-bts that ?24 dB? in > reduction does not exceed the maximum. Yes. I guess it's up to the BTS model to check that. > > Changes: > > > * Apply change to the BTS over OML immediately. > > that is nice but there is a bigger picture. Do we really want/can/need change > all VTY. We are certainly lacking in terms of live modification capabilities but > this path to add them might not be the right one. You might want to change > two parameters at once (switch the ARFCN and then use a higher output?). > > In the long-run I think we need to separate the running config from the one > that can be configured and with an ?apply? you can then move the config around. > I am hesitant to merge a hunk like this right now wihtout having a goal/target > to improve the entire situation. See my reply in the other email. We can certainly discuss future, but I don't think it should hold a patch improving the current situation. > > * Apply change even if the supplied value is odd, just warn that it is rounded. > > Previously the value was not set at all, which may have lead to a situation when > > a user thinks the BTS operating at low power, while it is running full power. > > No we should not round. We could change the VTY command to list 0|2|4.. > 22|24|26.. Good idea. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at rotty.xx.vu Tue Jun 16 21:23:27 2015 From: mail at rotty.xx.vu (Andreas Rottmann) Date: Tue, 16 Jun 2015 23:23:27 +0200 Subject: openbsc: build system tweaks Message-ID: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> Here are a bunch of buildsystem tweaks for openbsc. I'm not sure whether it is warranted to group them as a patch series, as they are (should be) independent of each other. From mail at rotty.xx.vu Tue Jun 16 21:23:28 2015 From: mail at rotty.xx.vu (Andreas Rottmann) Date: Tue, 16 Jun 2015 23:23:28 +0200 Subject: [PATCH 1/4] Fix build wrt. missing CFLAGS constituents In-Reply-To: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> Message-ID: <1434489811-10097-2-git-send-email-mail@rotty.xx.vu> From: Andreas Rottmann When libosmo-netif and/or libosmo-abis are installed in distinct prefixes, the build failed with non-found headers. --- openbsc/src/libfilter/Makefile.am | 2 +- openbsc/src/libtrau/Makefile.am | 2 +- openbsc/src/osmo-bsc/Makefile.am | 2 +- openbsc/src/osmo-bsc_mgcp/Makefile.am | 3 ++- openbsc/tests/gbproxy/Makefile.am | 2 +- openbsc/tests/gprs/Makefile.am | 2 +- openbsc/tests/mgcp/Makefile.am | 2 +- 7 files changed, 8 insertions(+), 7 deletions(-) diff --git a/openbsc/src/libfilter/Makefile.am b/openbsc/src/libfilter/Makefile.am index 4dbc590..ed3cd43 100644 --- a/openbsc/src/libfilter/Makefile.am +++ b/openbsc/src/libfilter/Makefile.am @@ -1,6 +1,6 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) \ - $(LIBOSMOVTY_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) + $(LIBOSMOVTY_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(LIBOSMOSCCP_CFLAGS) $(COVERAGE_CFLAGS) noinst_LIBRARIES = libfilter.a diff --git a/openbsc/src/libtrau/Makefile.am b/openbsc/src/libtrau/Makefile.am index 0c8cf17..0fe3a53 100644 --- a/openbsc/src/libtrau/Makefile.am +++ b/openbsc/src/libtrau/Makefile.am @@ -1,5 +1,5 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) -AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) +AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(LIBOSMONETIF_CFLAGS) $(COVERAGE_CFLAGS) AM_LDFLAGS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOABIS_LIBS) $(COVERAGE_LDFLAGS) noinst_LIBRARIES = libtrau.a diff --git a/openbsc/src/osmo-bsc/Makefile.am b/openbsc/src/osmo-bsc/Makefile.am index b4a2cba..69b363b 100644 --- a/openbsc/src/osmo-bsc/Makefile.am +++ b/openbsc/src/osmo-bsc/Makefile.am @@ -1,5 +1,5 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) -AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LIBOSMOCTRL_CFLAGS) $(LIBOSMOSCCP_CFLAGS) $(COVERAGE_CFLAGS) $(LIBOSMOABIS_CFLAGS) +AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(LIBOSMOCTRL_CFLAGS) $(LIBOSMONETIF_CFLAGS) $(LIBOSMOSCCP_CFLAGS) $(COVERAGE_CFLAGS) $(LIBOSMOABIS_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) bin_PROGRAMS = osmo-bsc diff --git a/openbsc/src/osmo-bsc_mgcp/Makefile.am b/openbsc/src/osmo-bsc_mgcp/Makefile.am index fba76b4..c62131b 100644 --- a/openbsc/src/osmo-bsc_mgcp/Makefile.am +++ b/openbsc/src/osmo-bsc_mgcp/Makefile.am @@ -1,6 +1,7 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) \ - $(LIBOSMOVTY_CFLAGS) $(LIBOSMOABIS_CFLAGS) $(COVERAGE_CFLAGS) + $(LIBOSMOVTY_CFLAGS) $(LIBOSMOABIS_CFLAGS) \ + $(LIBOSMONETIF_CFLAGS) $(COVERAGE_CFLAGS) bin_PROGRAMS = osmo-bsc_mgcp diff --git a/openbsc/tests/gbproxy/Makefile.am b/openbsc/tests/gbproxy/Makefile.am index f6dd785..4577e3a 100644 --- a/openbsc/tests/gbproxy/Makefile.am +++ b/openbsc/tests/gbproxy/Makefile.am @@ -1,5 +1,5 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) +AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOABIS_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) EXTRA_DIST = gbproxy_test.ok diff --git a/openbsc/tests/gprs/Makefile.am b/openbsc/tests/gprs/Makefile.am index 616042b..633c362 100644 --- a/openbsc/tests/gprs/Makefile.am +++ b/openbsc/tests/gprs/Makefile.am @@ -1,5 +1,5 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) +AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOABIS_CFLAGS) EXTRA_DIST = gprs_test.ok diff --git a/openbsc/tests/mgcp/Makefile.am b/openbsc/tests/mgcp/Makefile.am index ce9e596..08fde85 100644 --- a/openbsc/tests/mgcp/Makefile.am +++ b/openbsc/tests/mgcp/Makefile.am @@ -1,5 +1,5 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_srcdir) -AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMOSCCP_CFLAGS) $(COVERAGE_CFLAGS) $(LIBBCG729_CFLAGS) +AM_CFLAGS=-Wall -ggdb3 $(LIBOSMOCORE_CFLAGS) $(LIBOSMONETIF_CFLAGS) $(LIBOSMOSCCP_CFLAGS) $(COVERAGE_CFLAGS) $(LIBBCG729_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) EXTRA_DIST = mgcp_test.ok mgcp_transcoding_test.ok -- 2.1.4 From mail at rotty.xx.vu Tue Jun 16 21:23:29 2015 From: mail at rotty.xx.vu (Andreas Rottmann) Date: Tue, 16 Jun 2015 23:23:29 +0200 Subject: [PATCH 2/4] Add subdir-objects automake option In-Reply-To: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> Message-ID: <1434489811-10097-3-git-send-email-mail@rotty.xx.vu> From: Andreas Rottmann Having subdir-objects enabled is recommended by automake 1.14, to avoid future incompatibilities. However, adding that option breaks out-of-tree builds, and also seems to break "make distclean" for in-tree builds. The reason is that apparently, automake with subdir-objects enabled cannot cope with source files in a different, non-child directory. To avoid that, we simply compile the files referenced in this way into a static library in their own source directory, and instead of referencing the source files, we link against that library. Besides making the build system a bit more future proof, this change also potentially enhances build times, as it reduces the number of compiler invocations, in exchange a slight increase of "ar" invocations. --- openbsc/configure.ac | 2 +- openbsc/src/gprs/Makefile.am | 20 ++++++++++++-------- openbsc/src/osmo-bsc_nat/Makefile.am | 7 +++++-- openbsc/tests/bsc-nat-trie/Makefile.am | 6 +++--- openbsc/tests/bsc-nat/Makefile.am | 11 +++-------- openbsc/tests/bsc/Makefile.am | 6 +++--- openbsc/tests/gprs/Makefile.am | 6 +++--- openbsc/tests/smpp/Makefile.am | 7 ++++--- 8 files changed, 34 insertions(+), 31 deletions(-) diff --git a/openbsc/configure.ac b/openbsc/configure.ac index fb6feb9..e022393 100644 --- a/openbsc/configure.ac +++ b/openbsc/configure.ac @@ -3,7 +3,7 @@ AC_INIT([openbsc], m4_esyscmd([./git-version-gen .tarball-version]), [openbsc at lists.osmocom.org]) -AM_INIT_AUTOMAKE([dist-bzip2]) +AM_INIT_AUTOMAKE([subdir-objects dist-bzip2]) AC_CONFIG_TESTDIR(tests) dnl kernel style compile messages diff --git a/openbsc/src/gprs/Makefile.am b/openbsc/src/gprs/Makefile.am index f46a402..9765cdd 100644 --- a/openbsc/src/gprs/Makefile.am +++ b/openbsc/src/gprs/Makefile.am @@ -16,18 +16,22 @@ bin_PROGRAMS += osmo-sgsn endif endif +noinst_LIBRARIES = libgprs.a + +libgprs_a_SOURCES = gprs_gb_parse.c crc24.c gprs_utils.c \ + gprs_llc.c gprs_llc_parse.c gprs_llc_vty.c \ + gprs_subscriber.c \ + gprs_gsup_messages.c gprs_gsup_client.c + osmo_gbproxy_SOURCES = gb_proxy.c gb_proxy_main.c gb_proxy_vty.c \ - gb_proxy_patch.c gb_proxy_tlli.c gb_proxy_peer.c \ - gprs_gb_parse.c gprs_llc_parse.c crc24.c gprs_utils.c -osmo_gbproxy_LDADD = $(top_builddir)/src/libcommon/libcommon.a \ + gb_proxy_patch.c gb_proxy_tlli.c gb_proxy_peer.c +osmo_gbproxy_LDADD = libgprs.a $(top_builddir)/src/libcommon/libcommon.a \ $(OSMO_LIBS) -lrt osmo_sgsn_SOURCES = gprs_gmm.c gprs_sgsn.c gprs_sndcp.c gprs_sndcp_vty.c \ sgsn_main.c sgsn_vty.c sgsn_libgtp.c \ - gprs_llc.c gprs_llc_parse.c gprs_llc_vty.c crc24.c \ - sgsn_ctrl.c sgsn_auth.c gprs_subscriber.c \ - gprs_gsup_messages.c gprs_utils.c gprs_gsup_client.c \ - gsm_04_08_gprs.c sgsn_cdr.c sgsn_ares.c -osmo_sgsn_LDADD = \ + sgsn_ctrl.c sgsn_auth.c \ + gsm_04_08_gprs.c sgsn_cdr.c +osmo_sgsn_LDADD = libgprs.a \ $(top_builddir)/src/libcommon/libcommon.a \ -lgtp $(OSMO_LIBS) $(LIBOSMOABIS_LIBS) $(LIBCARES_LIBS) -lrt diff --git a/openbsc/src/osmo-bsc_nat/Makefile.am b/openbsc/src/osmo-bsc_nat/Makefile.am index d96a391..a38d68a 100644 --- a/openbsc/src/osmo-bsc_nat/Makefile.am +++ b/openbsc/src/osmo-bsc_nat/Makefile.am @@ -3,12 +3,15 @@ AM_CFLAGS=-Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) bin_PROGRAMS = osmo-bsc_nat +noinst_LIBRARIES = libbsc_nat.a - -osmo_bsc_nat_SOURCES = bsc_filter.c bsc_mgcp_utils.c bsc_nat.c bsc_nat_utils.c \ +libbsc_nat_a_SOURCES = \ + bsc_filter.c bsc_mgcp_utils.c bsc_nat_utils.c \ bsc_nat_vty.c bsc_sccp.c bsc_ussd.c bsc_nat_ctrl.c \ bsc_nat_rewrite.c bsc_nat_rewrite_trie.c bsc_nat_filter.c +osmo_bsc_nat_SOURCES = bsc_nat.c osmo_bsc_nat_LDADD = \ + libbsc_nat.a \ $(top_builddir)/src/libmgcp/libmgcp.a \ $(top_builddir)/src/libbsc/libbsc.a \ $(top_builddir)/src/libtrau/libtrau.a \ diff --git a/openbsc/tests/bsc-nat-trie/Makefile.am b/openbsc/tests/bsc-nat-trie/Makefile.am index cf8ebaf..64c71ba 100644 --- a/openbsc/tests/bsc-nat-trie/Makefile.am +++ b/openbsc/tests/bsc-nat-trie/Makefile.am @@ -6,9 +6,9 @@ EXTRA_DIST = bsc_nat_trie_test.ok prefixes.csv noinst_PROGRAMS = bsc_nat_trie_test -bsc_nat_trie_test_SOURCES = bsc_nat_trie_test.c \ - $(top_srcdir)/src/osmo-bsc_nat/bsc_nat_rewrite_trie.c -bsc_nat_trie_test_LDADD = $(top_builddir)/src/libbsc/libbsc.a \ +bsc_nat_trie_test_SOURCES = bsc_nat_trie_test.c +bsc_nat_trie_test_LDADD = $(top_builddir)/src/osmo-bsc_nat/libbsc_nat.a \ + $(top_builddir)/src/libbsc/libbsc.a \ $(top_builddir)/src/libmgcp/libmgcp.a \ $(top_builddir)/src/libtrau/libtrau.a \ $(top_builddir)/src/libcommon/libcommon.a \ diff --git a/openbsc/tests/bsc-nat/Makefile.am b/openbsc/tests/bsc-nat/Makefile.am index 26e5500..c1a5b1a 100644 --- a/openbsc/tests/bsc-nat/Makefile.am +++ b/openbsc/tests/bsc-nat/Makefile.am @@ -6,15 +6,10 @@ EXTRA_DIST = bsc_nat_test.ok bsc_data.c barr.cfg barr_dup.cfg prefixes.csv noinst_PROGRAMS = bsc_nat_test -bsc_nat_test_SOURCES = bsc_nat_test.c \ - $(top_srcdir)/src/osmo-bsc_nat/bsc_filter.c \ - $(top_srcdir)/src/osmo-bsc_nat/bsc_sccp.c \ - $(top_srcdir)/src/osmo-bsc_nat/bsc_nat_utils.c \ - $(top_srcdir)/src/osmo-bsc_nat/bsc_nat_rewrite.c \ - $(top_srcdir)/src/osmo-bsc_nat/bsc_nat_rewrite_trie.c \ - $(top_srcdir)/src/osmo-bsc_nat/bsc_mgcp_utils.c \ - $(top_srcdir)/src/osmo-bsc_nat/bsc_nat_filter.c +bsc_nat_test_SOURCES = bsc_nat_test.c + bsc_nat_test_LDADD = \ + $(top_builddir)/src/osmo-bsc_nat/libbsc_nat.a \ $(top_builddir)/src/libfilter/libfilter.a \ $(top_builddir)/src/libbsc/libbsc.a \ $(top_builddir)/src/libmgcp/libmgcp.a \ diff --git a/openbsc/tests/bsc/Makefile.am b/openbsc/tests/bsc/Makefile.am index 8b786ff..7c3a219 100644 --- a/openbsc/tests/bsc/Makefile.am +++ b/openbsc/tests/bsc/Makefile.am @@ -6,9 +6,9 @@ EXTRA_DIST = bsc_test.ok noinst_PROGRAMS = bsc_test -bsc_test_SOURCES = bsc_test.c \ - $(top_srcdir)/src/osmo-bsc/osmo_bsc_filter.c -bsc_test_LDADD = $(top_builddir)/src/libbsc/libbsc.a \ +bsc_test_SOURCES = bsc_test.c +bsc_test_LDADD = $(top_builddir)/src/osmo-bsc/libbsc.a \ + $(top_builddir)/src/libbsc/libbsc.a \ $(top_builddir)/src/libmsc/libmsc.a \ $(top_builddir)/src/libmgcp/libmgcp.a \ $(top_builddir)/src/libtrau/libtrau.a \ diff --git a/openbsc/tests/gprs/Makefile.am b/openbsc/tests/gprs/Makefile.am index 633c362..44d9965 100644 --- a/openbsc/tests/gprs/Makefile.am +++ b/openbsc/tests/gprs/Makefile.am @@ -5,7 +5,7 @@ EXTRA_DIST = gprs_test.ok noinst_PROGRAMS = gprs_test -gprs_test_SOURCES = gprs_test.c $(top_srcdir)/src/gprs/gprs_utils.c \ - $(top_srcdir)/src/gprs/gprs_gsup_messages.c +gprs_test_SOURCES = gprs_test.c -gprs_test_LDADD = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) +gprs_test_LDADD = $(top_builddir)/src/gprs/libgprs.a \ + $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) diff --git a/openbsc/tests/smpp/Makefile.am b/openbsc/tests/smpp/Makefile.am index b3d4568..d36266d 100644 --- a/openbsc/tests/smpp/Makefile.am +++ b/openbsc/tests/smpp/Makefile.am @@ -6,7 +6,8 @@ EXTRA_DIST = smpp_test.ok smpp_test.err noinst_PROGRAMS = smpp_test -smpp_test_SOURCES = smpp_test.c \ - $(top_builddir)/src/libmsc/smpp_utils.c -smpp_test_LDADD = $(LIBOSMOCORE_LIBS) \ +smpp_test_SOURCES = smpp_test.c +smpp_test_LDADD = \ + $(top_builddir)/src/libmsc/libmsc.a + $(LIBOSMOCORE_LIBS) \ $(top_builddir)/src/libcommon/libcommon.a -- 2.1.4 From mail at rotty.xx.vu Tue Jun 16 21:23:30 2015 From: mail at rotty.xx.vu (Andreas Rottmann) Date: Tue, 16 Jun 2015 23:23:30 +0200 Subject: [PATCH 3/4] Fix "make distcheck" In-Reply-To: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> Message-ID: <1434489811-10097-4-git-send-email-mail@rotty.xx.vu> From: Andreas Rottmann Running "make distcheck" failed trying to generate ".version" into the read-only unpacked source directory. Actually shipping ".version" in the tarball fixes that. --- openbsc/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/Makefile.am b/openbsc/Makefile.am index d7329ba..8696eb4 100644 --- a/openbsc/Makefile.am +++ b/openbsc/Makefile.am @@ -7,7 +7,7 @@ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = openbsc.pc BUILT_SOURCES = $(top_srcdir)/.version -EXTRA_DIST = git-version-gen osmoappdesc.py +EXTRA_DIST = git-version-gen osmoappdesc.py .version $(top_srcdir)/.version: echo $(VERSION) > $@-t && mv $@-t $@ dist-hook: -- 2.1.4 From mail at rotty.xx.vu Tue Jun 16 21:23:31 2015 From: mail at rotty.xx.vu (Andreas Rottmann) Date: Tue, 16 Jun 2015 23:23:31 +0200 Subject: [PATCH 4/4] build: avoid spurious hard dependency on libosmo-sccp In-Reply-To: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> Message-ID: <1434489811-10097-5-git-send-email-mail@rotty.xx.vu> From: Andreas Rottmann In the libfilter source code, which is built regardless of --enable-nat, headers from libosmo-sccp were used, thus causing a build failure (see below) when building without --enable-nat, and libosmo-sccp not being installed (or being installed in a prefix not otherwise included in the build). The build fails like this: In file included from ../../../src/libfilter/bsc_msg_filter.c:27:0: ../../../include/openbsc/bsc_nat_sccp.h:27:37: fatal error: osmocom/sccp/sccp_types.h: No such file or directory As the includes seem not to be actually needed, this change fixes the issue by just omitting them. --- openbsc/src/libfilter/bsc_msg_filter.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/openbsc/src/libfilter/bsc_msg_filter.c b/openbsc/src/libfilter/bsc_msg_filter.c index be518a4..eafeff4 100644 --- a/openbsc/src/libfilter/bsc_msg_filter.c +++ b/openbsc/src/libfilter/bsc_msg_filter.c @@ -24,7 +24,6 @@ #include #include -#include #include #include #include @@ -36,8 +35,6 @@ #include #include -#include - int bsc_filter_barr_find(struct rb_root *root, const char *imsi, int *cm, int *lu) { struct bsc_filter_barr_entry *n; -- 2.1.4 From Max.Suraev at fairwaves.co Tue Jun 16 21:44:56 2015 From: Max.Suraev at fairwaves.co (=?UTF-8?B?4piO?=) Date: Tue, 16 Jun 2015 23:44:56 +0200 Subject: bssgp test In-Reply-To: <55753EEE.4010906@sysmocom.de> References: <5571A0F9.7010404@fairwaves.co> <55753EEE.4010906@sysmocom.de> Message-ID: <558098D8.4000607@fairwaves.co> That makes it even more strange: I do see the fprintf, moreover if I explicitly print value of real_sendto in sendto wrapper from gprs_bssgp_test.c I got 0. Here is what I got when manually starting ./gprs_bssgp_test in libosmocore/tests/gb/.libs MESSAGE to 0x7f0000ff, msg length 12 02 00 81 01 01 82 0b 56 04 82 0b 55 ===== BSSGP test START ----- test_bssgp_suspend_resume START BSSGP primitive, SAP 16777219, prim = 3, op = 0, msg = 0b 1f 84 f0 12 34 56 1b 86 0f f1 80 20 37 00 All NS-VCs for NSEI 2901 are either dead or blocked! BSSGP primitive, SAP 16777219, prim = 4, op = 0, msg = 0e 1f 84 f0 12 34 56 1b 86 0f f1 80 20 37 00 1d 81 01 All NS-VCs for NSEI 2901 are either dead or blocked! ----- test_bssgp_suspend_resume END ----- test_bssgp_status START BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified BSSGP primitive, SAP 16777221, prim = 11, op = 2, msg = 41 07 81 27 BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI BSSGP primitive, SAP 16777221, prim = 11, op = 2, msg = 41 07 81 05 04 82 04 d2 ----- test_bssgp_status END NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989 ----- test_bssgp_flow_control_bvc START Unable to resolve NSEI 4660 to NS-VC! Assert failed rc >= 0 gb/gprs_bssgp_test.c:229 backtrace() returned 4 addresses ./gprs_bssgp_test() [0x4013c9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f0786082a40] ./gprs_bssgp_test() [0x4014e9] fish: Job 1, './gprs_bssgp_test' terminated by signal SIGABRT (Abort) Seems like it's not the linker to be blamed. When I try to gdb it I've got following backtrace: (gdb) bt full #0 0x00007ffff7407267 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 resultvar = 0 pid = 19343 selftid = 19343 #1 0x00007ffff7408eca in __GI_abort () at abort.c:89 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x7fffffffdef0, sa_sigaction = 0x7fffffffdef0}, sa_mask = {__val = {0, 4199616, 140737351974688, 6311344, 140737347502393, 0, 0, 42, 4294967274, 6311344, 22136, 0, 140737354092544, 0, 0, 0}}, sa_flags = 825242744, sa_restorer = 0x1} sigs = {__val = {32, 0 }} #2 0x00000000004013ce in test_bssgp_suspend_resume () at gb/gprs_bssgp_test.c:135 No locals. #3 main (argc=19343, argv=0x4b8f) at gb/gprs_bssgp_test.c:272 bss_peer = {sin_family = 2, sin_port = 125, sin_addr = {s_addr = 4278190207}, sin_zero = "\000\000\000\000\000\000\000"} The gb/gprs_bssgp_test.c:135 is following: OSMO_ASSERT(last_oph.primitive == PRIM_BSSGP_GMM_RESUME); Although I don't get yet what suspend-resume supposed to do in there and how it corresponds to printed log above. 08.06.2015 09:06, Jacob Erlbeck ?????: > Hi > > On 05.06.2015 15:15, ? wrote: >> Could you perhaps summarize what's happening around tests/gb/gprs_bssgp_test.c:229? > > The line before the failing test is > > rc = bssgp_tx_fc_bvc(&bctx, tag, bmax, rate, bmax_ms, rate_ms, > NULL, NULL); > > The bssgp_tx_fc_bvc function will in general call gprs_ns_sendmsg -> > gprs_ns_tx -> nsip_sendmsg -> sendto. The sendto function had been > "replaced" by redefining it locally which worked at least with the > default ld up to ubuntu 14.04. (see Holger's replies). > > The system's sendto will fail in the test, since the UDP socket has not > been configured. The local replacement (see gprs_bbsgp_test.c:37) will call > > fprintf(stderr, "MESSAGE to 0x%08x, msg length %d\n%s\n", > dest_host, len, osmo_hexdump(buf, len)); > > so you just need to look into the stderr output to see, whether this is > a linker issue. > > If yes, the issue will appear in more test programs, since that pattern > has been used many times. > > If there is no way to trick the linker to use the "old" behaviour, those > test programs will have to be changed to use another mocking mechanism, > e.g. by using the --wrap feature (if it is supported by the linker), see > openbsc:openbsc/tests/sgsn/sgsn_test.c. > > HTH > > Jacob > >> >> The test fails for me (and another person with ubuntu 15.04 x86_64) on OSMO_ASSERT(rc >>> = 0); >> >> This is 100% reproducible but I don't know much about Gb part so I'm not sure how to >> track this down properly. Any ideas/advices? >> > > -- best regards, Max, http://fairwaves.co From holger at freyther.de Wed Jun 17 05:47:45 2015 From: holger at freyther.de (Holger Freyther) Date: Wed, 17 Jun 2015 07:47:45 +0200 Subject: [PATCH 2/4] Add subdir-objects automake option In-Reply-To: <1434489811-10097-3-git-send-email-mail@rotty.xx.vu> References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> <1434489811-10097-3-git-send-email-mail@rotty.xx.vu> Message-ID: <70E0BA15-E52F-4879-97F4-E2B247614793@freyther.de> > On 16 Jun 2015, at 23:23, Andreas Rottmann wrote: > > From: Andreas Rottmann > > Having subdir-objects enabled is recommended by automake 1.14, to avoid > future incompatibilities. > > However, adding that option breaks out-of-tree builds, and also seems to > break "make distclean" for in-tree builds. The reason is that > apparently, automake with subdir-objects enabled cannot cope with source > files in a different, non-child directory. To avoid that, we simply > compile the files referenced in this way into a static library in their > own source directory, and instead of referencing the source files, we > link against that library. > > Besides making the build system a bit more future proof, this change > also potentially enhances build times, as it reduces the number of > compiler invocations, in exchange a slight increase of "ar" invocations. That automake behavior is shameful. What would be the effort to get rid off the recursive make? From holger at freyther.de Wed Jun 17 06:04:24 2015 From: holger at freyther.de (Holger Freyther) Date: Wed, 17 Jun 2015 08:04:24 +0200 Subject: [PATCH 2/2] libbsc: Update a BTS's SIs when ms_max_power is changed from VTY. In-Reply-To: References: <4CA5C18A-8CCB-4669-B686-C773515BC5C4@freyther.de> Message-ID: <2136E3D4-5D0B-4799-AF06-B2FE5FCB9497@freyther.de> > On 15 Jun 2015, at 21:01, Alexander Chemeris wrote: Good Morning Alexander, > I agree that transactional functionality would be nice and I had been thinking about this. But it's a big change which should be well planned and requires considerable effort to go through all commands and split configuration from application. One issue is that we'll need to create "shadow" registers for the non applied settings. E.g. in case of power control, the setting was actually applied at the BSC part of the control (it was using the setting variable directly), but was not propagated to the BTS party, which was really confusing from a user perspective. > > In short - I agree that such feature would be nice, but I don't think this is a showstopper for this patch, because it just makes things more consistent. we will not be able to find an agreement here. The current behavior is not consistent (we have attributes that apply immediately, after a BTS restart or even only after the restart of the system). Moving one VTY command from one class to another doesn?t improve the consistency in any way. The same inconsistency remains in the system, we face the same issue in documenting the inconsistencies. So when/how do we want to apply changes? Should all changes be abpplied after an ?apply? command? How is it done by other vendors that offer a VTY like interface? holger From alexander.huemer at xx.vu Wed Jun 17 08:04:12 2015 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Wed, 17 Jun 2015 10:04:12 +0200 Subject: [PATCH 2/4] Add subdir-objects automake option In-Reply-To: <70E0BA15-E52F-4879-97F4-E2B247614793@freyther.de> References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> <1434489811-10097-3-git-send-email-mail@rotty.xx.vu> <70E0BA15-E52F-4879-97F4-E2B247614793@freyther.de> Message-ID: <20150617080412.GA4074@yade.xx.vu> On Wed, Jun 17, 2015 at 07:47:45AM +0200, Holger Freyther wrote: > > On 16 Jun 2015, at 23:23, Andreas Rottmann wrote: > > > > From: Andreas Rottmann > > > > Having subdir-objects enabled is recommended by automake 1.14, to avoid > > future incompatibilities. > > > > However, adding that option breaks out-of-tree builds, and also seems to > > break "make distclean" for in-tree builds. The reason is that > > apparently, automake with subdir-objects enabled cannot cope with source > > files in a different, non-child directory. To avoid that, we simply > > compile the files referenced in this way into a static library in their > > own source directory, and instead of referencing the source files, we > > link against that library. > > > > Besides making the build system a bit more future proof, this change > > also potentially enhances build times, as it reduces the number of > > compiler invocations, in exchange a slight increase of "ar" invocations. > > That automake behavior is shameful. What would be the effort to get rid > off the recursive make? AFAIR there was a patch series a few years ago from Diego Elio Petten? (flameeyes) that changed the build system behavior of several osmo* subprojects to use non recursive make. There were objections against them, so they were not merged. Kind regards, -Alex From holger at freyther.de Wed Jun 17 11:36:05 2015 From: holger at freyther.de (Holger Freyther) Date: Wed, 17 Jun 2015 13:36:05 +0200 Subject: [PATCH 2/4] Add subdir-objects automake option In-Reply-To: <20150617080412.GA4074@yade.xx.vu> References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> <1434489811-10097-3-git-send-email-mail@rotty.xx.vu> <70E0BA15-E52F-4879-97F4-E2B247614793@freyther.de> <20150617080412.GA4074@yade.xx.vu> Message-ID: > On 17 Jun 2015, at 10:04, Alexander Huemer wrote: > > > AFAIR there was a patch series a few years ago from Diego Elio Petten? > (flameeyes) that changed the build system behavior of several osmo* > subprojects to use non recursive make. There were objections against > them, so they were not merged. hehe, but we did merge parts of libosmocore? E.g. all test directories are non-recursive there? From alexander.huemer at xx.vu Wed Jun 17 12:04:45 2015 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Wed, 17 Jun 2015 14:04:45 +0200 Subject: [PATCH 2/4] Add subdir-objects automake option In-Reply-To: References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> <1434489811-10097-3-git-send-email-mail@rotty.xx.vu> <70E0BA15-E52F-4879-97F4-E2B247614793@freyther.de> <20150617080412.GA4074@yade.xx.vu> Message-ID: <20150617120445.GA3829@yade.xx.vu> Hi! On Wed, Jun 17, 2015 at 01:36:05PM +0200, Holger Freyther wrote: > > > On 17 Jun 2015, at 10:04, Alexander Huemer wrote: > > > > > > AFAIR there was a patch series a few years ago from Diego Elio Petten? > > (flameeyes) that changed the build system behavior of several osmo* > > subprojects to use non recursive make. There were objections against > > them, so they were not merged. > > hehe, but we did merge parts of libosmocore? E.g. all test directories are > non-recursive there? The relevant commits with build system changes that were merged seem to be these: 7e007e0f87c4a06396ef46081ef1d69a4bdc11ae build: avoid multi-level recursion for src/ directory. d471a2192015440ec9b8c409268ba6433511f421 build: simplify headers management and remove recursion ea0e1eca2bc32b531242a3b0a3c471e492a6f493 build: simplify test handling and speed up build. I can dig up the unmerged ones from the old ML if that's of any value. Kind regards, -Alex From alexander.huemer at xx.vu Wed Jun 17 12:30:52 2015 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Wed, 17 Jun 2015 14:30:52 +0200 Subject: [PATCH 2/4] Add subdir-objects automake option In-Reply-To: <20150617120445.GA3829@yade.xx.vu> References: <1434489811-10097-1-git-send-email-mail@rotty.xx.vu> <1434489811-10097-3-git-send-email-mail@rotty.xx.vu> <70E0BA15-E52F-4879-97F4-E2B247614793@freyther.de> <20150617080412.GA4074@yade.xx.vu> <20150617120445.GA3829@yade.xx.vu> Message-ID: <20150617123052.GA11490@yade.xx.vu> Hi! On Wed, Jun 17, 2015 at 02:04:45PM +0200, Alexander Huemer wrote: > On Wed, Jun 17, 2015 at 01:36:05PM +0200, Holger Freyther wrote: > > > > > On 17 Jun 2015, at 10:04, Alexander Huemer wrote: > > > > > > > > > AFAIR there was a patch series a few years ago from Diego Elio Petten? > > > (flameeyes) that changed the build system behavior of several osmo* > > > subprojects to use non recursive make. There were objections against > > > them, so they were not merged. > > > > hehe, but we did merge parts of libosmocore? E.g. all test directories are > > non-recursive there? > > The relevant commits with build system changes that were merged seem to > be these: > > 7e007e0f87c4a06396ef46081ef1d69a4bdc11ae > build: avoid multi-level recursion for src/ directory. > > d471a2192015440ec9b8c409268ba6433511f421 > build: simplify headers management and remove recursion > > ea0e1eca2bc32b531242a3b0a3c471e492a6f493 > build: simplify test handling and speed up build. > > I can dig up the unmerged ones from the old ML if that's of any value. Actually, all patches from flameeyes for libosmocore were merged. Here are the overall numbers. merged/sent with commit summary lines of the unmerged patches. libosmocore 12/12 libosmo-abis 7/7 libosmo-dsp 3/5 build: flatten build to a single Makefile.am build: avoid running unused checks libosmo-sccp 0/7 mtp_pcap: mark structure as constant as well as static. m2ua: remove unset talloc context. build: flatten headers installation in include/Makefile.am build: set automake options in configure.ac only. build: simplify test build m2ua: accept a constant parameter in m2ua_from_msg. tests: remove warnings and make more data constant. osmo-gmr 0/7 build: avoid recursing into include/ for non-installed headers. build: simplify building by avoiding recursion in src/. gmr1_rx: remove to variables set but not used build: simplify documentation install. build: remove unused test and get rid of libtool. build: move automake options to configure.ac gitignore: ignore src/gmr1_gen_mat as well. sam7-util 2/2 Kind regards, -Alex From mike.mcternan at wavemobile.com Thu Jun 18 08:03:42 2015 From: mike.mcternan at wavemobile.com (Mike McTernan (wavemobile)) Date: Thu, 18 Jun 2015 08:03:42 +0000 Subject: [PATCH] Fix GSM900 ARFCN range check Message-ID: Allow ARFCN 0 to be used in GSM900 band. Signed-off-by: Michael McTernan Index: osmobss/openbsc/openbsc/src/libbsc/bsc_init.c =================================================================== --- osmobss.orig/openbsc/openbsc/src/libbsc/bsc_init.c 2015-06-03 11:36:16.114471430 +0100 +++ osmobss/openbsc/openbsc/src/libbsc/bsc_init.c 2015-06-18 08:53:14.116369178 +0100 @@ -379,10 +379,10 @@ static int bootstrap_bts(struct gsm_bts } break; case GSM_BAND_900: - if (bts->c0->arfcn < 1 || + if (bts->c0->arfcn < 0 || (bts->c0->arfcn > 124 && bts->c0->arfcn < 955) || bts->c0->arfcn > 1023) { - LOGP(DNM, LOGL_ERROR, "GSM900 channel must be between 1-124, 955-1023.\n"); + LOGP(DNM, LOGL_ERROR, "GSM900 channel must be between 0-124, 955-1023.\n"); return -EINVAL; } break; From mike.mcternan at wavemobile.com Thu Jun 18 08:15:12 2015 From: mike.mcternan at wavemobile.com (Mike McTernan (wavemobile)) Date: Thu, 18 Jun 2015 08:15:12 +0000 Subject: [PATCH 2/2] libbsc: Update a BTS's SIs when ms_max_power is changed from VTY. In-Reply-To: <2136E3D4-5D0B-4799-AF06-B2FE5FCB9497@freyther.de> References: <4CA5C18A-8CCB-4669-B686-C773515BC5C4@freyther.de> <2136E3D4-5D0B-4799-AF06-B2FE5FCB9497@freyther.de> Message-ID: > The current behavior is not consistent (we have attributes that apply > immediately, after a BTS restart or even only after the restart of the system). ... > So when/how do we want to apply changes? Should all changes be abpplied > after an ?apply? command? How is it done by other vendors that offer a VTY > like interface? I think it is sometimes tied into the admin lock/unlock functionality. So for example, a cell maybe 'locked' and the transmitter disabled, at which point parameters can be changed as required. Then when the cell is unlocked, the new parameter set is then applied before the transmitter is re-enabled. For co-dependent parameters there may be a validation step prior to unlock to ensure that the whole configuration is consistent and valid, though I can't think of many such parameters in this situation. An alternative method is to 'lock' a cell by leaving it transmitting but marking it as barred in the SI. Such a locking scheme does raise some questions as to the granularity i.e. do we lock at a BTS, BSC, MSC level or each one. And therefore the vty needs to know which parameters can be changed according to which network entities are locked - though the command hierarchy could lend some description to that. Kind Regards, Mike From jerlbeck at sysmocom.de Thu Jun 18 09:11:30 2015 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Thu, 18 Jun 2015 11:11:30 +0200 Subject: bssgp test In-Reply-To: <558098D8.4000607@fairwaves.co> References: <5571A0F9.7010404@fairwaves.co> <55753EEE.4010906@sysmocom.de> <558098D8.4000607@fairwaves.co> Message-ID: <55828B42.3080302@sysmocom.de> Hi On 16.06.2015 23:44, ? wrote: > That makes it even more strange: I do see the fprintf, moreover if I explicitly print > value of real_sendto in sendto wrapper from gprs_bssgp_test.c I got 0. > > ----- test_bssgp_flow_control_bvc START This message is commit from gprs_ns_sendmsg() within gb/gprs_ns.c: > Unable to resolve NSEI 4660 to NS-VC! So it is the override for that function (gprs_bssgp_test.c:67) that doesn't work. > Assert failed rc >= 0 gb/gprs_bssgp_test.c:229 > backtrace() returned 4 addresses > ./gprs_bssgp_test() [0x4013c9] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f0786082a40] > ./gprs_bssgp_test() [0x4014e9] > fish: Job 1, './gprs_bssgp_test' terminated by signal SIGABRT (Abort) > > > Seems like it's not the linker to be blamed. I don't agree, see above. Jacob -- - Jacob Erlbeck http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From jerlbeck at sysmocom.de Thu Jun 18 09:51:34 2015 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Thu, 18 Jun 2015 11:51:34 +0200 Subject: [PATCH] bssgp/test: Add missing START/END printfs Message-ID: <1434621094-19877-1-git-send-email-jerlbeck@sysmocom.de> Sponsored-by: On-Waves ehf --- tests/gb/gprs_bssgp_test.c | 7 ++++++- tests/gb/gprs_bssgp_test.ok | 2 ++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/tests/gb/gprs_bssgp_test.c b/tests/gb/gprs_bssgp_test.c index 63abf8b..14ba4d1 100644 --- a/tests/gb/gprs_bssgp_test.c +++ b/tests/gb/gprs_bssgp_test.c @@ -173,10 +173,13 @@ static void test_bssgp_status(void) static void test_bssgp_bad_reset() { - struct msgb *msg = bssgp_msgb_alloc(); + struct msgb *msg; uint16_t bvci_be = htons(2); uint8_t cause = BSSGP_CAUSE_OML_INTERV; + printf("----- %s START\n", __func__); + msg = bssgp_msgb_alloc(); + msgb_v_put(msg, BSSGP_PDUT_BVC_RESET); msgb_tvlv_put(msg, BSSGP_IE_BVCI, sizeof(bvci_be), (uint8_t *)&bvci_be); msgb_tvlv_put(msg, BSSGP_IE_CAUSE, sizeof(cause), &cause); @@ -184,6 +187,8 @@ static void test_bssgp_bad_reset() msgb_bvci(msg) = 0xbad; msgb_bssgp_send_and_free(msg); + + printf("----- %s END\n", __func__); } static void test_bssgp_flow_control_bvc(void) diff --git a/tests/gb/gprs_bssgp_test.ok b/tests/gb/gprs_bssgp_test.ok index a011bee..83d633b 100644 --- a/tests/gb/gprs_bssgp_test.ok +++ b/tests/gb/gprs_bssgp_test.ok @@ -7,6 +7,8 @@ BSSGP primitive, SAP 16777219, prim = 4, op = 0, msg = 0e 1f 84 f0 12 34 56 1b 8 BSSGP primitive, SAP 16777221, prim = 11, op = 2, msg = 41 07 81 27 BSSGP primitive, SAP 16777221, prim = 11, op = 2, msg = 41 07 81 05 04 82 04 d2 ----- test_bssgp_status END +----- test_bssgp_bad_reset START +----- test_bssgp_bad_reset END ----- test_bssgp_flow_control_bvc START Got message: 26 1e 81 2a 05 82 10 22 03 82 c0 40 01 82 08 11 1c 82 60 20 Got message: 26 1e 81 2a 05 82 10 22 03 82 c0 40 01 82 08 11 1c 82 60 20 3c 81 78 06 82 11 44 -- 1.9.1 From jerlbeck at sysmocom.de Thu Jun 18 11:21:30 2015 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Thu, 18 Jun 2015 13:21:30 +0200 Subject: [PATCH] bssgp: Fix IMSI buffer size (Coverity) Message-ID: <1434626490-23511-1-git-send-email-jerlbeck@sysmocom.de> Currently the size of the IMSI pointer is used instead of the size of the talloc'ed buffer. This commit changes the call to gsm48_mi_to_string to use the same value that has been used with talloc_zero_size(). The length is changed to 17 since that value is used for GSM_IMSI_LENGTH in openbsc. Fixes: Coverity CID 1040663 Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp_bss.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gb/gprs_bssgp_bss.c b/src/gb/gprs_bssgp_bss.c index 962bf2e..3a9012e 100644 --- a/src/gb/gprs_bssgp_bss.c +++ b/src/gb/gprs_bssgp_bss.c @@ -34,6 +34,8 @@ #include "common_vty.h" +#define GSM_IMSI_LENGTH 17 + uint8_t *bssgp_msgb_tlli_put(struct msgb *msg, uint32_t tlli) { uint32_t _tlli = htonl(tlli); @@ -498,8 +500,8 @@ int bssgp_rx_paging(struct bssgp_paging_info *pinfo, if (!TLVP_PRESENT(&tp, BSSGP_IE_IMSI)) goto err_mand_ie; if (!pinfo->imsi) - pinfo->imsi = talloc_zero_size(pinfo, 16); - gsm48_mi_to_string(pinfo->imsi, sizeof(pinfo->imsi), + pinfo->imsi = talloc_zero_size(pinfo, GSM_IMSI_LENGTH); + gsm48_mi_to_string(pinfo->imsi, GSM_IMSI_LENGTH, TLVP_VAL(&tp, BSSGP_IE_IMSI), TLVP_LEN(&tp, BSSGP_IE_IMSI)); -- 1.9.1 From holger at freyther.de Fri Jun 19 18:56:14 2015 From: holger at freyther.de (Holger Freyther) Date: Fri, 19 Jun 2015 20:56:14 +0200 Subject: [PATCH] bssgp: Fix IMSI buffer size (Coverity) In-Reply-To: <1434626490-23511-1-git-send-email-jerlbeck@sysmocom.de> References: <1434626490-23511-1-git-send-email-jerlbeck@sysmocom.de> Message-ID: <316F232F-1C72-461A-AA21-B13C38435688@freyther.de> > On 18 Jun 2015, at 13:21, Jacob Erlbeck wrote: > > Currently the size of the IMSI pointer is used instead of the size of > the talloc'ed buffer. > > This commit changes the call to gsm48_mi_to_string to use the same > value that has been used with talloc_zero_size(). The length is > changed to 17 since that value is used for GSM_IMSI_LENGTH in > openbsc. Thank you. It feels good to close the amount of open coverity issues. Could you identify a good place to put the IMSI_LENGTH/MSISDN_LENGTH in a header file of libosmogsm? I think we have two definitions in OpenBSC now and one in libosmocore. have a nice weekend holger From alexander.chemeris at gmail.com Tue Jun 23 22:27:13 2015 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 23 Jun 2015 18:27:13 -0400 Subject: [PATCH 2/2] libbsc: Update a BTS's SIs when ms_max_power is changed from VTY. In-Reply-To: <2136E3D4-5D0B-4799-AF06-B2FE5FCB9497@freyther.de> References: <4CA5C18A-8CCB-4669-B686-C773515BC5C4@freyther.de> <2136E3D4-5D0B-4799-AF06-B2FE5FCB9497@freyther.de> Message-ID: Hi Holger, On Wed, Jun 17, 2015 at 2:04 AM, Holger Freyther wrote: >> On 15 Jun 2015, at 21:01, Alexander Chemeris wrote: >> I agree that transactional functionality would be nice and I had been thinking about this. But it's a big change which should be well planned and requires considerable effort to go through all commands and split configuration from application. One issue is that we'll need to create "shadow" registers for the non applied settings. E.g. in case of power control, the setting was actually applied at the BSC part of the control (it was using the setting variable directly), but was not propagated to the BTS party, which was really confusing from a user perspective. >> >> In short - I agree that such feature would be nice, but I don't think this is a showstopper for this patch, because it just makes things more consistent. > > > we will not be able to find an agreement here. The current behavior is not consistent (we > have attributes that apply immediately, after a BTS restart or even only after the restart of > the system). Moving one VTY command from one class to another doesn?t improve the > consistency in any way. The same inconsistency remains in the system, we face the same > issue in documenting the inconsistencies. Please note that the current behavior of this command is that it already applies the change immediately by setting bts->ms_max_power. This value is then used at rsl_rx_chan_rqd() to initialize lchan->ms_power. But it does not apply it to SIs sent by the same BTS, which makes the effect of the command inconsistent. The commit I suggest just makes the behavior of the command consistent. Please also note that it makes complete sense to apply this value immediately when you're doing live cell tuning. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From holger at freyther.de Wed Jun 24 14:50:26 2015 From: holger at freyther.de (Holger Freyther) Date: Wed, 24 Jun 2015 16:50:26 +0200 Subject: [PATCH 2/2] libbsc: Update a BTS's SIs when ms_max_power is changed from VTY. In-Reply-To: References: <4CA5C18A-8CCB-4669-B686-C773515BC5C4@freyther.de> <2136E3D4-5D0B-4799-AF06-B2FE5FCB9497@freyther.de> Message-ID: <8C3DC7EA-009F-4037-90C9-EED2A586DE1B@freyther.de> > On 24 Jun 2015, at 00:27, Alexander Chemeris wrote: Dear Alexander, > Please note that the current behavior of this command is that it > already applies the change immediately by setting bts->ms_max_power. > This value is then used at rsl_rx_chan_rqd() to initialize > lchan->ms_power. But it does not apply it to SIs sent by the same BTS, > which makes the effect of the command inconsistent. The commit I > suggest just makes the behavior of the command consistent. we have completed the circle now and I don?t want to run another round. The ms_max_power aspect is annoying but it shows that we need to progress and look at the bigger picture. Are you willing to do that? holger From alexander.chemeris at gmail.com Wed Jun 24 21:45:43 2015 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 24 Jun 2015 17:45:43 -0400 Subject: [PATCH 2/2] libbsc: Update a BTS's SIs when ms_max_power is changed from VTY. In-Reply-To: <8C3DC7EA-009F-4037-90C9-EED2A586DE1B@freyther.de> References: <4CA5C18A-8CCB-4669-B686-C773515BC5C4@freyther.de> <2136E3D4-5D0B-4799-AF06-B2FE5FCB9497@freyther.de> <8C3DC7EA-009F-4037-90C9-EED2A586DE1B@freyther.de> Message-ID: Hi Holger, On Wed, Jun 24, 2015 at 10:50 AM, Holger Freyther wrote: >> On 24 Jun 2015, at 00:27, Alexander Chemeris wrote: >> Please note that the current behavior of this command is that it >> already applies the change immediately by setting bts->ms_max_power. >> This value is then used at rsl_rx_chan_rqd() to initialize >> lchan->ms_power. But it does not apply it to SIs sent by the same BTS, >> which makes the effect of the command inconsistent. The commit I >> suggest just makes the behavior of the command consistent. > > we have completed the circle now and I don?t want to run another round. The > ms_max_power aspect is annoying but it shows that we need to progress and > look at the bigger picture. Are you willing to do that? In the spirit of scratching the itch, I do need the ms_max_power patch, as it fixes an obvious issue and I want to share it with the community. I'm fine maintaining it ?? a branch if it's not good enough for the master. OTOH I don't have an itch with the lack of ?commit?/?apply? functionality, so it's hard for me to discuss it - I don't know requirements and use cases. I see a theoretical value of it, but relying on theoretical values is a sure way to over-engineer in my experience. If you have a real need for it, then you're probably much more qualified to look at it. I hope that's fair enough. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From brogan.tom.iii at gmail.com Fri Jun 26 20:49:07 2015 From: brogan.tom.iii at gmail.com (brogan.tom.iii at gmail.com) Date: Fri, 26 Jun 2015 23:49:07 +0300 Subject: NanoBTS for sale? Message-ID: I would like to know if anyone has a Nanobts for sale hopefully under 500$. I'm looking for the 900MHz or 1800MHz ones, preferably the ones with SMA antenna connectors (the white square ones) without internal antennas. Doesn't matter if they are used/old/new, just something that works without issues :) From admin at manateeshome.com Sun Jun 28 01:32:29 2015 From: admin at manateeshome.com (Pierre Kim) Date: Sun, 28 Jun 2015 10:32:29 +0900 Subject: Random nanoBTS reboot Message-ID: <558F4EAD.9090406@manateeshome.com> Hello, I've been experiencing this bug ever since I started experimenting with OpenBSC. At first I thought it as a problem with unstable connection, but it continued to happen even after I connected to the nanoBTS directly through a switch. I used Wireshark to track down the cause and discovered that OpenBSC was responding too late to PING message from the nanoBTS. I am attaching the pcap file of the moment. This happens as soon as 1 hour from the first connection, sometimes it runs okay for 18 hours but I've never seen my nanoBTS running straight for more than 24hrs Please take a look into the log. Any help will be greatly appreciated. Tell me in case if you need more information Regards, Pierre Following is the log from openbsc console. Sat Jun 27 03:24:43 2015 <0004> bsc_init.c:286 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 520 using MCC=450 MNC=9 LAC=1 CID=0 BSIC=63 TSC=7 Sat Jun 27 08:17:39 2015 <001a> ipa.c:246 Cannot send PING message. Reason: Broken pipe Sat Jun 27 08:17:39 2015 <001a> input/ipaccess.c:110 Unexpected return from ipa_ccm_rcvmsg_base (ret=-32) Sat Jun 27 08:17:39 2015 <001a> input/ipaccess.c:236 Sign link vanished, dead socket Sat Jun 27 08:17:39 2015 <001a> input/ipaccess.c:69 Forcing socket shutdown with no signal link set Sat Jun 27 08:20:51 2015 <001a> input/ipa.c:265 accept()ed new link from 192.168.28.31 to port 3002 Sat Jun 27 08:21:08 2015 <001a> input/ipa.c:265 accept()ed new link from 192.168.28.31 to port 3003 Sat Jun 27 08:21:11 2015 <0004> bsc_init.c:286 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 520 using MCC=450 MNC=9 LAC=1 CID=0 BSIC=63 TSC=7 and sometimes without the error from ipa_ccm_rcvmsg_base Sun Jun 28 09:17:40 2015 <001a> input/ipaccess.c:236 Sign link vanished, dead socket Sun Jun 28 09:17:40 2015 <001a> input/ipaccess.c:69 Forcing socket shutdown with no signal link set Sun Jun 28 09:20:39 2015 <001a> input/ipa.c:265 accept()ed new link from 192.168.28.31 to port 3002 Sun Jun 28 09:20:56 2015 <001a> input/ipa.c:265 accept()ed new link from 192.168.28.31 to port 3003 Sun Jun 28 09:20:59 2015 <0004> bsc_init.c:286 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 520 using MCC=450 MNC=9 LAC=1 CID=0 BSIC=63 TSC=7 -------------- next part -------------- A non-text attachment was scrubbed... Name: nanobts.pcap Type: application/octet-stream Size: 5285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nanobts2.pcap Type: application/octet-stream Size: 4705 bytes Desc: not available URL: From hrushak at gmail.com Fri Jun 12 20:11:34 2015 From: hrushak at gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQltC+0LPQvtCy?=) Date: Fri, 12 Jun 2015 20:11:34 -0000 Subject: OpenBSC + Huawei BTS 3900B Message-ID: Hi all. I'm working on probation on mobile operator as a student. Currently, I'm trying to create site for testing, using Huawei BTS 3900B and OpenBSC software. But I can't set up it. I have a several questions: 1) Huawei BTS uses Abis over IP, how can I connect this BTS to OpenBSC. 2) Are there any examples of configuration in this case? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmobsc11 at gmail.com Mon Jun 22 10:35:49 2015 From: osmobsc11 at gmail.com (F Abdu) Date: Mon, 22 Jun 2015 10:35:49 -0000 Subject: osmo-nitb hangs with large hlr.sqlite3 file Message-ID: Dear Experts, Hello, I am running a gsm system with followings: OpenBSC version: 0.13.0.319-30e0e LCR version 1.14 astersik version 1.8.10.1 The system is sited is a busy area. The system works fine for few days but hangs once the hlr.sqlite3 file size reaches near 12 MB and that causes the osmo-nitb to take 99% of the cpu usage. I used "./osmo-nitb -m -P -C" to run the system. The hlr.sqlite3 file increases @2MB/Day. The 'Subscriber' table of the hlr.sqlite3 file adds a large number of IMSI with authorized=0. Tables like Counters, Eqipment and EquipmentWatch are filling up with lots of data. Now the only solution to this problem is to manually delete the data from the tables. May I get some light to solve the issue form the experts like you all? With regards. [ Content from the openbsc.cfg file is as following: ! ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! e1_input e1_line 0 driver ipa network network country code XXX mobile network code XX short name Test long name Test auth policy closed location updating reject cause 13 encryption a5 0 neci 1 rrlp mode none mm info 0 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 4 timer t3111 1 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 bts 0 type sysmobts band GSMXXX cell_identity X location_area_code X training_sequence_code 7 base_station_id_code 63 ms max power 30 cell reselection hysteresis 4 rxlev access min 0 periodic location update 100 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id XXXX 0 oml ip.access stream_id 255 line 0 gprs mode none trx 0 rf_locked 0 arfcn XXX nominal power 23 max_power_red XX rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F timeslot 3 phys_chan_config TCH/F timeslot 4 phys_chan_config TCH/F timeslot 5 phys_chan_config TCH/F timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F -------------- next part -------------- An HTML attachment was scrubbed... URL: