From denis at artru.fr  Mon Apr  6 20:35:56 2020
From: denis at artru.fr (Denis Artru)
Date: Mon, 6 Apr 2020 22:35:56 +0200
Subject: OpenMSC: validity_minutes not set when sms is from SMPP + SMS not
 added in pending list.
Message-ID: <A121E3A3-EF02-4AD6-ABAA-93BF6E98830A@artru.fr>

Hello all,

1) When an SMS is received from SMPP, the validity_minutes is not set (value 0).
The consequence is that email is deleted from database too early in case of failure.
In file: src/libmsc/smpp_openbsc.c function submit_to_sms translate convert from submit_sm_t to gsm_sms.
But some field of gsm_sms are not filled, in particularly validity_minutes.
I think that validity_minutes must be computed from submit_sm_t.schedule_delivery_time or submit_sm_t.validity_period.
Sorry I don?t know exactly content of these values.

2) In file src/libmsc/sms_queue.c function sub_ready_for_sm,
before sending SMS using the function gsm411_send_sms,
the SMS is not place in pending list. Like it is done in functions sms_submit_pending and sms_send_next.
The consequence is that when handset do a Location Updating Request,
only one SMS is send if they are many SMS for this subscribers.
Because in function sms_sms_cb call of
pending = sms_find_pending(network->sms_queue, sig_sms->sms->id);
will always return 0.

I try the following fix and was working
but I don?t know if it possible that an SMS was already in the list? 

+	struct gsm_sms_queue *smsq = net->sms_queue;
+	struct gsm_sms_pending *pendingSms = sms_pending_from(smsq, sms);
+	if (!pendingSms) {
+		LOGP(DLSMS, LOGL_ERROR,
+			"Failed to create pending SMS entry.\n");
+		sms_free(sms);
+		return 0;
+	}
+	llist_add_tail(&pendingSms->entry, &smsq->pending_sms);
 	gsm411_send_sms(net, vsub, sms);
 	return 0;
 }

Thanks you,

Denis

From pespin at sysmocom.de  Tue Apr  7 08:03:29 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Tue, 7 Apr 2020 10:03:29 +0200
Subject: OpenMSC: validity_minutes not set when sms is from SMPP + SMS not
 added in pending list.
In-Reply-To: <A121E3A3-EF02-4AD6-ABAA-93BF6E98830A@artru.fr>
References: <A121E3A3-EF02-4AD6-ABAA-93BF6E98830A@artru.fr>
Message-ID: <bc99ec04-3a9a-d454-2752-f773126ee8e6@sysmocom.de>

Hi,

OpenMSC? Do you mean openbsc.git? or osmo-msc.git?


-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From denis at artru.fr  Tue Apr  7 18:21:51 2020
From: denis at artru.fr (Denis Artru)
Date: Tue, 7 Apr 2020 20:21:51 +0200
Subject: OpenMSC: validity_minutes not set when sms is from SMPP + SMS not
 added in pending list.
In-Reply-To: <bc99ec04-3a9a-d454-2752-f773126ee8e6@sysmocom.de>
References: <A121E3A3-EF02-4AD6-ABAA-93BF6E98830A@artru.fr>
 <bc99ec04-3a9a-d454-2752-f773126ee8e6@sysmocom.de>
Message-ID: <DFC612DF-E9E2-400A-943A-5EBC71783834@artru.fr>

Hello,

sorry for typo, it is osmo-msc
https://github.com/osmocom/osmo-msc

Denis


From hosseinisr at outlook.de  Sat Apr  4 10:48:15 2020
From: hosseinisr at outlook.de (Reza Hosseini)
Date: Sat, 4 Apr 2020 10:48:15 +0000
Subject: GSUP protocol 
Message-ID: <DM6PR11MB4299EFB8E8A05067B21FBD2BB1C40@DM6PR11MB4299.namprd11.prod.outlook.com>

Dear Osmocom developpers,

I already installed osmocomnitb and now i am trying to Show the core Network vulnerablites in Wireshark.
In order to use existing Osmocom libraries for GSUP protocol processing and USSD coding / decoding, I have to use the file "osmo-hlr / src / osmo-euse-demo.c" in my osmocom directory, the " http: // git "contains. osmocom.org/osmo-hlr/tree/src/osmo-euse-demo.c "Pool. But i don?t find the following libarries to patch it.

#include <string.h>
#include <stdio.h>
#include <errno.h>
#include <signal.h>
#include <osmocom/core/msgb.h>
#include <osmocom/core/select.h>
#include <osmocom/core/application.h>
#include <osmocom/core/utils.h>
#include <osmocom/core/logging.h>
#include <osmocom/gsm/gsup.h>
#include <osmocom/gsm/gsm0480.h>
#include <osmocom/gsm/protocol/gsm_04_80.h>
#include <osmocom/gsupclient/gsup_client.h>
#include <osmocom/hlr/logging.h>

How can i have Access to the .exe (already maked) of this library.

Kind regads,
Reza


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200404/4a6b644e/attachment.htm>

From hosseinisr at outlook.de  Mon Apr  6 17:18:16 2020
From: hosseinisr at outlook.de (Reza Hosseini)
Date: Mon, 6 Apr 2020 17:18:16 +0000
Subject: =?Windows-1252?Q?=93osmo-euse-demo.c=93_?=
Message-ID: <DM6PR11MB42996427898231853C726931B1C20@DM6PR11MB4299.namprd11.prod.outlook.com>


Dera Developers,

I am trying to make the ?osmo-euse-demo.c? file to execute it Ubuntu in order to demonstrate the core Network vulnerebalities. But in this Phase i?m facing the following error. Can you please tell me how can i solve this error. Or how can i have Access to the already maked file of ?osmo-euse-demo.c? to execute it .

Kind Regards,
Reza



root at reza-VirtualBox:/home/reza/osmocom/include# cc -v -I/home/reza/osmocom/include osmo-euse-demo.c
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/cc1 -quiet -v -I /home/reza/osmocom/include -imultiarch x86_64-linux-gnu osmo-euse-demo.c -quiet -dumpbase osmo-euse-demo.c -mtune=generic -march=x86-64 -auxbase osmo-euse-demo -version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccz56pXg.s
GNU C11 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
                compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/reza/osmocom/include
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C11 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
                compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b62ed4a2880cd4159476ea8293b72fa8
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-mtune=generic' '-march=x86-64'
as -v -I /home/reza/osmocom/include --64 -o /tmp/ccRIXQie.o /tmp/ccz56pXg.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccu0YtNb.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. /tmp/ccRIXQie.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
/tmp/ccRIXQie.o: In function `osmo_gsup_message_type_name':
osmo-euse-demo.c:(.text+0x36): undefined reference to `osmo_gsup_message_type_names'
osmo-euse-demo.c:(.text+0x3b): undefined reference to `get_value_string'
/tmp/ccRIXQie.o: In function `osmo_gsup_session_state_name':
osmo-euse-demo.c:(.text+0x54): undefined reference to `osmo_gsup_session_state_names'
osmo-euse-demo.c:(.text+0x59): undefined reference to `get_value_string'
/tmp/ccRIXQie.o: In function `gsm0480_op_code_name':
osmo-euse-demo.c:(.text+0x75): undefined reference to `gsm0480_op_code_names'
osmo-euse-demo.c:(.text+0x7a): undefined reference to `get_value_string'
/tmp/ccRIXQie.o: In function `euse_tx_ss':
osmo-euse-demo.c:(.text+0xf4): undefined reference to `msgb_free'
osmo-euse-demo.c:(.text+0x12d): undefined reference to `osmo_strlcpy'
osmo-euse-demo.c:(.text+0x171): undefined reference to `msgb_data'
osmo-euse-demo.c:(.text+0x187): undefined reference to `msgb_length'
osmo-euse-demo.c:(.text+0x19d): undefined reference to `gsm0480_msgb_alloc_name'
osmo-euse-demo.c:(.text+0x1d2): undefined reference to `osmo_panic'
osmo-euse-demo.c:(.text+0x1eb): undefined reference to `osmo_gsup_encode'
osmo-euse-demo.c:(.text+0x1fa): undefined reference to `msgb_free'
osmo-euse-demo.c:(.text+0x213): undefined reference to `osmo_gsup_client_send'
/tmp/ccRIXQie.o: In function `euse_tx_ussd_reject':
osmo-euse-demo.c:(.text+0x261): undefined reference to `gsm0480_gen_reject'
osmo-euse-demo.c:(.text+0x274): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x2be): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x2ed): undefined reference to `osmo_panic'
/tmp/ccRIXQie.o: In function `euse_tx_ussd_resp_7bit':
osmo-euse-demo.c:(.text+0x34a): undefined reference to `gsm0480_gen_ussd_resp_7bit'
osmo-euse-demo.c:(.text+0x35d): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x3b8): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x3e7): undefined reference to `osmo_panic'
/tmp/ccRIXQie.o: In function `euse_rx_proc_ss_req':
osmo-euse-demo.c:(.text+0x4b9): undefined reference to `gsm0480_parse_facility_ie'
osmo-euse-demo.c:(.text+0x509): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x595): undefined reference to `logp2'
/tmp/ccRIXQie.o: In function `gsupc_read_cb':
osmo-euse-demo.c:(.text+0x6e3): undefined reference to `osmo_gsup_decode'
osmo-euse-demo.c:(.text+0x701): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x714): undefined reference to `msgb_hexdump'
osmo-euse-demo.c:(.text+0x746): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x764): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x777): undefined reference to `msgb_hexdump'
osmo-euse-demo.c:(.text+0x7b6): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x7f9): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x83c): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x855): undefined reference to `msgb_free'
/tmp/ccRIXQie.o: In function `main':
osmo-euse-demo.c:(.text+0x8bd): undefined reference to `talloc_named_const'
osmo-euse-demo.c:(.text+0x8d4): undefined reference to `osmo_init_logging2'
osmo-euse-demo.c:(.text+0x98c): undefined reference to `osmo_gsup_client_create'
osmo-euse-demo.c:(.text+0x99d): undefined reference to `osmo_select_main'
collect2: error: ld returned 1 exit status
root at reza-VirtualBox:/home/reza/osmocom/include# cc -v -I/home/reza/osmocom/include osmo-euse-demo.c -o osmosample
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-o' 'osmosample' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/cc1 -quiet -v -I /home/reza/osmocom/include -imultiarch x86_64-linux-gnu osmo-euse-demo.c -quiet -dumpbase osmo-euse-demo.c -mtune=generic -march=x86-64 -auxbase osmo-euse-demo -version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccHY0eog.s
GNU C11 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
                compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/reza/osmocom/include
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C11 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
                compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b62ed4a2880cd4159476ea8293b72fa8
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-o' 'osmosample' '-mtune=generic' '-march=x86-64'
as -v -I /home/reza/osmocom/include --64 -o /tmp/cciVuWmr.o /tmp/ccHY0eog.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-o' 'osmosample' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccDFZPnC.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o osmosample /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. /tmp/cciVuWmr.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
/tmp/cciVuWmr.o: In function `osmo_gsup_message_type_name':
osmo-euse-demo.c:(.text+0x36): undefined reference to `osmo_gsup_message_type_names'
osmo-euse-demo.c:(.text+0x3b): undefined reference to `get_value_string'
/tmp/cciVuWmr.o: In function `osmo_gsup_session_state_name':
osmo-euse-demo.c:(.text+0x54): undefined reference to `osmo_gsup_session_state_names'
osmo-euse-demo.c:(.text+0x59): undefined reference to `get_value_string'
/tmp/cciVuWmr.o: In function `gsm0480_op_code_name':
osmo-euse-demo.c:(.text+0x75): undefined reference to `gsm0480_op_code_names'
osmo-euse-demo.c:(.text+0x7a): undefined reference to `get_value_string'
/tmp/cciVuWmr.o: In function `euse_tx_ss':
osmo-euse-demo.c:(.text+0xf4): undefined reference to `msgb_free'
osmo-euse-demo.c:(.text+0x12d): undefined reference to `osmo_strlcpy'
osmo-euse-demo.c:(.text+0x171): undefined reference to `msgb_data'
osmo-euse-demo.c:(.text+0x187): undefined reference to `msgb_length'
osmo-euse-demo.c:(.text+0x19d): undefined reference to `gsm0480_msgb_alloc_name'
osmo-euse-demo.c:(.text+0x1d2): undefined reference to `osmo_panic'
osmo-euse-demo.c:(.text+0x1eb): undefined reference to `osmo_gsup_encode'
osmo-euse-demo.c:(.text+0x1fa): undefined reference to `msgb_free'
osmo-euse-demo.c:(.text+0x213): undefined reference to `osmo_gsup_client_send'
/tmp/cciVuWmr.o: In function `euse_tx_ussd_reject':
osmo-euse-demo.c:(.text+0x261): undefined reference to `gsm0480_gen_reject'
osmo-euse-demo.c:(.text+0x274): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x2be): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x2ed): undefined reference to `osmo_panic'
/tmp/cciVuWmr.o: In function `euse_tx_ussd_resp_7bit':
osmo-euse-demo.c:(.text+0x34a): undefined reference to `gsm0480_gen_ussd_resp_7bit'
osmo-euse-demo.c:(.text+0x35d): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x3b8): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x3e7): undefined reference to `osmo_panic'
/tmp/cciVuWmr.o: In function `euse_rx_proc_ss_req':
osmo-euse-demo.c:(.text+0x4b9): undefined reference to `gsm0480_parse_facility_ie'
osmo-euse-demo.c:(.text+0x509): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x595): undefined reference to `logp2'
/tmp/cciVuWmr.o: In function `gsupc_read_cb':
osmo-euse-demo.c:(.text+0x6e3): undefined reference to `osmo_gsup_decode'
osmo-euse-demo.c:(.text+0x701): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x714): undefined reference to `msgb_hexdump'
osmo-euse-demo.c:(.text+0x746): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x764): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x777): undefined reference to `msgb_hexdump'
osmo-euse-demo.c:(.text+0x7b6): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x7f9): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x83c): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x855): undefined reference to `msgb_free'
/tmp/cciVuWmr.o: In function `main':
osmo-euse-demo.c:(.text+0x8bd): undefined reference to `talloc_named_const'
osmo-euse-demo.c:(.text+0x8d4): undefined reference to `osmo_init_logging2'
osmo-euse-demo.c:(.text+0x98c): undefined reference to `osmo_gsup_client_create'
osmo-euse-demo.c:(.text+0x99d): undefined reference to `osmo_select_main'
collect2: error: ld returned 1 exit status
root at reza-VirtualBox:/home/reza/osmocom/include# vim osmo
osmocom/          osmo-euse-demo.c
root at reza-VirtualBox:/home/reza/osmocom/include# vim osmo
osmocom/          osmo-euse-demo.c
root at reza-VirtualBox:/home/reza/osmocom/include# vim osmo
osmocom/          osmo-euse-demo.c
root at reza-VirtualBox:/home/reza/osmocom/include# cc -v -I/home/reza/osmocom/include osmo-euse-demo.c -o osmosamplemc
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-o' 'osmosamplemc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/cc1 -quiet -v -I /home/reza/osmocom/include -imultiarch x86_64-linux-gnu osmo-euse-demo.c -quiet -dumpbase osmo-euse-demo.c -mtune=generic -march=x86-64 -auxbase osmo-euse-demo -version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/cciw60w9.s
GNU C11 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
                compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/reza/osmocom/include
/usr/lib/gcc/x86_64-linux-gnu/7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C11 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
                compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b62ed4a2880cd4159476ea8293b72fa8
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-o' 'osmosamplemc' '-mtune=generic' '-march=x86-64'
as -v -I /home/reza/osmocom/include --64 -o /tmp/ccDvwYka.o /tmp/cciw60w9.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-I' '/home/reza/osmocom/include' '-o' 'osmosamplemc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccbULaab.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o osmosamplemc /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. /tmp/ccDvwYka.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
/tmp/ccDvwYka.o: In function `osmo_gsup_message_type_name':
osmo-euse-demo.c:(.text+0x36): undefined reference to `osmo_gsup_message_type_names'
osmo-euse-demo.c:(.text+0x3b): undefined reference to `get_value_string'
/tmp/ccDvwYka.o: In function `osmo_gsup_session_state_name':
osmo-euse-demo.c:(.text+0x54): undefined reference to `osmo_gsup_session_state_names'
osmo-euse-demo.c:(.text+0x59): undefined reference to `get_value_string'
/tmp/ccDvwYka.o: In function `gsm0480_op_code_name':
osmo-euse-demo.c:(.text+0x75): undefined reference to `gsm0480_op_code_names'
osmo-euse-demo.c:(.text+0x7a): undefined reference to `get_value_string'
/tmp/ccDvwYka.o: In function `euse_tx_ss':
osmo-euse-demo.c:(.text+0xf4): undefined reference to `msgb_free'
osmo-euse-demo.c:(.text+0x12d): undefined reference to `osmo_strlcpy'
osmo-euse-demo.c:(.text+0x171): undefined reference to `msgb_data'
osmo-euse-demo.c:(.text+0x187): undefined reference to `msgb_length'
osmo-euse-demo.c:(.text+0x19d): undefined reference to `gsm0480_msgb_alloc_name'
osmo-euse-demo.c:(.text+0x1d2): undefined reference to `osmo_panic'
osmo-euse-demo.c:(.text+0x1eb): undefined reference to `osmo_gsup_encode'
osmo-euse-demo.c:(.text+0x1fa): undefined reference to `msgb_free'
osmo-euse-demo.c:(.text+0x213): undefined reference to `osmo_gsup_client_send'
/tmp/ccDvwYka.o: In function `euse_tx_ussd_reject':
osmo-euse-demo.c:(.text+0x261): undefined reference to `gsm0480_gen_reject'
osmo-euse-demo.c:(.text+0x274): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x2be): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x2ed): undefined reference to `osmo_panic'
/tmp/ccDvwYka.o: In function `euse_tx_ussd_resp_7bit':
osmo-euse-demo.c:(.text+0x34a): undefined reference to `gsm0480_gen_ussd_resp_7bit'
osmo-euse-demo.c:(.text+0x35d): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x3b8): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x3e7): undefined reference to `osmo_panic'
/tmp/ccDvwYka.o: In function `euse_rx_proc_ss_req':
osmo-euse-demo.c:(.text+0x4b9): undefined reference to `gsm0480_parse_facility_ie'
osmo-euse-demo.c:(.text+0x509): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x595): undefined reference to `logp2'
/tmp/ccDvwYka.o: In function `gsupc_read_cb':
osmo-euse-demo.c:(.text+0x6e3): undefined reference to `osmo_gsup_decode'
osmo-euse-demo.c:(.text+0x701): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x714): undefined reference to `msgb_hexdump'
osmo-euse-demo.c:(.text+0x746): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x764): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x777): undefined reference to `msgb_hexdump'
osmo-euse-demo.c:(.text+0x7b6): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x7f9): undefined reference to `log_check_level'
osmo-euse-demo.c:(.text+0x83c): undefined reference to `logp2'
osmo-euse-demo.c:(.text+0x855): undefined reference to `msgb_free'
/tmp/ccDvwYka.o: In function `main':
osmo-euse-demo.c:(.text+0x8bd): undefined reference to `talloc_named_const'
osmo-euse-demo.c:(.text+0x8d4): undefined reference to `osmo_init_logging2'
osmo-euse-demo.c:(.text+0x98c): undefined reference to `osmo_gsup_client_create'
osmo-euse-demo.c:(.text+0x99d): undefined reference to `osmo_select_main'
collect2: error: ld returned 1 exit status
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200406/4ce4db87/attachment.htm>

From axilirator at gmail.com  Tue Apr  7 22:47:49 2020
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Wed, 8 Apr 2020 05:47:49 +0700
Subject: =?UTF-8?B?UmU6IOKAnG9zbW8tZXVzZS1kZW1vLmPigJw=?=
In-Reply-To: <DM6PR11MB42996427898231853C726931B1C20@DM6PR11MB4299.namprd11.prod.outlook.com>
References: <DM6PR11MB42996427898231853C726931B1C20@DM6PR11MB4299.namprd11.prod.outlook.com>
Message-ID: <CAPEnp=bv7QxRWFjXzi3HOsay2wsZO-wbbZyOV5ZcP7n=fv0xig@mail.gmail.com>

Hello Reza,

> in order to demonstrate the core Network vulnerebalities

please keep in mind that GSUP is a non-standard Osmocom-specific
protocol, so you won't find it in commercial networks. Not sure if
this is really what you are looking for. You may want to read about
MAP and DIAMETER.

> Can you please tell me how can i solve this error.

The problem is that you're trying to build it outside the build tree.
You don't have to do it this way as it's being built together with the
osmo-hlr binary.

> Or how can i have Access to the already maked file of ?osmo-euse-demo.c? to execute it .

Osmocom provides binary packages, see [1] for more details. I never
used them myself, but I think 'osmo-euse-demo' binary is a part of the
osmo-hlr package. After adding the package feeds, you can install
osmo-hlr using your package manager:

$ apt update
$ apt install osmo-hlr

Please note that we also have build scripts for Docker, see [2] and [3].

[1] https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages
[2] https://git.osmocom.org/docker-playground/tree/osmo-hlr-latest
[3] https://git.osmocom.org/docker-playground/tree/osmo-hlr-master

With best regards,
Vadim Yanitskiy.


From laforge at gnumonks.org  Wed Apr  8 06:51:12 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 08 Apr 2020 08:51:12 +0200
Subject: OsmoSTP connection
In-Reply-To: <CAKGRp3UemE0gmSVxbzKny1bXaz9qL2kGU+ukQ1O21Bqr1KMx4Q@mail.gmail.com>
References: <CAKGRp3UemE0gmSVxbzKny1bXaz9qL2kGU+ukQ1O21Bqr1KMx4Q@mail.gmail.com>
Message-ID: <0C2BBA93-C268-49A1-837D-D2004296E758@gnumonks.org>



Hi Igor,

Sorry for the late response, but you normally need to subscribe to the mailing list before posting - otherwise your message is in the moderation queue.

On March 16, 2020 1:52:41 PM GMT+01:00, Igor Kim <oldtraf1999 at gmail.com> wrote:
>Hello dears!
>I try to connect 2 STPs to each other via Sigtran M3UA protocol.
>But I don't understand, why my connection is fault. Could you please
>check
>my configuration?

Looks fine to me art first glance.

Can you please share log files and a pcap file with the sctp communication?

-- 
Sent from a mobile device. Please excuse my brevity.


From aaltokoskinen at gmail.com  Thu Apr  9 10:15:52 2020
From: aaltokoskinen at gmail.com (Aalto Koskinen)
Date: Thu, 9 Apr 2020 13:15:52 +0300
Subject: Fwd: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
Message-ID: <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>

Hi,

I looked at the forum for answers before posting, but I
unfortunately couldn't get answers to what I was looking for. I looked into
particular
https://www.mail-archive.com/openbsc at lists.osmocom.org/msg09819.html for
solving my issue.

Setup: USRP B210 as radio head. NITB modules as components for 2G Network
and BTS-TRX and TRX-UHD modules.
Issue:

   - TRX-UHD and BTS-TRX fail. NITB Module works. Components of NITB
   network are able to connect to each other.
   - I have the RSP POWEROFF message originating in log from TRX-UHD module
   and the BTS module is shuttiing down.
   - BTS connects via OML but fails to connect RSL.
   - As per the previous email archive, I wanted to login to VTY and check
   the logs, but, it logs out as the BTS module shuts down (I cannot connect
   and see what's happening).

I looked through the configuration files and seem correct to me.
Any suggestions would be appreciated on solving the issue. I am trying to
create a test 2G OSMOCOM network. Logs are written below and configuration
as attachments.

Thanks for your help!

*OSMO_BTS_TRX log:*
systemd[1]: Started Osmocom osmo-bts for osmo-trx.
osmo-bts-trx[23221]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238
osmo-bts-trx[23221]: <0010> telnet_interface.c:104 Available via telnet
127.0.0.1 4241
osmo-bts-trx[23221]: <0012> input/ipaccess.c:1024 enabling ipaccess BTS
mode, OML connecting to 192.168.0.9:3002
osmo-bts-trx[23221]: <000b> trx_if.c:1174 phy0.0: Open transceiver
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000d> abis.c:142 Signalling link down
osmo-bts-trx[23221]: <0001> bts.c:292 Shutting down BTS 0, Reason Abis close
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: Shutdown timer expired
osmo-bts-trx[23221]: ((*))
osmo-bts-trx[23221]:   |
osmo-bts-trx[23221]:  / \ OsmoBTS

*OSMO_TRX_UHD log:*

 ubuntu-HP-EliteBook-8470p systemd[1]: Started Osmocom SDR BTS L1
Transceiver (UHD Backend).
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:21
2020 DLGLOBAL <0007> telnet_interface.c:104 Available via telnet
127.0.0.1 4237
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:21
2020 DLCTRL <000e> control_if.c:911 CTRL at 127.0.0.1 4236
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:21
2020 DMAIN <0000> osmo-trx.cpp:485 [tid=140554411180864] Config
Settings
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Log Level............... 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Device args.............
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    TRX Base Port........... 5700
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    TRX
Address............. 127.0.0.1
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    GSM BTS
Address......... 127.0.0.1
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Channels................ 1
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Tx Samples-per-Symbol... 4
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Rx Samples-per-Symbol... 4
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    EDGE support............ 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Extended RACH support... 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Reference............... 1
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Filler Burst
Type....... Empty bursts
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Filler Burst TSC........ 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Filler Burst RACH Delay. 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Multi-Carrier........... 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Tuning offset........... 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    RSSI to dBm offset...... 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Swap channels........... 0
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Tx
Antennas............. '<default>'
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:    Rx
Antennas............. '<default>'
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:21
2020 DMAIN <0000> osmo-trx.cpp:439 [tid=140554411180864] Setting
SCHED_RR priority 18
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: [INFO] [UHD] linux; GNU
C++ version 7.4.0; Boost_106501; UHD_3.14.1.1-release
 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:21
2020 DDEV <0005> UHDDevice.cpp:470 [tid=140554411180864] Using
discovered UHD device
type=b200,name=MyB210,serial=31A92EA,product=B210
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:22 2020
DDEVDRV <0006> b200_impl.cpp:386 [tid=140554300024576] [B200] Detected
Device: B210
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:22 2020
DDEVDRV <0006> b200_impl.cpp:433 [tid=140554300024576] [B200]
Operating over USB 2.
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:22 2020
DDEVDRV <0006> b200_impl.cpp:587 [tid=140554300024576] [B200]
Initialize CODEC control...
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:650
[tid=140554300024576] [B200] Initialize Radio control...
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:957
[tid=140554300024576] [B200] Performing register loopback test...
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:966
[tid=140554300024576] [B200] Register loopback test passed
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:957
[tid=140554300024576] [B200] Performing register loopback test...
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:966
[tid=140554300024576] [B200] Register loopback test passed
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:758
[tid=140554300024576] [B200] Setting master clock rate selection to
'automatic'.
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:1013
[tid=140554300024576] [B200] Asking for clock rate 16.000000 MHz...
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:1024
[tid=140554300024576] [B200] Actually got clock rate 16.000000 MHz.
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DMAIN <0000> UHDDevice.cpp:214
[tid=140554411180864] Antennas configured successfully
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> multi_usrp.cpp:502
[tid=140554300024576] [MULTI_USRP] Setting master clock rate selection
to 'manual'.
huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu
Apr  9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:1013
[tid=140554300024576] [B200] Asking for clock rate 26.000000 MHz...
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DDEVDRV <0006> b200_impl.cpp:1024 [tid=140554300024576] [B200]
Actually got clock rate 26.000000 MHz.
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DDEV <0005> UHDDevice.cpp:275 [tid=140554411180864] Rates configured
for B210 4 SPS
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DDEV <0005> UHDDevice.cpp:235 [tid=140554411180864] Supported Tx gain
range [0; 89.75]
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DDEV <0005> UHDDevice.cpp:240 [tid=140554411180864] Supported Rx gain
range [0; 76]
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DDEV <0005> UHDDevice.cpp:244 [tid=140554411180864] Default setting Tx
gain for channel 0 to 44.875
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DDEV <0005> UHDDevice.cpp:251 [tid=140554411180864] Default setting Rx
gain for channel 0 to 38
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DDEV <0005> UHDDevice.cpp:569 [tid=140554411180864] Device
configuration: Single USRP:
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:   Device: B-Series Device
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:   Mboard 0: B210
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:   RX Channel: 0
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:     RX DSP: 0
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:     RX Dboard: A
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:     RX Subdev: FE-RX2
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:   TX Channel: 0
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:     TX DSP: 0
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:     TX Dboard: A
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]:     TX Subdev: FE-TX2
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DMAIN <0000> Threads.cpp:119 [tid=140554180474624] Thread
140554180474624 (task 8317) set name: CtrlService0
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DMAIN <0000> osmo-trx.cpp:533 [tid=140554411180864] -- Transceiver
active with 1 channel(s)
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
command is 'POWEROFF'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 2020
DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
response is 'RSP POWEROFF 0'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:28 2020
DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
command is 'POWEROFF'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:28 2020
DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
response is 'RSP POWEROFF 0'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:33 2020
DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
command is 'POWEROFF'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:33 2020
DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
response is 'RSP POWEROFF 0'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:38 2020
DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
command is 'POWEROFF'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:38 2020
DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
response is 'RSP POWEROFF 0'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:43 2020
DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
command is 'POWEROFF'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:43 2020
DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
response is 'RSP POWEROFF 0'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:49 2020
DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
command is 'POWEROFF'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:49 2020
DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
response is 'RSP POWEROFF 0'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:54 2020
DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
command is 'POWEROFF'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:54 2020
DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
response is 'RSP POWEROFF 0'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:59 2020
DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
command is 'POWEROFF'
ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:59 2020
DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
response is 'RSP POWEROFF 0'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/74e0a3a7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bsc.cfg
Type: application/octet-stream
Size: 1206 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/74e0a3a7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts-trx.cfg
Type: application/octet-stream
Size: 600 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/74e0a3a7/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-trx-uhd.cfg
Type: application/octet-stream
Size: 390 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/74e0a3a7/attachment-0002.obj>

From axilirator at gmail.com  Thu Apr  9 10:52:15 2020
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 9 Apr 2020 17:52:15 +0700
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
Message-ID: <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>

Hello Aalto,

your configuration looks good to me. As far as I understand, you're
running both osmo-bts-trx and osmo-trx on the same machine. As can be
seen from your logs, TRXC commands from osmo-bts-trx are received by
osmo-trx:

> <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF'

however the response messages from osmo-trx do not reach osmo-bts-trx:

> <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0'
> <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF)

Maybe your firewall is blocking traffic (udp/5701 and udp/5801)
somehow? Could you please send us a *.pcap capture ('lo' interface)?

With best regards,
Vadim Yanitskiy.


From aaltokoskinen at gmail.com  Thu Apr  9 12:09:06 2020
From: aaltokoskinen at gmail.com (Aalto Koskinen)
Date: Thu, 9 Apr 2020 15:09:06 +0300
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
 <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
Message-ID: <CAJx05u3LFbz56+V2Q8waE5pKYA2AAtAYsZW2MjUyeWjSZnaEDQ@mail.gmail.com>

Hi Vadim,

Thank you for your quick replies. (Previously, due to error, I sent reply
to you. Now, I have resent with openbsc in cc)

I wasn't sure, if my firewall is blocking the port or not. Hence, I took a
wire shark trace test.pcap. I ran sudo ufw allow 5701 and sudo ufw allow
5801 and then again took wire shark trace test2.pcap. Both traces are
attached. From my inspection, the ports have still the same messages.

I am also attaching the configuration of other components, as a reference.

Thanks again for the help

On Thu, 9 Apr 2020 at 13:52, Vadim Yanitskiy <axilirator at gmail.com> wrote:

> Hello Aalto,
>
> your configuration looks good to me. As far as I understand, you're
> running both osmo-bts-trx and osmo-trx on the same machine. As can be
> seen from your logs, TRXC commands from osmo-bts-trx are received by
> osmo-trx:
>
> > <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is
> 'POWEROFF'
>
> however the response messages from osmo-trx do not reach osmo-bts-trx:
>
> > <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is
> 'RSP POWEROFF 0'
> > <000b> trx_if.c:185 phy0.0: No satisfactory response from
> transceiver(CMD POWEROFF)
>
> Maybe your firewall is blocking traffic (udp/5701 and udp/5801)
> somehow? Could you please send us a *.pcap capture ('lo' interface)?
>
> With best regards,
> Vadim Yanitskiy.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-sgsn.cfg
Type: application/octet-stream
Size: 541 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-pcu.cfg
Type: application/octet-stream
Size: 79 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-ggsn.cfg
Type: application/octet-stream
Size: 1668 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pcap
Type: application/vnd.tcpdump.pcap
Size: 34866 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.pcap
Type: application/vnd.tcpdump.pcap
Size: 28554 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-stp.cfg
Type: application/octet-stream
Size: 337 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-msc.cfg
Type: application/octet-stream
Size: 345 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-hlr.cfg
Type: application/octet-stream
Size: 306 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-mgw-for-msc.cfg
Type: application/octet-stream
Size: 262 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200409/9570a1a1/attachment-0006.obj>

From axilirator at gmail.com  Thu Apr  9 12:38:45 2020
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 9 Apr 2020 19:38:45 +0700
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <CAJx05u3LFbz56+V2Q8waE5pKYA2AAtAYsZW2MjUyeWjSZnaEDQ@mail.gmail.com>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
 <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
 <CAJx05u3LFbz56+V2Q8waE5pKYA2AAtAYsZW2MjUyeWjSZnaEDQ@mail.gmail.com>
Message-ID: <CAPEnp=b49e5mfH78MdBMWRzDGaQCUw_YvTXm-gHTUTVGr4SUhQ@mail.gmail.com>

Hi again,

> Hence, I took a wire shark trace test.pcap.

I see ICMP Destination Unreachable messages in your captures:

>    3   0.010926    127.0.0.1 ? 127.0.0.1    OsmoTRXC 55 CMD POWEROFF
>    4   0.010938    127.0.0.1 ? 127.0.0.1    ICMP 83 Destination unreachable (Port unreachable)
>  145   2.011000    127.0.0.1 ? 127.0.0.1    OsmoTRXC 55 CMD POWEROFF
>  146   2.011016    127.0.0.1 ? 127.0.0.1    ICMP 83 Destination unreachable (Port unreachable)
>  185   4.011062    127.0.0.1 ? 127.0.0.1    OsmoTRXC 55 CMD POWEROFF
>  186   4.011144    127.0.0.1 ? 127.0.0.1    OsmoTRXC 57 RSP POWEROFF 0
>  239  18.099625    127.0.0.1 ? 127.0.0.1    OsmoTRXC 55 CMD POWEROFF
>  240  18.099703    127.0.0.1 ? 127.0.0.1    OsmoTRXC 57 RSP POWEROFF 0
>  269  35.349196    127.0.0.1 ? 127.0.0.1    OsmoTRXC 55 CMD POWEROFF
>  270  35.349271    127.0.0.1 ? 127.0.0.1    OsmoTRXC 57 RSP POWEROFF 0

Perhaps you're starting osmo-bts-trx before osmo-trx? Make sure to
start osmo-trx first and give it enough time to upload the UHD
firmware, unless you see "Transceiver active with X channel(s)".

With best regards,
Vadim Yanitskiy.


From pespin at sysmocom.de  Thu Apr  9 12:39:53 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 9 Apr 2020 14:39:53 +0200
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
 <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
Message-ID: <81b24fdc-7370-c023-5fa4-76e9dd8da602@sysmocom.de>

Hi,

I have the feeling the connection between osmo-trx and osmo-bts-trx is 
good. The problem is that your BTS<->BSC<->... is failing.

BTs shows these messages at startup because osmo-trx is not yet running:
""""
 > osmo-bts-trx[23221]: <000b> trx_if.c:1174 phy0.0: Open transceiver
 > osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory
 > response from transceiver(CMD POWEROFF)
"""

Then at some point osmo-trx answers:
"""
 > ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 
2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] 
command is 'POWEROFF'
 > ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24 
2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] 
response is 'RSP POWEROFF 0'
"""

But it's already too late, the BTS is already exiting due to some issue 
in Abis:
"""
 > osmo-bts-trx[23221]: <000d> abis.c:142 Signalling link down
 > osmo-bts-trx[23221]: <0001> bts.c:292 Shutting down BTS 0, Reason 
Abis close
"""

Regards,
Pau

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From axilirator at gmail.com  Thu Apr  9 12:53:10 2020
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 9 Apr 2020 19:53:10 +0700
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <81b24fdc-7370-c023-5fa4-76e9dd8da602@sysmocom.de>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
 <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
 <81b24fdc-7370-c023-5fa4-76e9dd8da602@sysmocom.de>
Message-ID: <CAPEnp=YuXf405j6-E-RmfzpFF7TP1pT1LTy7b+oGLN+zomud7Q@mail.gmail.com>

Hi Aalto, Pau,

> The problem is that your BTS<->BSC<->... is failing.

I don't see any related packets in the captures, neither RSL nor OML...

However, I see an obvious issue - IPA unit-id mismatch:

> # This is the unit id that has to match the BTS configuration
> ip.access unit_id 1800 0

vs

> ipa unit-id 6969 0

Are you using some configuration examples? If so, where are they from?
Also, are you sure that osmo-bsc is actually running on 192.168.122.1?

With best regards,
Vadim Yanitskiy.


From craig at unreasonablefarm.org  Fri Apr 10 18:21:15 2020
From: craig at unreasonablefarm.org (Craig Comstock)
Date: Fri, 10 Apr 2020 13:21:15 -0500
Subject: debug call failure on new nitb setup please?
Message-ID: <20200410182115.GA52122@other>

Hi,

I am setting up a nitb/nano3g right now and have the basics working with the nano3g talking to hnbgw and services running on my nitb box (rpi 3-something).

I have two of the same phones: ZTE Obsidian with Android 5.1 which are able to connect to my network.

When I try to call the other phone I don't get connected. It takes about 1 minute for the call to fail.

Once the phone mentioned some problem with "access configuration for normal calls".

Attached are my configs and logs from nano3g trace log and hnbgw journal during a failed call.

Any help would be appreciated. I am sure I did something obviously wrong.

I'll try and read the configs carefully to make sure that matches with what is up on the wiki.

Thanks,
Craig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2020-04-10-etc-osmocom.tgz
Type: application/x-gtar-compressed
Size: 2380 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200410/0669137f/attachment.bin>
-------------- next part --------------
-- Logs begin at Wed 2020-04-08 10:17:13 CDT. --
Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 37 bytes
Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:126 Decoding message RUA_DisconnectIEs (rua_decoder.c:126)
Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:388 RUA Disconnect.req(ctx=0x18,cause=radio(normal))
Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1009
Apr 10 12:57:47 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
Apr 10 12:57:47 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x17)
Apr 10 12:57:47 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuPS to RI=2,PC=188,SSN=142, rua_ctx_id 23 scu_conn_id 1000
Apr 10 12:57:47 nitb osmo-hnbgw[17756]: <0011> sccp_scoc.c:1657 SCCP-SCOC(1000)[0x716740]{CONN_PEND_OUT}: Event N-DATA.req not permitted
Apr 10 12:58:01 nitb osmo-hnbgw[17756]: <0000> context_map.c:151 Running context mapper garbage collection
Apr 10 12:58:24 nitb osmo-hnbgw[17756]: <0000> context_map.c:151 Running context mapper garbage collection
Apr 10 12:58:36 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DISCONNECT.indication)
Apr 10 12:58:36 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:334 handle_cn_disc_ind() conn_id=1000 originator=2
Apr 10 12:58:36 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:336 handle_cn_disc_ind() responding_addr=0.0.0.0
Apr 10 12:58:36 nitb osmo-hnbgw[17756]: <0002> rua_common.c:214 Error in ANY_fromType_aper
Apr 10 12:58:39 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DISCONNECT.indication)
Apr 10 12:58:39 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:334 handle_cn_disc_ind() conn_id=1002 originator=2
Apr 10 12:58:39 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:336 handle_cn_disc_ind() responding_addr=0.0.0.0
Apr 10 12:58:39 nitb osmo-hnbgw[17756]: <0002> rua_common.c:214 Error in ANY_fromType_aper
Apr 10 12:58:47 nitb osmo-hnbgw[17756]: <0000> context_map.c:151 Running context mapper garbage collection
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:359 RUA IuCS Connect.req(ctx=0x18, normal)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> context_map.c:93 Creating new Mapping RUA CTX 0x712cf0/24 <-> SCU Conn ID 0x713cd0/1010
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:241 RUA to SCCP N_CONNECT: called_addr:RI=2,PC=185,SSN=142
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:243 RUA to SCCP N_CONNECT: calling_addr:RI=2,PC=189,SSN=142
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-CONNECT.confirm)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:296 handle_cn_conn_conf() conn_id=1010
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:298 handle_cn_conn_conf() called_addr=0.0.0.0
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:300 handle_cn_conn_conf() calling_addr=0.0.0.0
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:302 handle_cn_conn_conf() responding_addr=0.0.0.0
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 78 bytes
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:359 RUA IuPS Connect.req(ctx=0x18, normal)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuPS to RI=2,PC=188,SSN=142, rua_ctx_id 24 scu_conn_id 1002
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:241 RUA to SCCP N_CONNECT: called_addr:RI=2,PC=188,SSN=142
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:243 RUA to SCCP N_CONNECT: calling_addr:RI=2,PC=189,SSN=142
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 58 bytes
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 44 bytes
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 55 bytes
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 37 bytes
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:126 Decoding message RUA_DisconnectIEs (rua_decoder.c:126)
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:388 RUA Disconnect.req(ctx=0x18,cause=radio(normal))
Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:359 RUA IuCS Connect.req(ctx=0x18, normal)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> context_map.c:93 Creating new Mapping RUA CTX 0x712cf0/24 <-> SCU Conn ID 0x713cd0/1011
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:241 RUA to SCCP N_CONNECT: called_addr:RI=2,PC=185,SSN=142
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:243 RUA to SCCP N_CONNECT: calling_addr:RI=2,PC=189,SSN=142
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-CONNECT.confirm)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:296 handle_cn_conn_conf() conn_id=1011
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:298 handle_cn_conn_conf() called_addr=0.0.0.0
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:300 handle_cn_conn_conf() calling_addr=0.0.0.0
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:302 handle_cn_conn_conf() responding_addr=0.0.0.0
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 78 bytes
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 58 bytes
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 44 bytes
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 43 bytes
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-UNITDATA.indication)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0003> ranap_decoder.c:714 Decoding message RANAP_PagingIEs (ranap_decoder.c:714)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:89 transmitting RUA payload of 46 bytes
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 47 bytes
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 37 bytes
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:126 Decoding message RUA_DisconnectIEs (rua_decoder.c:126)
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:388 RUA Disconnect.req(ctx=0x18,cause=radio(normal))
Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
-------------- next part --------------
Apr 10 17:57:42.490 [UEContext-23] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
Apr 10 17:57:42.490 [UEContext-23] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
Apr 10 17:57:42.499 [3GAP-3] C3GAP::Send uRSL msg id 9
Apr 10 17:57:47.440 [UEContext-22] UEContextRelease from UE
Apr 10 17:57:47.440 [UEContext-22] URSL> UEContextRelease
Apr 10 17:57:47.442 [UEContext-22] Starting TimerIdUeContextCleanupPending
Apr 10 17:57:57.427 [UEContext-22] TimerIdUeContextCleanupPending Timeout
Apr 10 17:57:57.427 [UEContext-22] TimerIdUeContextCleanupPending Timeout
Apr 10 17:57:57.428 [UEContext-22] UE context destroyed.  SRNTI 21, ACUEId 16, IuH CtxtId 23
Apr 10 17:57:57.428 [UEContext-22] Destroyed UEContext-22, Remaining URSLManager-4 UEContext-14 UEContext-17 UEContext-20 UEContext-21 UEContext-23 MIBCnx-1 3GAP-3 IuhClient-16 SysAgent-2 
Apr 10 17:58:56.171 [URSLManager-4] UEContextRequest from UE
Apr 10 17:58:56.173 [UEContext-24] Created UEContext-24, num classes 11
Apr 10 17:58:56.173 [UEContext-24] Create UE context.  SRNTI 23, ACUEId 18, cause 12
Apr 10 17:58:56.173 [UEContext-24] Create UE context.  SRNTI 23, ACUEId 18, cause 12
Apr 10 17:58:56.174 [3GAP-3] C3GAP::Send uRSL msg id 2
Apr 10 17:58:56.992 [UEContext-24] URSL InitialDirectTransfer received for CSDomain in state IncPending
Apr 10 17:58:56.992 [UEContext-24] Sending RUA Connect to HNB-GW for CSDomain with Context 0x18
Apr 10 17:58:56.993 [UEContext-24] Sending RUA Connect to HNB-GW for CSDomain with Context 0x18
Apr 10 17:58:56.993 [UEContext-24] URSL InitialDirectTransfer from UE, CSDomain, NAS len 20
Apr 10 17:58:57.040 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 54
Apr 10 17:58:57.041 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
Apr 10 17:58:57.045 [3GAP-3] C3GAP::Send uRSL msg id 7
Apr 10 17:58:57.614 [UEContext-24] URSL> InitialDirectTransfer
Apr 10 17:58:57.614 [UEContext-24] URSL InitialDirectTransfer received for PSDomain in state Active
Apr 10 17:58:57.614 [UEContext-24] Sending RUA Connect to HNB-GW for PSDomain with Context 0x18
Apr 10 17:58:57.614 [UEContext-24] Sending RUA Connect to HNB-GW for PSDomain with Context 0x18
Apr 10 17:58:57.614 [UEContext-24] URSL InitialDirectTransfer from UE, PSDomain, NAS len 91
Apr 10 17:58:57.753 [UEContext-24] URSL> UplinkDirectTransfer
Apr 10 17:58:57.753 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 12
Apr 10 17:58:57.831 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 34
Apr 10 17:58:57.831 [UEContext-24] RANAP SecurityModeControl request from CSDomain
Apr 10 17:58:57.832 [UEContext-24] HNB-GW> RANAP SecurityModeControl, CSDomain
Apr 10 17:58:57.839 [3GAP-3] C3GAP::Send uRSL msg id 10
Apr 10 17:58:58.090 [UEContext-24] URSL SecurityModeComp, CSDomain
Apr 10 17:58:58.091 [UEContext-24] URSL SecurityModeComp, CSDomain, URSL ChosenIntAlgo 0
Apr 10 17:58:58.098 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 20
Apr 10 17:58:58.098 [UEContext-24] RANAP CommonId from CSDomain
Apr 10 17:58:58.099 [UEContext-24] HNB-GW> RANAP CommonId, CSDomain
Apr 10 17:58:58.099 [UEContext-24] RANAP CommonId provided IMSI 901700000015242
Apr 10 17:58:58.298 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 31
Apr 10 17:58:58.298 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
Apr 10 17:58:58.304 [3GAP-3] C3GAP::Send uRSL msg id 7
Apr 10 17:58:58.562 [UEContext-24] URSL> UplinkDirectTransfer
Apr 10 17:58:58.562 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 2
Apr 10 17:58:58.594 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 13
Apr 10 17:58:58.595 [UEContext-24] RANAP IuReleaseCommand
Apr 10 17:58:58.595 [UEContext-24] HNB-GW> RANAP IuRelease, CSDomain
Apr 10 17:58:58.595 [UEContext-24] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
Apr 10 17:58:58.595 [UEContext-24] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
Apr 10 17:58:58.601 [3GAP-3] C3GAP::Send uRSL msg id 9
Apr 10 17:58:58.993 [UEContext-24] URSL> InitialDirectTransfer
Apr 10 17:58:58.993 [UEContext-24] URSL InitialDirectTransfer received for CSDomain in state Active
Apr 10 17:58:58.994 [UEContext-24] Sending RUA Connect to HNB-GW for CSDomain with Context 0x18
Apr 10 17:58:58.994 [UEContext-24] Sending RUA Connect to HNB-GW for CSDomain with Context 0x18
Apr 10 17:58:58.994 [UEContext-24] URSL InitialDirectTransfer from UE, CSDomain, NAS len 16
Apr 10 17:58:59.003 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 54
Apr 10 17:58:59.004 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
Apr 10 17:58:59.009 [3GAP-3] C3GAP::Send uRSL msg id 7
Apr 10 17:58:59.503 [UEContext-24] URSL> UplinkDirectTransfer
Apr 10 17:58:59.503 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 12
Apr 10 17:58:59.510 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 34
Apr 10 17:58:59.511 [UEContext-24] RANAP SecurityModeControl request from CSDomain
Apr 10 17:58:59.511 [UEContext-24] HNB-GW> RANAP SecurityModeControl, CSDomain
Apr 10 17:58:59.515 [3GAP-3] C3GAP::Send uRSL msg id 10
Apr 10 17:58:59.760 [UEContext-24] URSL SecurityModeComp, CSDomain
Apr 10 17:58:59.760 [UEContext-24] URSL SecurityModeComp, CSDomain, URSL ChosenIntAlgo 0
Apr 10 17:58:59.794 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 20
Apr 10 17:58:59.794 [UEContext-24] RANAP CommonId from CSDomain
Apr 10 17:58:59.794 [UEContext-24] HNB-GW> RANAP CommonId, CSDomain
Apr 10 17:58:59.795 [UEContext-24] RANAP CommonId provided IMSI 901700000015242
Apr 10 17:59:00.083 [UEContext-24] URSL> UplinkDirectTransfer
Apr 10 17:59:00.083 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 31
Apr 10 17:59:00.090 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 19
Apr 10 17:59:00.091 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
Apr 10 17:59:00.095 [3GAP-3] C3GAP::Send uRSL msg id 7
Apr 10 17:59:00.291 [RANAP ConnectionlessInd] RANAP Paging provided IMSI 901700000015240
Apr 10 17:59:00.291 [RANAP] Paging 901700000015240
Apr 10 17:59:00.295 [3GAP-3] C3GAP::Send uRSL msg id 20
Apr 10 17:59:00.297 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 23
Apr 10 17:59:00.298 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
Apr 10 17:59:00.302 [3GAP-3] C3GAP::Send uRSL msg id 7
Apr 10 17:59:00.803 [UEContext-24] URSL> UplinkDirectTransfer
Apr 10 17:59:00.803 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 2
Apr 10 17:59:00.809 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 13
Apr 10 17:59:00.809 [UEContext-24] RANAP IuReleaseCommand
Apr 10 17:59:00.810 [UEContext-24] HNB-GW> RANAP IuRelease, CSDomain
Apr 10 17:59:00.810 [UEContext-24] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
Apr 10 17:59:00.810 [UEContext-24] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
Apr 10 17:59:00.816 [3GAP-3] C3GAP::Send uRSL msg id 9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200410/0669137f/attachment-0001.bin>

From pespin at sysmocom.de  Fri Apr 10 23:57:55 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Sat, 11 Apr 2020 01:57:55 +0200
Subject: debug call failure on new nitb setup please?
In-Reply-To: <20200410182115.GA52122@other>
References: <20200410182115.GA52122@other>
Message-ID: <2b89ecf4-da2f-d202-f0bc-5744a18025c7@sysmocom.de>

Hi,

It is going to be a lot easier to find possible issues if you share a 
full pcap with all the messaging going during the phone call.


-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From nhofmeyr at sysmocom.de  Tue Apr 14 12:21:31 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 14 Apr 2020 14:21:31 +0200
Subject: debug call failure on new nitb setup please?
In-Reply-To: <20200410182115.GA52122@other>
References: <20200410182115.GA52122@other>
Message-ID: <20200414122131.GA31595@my.box>

Hi Craig,

Verify that both UEs are successfully attached (verify by running some USSD
code configured in the HLR, e.g. *#100#). According to the nano3G trace it
looks like that worked fine.

One thing that could still go wrong is the Paging. I have noted at occasions
that a nano3G may fail to Page by IMSI, when the UE has only attached using a
TMSI. You can make the phones attempt an attach at some other random operator
and fail, it usually will forget its previous TMSI. If you now re-attach to
your own network, it will be using its IMSI to attach. You can try to set an
ACL in the nano3G's dmi to force using an IMSI like:
  set csgAccessMode=CSG_ACCESS_MODE_CLOSED_ACCESS
  set accessControlList = ({"901700000014701",1,"14701"},{"901700000014705",1,"14705"},{"901700000014706",1,"14706"})

Other than that, the most interesting logs are the osmo-msc and osmo-hlr logs.
I'm not familiar with the nano3G's logs, and the HNBGW is just a plain
forwarding element, it's logs aren't very revealing.

Ideally also examine a network trace, you can filter by 'sctp' or
'ranap || hnbap'. See whether you are getting a Paging Response.

~N

On Fri, Apr 10, 2020 at 01:21:15PM -0500, Craig Comstock wrote:
> Hi,
> 
> I am setting up a nitb/nano3g right now and have the basics working with the nano3g talking to hnbgw and services running on my nitb box (rpi 3-something).
> 
> I have two of the same phones: ZTE Obsidian with Android 5.1 which are able to connect to my network.
> 
> When I try to call the other phone I don't get connected. It takes about 1 minute for the call to fail.
> 
> Once the phone mentioned some problem with "access configuration for normal calls".
> 
> Attached are my configs and logs from nano3g trace log and hnbgw journal during a failed call.
> 
> Any help would be appreciated. I am sure I did something obviously wrong.
> 
> I'll try and read the configs carefully to make sure that matches with what is up on the wiki.
> 
> Thanks,
> Craig


> -- Logs begin at Wed 2020-04-08 10:17:13 CDT. --
> Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 37 bytes
> Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:126 Decoding message RUA_DisconnectIEs (rua_decoder.c:126)
> Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:388 RUA Disconnect.req(ctx=0x18,cause=radio(normal))
> Apr 10 12:57:42 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1009
> Apr 10 12:57:47 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
> Apr 10 12:57:47 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x17)
> Apr 10 12:57:47 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuPS to RI=2,PC=188,SSN=142, rua_ctx_id 23 scu_conn_id 1000
> Apr 10 12:57:47 nitb osmo-hnbgw[17756]: <0011> sccp_scoc.c:1657 SCCP-SCOC(1000)[0x716740]{CONN_PEND_OUT}: Event N-DATA.req not permitted
> Apr 10 12:58:01 nitb osmo-hnbgw[17756]: <0000> context_map.c:151 Running context mapper garbage collection
> Apr 10 12:58:24 nitb osmo-hnbgw[17756]: <0000> context_map.c:151 Running context mapper garbage collection
> Apr 10 12:58:36 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DISCONNECT.indication)
> Apr 10 12:58:36 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:334 handle_cn_disc_ind() conn_id=1000 originator=2
> Apr 10 12:58:36 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:336 handle_cn_disc_ind() responding_addr=0.0.0.0
> Apr 10 12:58:36 nitb osmo-hnbgw[17756]: <0002> rua_common.c:214 Error in ANY_fromType_aper
> Apr 10 12:58:39 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DISCONNECT.indication)
> Apr 10 12:58:39 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:334 handle_cn_disc_ind() conn_id=1002 originator=2
> Apr 10 12:58:39 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:336 handle_cn_disc_ind() responding_addr=0.0.0.0
> Apr 10 12:58:39 nitb osmo-hnbgw[17756]: <0002> rua_common.c:214 Error in ANY_fromType_aper
> Apr 10 12:58:47 nitb osmo-hnbgw[17756]: <0000> context_map.c:151 Running context mapper garbage collection
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:359 RUA IuCS Connect.req(ctx=0x18, normal)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> context_map.c:93 Creating new Mapping RUA CTX 0x712cf0/24 <-> SCU Conn ID 0x713cd0/1010
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:241 RUA to SCCP N_CONNECT: called_addr:RI=2,PC=185,SSN=142
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:243 RUA to SCCP N_CONNECT: calling_addr:RI=2,PC=189,SSN=142
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-CONNECT.confirm)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:296 handle_cn_conn_conf() conn_id=1010
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:298 handle_cn_conn_conf() called_addr=0.0.0.0
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:300 handle_cn_conn_conf() calling_addr=0.0.0.0
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:302 handle_cn_conn_conf() responding_addr=0.0.0.0
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 78 bytes
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:359 RUA IuPS Connect.req(ctx=0x18, normal)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuPS to RI=2,PC=188,SSN=142, rua_ctx_id 24 scu_conn_id 1002
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:241 RUA to SCCP N_CONNECT: called_addr:RI=2,PC=188,SSN=142
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:243 RUA to SCCP N_CONNECT: calling_addr:RI=2,PC=189,SSN=142
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:58:57 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 58 bytes
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 44 bytes
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 55 bytes
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 37 bytes
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:126 Decoding message RUA_DisconnectIEs (rua_decoder.c:126)
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:388 RUA Disconnect.req(ctx=0x18,cause=radio(normal))
> Apr 10 12:58:58 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1010
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:359 RUA IuCS Connect.req(ctx=0x18, normal)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> context_map.c:93 Creating new Mapping RUA CTX 0x712cf0/24 <-> SCU Conn ID 0x713cd0/1011
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:241 RUA to SCCP N_CONNECT: called_addr:RI=2,PC=185,SSN=142
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:243 RUA to SCCP N_CONNECT: calling_addr:RI=2,PC=189,SSN=142
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-CONNECT.confirm)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:296 handle_cn_conn_conf() conn_id=1011
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:298 handle_cn_conn_conf() called_addr=0.0.0.0
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:300 handle_cn_conn_conf() calling_addr=0.0.0.0
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:302 handle_cn_conn_conf() responding_addr=0.0.0.0
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 78 bytes
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 58 bytes
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:58:59 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 44 bytes
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 43 bytes
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-UNITDATA.indication)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0003> ranap_decoder.c:714 Decoding message RANAP_PagingIEs (ranap_decoder.c:714)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:89 transmitting RUA payload of 46 bytes
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 47 bytes
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:327 Decoding message RUA_DirectTransferIEs (rua_decoder.c:327)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:417 RUA Data.req(ctx=0x18)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> hnbgw_cn.c:364 sccp_sap_up(N-DATA.indication)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:126 transmitting RUA (cn=cs) payload of 37 bytes
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0000> rua_decoder.c:126 Decoding message RUA_DisconnectIEs (rua_decoder.c:126)
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:388 RUA Disconnect.req(ctx=0x18,cause=radio(normal))
> Apr 10 12:59:00 nitb osmo-hnbgw[17756]: <0002> hnbgw_rua.c:229 rua_to_scu() IuCS to RI=2,PC=185,SSN=142, rua_ctx_id 24 scu_conn_id 1011

> Apr 10 17:57:42.490 [UEContext-23] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
> Apr 10 17:57:42.490 [UEContext-23] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
> Apr 10 17:57:42.499 [3GAP-3] C3GAP::Send uRSL msg id 9
> Apr 10 17:57:47.440 [UEContext-22] UEContextRelease from UE
> Apr 10 17:57:47.440 [UEContext-22] URSL> UEContextRelease
> Apr 10 17:57:47.442 [UEContext-22] Starting TimerIdUeContextCleanupPending
> Apr 10 17:57:57.427 [UEContext-22] TimerIdUeContextCleanupPending Timeout
> Apr 10 17:57:57.427 [UEContext-22] TimerIdUeContextCleanupPending Timeout
> Apr 10 17:57:57.428 [UEContext-22] UE context destroyed.  SRNTI 21, ACUEId 16, IuH CtxtId 23
> Apr 10 17:57:57.428 [UEContext-22] Destroyed UEContext-22, Remaining URSLManager-4 UEContext-14 UEContext-17 UEContext-20 UEContext-21 UEContext-23 MIBCnx-1 3GAP-3 IuhClient-16 SysAgent-2 
> Apr 10 17:58:56.171 [URSLManager-4] UEContextRequest from UE
> Apr 10 17:58:56.173 [UEContext-24] Created UEContext-24, num classes 11
> Apr 10 17:58:56.173 [UEContext-24] Create UE context.  SRNTI 23, ACUEId 18, cause 12
> Apr 10 17:58:56.173 [UEContext-24] Create UE context.  SRNTI 23, ACUEId 18, cause 12
> Apr 10 17:58:56.174 [3GAP-3] C3GAP::Send uRSL msg id 2
> Apr 10 17:58:56.992 [UEContext-24] URSL InitialDirectTransfer received for CSDomain in state IncPending
> Apr 10 17:58:56.992 [UEContext-24] Sending RUA Connect to HNB-GW for CSDomain with Context 0x18
> Apr 10 17:58:56.993 [UEContext-24] Sending RUA Connect to HNB-GW for CSDomain with Context 0x18
> Apr 10 17:58:56.993 [UEContext-24] URSL InitialDirectTransfer from UE, CSDomain, NAS len 20
> Apr 10 17:58:57.040 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 54
> Apr 10 17:58:57.041 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
> Apr 10 17:58:57.045 [3GAP-3] C3GAP::Send uRSL msg id 7
> Apr 10 17:58:57.614 [UEContext-24] URSL> InitialDirectTransfer
> Apr 10 17:58:57.614 [UEContext-24] URSL InitialDirectTransfer received for PSDomain in state Active
> Apr 10 17:58:57.614 [UEContext-24] Sending RUA Connect to HNB-GW for PSDomain with Context 0x18
> Apr 10 17:58:57.614 [UEContext-24] Sending RUA Connect to HNB-GW for PSDomain with Context 0x18
> Apr 10 17:58:57.614 [UEContext-24] URSL InitialDirectTransfer from UE, PSDomain, NAS len 91
> Apr 10 17:58:57.753 [UEContext-24] URSL> UplinkDirectTransfer
> Apr 10 17:58:57.753 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 12
> Apr 10 17:58:57.831 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 34
> Apr 10 17:58:57.831 [UEContext-24] RANAP SecurityModeControl request from CSDomain
> Apr 10 17:58:57.832 [UEContext-24] HNB-GW> RANAP SecurityModeControl, CSDomain
> Apr 10 17:58:57.839 [3GAP-3] C3GAP::Send uRSL msg id 10
> Apr 10 17:58:58.090 [UEContext-24] URSL SecurityModeComp, CSDomain
> Apr 10 17:58:58.091 [UEContext-24] URSL SecurityModeComp, CSDomain, URSL ChosenIntAlgo 0
> Apr 10 17:58:58.098 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 20
> Apr 10 17:58:58.098 [UEContext-24] RANAP CommonId from CSDomain
> Apr 10 17:58:58.099 [UEContext-24] HNB-GW> RANAP CommonId, CSDomain
> Apr 10 17:58:58.099 [UEContext-24] RANAP CommonId provided IMSI 901700000015242
> Apr 10 17:58:58.298 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 31
> Apr 10 17:58:58.298 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
> Apr 10 17:58:58.304 [3GAP-3] C3GAP::Send uRSL msg id 7
> Apr 10 17:58:58.562 [UEContext-24] URSL> UplinkDirectTransfer
> Apr 10 17:58:58.562 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 2
> Apr 10 17:58:58.594 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 13
> Apr 10 17:58:58.595 [UEContext-24] RANAP IuReleaseCommand
> Apr 10 17:58:58.595 [UEContext-24] HNB-GW> RANAP IuRelease, CSDomain
> Apr 10 17:58:58.595 [UEContext-24] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
> Apr 10 17:58:58.595 [UEContext-24] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
> Apr 10 17:58:58.601 [3GAP-3] C3GAP::Send uRSL msg id 9
> Apr 10 17:58:58.993 [UEContext-24] URSL> InitialDirectTransfer
> Apr 10 17:58:58.993 [UEContext-24] URSL InitialDirectTransfer received for CSDomain in state Active
> Apr 10 17:58:58.994 [UEContext-24] Sending RUA Connect to HNB-GW for CSDomain with Context 0x18
> Apr 10 17:58:58.994 [UEContext-24] Sending RUA Connect to HNB-GW for CSDomain with Context 0x18
> Apr 10 17:58:58.994 [UEContext-24] URSL InitialDirectTransfer from UE, CSDomain, NAS len 16
> Apr 10 17:58:59.003 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 54
> Apr 10 17:58:59.004 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
> Apr 10 17:58:59.009 [3GAP-3] C3GAP::Send uRSL msg id 7
> Apr 10 17:58:59.503 [UEContext-24] URSL> UplinkDirectTransfer
> Apr 10 17:58:59.503 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 12
> Apr 10 17:58:59.510 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 34
> Apr 10 17:58:59.511 [UEContext-24] RANAP SecurityModeControl request from CSDomain
> Apr 10 17:58:59.511 [UEContext-24] HNB-GW> RANAP SecurityModeControl, CSDomain
> Apr 10 17:58:59.515 [3GAP-3] C3GAP::Send uRSL msg id 10
> Apr 10 17:58:59.760 [UEContext-24] URSL SecurityModeComp, CSDomain
> Apr 10 17:58:59.760 [UEContext-24] URSL SecurityModeComp, CSDomain, URSL ChosenIntAlgo 0
> Apr 10 17:58:59.794 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 20
> Apr 10 17:58:59.794 [UEContext-24] RANAP CommonId from CSDomain
> Apr 10 17:58:59.794 [UEContext-24] HNB-GW> RANAP CommonId, CSDomain
> Apr 10 17:58:59.795 [UEContext-24] RANAP CommonId provided IMSI 901700000015242
> Apr 10 17:59:00.083 [UEContext-24] URSL> UplinkDirectTransfer
> Apr 10 17:59:00.083 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 31
> Apr 10 17:59:00.090 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 19
> Apr 10 17:59:00.091 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
> Apr 10 17:59:00.095 [3GAP-3] C3GAP::Send uRSL msg id 7
> Apr 10 17:59:00.291 [RANAP ConnectionlessInd] RANAP Paging provided IMSI 901700000015240
> Apr 10 17:59:00.291 [RANAP] Paging 901700000015240
> Apr 10 17:59:00.295 [3GAP-3] C3GAP::Send uRSL msg id 20
> Apr 10 17:59:00.297 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 23
> Apr 10 17:59:00.298 [UEContext-24] HNB-GW> RANAP DirectTransfer CSDomain
> Apr 10 17:59:00.302 [3GAP-3] C3GAP::Send uRSL msg id 7
> Apr 10 17:59:00.803 [UEContext-24] URSL> UplinkDirectTransfer
> Apr 10 17:59:00.803 [UEContext-24] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 2
> Apr 10 17:59:00.809 [UEContext-24] RUA DirectTransferInd, domain 0, RANAP length 13
> Apr 10 17:59:00.809 [UEContext-24] RANAP IuReleaseCommand
> Apr 10 17:59:00.810 [UEContext-24] HNB-GW> RANAP IuRelease, CSDomain
> Apr 10 17:59:00.810 [UEContext-24] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
> Apr 10 17:59:00.810 [UEContext-24] Sending RUADisconnect to HNB-GW for CSDomain Context 0x18
> Apr 10 17:59:00.816 [3GAP-3] C3GAP::Send uRSL msg id 9




-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200414/aad02f85/attachment.bin>

From aaltokoskinen at gmail.com  Tue Apr 14 13:27:32 2020
From: aaltokoskinen at gmail.com (Aalto Koskinen)
Date: Tue, 14 Apr 2020 16:27:32 +0300
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <81b24fdc-7370-c023-5fa4-76e9dd8da602@sysmocom.de>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
 <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
 <81b24fdc-7370-c023-5fa4-76e9dd8da602@sysmocom.de>
Message-ID: <CAJx05u3D7YG8kxzwjVYPqeF9CYT=-UziiMBaXHoTQ_vTTn9btg@mail.gmail.com>

Hi Vadim and Pau,

Thank you for the quick replies.

*Pau:* Probably your guess is correct. I am looking into it in detail at
the moment the core network configurations.
*Vadim*: I started osmo-trx first and waited until the message "Transceiver
active with 1 channel(s)", before running osmo-bts-trx and other modules.
I will look into the wireshark capture to ensure that there are RSL and OML
packets. Yes. I am using the configuration examples from
*https://osmocom.org/attachments/3473/nitb.tar
<https://osmocom.org/attachments/3473/nitb.tar>.* I am not sure, how to
test osmo-bsc is actually running on 192.168.122.1 (I guess, I have to ping
to ensure). Meanwhile, is there a basic configuration where I can run the
system? Can I find it somewhere(I tried to run /usr/local/etc/osmocom
config files and it didn't work. Probably, I have to fine tune the
configurations)? And, is there a wireshark trace by any chance for
reference?

On Thu, 9 Apr 2020 at 15:39, Pau Espin Pedrol <pespin at sysmocom.de> wrote:

> Hi,
>
> I have the feeling the connection between osmo-trx and osmo-bts-trx is
> good. The problem is that your BTS<->BSC<->... is failing.
>
> BTs shows these messages at startup because osmo-trx is not yet running:
> """"
>  > osmo-bts-trx[23221]: <000b> trx_if.c:1174 phy0.0: Open transceiver
>  > osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory
>  > response from transceiver(CMD POWEROFF)
> """
>
> Then at some point osmo-trx answers:
> """
>  > ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24
> 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
> command is 'POWEROFF'
>  > ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24
> 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
> response is 'RSP POWEROFF 0'
> """
>
> But it's already too late, the BTS is already exiting due to some issue
> in Abis:
> """
>  > osmo-bts-trx[23221]: <000d> abis.c:142 Signalling link down
>  > osmo-bts-trx[23221]: <0001> bts.c:292 Shutting down BTS 0, Reason
> Abis close
> """
>
> Regards,
> Pau
>
> --
> - Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Director: Harald Welte
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200414/c4bfc0ef/attachment.htm>

From laforge at osmocom.org  Tue Apr 14 15:12:43 2020
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 14 Apr 2020 17:12:43 +0200
Subject: debug call failure on new nitb setup please?
In-Reply-To: <20200414122131.GA31595@my.box>
References: <20200410182115.GA52122@other>
 <20200414122131.GA31595@my.box>
Message-ID: <20200414151243.GS4127396@nataraja>

Hi Neels,

On Tue, Apr 14, 2020 at 02:21:31PM +0200, Neels Hofmeyr wrote:

> One thing that could still go wrong is the Paging. I have noted at occasions
> that a nano3G may fail to Page by IMSI, when the UE has only attached using a
> TMSI.

Maybe we aren't sending the CommonID with the mapping of TMSI<->IMSI in that case,
or somehow send it wrong?  I suppose it exists exactly for these situations, to tell
the RAN which IMSI the MS has, if it is not sent over the radio intreface.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From hosseinisr at outlook.de  Tue Apr 14 16:24:06 2020
From: hosseinisr at outlook.de (Reza Hosseini)
Date: Tue, 14 Apr 2020 16:24:06 +0000
Subject: Hello
Message-ID: <DM6PR11MB4299F597FB25524C506B6453B1DA0@DM6PR11MB4299.namprd11.prod.outlook.com>

Dear Developers,

I am trying to build the osmo-euse-demo on the Osmocom VM, executing the following commands:

#Install required development libraries:
sudo apt-get install libosmo-gsup-client-dev
#Get the source code and a missing header file
wget https://raw.githubusercontent.com/osmocom/osmo-hlr/master/src/osmo-euse-demo.c
wget https://raw.githubusercontent.com/osmocom/osmo-hlr/master/include/osmocom/hlr/logging.h
mkdir -p osmocom/hlr/
mv logging.h osmocom/hlr/
#Compile source
gcc -I. -o osmo-euse-demo osmo-euse-demo.c -losmocore -losmo-gsup-client -losmogsm -ltalloc
#Run
./osmo-euse-demo


But i am now facing this error :

E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

Can you please tell me what is the reasin behind this error !? And how can i solve it ?

Many thanks for your consideraion,

Reza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200414/6706ce29/attachment.htm>

From laforge at osmocom.org  Tue Apr 14 17:34:34 2020
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 14 Apr 2020 19:34:34 +0200
Subject: Hello
In-Reply-To: <DM6PR11MB4299F597FB25524C506B6453B1DA0@DM6PR11MB4299.namprd11.prod.outlook.com>
References: <DM6PR11MB4299F597FB25524C506B6453B1DA0@DM6PR11MB4299.namprd11.prod.outlook.com>
Message-ID: <20200414173434.GT4127396@nataraja>

Hi Reza,

On Tue, Apr 14, 2020 at 04:24:06PM +0000, Reza Hosseini wrote:
> E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
> E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?

This has nothing at all to do with Osmocom.  If you wan to develop/build software on Debian/Ubuntu
type operating systems, I suggest you become more familiar with the apt / dpkg package
management system.  It seems too processes are simultaneously trying to install/remove packages.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From craig at unreasonablefarm.org  Tue Apr 14 18:38:50 2020
From: craig at unreasonablefarm.org (Craig Comstock)
Date: Tue, 14 Apr 2020 13:38:50 -0500
Subject: debug call failure on new nitb setup please?
In-Reply-To: <20200414151243.GS4127396@nataraja>
References: <20200410182115.GA52122@other> <20200414122131.GA31595@my.box>
 <20200414151243.GS4127396@nataraja>
Message-ID: <00CD562B-6A0E-4732-80D7-3B0BA1885747@unreasonablefarm.org>

I should be able to test again and provide pcap and more logs tonight. Thanks for the ideas!

Craig

On April 14, 2020 10:12:43 AM CDT, Harald Welte <laforge at osmocom.org> wrote:
>Hi Neels,
>
>On Tue, Apr 14, 2020 at 02:21:31PM +0200, Neels Hofmeyr wrote:
>
>> One thing that could still go wrong is the Paging. I have noted at
>occasions
>> that a nano3G may fail to Page by IMSI, when the UE has only attached
>using a
>> TMSI.
>
>Maybe we aren't sending the CommonID with the mapping of TMSI<->IMSI in
>that case,
>or somehow send it wrong?  I suppose it exists exactly for these
>situations, to tell
>the RAN which IMSI the MS has, if it is not sent over the radio
>intreface.
>
>-- 
>- Harald Welte <laforge at osmocom.org>           
>http://laforge.gnumonks.org/
>============================================================================
>"Privacy in residential applications is a desirable marketing option."
>                                             (ETSI EN 300 175-7 Ch. A6)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200414/8789701c/attachment.htm>

From borgers at mi.fu-berlin.de  Wed Apr 15 07:18:04 2020
From: borgers at mi.fu-berlin.de (Philipp Borgers)
Date: Wed, 15 Apr 2020 09:18:04 +0200
Subject: open source mobile communications in the context of search and rescue
Message-ID: <20200415071804.GE6986@mi.fu-berlin.de>

Hi,

we are looking for some help creating open source mobile communication
infrastructure in the context of a search and rescue (SAR) mission at sea.

We would like to use the osmocom stack as sensing and communication
infrastructure at sea.

How precise is the timing advance for localization?

Neels mentioned that "modern" mobile stations equipped with a GPS receiver can
report the location to the operator. Could you point me to the right standard?

Is there any reliable and open source tooling to determine the direction of the
signal with multiple receivers (e.g. SDRs) in close proximity?

You can find out more about the project here:

https://www.hs-augsburg.de/searchwing/

Sorry for the mostly German content.

Thanks for your help!

Best Regards
Philipp Borgers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200415/861507e2/attachment.bin>

From laforge at osmocom.org  Wed Apr 15 09:00:16 2020
From: laforge at osmocom.org (Harald Welte)
Date: Wed, 15 Apr 2020 11:00:16 +0200
Subject: open source mobile communications in the context of search and
 rescue
In-Reply-To: <20200415071804.GE6986@mi.fu-berlin.de>
References: <20200415071804.GE6986@mi.fu-berlin.de>
Message-ID: <20200415090016.GY4127396@nataraja>

Hi Philipp,

On Wed, Apr 15, 2020 at 09:18:04AM +0200, Philipp Borgers wrote:
> How precise is the timing advance for localization?

As per GSM specs, it's one symbol duration, which is about 500m in terms of
distance.  OsmoBTS supports a higher-resolution reporting in the A-bis RSL
measurement reports (in units of 1/256 of symbol duration). However, the actual
achievable real-world precision is likely much less (maybe a quarter-bit), resulting
in 125m.

> Neels mentioned that "modern" mobile stations equipped with a GPS receiver can
> report the location to the operator. Could you point me to the right standard?

RRLP (Radio Resource Location Protocol). We did a proof of concept implementation
for this more than a decade ago, it was tested at HAR2009 at the time:
https://osmocom.org/projects/security/wiki/RRLP
https://git.osmocom.org/osmocom-lcs/

RRLP is part of the larger LCS (Location Services) architecture:
At https://osmocom.org/projects/osmobsc/wiki/Location_Services it is described how
they work in the specs.

The Osmocom implementation bypassed all of the standardized network-internal interfaces,
had no SMLC, Lb interface, ... - in the end, only the radio interface to the mobile phone is
what's relevant to get positioning.

The related code has not been maintained for 10 years or so, all of the rest of the
osmocom infrastructure has evolved a lot ever since - and it only was a proof-of-concept
to begin with.  So I would assume that considerable time would have to be spent
in testing / fixing / stabilizing / integration.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From schumi4664 at gmail.com  Fri Apr 10 11:35:08 2020
From: schumi4664 at gmail.com (michael schumi)
Date: Fri, 10 Apr 2020 14:35:08 +0300
Subject: pcsc_scan not reading
Message-ID: <CADb5XYNig3t1YPYn0HO1_erD7=c_ch_Dsh9qJ29Mre=6RTsaLA@mail.gmail.com>

i am trying to read the sim card using sim reader but not able to read
i used command pcsc_scan but its taking huge time for scanning and only
scanning
waiting for the first reader... like this please check whats the issue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200410/58ff373f/attachment.htm>

From guilly at gmail.com  Wed Apr 15 09:28:45 2020
From: guilly at gmail.com (=?UTF-8?Q?Sebasti=C3=A1n_Viviani?=)
Date: Wed, 15 Apr 2020 10:28:45 +0100
Subject: pysim contributions
Message-ID: <CAD4iyQ-uxy_h8OLhiX=DdTEDwNncB8Y7BnvD1xJ1bkg+1+K2Dw@mail.gmail.com>

Hello,
    apologies for the generic question, but how can I contribute to the
pysim project?
    I made a couple of fixes and added some stuff I needed for some tests,
but looks like github rejects the pull requests, project is not listed in
gerrit, there is no specific mail list, and the osmocom git repo rejects
any push :-(
        Kind regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200415/c09b56fd/attachment.htm>

From axilirator at gmail.com  Wed Apr 15 13:55:01 2020
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Wed, 15 Apr 2020 20:55:01 +0700
Subject: pysim contributions
In-Reply-To: <CAD4iyQ-uxy_h8OLhiX=DdTEDwNncB8Y7BnvD1xJ1bkg+1+K2Dw@mail.gmail.com>
References: <CAD4iyQ-uxy_h8OLhiX=DdTEDwNncB8Y7BnvD1xJ1bkg+1+K2Dw@mail.gmail.com>
Message-ID: <CAPEnp=YFfu9fD45irdEuNk7YUJiGDEuruWDswrc7_XS24O9YFw@mail.gmail.com>

Hello Sebasti?n,

> project is not listed in gerrit

pySIM is there: https://gerrit.osmocom.org/admin/repos/pysim ;)
Looking forward to see your contributions!

With best regards,
Vadim Yanitskiy.


From aaltokoskinen at gmail.com  Wed Apr 15 15:38:55 2020
From: aaltokoskinen at gmail.com (Aalto Koskinen)
Date: Wed, 15 Apr 2020 18:38:55 +0300
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <CAJx05u3D7YG8kxzwjVYPqeF9CYT=-UziiMBaXHoTQ_vTTn9btg@mail.gmail.com>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
 <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
 <81b24fdc-7370-c023-5fa4-76e9dd8da602@sysmocom.de>
 <CAJx05u3D7YG8kxzwjVYPqeF9CYT=-UziiMBaXHoTQ_vTTn9btg@mail.gmail.com>
Message-ID: <CAJx05u3MxX4V0v8=6zR_2n6nT+RR9mKfEBKfgJoXYTs9SiWvaw@mail.gmail.com>

Hi,

I figured out that the issue is in connectivity between BSC and BTS. I am
able to fix half of the issue. I would appreciate any further guidance.

*Firstly, I ran only BTS module*. In the BTS log, I see an OML connection
established. Transcribed are the logs.

<0017> control_if.c:911 CTRL at 127.0.0.1 4238
<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
<0012> input/ipaccess.c:1024 enabling ipaccess BTS mode, OML connecting to
127.0.0.1:3002
<000b> trx_if.c:1174 phy0.0: Open transceiver

*<0012> input/ipa.c:128 127.0.0.1:3002 <http://127.0.0.1:3002> connection
done*<0012> input/ipaccess.c:846 received ID_GET for unit ID 1800/0/0
<000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD
POWEROFF)

It again fails to get any response.

*Next, I ran the combination of TRX-UHD module and BTS module. *I failed to
get even OML connection.

<0017> control_if.c:911 CTRL at 127.0.0.1 4238
<0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
<0012> input/ipaccess.c:1024 enabling ipaccess BTS mode, OML connecting to
127.0.0.1:3002
<000b> trx_if.c:1174 phy0.0: Open transceiver
<000d> abis.c:142 Signalling link down
<0001> bts.c:292 Shutting down BTS 0, Reason Abis close
Shutdown timer expired

I could see only this in trace.

[image: a.png]

Thanks for the help.

On Tue, 14 Apr 2020 at 16:27, Aalto Koskinen <aaltokoskinen at gmail.com>
wrote:

> Hi Vadim and Pau,
>
> Thank you for the quick replies.
>
> *Pau:* Probably your guess is correct. I am looking into it in detail at
> the moment the core network configurations.
> *Vadim*: I started osmo-trx first and waited until the message
> "Transceiver active with 1 channel(s)", before running osmo-bts-trx and
> other modules.
> I will look into the wireshark capture to ensure that there are RSL and
> OML packets. Yes. I am using the configuration examples from *https://osmocom.org/attachments/3473/nitb.tar
> <https://osmocom.org/attachments/3473/nitb.tar>.* I am not sure, how to
> test osmo-bsc is actually running on 192.168.122.1 (I guess, I have to ping
> to ensure). Meanwhile, is there a basic configuration where I can run the
> system? Can I find it somewhere(I tried to run /usr/local/etc/osmocom
> config files and it didn't work. Probably, I have to fine tune the
> configurations)? And, is there a wireshark trace by any chance for
> reference?
>
> On Thu, 9 Apr 2020 at 15:39, Pau Espin Pedrol <pespin at sysmocom.de> wrote:
>
>> Hi,
>>
>> I have the feeling the connection between osmo-trx and osmo-bts-trx is
>> good. The problem is that your BTS<->BSC<->... is failing.
>>
>> BTs shows these messages at startup because osmo-trx is not yet running:
>> """"
>>  > osmo-bts-trx[23221]: <000b> trx_if.c:1174 phy0.0: Open transceiver
>>  > osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory
>>  > response from transceiver(CMD POWEROFF)
>> """
>>
>> Then at some point osmo-trx answers:
>> """
>>  > ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24
>> 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
>> command is 'POWEROFF'
>>  > ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24
>> 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
>> response is 'RSP POWEROFF 0'
>> """
>>
>> But it's already too late, the BTS is already exiting due to some issue
>> in Abis:
>> """
>>  > osmo-bts-trx[23221]: <000d> abis.c:142 Signalling link down
>>  > osmo-bts-trx[23221]: <0001> bts.c:292 Shutting down BTS 0, Reason
>> Abis close
>> """
>>
>> Regards,
>> Pau
>>
>> --
>> - Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
>> =======================================================================
>> * sysmocom - systems for mobile communications GmbH
>> * Alt-Moabit 93
>> * 10559 Berlin, Germany
>> * Sitz / Registered office: Berlin, HRB 134158 B
>> * Geschaeftsfuehrer / Managing Director: Harald Welte
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200415/4bc714b3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.png
Type: image/png
Size: 25222 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200415/4bc714b3/attachment.png>

From domi at tomcsanyi.net  Wed Apr 15 20:38:12 2020
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Wed, 15 Apr 2020 22:38:12 +0200 (CEST)
Subject: pcsc_scan not reading
In-Reply-To: <CADb5XYNig3t1YPYn0HO1_erD7=c_ch_Dsh9qJ29Mre=6RTsaLA@mail.gmail.com>
References: <CADb5XYNig3t1YPYn0HO1_erD7=c_ch_Dsh9qJ29Mre=6RTsaLA@mail.gmail.com>
Message-ID: <556E306D-6CD4-4B0A-80F8-37B000C5F50C@tomcsanyi.net>

Hi Michael,

Your reader is not recognized.
Check on the website of pcscd if it is supported or not.
Maybe you need a newer version of pcscd to detect the reader correctly.

Cheers,
Domi


> 2020. ?pr. 15. d?tummal, 15:43 id?pontban michael schumi <schumi4664 at gmail.com> ?rta:
> 
> ?
> i am trying to read the sim card using sim reader but not able to read 
> i used command pcsc_scan but its taking huge time for scanning and only scanning
> waiting for the first reader... like this please check whats the issue

From hosseinisr at outlook.de  Thu Apr 16 14:42:15 2020
From: hosseinisr at outlook.de (Reza Hosseini)
Date: Thu, 16 Apr 2020 14:42:15 +0000
Subject: GSUP client
Message-ID: <DM6PR11MB4299A9DF24FDF5DD2742AFE5B1D80@DM6PR11MB4299.namprd11.prod.outlook.com>

Hello Mr. Welte,

I am writing to ask you please, if it is possible to provide me with documents on the GSUP Client program. I have to implement my own application and send the required GSUP messages to the HLR to get subscriber data from hlr in Osmocom.

Many thanks for your considerations.

Reza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200416/9c135512/attachment.htm>

From laforge at osmocom.org  Thu Apr 16 17:15:39 2020
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 16 Apr 2020 19:15:39 +0200
Subject: GSUP client
In-Reply-To: <DM6PR11MB4299A9DF24FDF5DD2742AFE5B1D80@DM6PR11MB4299.namprd11.prod.outlook.com>
References: <DM6PR11MB4299A9DF24FDF5DD2742AFE5B1D80@DM6PR11MB4299.namprd11.prod.outlook.com>
Message-ID: <20200416171539.GE4127396@nataraja>

Hi Reza,

On Thu, Apr 16, 2020 at 02:42:15PM +0000, Reza Hosseini wrote:
> I am writing to ask you please, if it is possible to provide me with documents on the GSUP Client program. 

Which particular program are you referring to?  libosmo-gsupclient and osmo-gsup-client?
They are fully open source, you can study it as much as you want.  You can use the library
from any other GPL/AGPL licensed program that you want to write yourself.

> I have to implement my own application and send the required GSUP messages to the HLR to get subscriber data from hlr in Osmocom.

If that application is GPL/AGPL licensed open source software, you can use libosmo-gsup-client.

If not, you would have to implement the GSUP protocol directly.  The protocol
is documented in the OsmoHLR user manual.

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From hosseinisr at outlook.de  Fri Apr 17 11:12:41 2020
From: hosseinisr at outlook.de (Reza Hosseini)
Date: Fri, 17 Apr 2020 11:12:41 +0000
Subject: GSUP client 
Message-ID: <DM6PR11MB42993ADA58EE51D026CA3347B1D90@DM6PR11MB4299.namprd11.prod.outlook.com>

Dear Mr. Welte,

In order to be more familiar with the further development of the osmo-euse file, I need to know which libraries and which programming style I should use to be on the right track.

Is it possible to provide me please the some lines of your code  which is sending the USSD code via the GSUP client to hlr and called up data from OSMO-HLR?

I need this for my master's thesis (Education Purpose), so I don't need a license for it.

Many thanks for your consideration,

Reza


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200417/69aae45f/attachment.htm>

From mirpax2000 at yahoo.fr  Mon Apr 20 16:02:21 2020
From: mirpax2000 at yahoo.fr (Laurent Kza)
Date: Mon, 20 Apr 2020 18:02:21 +0200
Subject: Asterisk - Osmosom connection issue
References: <9D24FC55-7374-44AA-AD22-EF3D279C43C4.ref@yahoo.fr>
Message-ID: <9D24FC55-7374-44AA-AD22-EF3D279C43C4@yahoo.fr>

Hi all,

I am new to the use of the Osmocom project, it is indeed a very nice job.

I am currently trying to set up a configuration with a Asterisk PBX server and I have 2 questions:

1/ RTP configuration
The SIP part (sip-connector vs Asterisk connection) works well so far, the communication starts but with no audio.
I noticed that the RTP flux is sent to localhost instead of my server address (set as remote in sip-connector.cfg) and I was wondering if there is any possibility to send the RTP flow to an address which is not localhost ?

sip
 local 0.0.0.0 5069
 remote 127.0.0.1 5060


2/ codec issue
In a configuration where all the Osmocom servers (MSC, MGW, BSC?) and Asterisk are on the same machine, it got a message from my asterisk server, saying that no codec can be found to start a communication. By default, the wiki/manuals states that gsm has to be used but perhaps I am missing something in the BSC configuration, especially in the codec choice.

<--- SIP read from UDP:10.184.10.162:5069 --->
INVITE sip:899 at 127.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.184.10.162:5069;rport;branch=z9hG4bKpe1UXZU1amUja
Max-Forwards: 70
From: <sip:422 at 0.0.0.0:5069>;tag=vyQKX32r72ZyQ
To: <sip:899 at 127.0.0.1:5060>
Call-ID: cd65c5a0-fdbf-1238-51a9-000c29cfd753
CSeq: 949096397 INVITE
Contact: <sip:10.184.10.162:5069>
User-Agent: sofia-sip/1.12.11devel
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Length: 133

v=0
o=Osmocom 0 0 IN IP4 127.0.0.1
s=GSM Call
c=IN IP4 127.0.0.1
t=0 0
m=audio 4016 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=sendrecv
<------------->
--- (13 headers 8 lines) ---
Sending to 10.184.10.162:5069 (no NAT)
Sending to 10.184.10.162:5069 (no NAT)
Using INVITE request as basis request - cd65c5a0-fdbf-1238-51a9-000c29cfd753
No matching peer for '422' from '10.184.10.162:5069'
  == Using SIP RTP CoS mark 5
Got SDP version 0 and unique parts [Osmocom 0 IN IP4 127.0.0.1]
Found RTP audio format 3
Found audio description format GSM for ID 3
[2020-04-20 17:38:19] NOTICE[14918][C-00000015]: chan_sip.c:10957 process_sdp: No compatible codecs, not accepting this offer!



Thanks for your help
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200420/db5048c4/attachment.htm>

From keith at rhizomatica.org  Tue Apr 21 04:00:54 2020
From: keith at rhizomatica.org (Keith)
Date: Mon, 20 Apr 2020 23:00:54 -0500
Subject: Asterisk - Osmosom connection issue
In-Reply-To: <9D24FC55-7374-44AA-AD22-EF3D279C43C4@yahoo.fr>
References: <9D24FC55-7374-44AA-AD22-EF3D279C43C4.ref@yahoo.fr>
 <9D24FC55-7374-44AA-AD22-EF3D279C43C4@yahoo.fr>
Message-ID: <9093c39f-bde0-c5de-ff87-45379b3b8ee9@rhizomatica.org>


On 20/04/2020 11:02, Laurent Kza wrote:

> Hi all,

Hi Laurent, it's really a very very long time since I have used
Asterisk, but I can possibly help you to work through this.



> 1/ RTP configuration

Just to be clear, you are using the full stack, osmo-bsc/msc/mgw ? or
the osmo-nitb?

What is your BTS?

> I was wondering if there is any possibility to send the RTP flow to an
address which is not localhost ?

It is signaled in the SDP, if you are originating the call from
asterisk, then it's an asterisk parameter somewhere. If it's a mobile to
mobile call, the B-leg is still "originating" from Asterisk.

When you say "localhost instead of your server address", can you
clarify, how many "servers" (be they VMs or whatever) are involved here?
Just the one?

Maybe you mean your public (or private) address on a network card? To my
mind, "localhost" is a "server address" certainly in the case of an
osmo-mgw <--> asterisk stream on the same box, then it would be.


> Found audio description format GSM for ID 3
> [2020-04-20 17:38:19] NOTICE[14918][C-00000015]: chan_sip.c:10957
process_sdp: No compatible codecs, not accepting this offer!
>

This looks to me like Asterisk is pretty clearly saying it does not
support the GSM codec, or does not have this enabled in configuration
somewhere.

BTW, rather than looking at SIP log on the console, I highly recommend
you use sngrep, it gives you a visual representation of SIP messages and
media flows that makes every some much more clear!

K.






From aaltokoskinen at gmail.com  Tue Apr 21 19:35:56 2020
From: aaltokoskinen at gmail.com (Aalto Koskinen)
Date: Tue, 21 Apr 2020 22:35:56 +0300
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <CAJx05u3MxX4V0v8=6zR_2n6nT+RR9mKfEBKfgJoXYTs9SiWvaw@mail.gmail.com>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
 <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
 <81b24fdc-7370-c023-5fa4-76e9dd8da602@sysmocom.de>
 <CAJx05u3D7YG8kxzwjVYPqeF9CYT=-UziiMBaXHoTQ_vTTn9btg@mail.gmail.com>
 <CAJx05u3MxX4V0v8=6zR_2n6nT+RR9mKfEBKfgJoXYTs9SiWvaw@mail.gmail.com>
Message-ID: <CAJx05u3Qcp0Sha9g08GJTdEGuxdLG8RxpABXSSEi4LdDa1n2Xw@mail.gmail.com>

Hi,

Sorry to bother you all again. I am stuck with this since a week trying to
figure out, but failing so. I am able to see OML in wireshark
traces(attached as a picture), but still not able to see RSL protocol.
I need to be able to connect bts-trx and bsc modules to get a working
connection. Any suggestions would be appreciated.

Thanks for the help.

On Wed, 15 Apr 2020 at 18:38, Aalto Koskinen <aaltokoskinen at gmail.com>
wrote:

> Hi,
>
> I figured out that the issue is in connectivity between BSC and BTS. I am
> able to fix half of the issue. I would appreciate any further guidance.
>
> *Firstly, I ran only BTS module*. In the BTS log, I see an OML connection
> established. Transcribed are the logs.
>
> <0017> control_if.c:911 CTRL at 127.0.0.1 4238
> <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
> <0012> input/ipaccess.c:1024 enabling ipaccess BTS mode, OML connecting to
> 127.0.0.1:3002
> <000b> trx_if.c:1174 phy0.0: Open transceiver
>
> *<0012> input/ipa.c:128 127.0.0.1:3002 <http://127.0.0.1:3002> connection
> done*<0012> input/ipaccess.c:846 received ID_GET for unit ID 1800/0/0
> <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD
> POWEROFF)
>
> It again fails to get any response.
>
> *Next, I ran the combination of TRX-UHD module and BTS module. *I failed
> to get even OML connection.
>
> <0017> control_if.c:911 CTRL at 127.0.0.1 4238
> <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241
> <0012> input/ipaccess.c:1024 enabling ipaccess BTS mode, OML connecting to
> 127.0.0.1:3002
> <000b> trx_if.c:1174 phy0.0: Open transceiver
> <000d> abis.c:142 Signalling link down
> <0001> bts.c:292 Shutting down BTS 0, Reason Abis close
> Shutdown timer expired
>
> I could see only this in trace.
>
> [image: a.png]
>
> Thanks for the help.
>
> On Tue, 14 Apr 2020 at 16:27, Aalto Koskinen <aaltokoskinen at gmail.com>
> wrote:
>
>> Hi Vadim and Pau,
>>
>> Thank you for the quick replies.
>>
>> *Pau:* Probably your guess is correct. I am looking into it in detail at
>> the moment the core network configurations.
>> *Vadim*: I started osmo-trx first and waited until the message
>> "Transceiver active with 1 channel(s)", before running osmo-bts-trx and
>> other modules.
>> I will look into the wireshark capture to ensure that there are RSL and
>> OML packets. Yes. I am using the configuration examples from *https://osmocom.org/attachments/3473/nitb.tar
>> <https://osmocom.org/attachments/3473/nitb.tar>.* I am not sure, how to
>> test osmo-bsc is actually running on 192.168.122.1 (I guess, I have to ping
>> to ensure). Meanwhile, is there a basic configuration where I can run the
>> system? Can I find it somewhere(I tried to run /usr/local/etc/osmocom
>> config files and it didn't work. Probably, I have to fine tune the
>> configurations)? And, is there a wireshark trace by any chance for
>> reference?
>>
>> On Thu, 9 Apr 2020 at 15:39, Pau Espin Pedrol <pespin at sysmocom.de> wrote:
>>
>>> Hi,
>>>
>>> I have the feeling the connection between osmo-trx and osmo-bts-trx is
>>> good. The problem is that your BTS<->BSC<->... is failing.
>>>
>>> BTs shows these messages at startup because osmo-trx is not yet running:
>>> """"
>>>  > osmo-bts-trx[23221]: <000b> trx_if.c:1174 phy0.0: Open transceiver
>>>  > osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory
>>>  > response from transceiver(CMD POWEROFF)
>>> """
>>>
>>> Then at some point osmo-trx answers:
>>> """
>>>  > ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24
>>> 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0]
>>> command is 'POWEROFF'
>>>  > ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr  9 11:22:24
>>> 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0]
>>> response is 'RSP POWEROFF 0'
>>> """
>>>
>>> But it's already too late, the BTS is already exiting due to some issue
>>> in Abis:
>>> """
>>>  > osmo-bts-trx[23221]: <000d> abis.c:142 Signalling link down
>>>  > osmo-bts-trx[23221]: <0001> bts.c:292 Shutting down BTS 0, Reason
>>> Abis close
>>> """
>>>
>>> Regards,
>>> Pau
>>>
>>> --
>>> - Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
>>> =======================================================================
>>> * sysmocom - systems for mobile communications GmbH
>>> * Alt-Moabit 93
>>> * 10559 Berlin, Germany
>>> * Sitz / Registered office: Berlin, HRB 134158 B
>>> * Geschaeftsfuehrer / Managing Director: Harald Welte
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200421/c8689b06/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.png
Type: image/png
Size: 25222 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200421/c8689b06/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oml.png
Type: image/png
Size: 100817 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200421/c8689b06/attachment-0001.png>

From pespin at sysmocom.de  Wed Apr 22 09:14:50 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 22 Apr 2020 11:14:50 +0200
Subject: OSMOCOM TRX_BTS_BSC Connection Issue
In-Reply-To: <CAJx05u3Qcp0Sha9g08GJTdEGuxdLG8RxpABXSSEi4LdDa1n2Xw@mail.gmail.com>
References: <CAJx05u2LR3arRYZtJd7NzgMmHu2hDQGziEDEMot--qe_RFQJ4A@mail.gmail.com>
 <CAJx05u2T473F9S1-c1ZHeRPB1ReCRG=ueZvCOfGrQysRKahJfA@mail.gmail.com>
 <CAPEnp=a=WHnjpAoawT_cxWkpS1AegO9XaUSptusr=9gKX8_=kA@mail.gmail.com>
 <81b24fdc-7370-c023-5fa4-76e9dd8da602@sysmocom.de>
 <CAJx05u3D7YG8kxzwjVYPqeF9CYT=-UziiMBaXHoTQ_vTTn9btg@mail.gmail.com>
 <CAJx05u3MxX4V0v8=6zR_2n6nT+RR9mKfEBKfgJoXYTs9SiWvaw@mail.gmail.com>
 <CAJx05u3Qcp0Sha9g08GJTdEGuxdLG8RxpABXSSEi4LdDa1n2Xw@mail.gmail.com>
Message-ID: <9fd79cad-5b48-dce7-c354-53fa48f9126d@sysmocom.de>

Hi,

your png image clearly shows that you have some problem with AoIP side
(SCTP connections failing). Are you running osmo-stp and osmo-msc?

It's useless trying to help you better if you don't provide at least
config files and a pcap with all the generated traffic while start and
running your network.

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From nhofmeyr at sysmocom.de  Fri Apr 24 12:55:59 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 24 Apr 2020 14:55:59 +0200
Subject: GSUP client
In-Reply-To: <DM6PR11MB42993ADA58EE51D026CA3347B1D90@DM6PR11MB4299.namprd11.prod.outlook.com>
References: <DM6PR11MB42993ADA58EE51D026CA3347B1D90@DM6PR11MB4299.namprd11.prod.outlook.com>
Message-ID: <20200424125559.GB20136@my.box>

On Fri, Apr 17, 2020 at 11:12:41AM +0000, Reza Hosseini wrote:
> Dear Mr. Welte,
> 
> In order to be more familiar with the further development of the osmo-euse file, I need to know which libraries and which programming style I should use to be on the right track.
> 
> Is it possible to provide me please the some lines of your code  which is sending the USSD code via the GSUP client to hlr and called up data from OSMO-HLR?
>
> I need this for my master's thesis (Education Purpose), so I don't need a license for it.

It may seem complex and confusing at first, but all the code is available, and
open for use, you just need to find your way through it :)

So far we are handling USSD in osmo-hlr itself, see for example
osmo-hlr/src/hlr_ussd.c: handle_ussd_own_imsi() and handle_ussd_own_msisdn().
Grep for those to find out how they integrate.

Handling USSD outside of the HLR is a relatively new concept which has not seen
actual productive use yet, so there may be rough edges. The euse-demo you
mentioned earlier should be such an example.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200424/8bc5d2f0/attachment.bin>

From andrew at carrierdetect.com  Sat Apr 25 10:28:52 2020
From: andrew at carrierdetect.com (Andrew Back)
Date: Sat, 25 Apr 2020 11:28:52 +0100
Subject: Docker containers.
Message-ID: <455a5c3c-cd8b-09ff-6975-f1af06c4a7cf@carrierdetect.com>

Appreciate that the Osmocom Docker configurations exist principally for
automated testing and here it may not make sense, but I wondered if
builds are published to a registry?

The Makefile in the make project located in the docker-playground repo
sets docker.io as registry and has a target for docker push. Also see
OBS Release.key files in project sub-directories, but couldn't find
container builds being published anywhere.

Was hoping I could just pull containers for the latest project versions,
without cloning and building the containers in docker-playground.

Also saw the comments from 2017 on Docker shortcomings and assuming SCTP
works OK now in Docker networking?

Regards,

Andrew


From laforge at osmocom.org  Sat Apr 25 14:30:44 2020
From: laforge at osmocom.org (Harald Welte)
Date: Sat, 25 Apr 2020 16:30:44 +0200
Subject: Docker containers.
In-Reply-To: <455a5c3c-cd8b-09ff-6975-f1af06c4a7cf@carrierdetect.com>
References: <455a5c3c-cd8b-09ff-6975-f1af06c4a7cf@carrierdetect.com>
Message-ID: <20200425143044.GK690476@nataraja>

Hi Andrew,

On Sat, Apr 25, 2020 at 11:28:52AM +0100, Andrew Back wrote:
> Appreciate that the Osmocom Docker configurations exist principally for
> automated testing and here it may not make sense, but I wondered if
> builds are published to a registry?

no, they are intentionally not.  As long as the container community does
not provide proper tools helping to generate license compliant binary
builds, I don't think we want to (or anyone should!) publicly release
binary container images/layers.

Docker and other related entities have been ignoring this for years,
despite lots of voices raising this topic.  See for example
https://lwn.net/Articles/752982/

How, for example, would you comply with copyleft style licenses such as
LGPL/GPL/AGPL to automatize the process of providing the "complete
corresponding source code" to all the binaries that go into a Docker
image?  Particularly if you are using upstream images that other people
have built who don't provide you with this information?

You would basically have to recursively collect all the debian source
packages of both your layer, as well as all the layers you inherited
from.  I'm not aware of any tooling that one could use to automatize
that process.

> The Makefile in the make project located in the docker-playground repo
> sets docker.io as registry and has a target for docker push. Also see
> OBS Release.key files in project sub-directories, but couldn't find
> container builds being published anywhere.

In my opinion, the only way to safely distribute container images is to
not distribute them, but only distribute the Dockerfile and have users
build the images from there.

So we do have our own internal docker registry that is used within the
Osmocom CI and testing, exactly to prevent any potentially license
incompliant public distribution.

> Also saw the comments from 2017 on Docker shortcomings and assuming SCTP
> works OK now in Docker networking?

I don't know what is the status.  In general, I consider the standard
way how docker deals with networking completely broken.  The incredible
ignorance of assuming the internet only has TCP and UDP is a 1980ies
assumption.  Doing NAT everywhere and programmatically inserting
iptables rules from the docker daemon is also not quite elegant.

For any kind of Docker use for cellular network infrastructure the only
option is to use docker networks (i.e. virtual ethernet segments) and
have static per-container IP addresses.  So you don't ever use any of
the EXPOSE / NAT / ... stuff.

Beware that Docker also doesn't fully support this scenario for any
reasonable production deployment, as you cannot have a container being
part of multiple docker networks while having reliable network device
names.  Allegedly the eth0..N are now assigned in "alphabetically
increasing order of the docker-network name", which is also way too
fragile for my point of view.

So in the end, my observation still remains: One cannot use Docker in
cellular network infrastructure, at least not in 2G, 3G or 4G, where
everything relies on static IP addreses and SCTP.

It's enough for test autmation, but certainly not for production use.

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at osmocom.org  Sat Apr 25 14:36:04 2020
From: laforge at osmocom.org (Harald Welte)
Date: Sat, 25 Apr 2020 16:36:04 +0200
Subject: Docker containers.
In-Reply-To: <20200425143044.GK690476@nataraja>
References: <455a5c3c-cd8b-09ff-6975-f1af06c4a7cf@carrierdetect.com>
 <20200425143044.GK690476@nataraja>
Message-ID: <20200425143604.GL690476@nataraja>

Small Follow-up, before it gets too off-topic:

On Sat, Apr 25, 2020 at 04:30:44PM +0200, Harald Welte wrote:
> Docker and other related entities have been ignoring this for years,
> despite lots of voices raising this topic.  See for example
> https://lwn.net/Articles/752982/

Just yesterday there also is the following publication of the Linux Foundation
on this topic:
https://www.linuxfoundation.org/blog/2020/04/docker-containers-what-are-the-open-source-licensing-considerations/

Quote:

> How do we collect and publish the required source code?
> [...]
> This is currently an unsolved problem.

Seeing this seven years after the initial release of Docker clearly sends
one message: They don't give a s**t about enabling their users to be able to
follow open source license compliance.

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From andrew at carrierdetect.com  Sat Apr 25 15:48:13 2020
From: andrew at carrierdetect.com (Andrew Back)
Date: Sat, 25 Apr 2020 16:48:13 +0100
Subject: Docker containers.
In-Reply-To: <20200425143044.GK690476@nataraja>
References: <455a5c3c-cd8b-09ff-6975-f1af06c4a7cf@carrierdetect.com>
 <20200425143044.GK690476@nataraja>
Message-ID: <6a151ebc-fb0f-5511-f754-ad7d336fb41c@carrierdetect.com>

Hi Harald,

On 25/04/2020 15:30, Harald Welte wrote:
> Hi Andrew,
> 
> On Sat, Apr 25, 2020 at 11:28:52AM +0100, Andrew Back wrote:
>> Appreciate that the Osmocom Docker configurations exist principally for
>> automated testing and here it may not make sense, but I wondered if
>> builds are published to a registry?
> 
> no, they are intentionally not.  As long as the container community does
> not provide proper tools helping to generate license compliant binary
> builds, I don't think we want to (or anyone should!) publicly release
> binary container images/layers.

Not even if manual efforts are made to provide such information in, for
example, a README file that is then published via the registry? I get
that pointing at parent images/layers and additional packages and
sources pulled-in via the Dockerfile, is not ideal.

> Docker and other related entities have been ignoring this for years,
> despite lots of voices raising this topic.  See for example
> https://lwn.net/Articles/752982/

Right, so I think I recall some of these discussions the first time
around and had assumed the issue had been addressed in some way.

> How, for example, would you comply with copyleft style licenses such as
> LGPL/GPL/AGPL to automatize the process of providing the "complete
> corresponding source code" to all the binaries that go into a Docker
> image?  Particularly if you are using upstream images that other people
> have built who don't provide you with this information?

With many layers and inheritance I can see how this could be problematic
without tooling that provides comprehensive coverage, but saying e.g.
Debian based image + src1 + src2 .. etc. would not be sufficient?

Debian publish official images to Docker Hub, so perhaps I would benefit
from taking a look at their approach to this also.

> You would basically have to recursively collect all the debian source
> packages of both your layer, as well as all the layers you inherited
> from.  I'm not aware of any tooling that one could use to automatize
> that process.
> 
>> The Makefile in the make project located in the docker-playground repo
>> sets docker.io as registry and has a target for docker push. Also see
>> OBS Release.key files in project sub-directories, but couldn't find
>> container builds being published anywhere.
> 
> In my opinion, the only way to safely distribute container images is to
> not distribute them, but only distribute the Dockerfile and have users
> build the images from there.
> 
> So we do have our own internal docker registry that is used within the
> Osmocom CI and testing, exactly to prevent any potentially license
> incompliant public distribution.
> 
>> Also saw the comments from 2017 on Docker shortcomings and assuming SCTP
>> works OK now in Docker networking?
> 
> I don't know what is the status.  In general, I consider the standard
> way how docker deals with networking completely broken.  The incredible
> ignorance of assuming the internet only has TCP and UDP is a 1980ies
> assumption.  Doing NAT everywhere and programmatically inserting
> iptables rules from the docker daemon is also not quite elegant.

The documentation suggests overlay networks support SCTP now:

https://docs.docker.com/network/overlay/#operations-for-standalone-containers-on-overlay-networks

Not sure about bridge networks.

I can see how extensive use of NAT may be problematic.

> For any kind of Docker use for cellular network infrastructure the only
> option is to use docker networks (i.e. virtual ethernet segments) and
> have static per-container IP addresses.  So you don't ever use any of
> the EXPOSE / NAT / ... stuff.
> 
> Beware that Docker also doesn't fully support this scenario for any
> reasonable production deployment, as you cannot have a container being
> part of multiple docker networks while having reliable network device
> names.  Allegedly the eth0..N are now assigned in "alphabetically
> increasing order of the docker-network name", which is also way too
> fragile for my point of view.
> 
> So in the end, my observation still remains: One cannot use Docker in
> cellular network infrastructure, at least not in 2G, 3G or 4G, where
> everything relies on static IP addreses and SCTP.

Various vendors seem to be using Docker in NFV/SDN architectures and it
would be nice to think there will be a way forward, which does not mean
that we end up with a dichotomy, whereby other infrastructure is part of
that world and Osmocom excluded. Be it through compliance tooling and
best practices, plus Docker improvements ? or whatever it takes.

> It's enough for test autmation, but certainly not for production use.
Thanks for the detailed reply, it's appreciated.

Regards,

Andrew


From laforge at osmocom.org  Sat Apr 25 17:32:33 2020
From: laforge at osmocom.org (Harald Welte)
Date: Sat, 25 Apr 2020 19:32:33 +0200
Subject: Docker containers.
In-Reply-To: <6a151ebc-fb0f-5511-f754-ad7d336fb41c@carrierdetect.com>
References: <455a5c3c-cd8b-09ff-6975-f1af06c4a7cf@carrierdetect.com>
 <20200425143044.GK690476@nataraja>
 <6a151ebc-fb0f-5511-f754-ad7d336fb41c@carrierdetect.com>
Message-ID: <20200425173233.GM690476@nataraja>

Hi Andrew,

On Sat, Apr 25, 2020 at 04:48:13PM +0100, Andrew Back wrote:
> The documentation suggests overlay networks support SCTP now:
> Not sure about bridge networks.

Well, as soon as you have an actual Layer3 or Layer2 network, for sure
you can use SCTP.

> Various vendors seem to be using Docker in NFV/SDN architectures 

I am convinced that either they must be building their own "network
drivers/plugins" to docker, or they can not implement 2G/3G 3GPP
interfaces as we know them.  This is not an Osmocom specific topic.

> would be nice to think there will be a way forward, which does not mean
> that we end up with a dichotomy, whereby other infrastructure is part of
> that world and Osmocom excluded. Be it through compliance tooling and
> best practices, plus Docker improvements ? or whatever it takes.

Honestly, I seriously don't think that Docker is the right tool.  It is
actively hostile towards anyone doing anything serious in terms of
networking.  It is already an enormous nightmare to model the most
trivial of networking topologies.  It is centered around dns and dynamic
IP addresses, while classic 2G/3G is based around static IP addresses
everywhere.  You cannot have SS7/SIGTRAN on a container that gets a
dynamic IP address via DHCP.

I could imagine that other container runtimes with a less monolithic and
more modular approach might be more amenable to the requirements of 3GPP
networks, but I lack any hands-on experience with that.  Docker is just
trying to solve too many things at the same time, without giving users
the kind of tools/access to the underlying infrastructure.  Just take
the example about no way to get persistent network device naming:
	https://github.com/moby/moby/issues/25181
	https://github.com/docker/compose/issues/4645

Similarly, there is no functionality in Docker how you can move a
physical network device into a specific container.  Peaple have built
kludges/workarounds for that (https://github.com/jpetazzo/pipework)
but that's not Docker itself.

There are so many things people have been able to do for decades with
the Linux network stack on bare metal, and which they still can do with
Linux e.g. in lxc containers that I assume no Docker developer has even
imagined possible.  It's like you used to have a full mechanical
workshop available, an Docker then arbitrarily limits this to a set of
three philips screw drivers because that's what most people need ;)

Just because some people in the industry have heard some buzzwords and
think that Docker is the right tool to virtualize 3GPP network elements
doesn't mean that we have to agree :)

Sorry, I've already wasted way too many days of my life trying to work
around random arbitrary constraints of docker networking :/

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at osmocom.org  Sat Apr 25 17:48:42 2020
From: laforge at osmocom.org (Harald Welte)
Date: Sat, 25 Apr 2020 19:48:42 +0200
Subject: Docker containers.
In-Reply-To: <6a151ebc-fb0f-5511-f754-ad7d336fb41c@carrierdetect.com>
References: <455a5c3c-cd8b-09ff-6975-f1af06c4a7cf@carrierdetect.com>
 <20200425143044.GK690476@nataraja>
 <6a151ebc-fb0f-5511-f754-ad7d336fb41c@carrierdetect.com>
Message-ID: <20200425174842.GO690476@nataraja>

On Sat, Apr 25, 2020 at 04:48:13PM +0100, Andrew Back wrote:

> With many layers and inheritance I can see how this could be problematic
> without tooling that provides comprehensive coverage, but saying e.g.
> Debian based image + src1 + src2 .. etc. would not be sufficient?

Do you have a tool to provide the "complete corresponding source code" to a given
"Debian bsaed image"?  Specifically, a tool that is capable of producing
this source code for every of your container image builds that you may have
created during the past 3 years (you may not even have that binary image around anymore)?

Because that's what license compliance takes, as those three years after last
distribution is the period during which you must provide the complete and corresponding
sources.

So until there is easy tooling to automatize this, I don't think there is
a way to safely provide container images.

> Debian publish official images to Docker Hub, so perhaps I would benefit
> from taking a look at their approach to this also.

It would be interesting, indeed.

However, even if Debian provided the CCS (complete+corrsponding source)
to every of their image/layer builds, passing along that written offer
of a third party (such as Debian) to provide the source is nothing we
can do, at least not from servers operated by and paid for by sysmocom,
a for-profit entity.  The GPLv2 Section 2c exception for noncommercial
distribution hence doesn't apply, i.e. we would be directly responsible for
providing the complete and corresponding source for each build of each
image/layer we ever publish.

Osmocom is a project about open source mobile communications software,
and we are creating + distributing our own software.  We provide source
and binary packages for a variety of distributions/releases, instructions how to
build from source as well as Dockerfiles and Ansible playbooks on how to
automatically build/install the software.  I think that shipping
container or VM images is out of scope.  We have plenty of issues within
the core scope of our projects to work on (1004 open issues on
osmocom.org at the point of this writing), and I'd suggest we focus on that.

Regards,
	Harald

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Tue Apr 28 15:17:04 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 28 Apr 2020 17:17:04 +0200
Subject: DGSM merge: need feedback on open questions
Message-ID: <20200428151704.GA5297@my.box>

Hi all,

we need to wrap up the DGSM work and get it to a state that can be merged to
master.

There are still open issues that I am not sure how to solve, which I've
mentioned on some occasions, but it seems to not have been loud enough.
I would easily choose one way, but am not sure about others' opinions.


(1) One open point is the GSUP peer identification.  I've added a comment
explaining it in https://gerrit.osmocom.org/c/osmo-hlr/+/16459/9

Me personally, I would strip down basically all of that complexity again and go
with the simplest solution, a nul terminated size limited char string for GSUP
peer id. The patch became what it is because vague requirements were thrown in
the mix and I tried to accomodate them, and now it ended up being a rather ugly
shim around a simple char string, really.


(2) Another open question is the freeing behavior in osmo_gsup_req (for proper
async handling of DGSM, and to ensure proper GSUP responses).  I've added a
comment explaining that in https://gerrit.osmocom.org/c/osmo-hlr/+/16205/29


The gist for both issues is that I could write patches that would have a large
ripple effect throug many files and follow-up patches, but if we again disagree
on the outcome, the work would multiply.

So, DGSM works and is ready, except that we need to agree on what will be
accepted by review. I need opinions to be able to complete this (or possibly a
"go" to do whatever I think is right and merge that).

Thanks!

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200428/d21c303d/attachment.bin>

From laforge at osmocom.org  Tue Apr 28 17:00:06 2020
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 28 Apr 2020 19:00:06 +0200
Subject: DGSM merge: need feedback on open questions
In-Reply-To: <20200428151704.GA5297@my.box>
References: <20200428151704.GA5297@my.box>
Message-ID: <20200428170006.GO1055326@nataraja>

Hi Neels,

On Tue, Apr 28, 2020 at 05:17:04PM +0200, Neels Hofmeyr wrote:
> we need to wrap up the DGSM work and get it to a state that can be merged to
> master.

Indeed.

> (1) One open point is the GSUP peer identification.  I've added a comment
> explaining it in https://gerrit.osmocom.org/c/osmo-hlr/+/16459/9
> 
> Me personally, I would strip down basically all of that complexity again and go
> with the simplest solution, a nul terminated size limited char string for GSUP
> peer id. The patch became what it is because vague requirements were thrown in
> the mix and I tried to accomodate them, and now it ended up being a rather ugly
> shim around a simple char string, really.

I defer to your judgement.

> (2) Another open question is the freeing behavior in osmo_gsup_req (for proper
> async handling of DGSM, and to ensure proper GSUP responses).  I've added a
> comment explaining that in https://gerrit.osmocom.org/c/osmo-hlr/+/16205/29

No strong opinion either way, slight preference towards the way the patch
currently is.

Let's see if somebody has strong opinions otherwise.
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From keith at rhizomatica.org  Tue Apr 28 19:25:35 2020
From: keith at rhizomatica.org (Keith)
Date: Tue, 28 Apr 2020 14:25:35 -0500
Subject: DGSM merge: need feedback on open questions
In-Reply-To: <20200428151704.GA5297@my.box>
References: <20200428151704.GA5297@my.box>
Message-ID: <9a4ae221-1fb3-1248-b941-446fb5806320@rhizomatica.org>


On 28/04/2020 10:17, Neels Hofmeyr wrote:

>
> There are still open issues that I am not sure how to solve, which I've
> mentioned on some occasions, but it seems to not have been loud enough.
> I would easily choose one way, but am not sure about others' opinions.

I guess this falls somewhat into my lap and I have to admit to not
having looked at it enough.

I don't think it is that you are not loud enough. It's just this is
still way way ahead of the speeds things seem to be able to move at the
the world of "ma?ana..."

I can't even respond to your specific questions. (1) and (2). All I
could say, for my part, at this point would be "go" with your way and
then "somebody" will have to deal with any fallout later from not being
up to speed with it now.

> So, DGSM works and is ready, except that we need to agree on what will be
> accepted by review. I need opinions to be able to complete this (or possibly a
> "go" to do whatever I think is right and merge that).
So, if it is "just" questions which are to do with the tech of the
implementation, then I guess my opinion is not very relevant.

k




From zhankun_bi at 163.com  Mon Apr 27 02:45:04 2020
From: zhankun_bi at 163.com (cruise)
Date: Mon, 27 Apr 2020 10:45:04 +0800
Subject: version problem of libosmocore during installing osmoTRX
Message-ID: <721df635-4211-f28c-2d9c-16d6b8996b2f@163.com>

$ git clone git?//git.osmocom.org/osmo-trx $ git branch * master $ 
./configure ... checking for LIBOSMOCORE... no configure: error: Package 
requirements (libosmocore >= 1.3.0) were not met: No package 
'libosmocore' found Consider adjusting the PKG_CONFIG_PATH environment 
variable if you installed software in a non-standard prefix. Then, check 
the information of libosmocore: $dpkg -l |grep libosmocore ii 
libosmocore:amd64 0.9.0-7 amd64 Open Source MObile COMmunications CORE 
library (metapackage) ii libosmocore6:amd64 0.9.0-7 amd64 Osmo Core 
library $ sudo apt-get install libosmocore ... libosmocore has already 
been the newest version (0.9.0-7)? why???what can i do?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200427/7dd8a522/attachment.htm>

From zhankun_bi at 163.com  Thu Apr 30 08:09:10 2020
From: zhankun_bi at 163.com (cruise)
Date: Thu, 30 Apr 2020 16:09:10 +0800
Subject: POWEROFF after the osmo-NITB has been installed
Message-ID: <60fc05d5-5a50-8df5-1be7-b1f8b28b7c06@163.com>

Hello:

I installed the osmo-NITB on ubuntu18.04, including 
osmo-trx,osmo-bts,and openbsc.

I run these three applications in three terminals successively, it seems 
ok, but the tx/rx leds on usrp-b210 hardware platform are not lighted,

and the print message in the osmo-trx terminal shows :

Thu Apr 30 15:28:28 2020 DTRXCTRL <0002> Transceiver.cpp:832 
[tid=139871716352896][chan=0] command is 'POWEROFF'
Thu Apr 30 15:28:28 2020 DTRXCTRL <0002> Transceiver.cpp:977 
[tid=139871716352896][chan=0] response is 'RSP POWEROFF 0'

I try to send some commands on another terminal which launch a telnet 
session which connects to the osmo-bts control interface(port number is 
4238) , but it not working.

what can i do next?

thanks a lot.




From axilirator at gmail.com  Thu Apr 30 10:22:52 2020
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 30 Apr 2020 17:22:52 +0700
Subject: version problem of libosmocore during installing osmoTRX
In-Reply-To: <721df635-4211-f28c-2d9c-16d6b8996b2f@163.com>
References: <721df635-4211-f28c-2d9c-16d6b8996b2f@163.com>
Message-ID: <CAPEnp=ZtdNRFZz9i7dcEPqRJmDRj4WBpR604tD=dzVDF7Wm=Wg@mail.gmail.com>

Hello,

> error: Package requirements (libosmocore >= 1.3.0) were not met:
> libosmocore has already been the newest version (0.9.0-7)

it's obvious that your libosmocore is too old. I guess you're using a
non-official package repository with ancient unmaintained packages.
Osmocom provides up to date nightly [1] and latest release [2] binary
packages for Debian-based distributions. You should remove your old
package and use the one from Osmocom's repository. Or simply build the
recent libosmocore yourself.

[1] https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds
[2] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds

With best regards,
Vadim Yanitskiy.


From axilirator at gmail.com  Thu Apr 30 10:35:49 2020
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Thu, 30 Apr 2020 17:35:49 +0700
Subject: POWEROFF after the osmo-NITB has been installed
In-Reply-To: <60fc05d5-5a50-8df5-1be7-b1f8b28b7c06@163.com>
References: <60fc05d5-5a50-8df5-1be7-b1f8b28b7c06@163.com>
Message-ID: <CAPEnp=YjOBgREc6CdikopQasGYOLK=ScMT5VrWsZCY+dUN_++g@mail.gmail.com>

Hello,

> what can i do next?

Please attach your logs and *.pcap traces (not screenshots!), so we
can see what's going on. Otherwise there is no way to help you.

NOTE: OpenBSC has been deprecated and not maintained anymore.

With best regards,
Vadim Yanitskiy.


From nhofmeyr at sysmocom.de  Thu Apr 30 17:43:38 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 30 Apr 2020 19:43:38 +0200
Subject: DGSM merge: need feedback on open questions
In-Reply-To: <20200428151704.GA5297@my.box>
References: <20200428151704.GA5297@my.box>
Message-ID: <20200430174338.GA8397@my.box>

On Tue, Apr 28, 2020 at 05:17:04PM +0200, Neels Hofmeyr wrote:
> we need to wrap up the DGSM work and get it to a state that can be merged to
> master.

My latest summary on this is:

- keith had no time to look at this, says to go ahead and deal with the merged
situation later.

- pespin would prefer an opaque data structure for peer id, for ABI compat
reasons.

- I'm reluctant to add opaque data because that requires dynamic allocation.
Concerning future ABI compatibility, I agree that it would be a nice thing but
is not a hard requirement. IMHO it isn't worth adding dynamic allocation (and
rewriting many patches on this branch) for it.

- laforge indicates slight preference of the patch staying as it is now.

- I would actually prefer a plain char string (the current real world usage).
My gut feel is that the peer id will remain API bloat forever, but it gives the
benefit of the doubt to being able to expand the API compatibly in the future.

Seems like everyone is pointing in a slightly different direction.  But I think
most of our concerns are rather scratching the surface rather than being
substantial deep review on the core implementations of D-GSM.

In the last patch set, I only renamed osmo_gsup_peer_id to osmo_cni_peer_id,
added some API doc and tweaked some commit log messages, added a const.

So, essentially, these patches are still the same that they have been for
months

I've probed the patches for desirable changes for a while and seem to hit
reasons to not change anything in every direction. So we either find agreement
on how to change these patches, or we merge them as they are. I think there is
agreement that we don't want to keep this on a branch for much longer, so I'd
ask reviewers to converge on a verdict, ideally one that says CR+2...

On the level of maturity: osmith and I have tested the D-GSM setup a lot, and
the substantial code changes in osmo-hlr (new LU FSM and osmo_gsup_req and peer
id) have already been running at 36c3 in Leipzig without issues.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200430/bf2bc57f/attachment.bin>