From infibiti16 at gmail.com Tue May 7 06:05:06 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Tue, 7 May 2019 14:05:06 +0800 Subject: Fwd: Problems In-Reply-To: References: Message-ID: I have these problems on make command. What should i do ? I'm using Ubuntu 16.04 32 bit -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2019-05-01 14-05-41.png Type: image/png Size: 46004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 12.png Type: image/png Size: 231808 bytes Desc: not available URL: From vvvelichkov at gmail.com Tue May 7 22:20:37 2019 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Wed, 8 May 2019 01:20:37 +0300 Subject: Fwd: Problems In-Reply-To: References: Message-ID: <560f72cd-e425-5382-2303-058a6fdd8038@gmail.com> Hi Bilguun Tugs, On 07/05/2019 09.05, Bilguun Tugs wrote: > I have these problems on make command. What should i do ? > I'm using Ubuntu 16.04 32 bit Please never send screenshots. See http://lists.osmocom.org/pipermail/baseband-devel/2012-March/003012.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From infibiti16 at gmail.com Thu May 9 06:03:52 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Thu, 9 May 2019 14:03:52 +0800 Subject: Trx build problem Message-ID: *There is an error to make command.* make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src/mobile' make[3]: Entering directory '/home/bilguun/Desktop/trx/src/host/layer23/src' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src' make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src' make[2]: Entering directory '/home/bilguun/Desktop/trx/src/host/layer23' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23' make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23' make -C host/osmocon make[1]: Entering directory '/home/bilguun/Desktop/trx/src/host/osmocon' make all-am make[2]: Entering directory '/home/bilguun/Desktop/trx/src/host/osmocon' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/osmocon' make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/osmocon' make -C host/gsmmap make[1]: Entering directory '/home/bilguun/Desktop/trx/src/host/gsmmap' make all-am make[2]: Entering directory '/home/bilguun/Desktop/trx/src/host/gsmmap' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/gsmmap' make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/gsmmap' make -C target/firmware CROSS_COMPILE=arm-elf- make[1]: Entering directory '/home/bilguun/Desktop/trx/src/target/firmware' LD board/compal_e88/hello_world.highram.elf arm-elf-ld: ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): Relocations in generic ELF (EM: 3) arm-elf-ld: ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): Relocations in generic ELF (EM: 3) arm-elf-ld: ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): Relocations in generic ELF (EM: 3) arm-elf-ld: ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): Relocations in generic ELF (EM: 3) ../../shared/libosmocore/build-target/src/.libs/libosmocore.a: could not read symbols: File in wrong format Makefile.inc:135: recipe for target 'board/compal_e88/hello_world.highram.elf' failed make[1]: *** [board/compal_e88/hello_world.highram.elf] Error 1 make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/target/firmware' Makefile:57: recipe for target 'firmware' failed make: *** [firmware] Error 2 I cant build layer23. What should i do ? (OS UBUNTU 32 bit). -------------- next part -------------- An HTML attachment was scrubbed... URL: From infibiti16 at gmail.com Thu May 9 06:06:26 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Thu, 9 May 2019 14:06:26 +0800 Subject: libdbdi-drivers error Message-ID: *cannot make those files.* *Error looks like* make[3]: Entering directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0/drivers/sqlite3' /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I/usr/local/include -DDBDIR=\"/usr/local/var/lib/libdbi/sqlite3\" -std=gnu99 -MT dbd_sqlite3.lo -MD -MP -MF .deps/dbd_sqlite3.Tpo -c -o dbd_sqlite3.lo dbd_sqlite3.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I/usr/local/include -DDBDIR=\"/usr/local/var/lib/libdbi/sqlite3\" -std=gnu99 -MT dbd_sqlite3.lo -MD -MP -MF .deps/dbd_sqlite3.Tpo -c dbd_sqlite3.c -fPIC -DPIC -o .libs/dbd_sqlite3.o dbd_sqlite3.c:316:5: error: conflicting types for ?dbd_goto_row? int dbd_goto_row(dbi_result_t *result, unsigned long long rowidx, unsigned long ^ In file included from dbd_sqlite3.c:58:0: /usr/local/include/dbi/dbd.h:41:5: note: previous declaration of ?dbd_goto_row? was here int dbd_goto_row(dbi_result_t *result, unsigned long long rowidx); ^ dbd_sqlite3.c: In function ?dbd_list_dbs?: dbd_sqlite3.c:409:16: warning: implicit declaration of function ?_dirent_buf_size? [-Wimplicit-function-declaration] entry_size = _dirent_buf_size(dp); ^ dbd_sqlite3.c: In function ?dbd_list_tables?: dbd_sqlite3.c:504:3: error: unknown type name ?dbi_inst? dbi_inst instance; ^ dbd_sqlite3.c:513:14: warning: implicit declaration of function ?dbi_driver_get_instance? [-Wimplicit-function-declaration] instance = dbi_driver_get_instance(dbi_conn_get_driver(conn)); ^ dbd_sqlite3.c:514:14: warning: implicit declaration of function ?dbi_conn_new_r? [-Wimplicit-function-declaration] tempconn = dbi_conn_new_r("sqlite3", instance); ^ dbd_sqlite3.c:514:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion] tempconn = dbi_conn_new_r("sqlite3", instance); ^ Makefile:502: recipe for target 'dbd_sqlite3.lo' failed make[3]: *** [dbd_sqlite3.lo] Error 1 make[3]: Leaving directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0/drivers/sqlite3' Makefile:404: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0/drivers' Makefile:455: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0' Makefile:385: recipe for target 'all' failed make: *** [all] Error 2 What should i do ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Thu May 9 10:30:02 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 9 May 2019 17:30:02 +0700 Subject: libdbdi-drivers error In-Reply-To: References: Message-ID: Hello, > Entering directory '/home/bilguun/Desktop/libdbi-drivers-0.9.0/drivers/sqlite3' > What should i do ? Please read the mailing list description: "This list is for discussion surrounding the OsmocomBB project, working on an open source / free software GSM baseband processor firmware + protocol stack. " Neither libdbi, nor libdbd-sqlite is a part of the Osmocom project. There is usually no need to compile both libraries from source, as they're available as binary packages in the most distributions. With best regards, Vadim Yanitskiy. From infibiti16 at gmail.com Thu May 9 10:31:21 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Thu, 9 May 2019 18:31:21 +0800 Subject: libdbdi-drivers error In-Reply-To: References: Message-ID: Ok, thanks. On Thu, May 9, 2019 at 6:30 PM Vadim Yanitskiy wrote: > Hello, > > > Entering directory > '/home/bilguun/Desktop/libdbi-drivers-0.9.0/drivers/sqlite3' > > What should i do ? > > Please read the mailing list description: "This list is for discussion > surrounding > the OsmocomBB project, working on an open source / free software GSM > baseband processor firmware + protocol stack. " > > Neither libdbi, nor libdbd-sqlite is a part of the Osmocom project. > > There is usually no need to compile both libraries from source, as > they're available as binary packages in the most distributions. > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvvelichkov at gmail.com Thu May 9 10:58:18 2019 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Thu, 9 May 2019 13:58:18 +0300 Subject: Trx build problem In-Reply-To: References: Message-ID: <474f4a93-c4b4-54fd-8887-d81ba8cbec09@gmail.com> Hi Bilguun Tugs, On 09/05/2019 09.03, Bilguun Tugs wrote: > arm-elf-ld: > ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): > Relocations in generic ELF (EM: 3) > arm-elf-ld: > ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): > Relocations in generic ELF (EM: 3) > arm-elf-ld: > ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): > Relocations in generic ELF (EM: 3) > arm-elf-ld: > ../../shared/libosmocore/build-target/src/.libs/libosmocore.a(msgb.o): > Relocations in generic ELF (EM: 3) > ../../shared/libosmocore/build-target/src/.libs/libosmocore.a: could > not read symbols: File in wrong format The exact same errors were reported in http://lists.osmocom.org/pipermail/baseband-devel/2012-March/003012.html and the problem was with the following two commands. ? git clean -dfx ? make Regards, Vasil From infibiti16 at gmail.com Sat May 11 08:44:06 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Sat, 11 May 2019 16:44:06 +0800 Subject: Trx connection problem Message-ID: In this command there is something wrong. Im using motorola c118. Command : ./osmocon -m c123xor -p /dev/ttyUSB1 -s /tmp/osmocom l2 -c target/firmware/board/compal_e88/trx.highram.bin Received PROMPT2 from phone, starting download handle_write(): 39 bytes (39/39) handle_write(): finished got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 03 . got 1 bytes from modem, data looks like: 42 B Received DOWNLOAD ACK from phone, your code is running now! Enabled Compal ramloader -> Calypso romloader chainloading mode Received ident ack from phone, sending parameter sequence opening file: No such file or directory what was the problem ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sat May 11 13:03:34 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sat, 11 May 2019 20:03:34 +0700 Subject: Trx connection problem In-Reply-To: References: Message-ID: Hello, > Command : ./osmocon -m c123xor -p /dev/ttyUSB1 -s /tmp/osmocom l2 -c target/firmware/board/compal_e88/trx.highram.bin Before running a base station, please at least learn how to access the filesystem in UNIX based operating systems. Apparently, there is directory 'target' in 'src/host/osmocon'. It's in 'src/', so either run osmocon from 'src', or use '../../target/firmware/board/compal_e88/trx.highram.bin'. For more details, see: https://osmocom.org/projects/baseband/wiki/CalypsoBTS. With best regards, Vadim Yanitskiy. From infibiti16 at gmail.com Mon May 13 03:03:11 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Mon, 13 May 2019 11:03:11 +0800 Subject: Trx connection problem In-Reply-To: References: Message-ID: Thanks, I'll check it out. On Sat, May 11, 2019 at 9:03 PM Vadim Yanitskiy wrote: > Hello, > > > Command : ./osmocon -m c123xor -p /dev/ttyUSB1 -s /tmp/osmocom l2 -c > target/firmware/board/compal_e88/trx.highram.bin > > Before running a base station, please at least learn how to access the > filesystem in UNIX based operating systems. Apparently, there is > directory 'target' in 'src/host/osmocon'. It's in 'src/', so either > run osmocon from 'src', or use > '../../target/firmware/board/compal_e88/trx.highram.bin'. > > For more details, see: > https://osmocom.org/projects/baseband/wiki/CalypsoBTS. > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From infibiti16 at gmail.com Wed May 15 07:50:55 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Wed, 15 May 2019 15:50:55 +0800 Subject: Transceiver error Message-ID: *cd /root/osmocom/trx/src/host/layer23/src/transceiver/* *./transceiver -a ARFCN -2 -r 99* *I want to write this command. But it didnt have any transceiver file on this. I write make command but it seems so many error* root at bilguun-shady:~/Desktop/trx/src/host/layer23/src/transceiver# make CCLD transceiver gmsk.o: In function `osmo_gmsk_free': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:85: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:87: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_generate_pulse': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:110: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:123: undefined reference to `expf' gmsk.o: In function `osmo_gmsk_generate_rotation_tables': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:145: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:146: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' gmsk.o: In function `osmo_gmsk_generate_pulse': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:128: undefined reference to `sqrtf' gmsk.o: In function `osmo_gmsk_modulate_burst': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:209: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:227: undefined reference to `osmo_cxvec_convolve' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:230: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_trainseq_generate': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:256: undefined reference to `osmo_cxvec_correlate' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:260: undefined reference to `osmo_cxvec_peak_energy_find' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:265: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:272: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_trainseq_free': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:286: undefined reference to `osmo_cxvec_free' gsm_ab.o: In function `gsm_ab_detect': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:53: undefined reference to `osmo_cxvec_correlate' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:57: undefined reference to `osmo_cxvec_peak_energy_find' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' gsm_ab.o: In function `gsm_ab_demodulate': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:90: undefined reference to `osmo_cxvec_scale' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:91: undefined reference to `osmo_cxvec_delay' demod.o: In function `gsm_ab_ind_process': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:51: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:62: undefined reference to `osmo_cxvec_sig_normalize' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:70: undefined reference to `cabsf' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:76: undefined reference to `cabsf' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:101: undefined reference to `osmo_cxvec_free' collect2: error: ld returned 1 exit status Makefile:355: recipe for target 'transceiver' failed make: *** [transceiver] Error 1 What should i do ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvvelichkov at gmail.com Wed May 15 10:30:04 2019 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Wed, 15 May 2019 13:30:04 +0300 Subject: Transceiver error In-Reply-To: References: Message-ID: <7023c191-7503-5647-a2c5-d23bea1668ab@gmail.com> Hi Bilguun Tugs, On 15/05/2019 10.50, Bilguun Tugs wrote: > root at bilguun-shady:~/Desktop/trx/src/host/layer23/src/transceiver# make > ? CCLD???? transceiver > gmsk.o: In function `osmo_gmsk_free': > /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:83: > undefined reference to `osmo_cxvec_free' The `osmo_cxvecf_free` function is implemented in the libosmo-dsp library but for some reason the linker could not find it. > What should i do ? Try re-installing the latest version of libosmo-dsp and if you have multiple versions of libosmodsp.so* in /usr/local/lib try removing them all and re-install. Regards, Vasil From infibiti16 at gmail.com Wed May 15 10:47:57 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Wed, 15 May 2019 18:47:57 +0800 Subject: Transceiver error In-Reply-To: <7023c191-7503-5647-a2c5-d23bea1668ab@gmail.com> References: <7023c191-7503-5647-a2c5-d23bea1668ab@gmail.com> Message-ID: I will try that. On Wed, May 15, 2019 at 6:30 PM Vasil Velichkov wrote: > Hi Bilguun Tugs, > > On 15/05/2019 10.50, Bilguun Tugs wrote: > > root at bilguun-shady:~/Desktop/trx/src/host/layer23/src/transceiver# make > > CCLD transceiver > > gmsk.o: In function `osmo_gmsk_free': > > /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:83: > > undefined reference to `osmo_cxvec_free' > > The `osmo_cxvecf_free` function is implemented in the libosmo-dsp > library but for some reason the linker could not find it. > > > What should i do ? > > Try re-installing the latest version of libosmo-dsp and if you have > multiple versions of libosmodsp.so* in /usr/local/lib try removing them > all and re-install. > > Regards, > Vasil > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From infibiti16 at gmail.com Fri May 17 05:39:20 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Fri, 17 May 2019 13:39:20 +0800 Subject: Transceiver problem Message-ID: How to make this command ? Im doing this article. Also installed all those libraries. But cannot build transceiver file. Im installed libosmo-dsp. https://www.smartspate.com/how-to-create-2g-network-at-your-own-home/ root at bilguun-shady:~/Desktop/trx/src/host/layer23/src/transceiver# make install CCLD transceiver gmsk.o: In function `osmo_gmsk_free': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:85: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:87: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_generate_pulse': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:110: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:123: undefined reference to `expf' gmsk.o: In function `osmo_gmsk_generate_rotation_tables': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:145: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:146: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' gmsk.o: In function `osmo_gmsk_generate_pulse': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:128: undefined reference to `sqrtf' gmsk.o: In function `osmo_gmsk_modulate_burst': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:209: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:227: undefined reference to `osmo_cxvec_convolve' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:230: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_trainseq_generate': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:256: undefined reference to `osmo_cxvec_correlate' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:260: undefined reference to `osmo_cxvec_peak_energy_find' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:265: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:272: undefined reference to `osmo_cxvec_free' gmsk.o: In function `osmo_gmsk_trainseq_free': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gmsk.c:286: undefined reference to `osmo_cxvec_free' gsm_ab.o: In function `gsm_ab_detect': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:53: undefined reference to `osmo_cxvec_correlate' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:57: undefined reference to `osmo_cxvec_peak_energy_find' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' gsm_ab.o: In function `gsm_ab_demodulate': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:90: undefined reference to `osmo_cxvec_scale' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/gsm_ab.c:91: undefined reference to `osmo_cxvec_delay' demod.o: In function `gsm_ab_ind_process': /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:51: undefined reference to `osmo_cxvec_alloc' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:62: undefined reference to `osmo_cxvec_sig_normalize' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:70: undefined reference to `cabsf' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:76: undefined reference to `cabsf' /home/bilguun/Desktop/trx/src/host/layer23/src/transceiver/demod.c:101: undefined reference to `osmo_cxvec_free' collect2: error: ld returned 1 exit status Makefile:355: recipe for target 'transceiver' failed make: *** [transceiver] Error 1 What should i do ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From infibiti16 at gmail.com Mon May 20 11:04:24 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Mon, 20 May 2019 19:04:24 +0800 Subject: Trx Make error Message-ID: *root at bilguun-shady:~/Desktop/trx/src# make HOST_layer23_CONFARGS=--enable-transceiver* There is another problem on building trx. Im doing this article step by step. In this command there comes into that error. make[3]: Entering directory '/home/bilguun/Desktop/trx/src/host/layer23/src/mobile' CC gsm322.o gsm322.c: In function ?gsm322_cs_select?: gsm322.c:1865:3: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] band = gsm_arfcn2band(index2arfcn(i)); ^ gsm322.c: In function ?gsm322_search_end?: gsm322.c:2055:30: warning: variable ?mnc? set but not used [-Wunused-but-set-variable] int tune_back = 0, mcc = 0, mnc = 0; ^ gsm322.c: In function ?gsm322_nb_check?: gsm322.c:4196:3: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] band = gsm_arfcn2band(nb->arfcn); ^ gsm322.c: In function ?gsm322_nb_new_rxlev?: gsm322.c:4693:2: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] int band = gsm_arfcn2band(cs->arfcn); ^ gsm322.c: In function ?gsm322_exit?: gsm322.c:5142:7: warning: variable ?rc? set but not used [-Wunused-but-set-variable] int rc; ^ In file included from /usr/include/string.h:635:0, from gsm322.c:25: In function ?memset?, inlined from ?bargraph.constprop? at gsm322.c:325:2: /usr/include/i386-linux-gnu/bits/string3.h:86:7: warning: call to ?__warn_memset_zero_len? declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters __warn_memset_zero_len (); ^ CC gsm480_ss.o gsm480_ss.c: In function ?gsm480_tx_ussd?: gsm480_ss.c:535:2: warning: ?gsm_7bit_encode? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:242): Use gsm_7bit_encode_n() instead [-Wdeprecated-declarations] length = gsm_7bit_encode(msg->data, text); ^ gsm480_ss.c: In function ?gsm480_rx_ussd?: gsm480_ss.c:779:2: warning: ?gsm_7bit_decode? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n() instead [-Wdeprecated-declarations] gsm_7bit_decode(text, tag_data, num_chars); ^ gsm480_ss.c: In function ?gsm480_mmss_ind?: gsm480_ss.c:1221:6: warning: variable ?rc? set but not used [-Wunused-but-set-variable] int rc = 0; ^ CC gsm411_sms.o gsm411_sms.c: In function ?sms_from_text?: gsm411_sms.c:116:2: warning: ?gsm_7bit_encode? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:242): Use gsm_7bit_encode_n() instead [-Wdeprecated-declarations] sms->user_data_len = gsm_7bit_encode(sms->user_data, sms->text); ^ gsm411_sms.c: In function ?gsm340_rx_tpdu?: gsm411_sms.c:285:4: warning: ?gsm_7bit_decode? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n() instead [-Wdeprecated-declarations] gsm_7bit_decode(gsms->text, smsp, gsms->user_data_len); ^ gsm411_sms.c:228:19: warning: variable ?sms_mms? set but not used [-Wunused-but-set-variable] uint8_t sms_mti, sms_mms; ^ gsm411_sms.c: In function ?gsm411_rx_rp_ud?: gsm411_sms.c:375:2: warning: format ?%li? expects argument of type ?long int?, but argument 7 has type ?int? [-Wformat=] LOGP(DLSMS, LOGL_INFO, "TPDU(%li,%s)\n", msg->tail-msg->l4h, ^ gsm411_sms.c:375:2: warning: format ?%li? expects argument of type ?long int?, but argument 7 has type ?int? [-Wformat=] CC gsm48_cc.o CC gsm48_mm.o gsm48_mm.c: In function ?decode_network_name?: gsm48_mm.c:269:2: warning: ?gsm_7bit_decode? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:240): Use gsm_7bit_decode_n() instead [-Wdeprecated-declarations] gsm_7bit_decode(name, lv + 2, length); ^ gsm48_mm.c: In function ?gsm48_mmr_dequeue?: gsm48_mm.c:780:20: warning: variable ?mmr? set but not used [-Wunused-but-set-variable] struct gsm48_mmr *mmr; ^ gsm48_mm.c: In function ?gsm48_mm_conn_go_dedic?: gsm48_mm.c:3252:25: warning: variable ?nmmh? set but not used [-Wunused-but-set-variable] struct gsm48_mmxx_hdr *nmmh; ^ gsm48_mm.c: In function ?gsm48_mm_sync_ind_active?: gsm48_mm.c:3333:25: warning: variable ?nmmh? set but not used [-Wunused-but-set-variable] struct gsm48_mmxx_hdr *nmmh; ^ gsm48_mm.c: In function ?gsm48_rcv_rr_sapi3?: gsm48_mm.c:3603:28: warning: variable ?nmmh? set but not used [-Wunused-but-set-variable] struct gsm48_mmxx_hdr *nmmh; ^ CC gsm48_rr.o gsm48_rr.c: In function ?gsm48_rr_tx_rand_acc?: gsm48_rr.c:1668:3: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] LOGP(DRR, LOGL_INFO, "Use alternative tx-power %d (%d dBm)\n", ^ gsm48_rr.c:1668:3: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] gsm48_rr.c:1676:4: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] LOGP(DRR, LOGL_INFO, "Use MS-TXPWR-MAX-CCH power value " ^ gsm48_rr.c:1676:4: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] gsm48_rr.c:1683:4: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] LOGP(DRR, LOGL_INFO, "Use MS-TXPWR-MAX-CCH power value " ^ gsm48_rr.c:1683:4: warning: ?gsm_arfcn2band? is deprecated (declared at /usr/local/include/osmocom/gsm/gsm_utils.h:164): Use gsm_arfcn2band_rc() instead [-Wdeprecated-declarations] gsm48_rr.c: In function ?gsm48_rr_tx_meas_rep?: gsm48_rr.c:2736:53: warning: variable ?multi_rep? set but not used [-Wunused-but-set-variable] uint8_t rep_ba = 0, rep_valid = 0, meas_valid = 0, multi_rep = 0; ^ gsm48_rr.c: At top level: gsm48_rr.c:813:13: warning: ?start_rr_t3124? defined but not used [-Wunused-function] static void start_rr_t3124(struct gsm48_rrlayer *rr, int sec, int micro) ^ CC mnccms.o CC settings.o CC subscriber.o subscriber.c: In function ?gsm_subscr_generate_kc?: subscriber.c:947:4: warning: ?comp128? is deprecated (declared at /usr/local/include/osmocom/gsm/comp128.h:22): Use generic API from osmocom/crypt/auth.h instead [-Wdeprecated-declarations] comp128(set->test_ki, rand, sres, subscr->key); ^ CC support.o CC transaction.o CC vty_interface.o vty_interface.c: In function ?ms_vty_init?: vty_interface.c:2840:2: warning: ?install_default? is deprecated (declared at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly with install_node() [-Wdeprecated-declarations] install_default(MS_NODE); ^ vty_interface.c:2885:2: warning: ?install_default? is deprecated (declared at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly with install_node() [-Wdeprecated-declarations] install_default(SUPPORT_NODE); ^ vty_interface.c:2943:2: warning: ?install_default? is deprecated (declared at /usr/local/include/osmocom/vty/command.h:364): Now happens implicitly with install_node() [-Wdeprecated-declarations] install_default(TESTSIM_NODE); ^ CC voice.o CC mncc_sock.o AR libmobile.a ar: `u' modifier ignored since `D' is the default (see `U') CC main.o main.c: In function ?main?: main.c:220:2: warning: ?msgb_set_talloc_ctx? is deprecated (declared at /usr/local/include/osmocom/core/msgb.h:734): Use msgb_talloc_ctx_init() instead [-Wdeprecated-declarations] msgb_set_talloc_ctx(l23_ctx); ^ CC app_mobile.o app_mobile.c:376:2: warning: initialization from incompatible pointer type .go_parent_cb = ms_vty_go_parent, ^ app_mobile.c:376:2: warning: (near initialization for ?vty_info.go_parent_cb?) CCLD mobile libmobile.a(gsm322.o): In function `memset': /usr/include/i386-linux-gnu/bits/string3.h:86: undefined reference to `__warn_memset_zero_len' collect2: error: ld returned 1 exit status Makefile:379: recipe for target 'mobile' failed make[3]: *** [mobile] Error 1 make[3]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src/mobile' Makefile:325: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23/src' Makefile:350: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/bilguun/Desktop/trx/src/host/layer23' Makefile:51: recipe for target 'layer23' failed make: *** [layer23] Error 2 What should i do ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From infibiti16 at gmail.com Wed May 22 07:16:43 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Wed, 22 May 2019 15:16:43 +0800 Subject: Layer23- transceiver make command error Message-ID: Im following this article. These errors given. I wanna do this command. https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-osmocom-bb-compatible-phones-on-kali-rolling/ *Shell #3* # cd trx/src/host/layer23/src/transceiver/ # sudo ./transceiver -a [YOUR ARFCN FOUND WITH RSSI] -2 -r 99 This command doesnt work in trx folder. (kali 18.1) rot at kali:~/trx/src/host/layer23/src/transceiver# make CCLD transceiver /usr/bin/ld: gmsk.o: in function `osmo_gmsk_free': /root/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined reference to `osmo_cxvec_free' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:85: undefined reference to `osmo_cxvec_free' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:87: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_pulse': /root/trx/src/host/layer23/src/transceiver/gmsk.c:110: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:123: undefined reference to `expf' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_rotation_tables': /root/trx/src/host/layer23/src/transceiver/gmsk.c:145: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:146: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:153: undefined reference to `cexp' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_pulse': /root/trx/src/host/layer23/src/transceiver/gmsk.c:128: undefined reference to `sqrtf' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_modulate_burst': /root/trx/src/host/layer23/src/transceiver/gmsk.c:209: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:227: undefined reference to `osmo_cxvec_convolve' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:230: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_trainseq_generate': /root/trx/src/host/layer23/src/transceiver/gmsk.c:256: undefined reference to `osmo_cxvec_correlate' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:260: undefined reference to `osmo_cxvec_peak_energy_find' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:265: undefined reference to `osmo_cxvec_free' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:272: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gmsk.o: in function `osmo_gmsk_trainseq_free': /root/trx/src/host/layer23/src/transceiver/gmsk.c:286: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gsm_ab.o: in function `gsm_ab_detect': /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:53: undefined reference to `osmo_cxvec_correlate' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:57: undefined reference to `osmo_cxvec_peak_energy_find' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: undefined reference to `osmo_cxvec_free' /usr/bin/ld: gsm_ab.o: in function `gsm_ab_demodulate': /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:90: undefined reference to `osmo_cxvec_scale' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:91: undefined reference to `osmo_cxvec_delay' /usr/bin/ld: demod.o: in function `gsm_ab_ind_process': /root/trx/src/host/layer23/src/transceiver/demod.c:51: undefined reference to `osmo_cxvec_alloc' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:62: undefined reference to `osmo_cxvec_sig_normalize' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:70: undefined reference to `cabsf' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:76: undefined reference to `cabsf' /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:101: undefined reference to `osmo_cxvec_free' collect2: error: ld returned 1 exit status make: *** [Makefile:360: transceiver] Error 1 How to build transceiver file ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvvelichkov at gmail.com Wed May 22 16:02:02 2019 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Wed, 22 May 2019 19:02:02 +0300 Subject: Layer23- transceiver make command error In-Reply-To: References: Message-ID: Hi Bilguun Tugs, On 22/05/2019 10.16, Bilguun Tugs wrote: > |rot at kali:~/trx/src/host/layer23/src/transceiver# make| > || > |? CCLD???? transceiver > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_free': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined > reference to `osmo_cxvec_free' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:85: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:87: > undefined reference to `osmo_cxvec_free' > | Most probably the layer23 has not been configured with |--enable-transceiver flag. Try to reconfigure it with using the following commands | ??? cd |/root/trx/src/host/layer23/ ??? ./configure --enable-transceiver ??? make|| | And if it still fails execute the following commands and provide their full output ??? for lib in $(find / -name libosmodsp.so); do echo $lib; objdump -T $lib | grep osmo_cxvec_free; done ??? grep osmo_cxvec_free $(find / -name cxvec.h)| ||||head -10 /root/trx/src/host/layer23/config.log || ||grep -i "OSMODSP" |/root/trx/src/host/layer23/config.log ||??? grep -R -i "OSMODSP" |/root/trx/src/host/layer23/src/transceiver/| ||||||||cd |||||||||/root/trx/src/host/layer23/src/transceiver/| && make V=1|||||||| |||| Regards, Vasil -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvvelichkov at gmail.com Wed May 22 16:08:53 2019 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Wed, 22 May 2019 19:08:53 +0300 Subject: Layer23- transceiver make command error In-Reply-To: References: Message-ID: Hi Bilguun Tugs, My email client somehow messed up the formatting of my previous email, hope now will be better. On 22/05/2019 10.16, Bilguun Tugs wrote: > |rot at kali:~/trx/src/host/layer23/src/transceiver# make| > || > |? CCLD???? transceiver > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_free': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined > reference to `osmo_cxvec_free' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:85: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:87: > undefined reference to `osmo_cxvec_free' > | Most probably the layer23 has not been configured with |--enable-transceiver flag. Try to reconfigure it with using the following commands | cd |/root/trx/src/host/layer23/ ./configure --enable-transceiver make|| | And if it still fails execute the following commands and provide their full output for lib in $(find / -name libosmodsp.so); do echo $lib; objdump -T $lib | grep osmo_cxvec_free; done grep osmo_cxvec_free $(find / -name cxvec.h)| ||||head -10 /root/trx/src/host/layer23/config.log ||||grep -i "OSMODSP" |/root/trx/src/host/layer23/config.log ||grep -R -i "OSMODSP" |/root/trx/src/host/layer23/src/transceiver/| ||||||||cd |||||||||/root/trx/src/host/layer23/src/transceiver/| && make V=1|||||||| |||| Regards, Vasil -------------- next part -------------- An HTML attachment was scrubbed... URL: From bastienbaranoff at gmail.com Wed May 22 16:15:15 2019 From: bastienbaranoff at gmail.com (Bastien Baranoff) Date: Wed, 22 May 2019 18:15:15 +0200 Subject: Layer23- transceiver make command error In-Reply-To: References: Message-ID: Hello I was able to reproduce the bug to compile transceiver don't go in /root/trx/src/host/layer23/src/transceiver make fails here Rather than that do the following go to root folder # git clone https://github.com/osmocom/osmocom-bb trx # cd trx/src # nano target/firmware/Makefile (tx enable...) # git checkout jolly/testing # make HOST_layer23_CONFARGS=--enable-transceiver Le mer. 22 mai 2019 ? 09:18, Bilguun Tugs a ?crit : > > Im following this article. These errors given. I wanna do this command. > > https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-osmocom-bb-compatible-phones-on-kali-rolling/ > > *Shell #3* > # cd trx/src/host/layer23/src/transceiver/ > # sudo ./transceiver -a [YOUR ARFCN FOUND WITH RSSI] -2 -r 99 > This command doesnt work in trx folder. (kali 18.1) > > > > rot at kali:~/trx/src/host/layer23/src/transceiver# make > CCLD transceiver > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_free': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:83: undefined reference > to `osmo_cxvec_free' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:85: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:87: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_pulse': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:110: undefined reference > to `osmo_cxvec_alloc' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:123: > undefined reference to `expf' > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_rotation_tables': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:145: undefined reference > to `osmo_cxvec_alloc' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:146: > undefined reference to `osmo_cxvec_alloc' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:153: > undefined reference to `cexp' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:153: > undefined reference to `cexp' > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_generate_pulse': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:128: undefined reference > to `sqrtf' > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_modulate_burst': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:209: undefined reference > to `osmo_cxvec_alloc' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:227: > undefined reference to `osmo_cxvec_convolve' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:230: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_trainseq_generate': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:256: undefined reference > to `osmo_cxvec_correlate' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:260: > undefined reference to `osmo_cxvec_peak_energy_find' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:265: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gmsk.c:272: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: gmsk.o: in function `osmo_gmsk_trainseq_free': > /root/trx/src/host/layer23/src/transceiver/gmsk.c:286: undefined reference > to `osmo_cxvec_free' > /usr/bin/ld: gsm_ab.o: in function `gsm_ab_detect': > /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:53: undefined > reference to `osmo_cxvec_correlate' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:57: > undefined reference to `osmo_cxvec_peak_energy_find' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:67: > undefined reference to `osmo_cxvec_free' > /usr/bin/ld: gsm_ab.o: in function `gsm_ab_demodulate': > /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:90: undefined > reference to `osmo_cxvec_scale' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/gsm_ab.c:91: > undefined reference to `osmo_cxvec_delay' > /usr/bin/ld: demod.o: in function `gsm_ab_ind_process': > /root/trx/src/host/layer23/src/transceiver/demod.c:51: undefined reference > to `osmo_cxvec_alloc' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:62: > undefined reference to `osmo_cxvec_sig_normalize' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:70: > undefined reference to `cabsf' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:76: > undefined reference to `cabsf' > /usr/bin/ld: /root/trx/src/host/layer23/src/transceiver/demod.c:101: > undefined reference to `osmo_cxvec_free' > collect2: error: ld returned 1 exit status > make: *** [Makefile:360: transceiver] Error 1 > > How to build transceiver file ? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu May 23 11:15:12 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 23 May 2019 13:15:12 +0200 Subject: hand-over in L1CTL / trxcon Message-ID: <20190523111512.GQ30189@nataraja> Hi Vadim, I'm currently facing the problem of testing hand-over related channel-activation in OsmoBTS. Three are various rules about how this has to be done, and a closer look indicates that both osmo-bts-trx as well as osmo-bts-sysmo don't get that right at all. I'd like to write TTCN-3 tests as part of BTS_Tests.ttcn, which uses L1CTL to control a (virtual or real) L1 for the MS side of testing the BTS. To break this down to low-level requirements in terms of MS capabilities: * switch to a different ARFCN * switch to a speciifed timeslot * change the synchroniztaion (in terms of where we currently are in the TDMA multiplex) to a given neighbor cell. The MS will have performed neighbor measurements before, and as part of that will hav received FCCH + SCH and hence know the timing both in terms of carrier freq as well as TDMA position [none of this is relevant for a fake_trx + trxcon setup] * ability to enable only the receiver for the main channel (SDCCH/FACCH), but suppress any reception (or passing up of received) SACCH. * ability to transmit RACH burst[s] in uplink on that new dedicated channel * ability to later on enable full Rx/Tx of all logical channels on that dedicated channel I've looked at the jolly/handover branch from 2013, and rebased that on top of current master, the result can be seen in laforge/jolly_handover_rebase Change-Id Iadbc47f006d1f8a019822aedee180814de13cb2d specifically adds new flags to DM_EST_REQ to * disable uplink transmission * use the sync information of a neighbor cell I would like to get at least that change to L1CTL merged to master, and while doing that, update all implementations of L1CTL at the same time. It may make sense to also merge Change-Id I792b52d9bf115a2def9720eed3d62982d8cdbe00 while at it, which is required for neighbor channel measurements + reporting. We should also use that opportunity to introduce some kind of versioning support to L1CTL, to ensure future extensions of the protocol can be made in a way where incompatibility can at least be detected at runtime. Now the next question is how to this will impact trxcon/fake_trx. AFAICT, there is a comment in trxcon hinting that the TRX TUNE comamnd of a DM_EST_REQ would fail if there was already and established channel before. Is that correct? If so, what is the suggested/recommended way to get trxcon to support at least the minimum of what's required for handover in a virtual environment? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Sat May 25 23:50:21 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 26 May 2019 06:50:21 +0700 Subject: hand-over in L1CTL / trxcon In-Reply-To: <20190523111512.GQ30189@nataraja> References: <20190523111512.GQ30189@nataraja> Message-ID: Hi Harald, sorry for late response, I took me some time to recover after PHDays. > I'd like to write TTCN-3 tests as part of BTS_Tests.ttcn, > which uses L1CTL to control a (virtual or real) L1 for > the MS side of testing the BTS. Great! I will be happy to cooperate you on the MS side. > To break this down to low-level requirements > in terms of MS capabilities: > * switch to a different ARFCN > * switch to a speciifed timeslot As far as I understand (sorry, my HO knowledge is very limited), this should be possible while being on a dedicated channel. In general, it is already possible with the current code: that's exactly how ASSIGNMENT COMMAND works AFAIR. To do that, the controlling side need to send a L1CTL_RESET_REQ, followed by L1CTL_FBSB_REQ, and then finally L1CTL_DM_EST_REQ. Otherwise the old dedicated connection would remain active... The main problem of this approach is that the new ARFCN the MS is requested to switch needs to be C0 (i.e. transmit both FCCH and BCCH). Otherwise L1CTL_FBSB_REQ would fail. That's a poor man's (I would even say ugly) approach, and as it turns out, there is L1CTL_DM_FREQ_REQ, which allows to schedule frequency change at the given TDMA frame number! But not the timeslot change :/ At the moment, trxcon does not support L1CTL_DM_FREQ_REQ. But I think this is the way to go. (Ab)using L1CTL_DM_EST_REQ in order to change ARFCN and/or TDMA TN looks like a bad idea to me. It should be used for a single purpose - go from IDLE to DEDICATED. > * change the synchroniztaion (in terms of where we currently are > in the TDMA multiplex) to a given neighbor cell. [...] > [none of this is relevant for a fake_trx + trxcon setup] Why not relevant? I believe with the recently refactored FakeTRX we can connect as much BTS and/or TRX instances as we need, and I think we can even play with the clock distribution, so two or more BTS instances would use independent clock sources ;) For changing TDMA parameters, we can think about introducing a new message, e.g. L1CTL_DM_TDMA_REQ, that by analogy with the mentioned L1CTL_DM_FREQ_REQ would allow to schedule TDMA parameters change at the given TDMA frame number. > * ability to enable only the receiver for the main channel > (SDCCH/FACCH), but suppress any reception (or passing up > of received) SACCH. So this is only needed for handover, right? If yes, we can extend the 'l1ctl_info_ul' (which is included in L1CTL_DM_FREQ_REQ) with such information. Fortunately, there are two padding bytes in it. > * ability to transmit RACH burst[s] in uplink on that > new dedicated channel So there is no warranty that the new dedicated channel would contain RACH slots, right? That's another limitation of trxcon: it can send RACH bursts on RACH slots only, and only on TS0. The second limitation can be easily fixed by indicating a proper timeslot in the 'l1ctl_info_ul' header of L1CTL_RACH_REQ. Currently the higher layers leave this header empty, so we always assume 'chan_nr' == 0x88, which corresponds to RACH on TS0. The first limitation comes from the architecture of trxcon. Unlike the firmware for Calypso targets, trxcon's scheduler is 'layout-based', i.e. we have the TDMA multiframe layouts and mapping the current TDMA frame number to them gives us an idea what to do. The firmware's scheduler, which runs on top of the DSP's internal scheduler, is following the 'task-based' approach, i.e. we have different sets of active and inactive tasks with TDMA frame numbers indicating when exactly we should execute them. The 'layout-based' approach does not allow us to schedule any tasks, such as frequency redefinition, TDMA parameters change, or Access Burst transmission, on a given frame number. Therefore, we either need to completely switch (i.e. rewrite) trxcon to the 'task-based' architecture, or extent the existing scheduler with the ability to schedule some tasks, so we would have a mixed architecture. > * ability to later on enable full Rx/Tx of all logical channels > on that dedicated channel It looks like we need a new L1CTL message for (de)activating TDMA timeslots on the current channel, and (de)activate particular logical channels on them. That would be also useful for other tests, e.g. multi-TS transmission in (E)GPRS. > I've looked at the jolly/handover branch from 2013, and rebased > that on top of current master, the result can be seen in > laforge/jolly_handover_rebase I had a quick look so far, and in general it looks good to me. We just need to conclude on the L1CTL changes (see above). > We should also use that opportunity to introduce some kind of > versioning support to L1CTL, to ensure future extensions of the > protocol can be made in a way where incompatibility can at least > be detected at runtime [...] A very early / draft implementation can be found in a separate branch 'fixeria/l1ctl_nego': https://git.osmocom.org/osmocom-bb/log/?h=fixeria/l1ctl_nego this branch actually depends on: https://gerrit.osmocom.org/#/c/libosmocore/+/10034/ I wish I had more time to finish it... > Now the next question is how to this will impact trxcon/fake_trx. > AFAICT, there is a comment in trxcon hinting that the TRX TUNE > comamnd of a DM_EST_REQ would fail if there was already an > established channel before. Is that correct? I just checked the code, and I think it would not fail, but result into having the old channel left active. As I already mentioned above, I don't like the idea of abusing this message for handover. > If so, what is the suggested/recommended way to get trxcon to > support at least the minimum of what's required for handover > in a virtual environment? Let's resume everything, so that would be the answer: - We should not abuse L1CTL_DM_FREQ_REQ for handover, it should be used for a single purpose: switch from IDLE to DEDICATED. - Let's instead use both L1CTL_DM_FREQ_REQ and L1CTL_DM_TDMA_REQ (to be introduced) for handover remated manipulations. - Alternatively, we can introduce L1CTL_DM_HANDOVER_REQ that would contain both FDMA and TDMA parameters. - Let's introduce a new L1CTL message for (de)activating TDMA timeslots on the current channel, and (de)activating its logical channels. - We need to implement the ability to schedule tasks at the given TDMA frame number in trxcon, so it would be possible to change the FDMA and TDMA parameters, and send Access Bursts on non-RACH slots. - Let's try to hack the clock distribution in FakeTRX, so that would allow us to test handover between non-synchronized virtual Base Stations. Please note that I don't insist on any of these points, this is just my understanding of the way how the handover integration should be done. I am open for discussion ;) With best regards, Vadim Yanitskiy. From infibiti16 at gmail.com Tue May 28 06:47:38 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Tue, 28 May 2019 14:47:38 +0800 Subject: OSMO-nitb problem Message-ID: Hi im doing this article. https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-osmocom-bb-compatible-phones-on-kali-rolling/ But this error comes at shell #4 root at kali:~# osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -m -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM There is no such command. Error occurred during reading the below line: timer t3103 0 <0005> bsc_init.c:551 Failed to parse the config file: '/root/.osmocom/open-bsc.cfg' Reading config failed. Exiting. What should i fix it ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From infibiti16 at gmail.com Tue May 28 06:58:47 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Tue, 28 May 2019 14:58:47 +0800 Subject: Osmo-bts-trx command error Message-ID: How to do this command. Im following this article. https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-osmocom-bb-compatible-phones-on-kali-rolling/ root at kali:~# osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg -r 99 ((*)) | / \ OsmoBTS There is no such command. Error occurred during reading the below line: band GSM900 Failed to parse the config file: '/root/.osmocom/osmo-bts.cfg' *What should I do?* -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Tue May 28 09:07:21 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 28 May 2019 16:07:21 +0700 Subject: Osmo-bts-trx command error In-Reply-To: References: Message-ID: Dear Bilguun, please stop spamming the mailing list with every single error message you get. This is not a pastebin after all. Don't get me wrong, I am not trying to turn you out-of-doors, but you should be able to resolve such issues yourself. In this particular case it's obvious, just read your own message: > There is no such command. > Error occurred during reading the below line: > band GSM900 it already contains half of answer. Most likely, your configuration file missing the proper alignment, have a look at the examples: https://git.osmocom.org/osmo-bts/tree/doc/examples/trx > Im following this article. > https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-osmocom-bb-compatible-phones-on-kali-rolling/ This article might be outdated. I recommend to follow our own wiki. If you are going to run a base station, you should really understand what you're doing, but not just copy-pasting from random articles. There is a tutorial about CalypsoBTS, read it carefully: https://osmocom.org/projects/baseband/wiki/CalypsoBTS Thanks for your understanding. With best regards, Vadim Yanitskiy. From infibiti16 at gmail.com Tue May 28 09:44:29 2019 From: infibiti16 at gmail.com (Bilguun Tugs) Date: Tue, 28 May 2019 17:44:29 +0800 Subject: Osmo-bts-trx command error In-Reply-To: References: Message-ID: Thank you for your response. On Tue, May 28, 2019 at 5:07 PM Vadim Yanitskiy wrote: > Dear Bilguun, > > please stop spamming the mailing list with every single error > message you get. This is not a pastebin after all. Don't get > me wrong, I am not trying to turn you out-of-doors, > but you should be able to resolve such issues yourself. > > In this particular case it's obvious, just read your own message: > > > There is no such command. > > Error occurred during reading the below line: > > band GSM900 > > it already contains half of answer. Most likely, your configuration file > missing the proper alignment, have a look at the examples: > > https://git.osmocom.org/osmo-bts/tree/doc/examples/trx > > > Im following this article. > > > https://bastienbaranoff.wordpress.com/2018/08/10/gsm-base-station-with-two-osmocom-bb-compatible-phones-on-kali-rolling/ > > This article might be outdated. I recommend to follow our own wiki. > If you are going to run a base station, you should really understand > what you're doing, but not just copy-pasting from random articles. > > There is a tutorial about CalypsoBTS, read it carefully: > > https://osmocom.org/projects/baseband/wiki/CalypsoBTS > > Thanks for your understanding. > > With best regards, > Vadim Yanitskiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 79543015 at qq.com Tue May 28 10:25:20 2019 From: 79543015 at qq.com (=?gb18030?B?c29uZ2Jvc2k=?=) Date: Tue, 28 May 2019 18:25:20 +0800 Subject: Perfect module (D751749ZHH) Message-ID: Hello every one: I am making a FAKE BTS defender(DOS of fake bts) since Jul 2017. This product is used to detect and attack the fake GSM station(running openbts). I use c118 at first and it work fine. But c118 is not a good idea for production. I have disassembled many old GPRS modules , at last I found this module is perfect(D751749ZHH). Now I have 500 pcs left This module have TCK/TMS/TDO/TDI ?I make a custom OsmocomBB firmware , only need modify some IO control for RF switch, there are some picture to share with you. OsmocomBB is running on an ARM board You can mail me 79543015 at qq.com , if you are interested in this :P -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue May 28 12:34:23 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 28 May 2019 14:34:23 +0200 Subject: Perfect module (D751749ZHH) In-Reply-To: References: Message-ID: <20190528123423.GZ22070@nataraja> Hi Songbosi, On Tue, May 28, 2019 at 06:25:20PM +0800, songbosi wrote: > I have disassembled many old GPRS modules , at last I found this > module is perfect(D751749ZHH). Now I have 500 pcs left Can you clarify which particular "module" you are referring to? Where can the interested OsmocomBB developer/user community obtain them from? > This module have TCK/TMS/TDO/TDI ?I make a custom OsmocomBB firmware > , only need modify some IO control for RF switch, there are some > picture to share with you. As Osmocom is a collaborative open source development project, we would appreciate your patches and other contributions to the code at least as much as pictures of what you are doing :) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue May 28 12:38:37 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 28 May 2019 14:38:37 +0200 Subject: OSMO-nitb problem In-Reply-To: References: Message-ID: <20190528123837.GA22070@nataraja> Dear Bilguun, plase note OsmoNITB is obsolete and no longer maintained for quite some time now. We strongly encourage you to use the new "split" stack with separate BSC, MSC, HLR, ... Please follow instructions at https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box On Tue, May 28, 2019 at 02:47:38PM +0800, Bilguun Tugs wrote: > Error occurred during reading the below line: > timer t3103 0 you are using a configuration file from a program version that doesn't match the version you are using. I'm a bit puzzled about this, as the timer-related command was added in Nvoember 2009 in commit 23975e718fd456ff8be7effbb915903f1bc173be. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 79543015 at qq.com Tue May 28 19:29:31 2019 From: 79543015 at qq.com (=?gb18030?B?c29uZ2Jvc2k=?=) Date: Wed, 29 May 2019 03:29:31 +0800 Subject: =?gb18030?B?u9i4tKO6IFBlcmZlY3QgbW9kdWxlIChENzUxNzQ5?= =?gb18030?B?WkhIKQ==?= In-Reply-To: <20190528123423.GZ22070@nataraja> References: <20190528123423.GZ22070@nataraja> Message-ID: Hi Harald, For your reference https://app.2sim.cn/gsm/GTM900.pdf https://app.2sim.cn/gsm/huawei.jpg https://app.2sim.cn/gsm/huawei2.jpg https://app.2sim.cn/gsm/huawei3.jpg This module is HUAWEI GTM900-B I have about 500 pcs left, I could sell them with $15/pcs BR ------------------ ???? ------------------ ???: "Harald Welte"; ????: 2019?5?28?(???) ??8:34 ???: "songbosi"<79543015 at qq.com>; ??: "baseband-devel"; ??: Re: Perfect module (D751749ZHH) Hi Songbosi, On Tue, May 28, 2019 at 06:25:20PM +0800, songbosi wrote: > I have disassembled many old GPRS modules , at last I found this > module is perfect(D751749ZHH). Now I have 500 pcs left Can you clarify which particular "module" you are referring to? Where can the interested OsmocomBB developer/user community obtain them from? > This module have TCK/TMS/TDO/TDI ?I make a custom OsmocomBB firmware > , only need modify some IO control for RF switch, there are some > picture to share with you. As Osmocom is a collaborative open source development project, we would appreciate your patches and other contributions to the code at least as much as pictures of what you are doing :) Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue May 28 22:01:04 2019 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 29 May 2019 00:01:04 +0200 Subject: hand-over in L1CTL / trxcon In-Reply-To: References: <20190523111512.GQ30189@nataraja> Message-ID: <20190528220103.GG22070@nataraja> Hi Vadim, On Sun, May 26, 2019 at 06:50:21AM +0700, Vadim Yanitskiy wrote: > Great! I will be happy to cooperate you on the MS side. thanks! > > To break this down to low-level requirements > > in terms of MS capabilities: > > * switch to a different ARFCN > > * switch to a speciifed timeslot > > As far as I understand (sorry, my HO knowledge is very limited), > this should be possible while being on a dedicated channel. correct. However, for BTS_Tests.ttcn it doesn't really matter, as we are testing the individual low-level transactions and we can simply * RSL CHAN ACT (type == handover) * ask the MS to enter dedicated mode directly on that timeslot without any actual hand-over and no previous channel present. But that of course is insufficient for using it on real networks. > In general, it is already possible with the current code: that's > exactly how ASSIGNMENT COMMAND works AFAIR. good. > To do that, the controlling side need to send a L1CTL_RESET_REQ, > followed by L1CTL_FBSB_REQ, and then finally L1CTL_DM_EST_REQ. > Otherwise the old dedicated connection would remain active... Sounds like we need a DM_REL_REQ - and we actually have one. I would normally expect that to be used to release dedicated mode? Looking at layer23, it seems we have DM_REL_REQ, then RESET, then a new DM_EST_REQ during assignment. > The main problem of this approach is that the new ARFCN the MS > is requested to switch needs to be C0 (i.e. transmit both FCCH > and BCCH). Otherwise L1CTL_FBSB_REQ would fail. You are referring to trxcon or calypso-layer1 here? I'm asking as it is a perfectly natural occurring event to have an ASSIGNMENT on the same BTS but to a dedicated channel on a different ARFCN - and I would be surprised if caylypso-l1 of osmocom-bb wouldn't support that. > That's a poor man's (I would even say ugly) approach, and as it > turns out, there is L1CTL_DM_FREQ_REQ, which allows to schedule > frequency change at the given TDMA frame number! But not the > timeslot change :/ I actually think it's not ugly at all. You release the old dedicated channel and establish a new one. > At the moment, trxcon does not support L1CTL_DM_FREQ_REQ. But I > think this is the way to go. This is for changing the frequency on an exstablished dedicated channel, because the network descides to change its ARFCNs or hopping sequences at some point during operation. A very rare event, which I wouldn't be too worried about if we didn't cover it (but we in fact do in OsmocomBB!). > (Ab)using L1CTL_DM_EST_REQ in order to change ARFCN and/or TDMA TN > looks like a bad idea to me. It should be used for a single purpose - > go from IDLE to DEDICATED. It's not abusing. We actually do release the old channel and establish a new one... > > * change the synchroniztaion (in terms of where we currently are > > in the TDMA multiplex) to a given neighbor cell. [...] > > [none of this is relevant for a fake_trx + trxcon setup] > > Why not relevant? I believe with the recently refactored FakeTRX > we can connect as much BTS and/or TRX instances as we need, and > I think we can even play with the clock distribution, so two or > more BTS instances would use independent clock sources ;) you are right for the frame numbers which of course would be different between [even virtual] BTSs. However, there's of course no acquisition of FCCH to track the carrier frequency, which is probably what I was thinking, but not writing about. > For changing TDMA parameters, we can think about introducing a new > message, e.g. L1CTL_DM_TDMA_REQ, that by analogy with the mentioned > L1CTL_DM_FREQ_REQ would allow to schedule TDMA parameters change > at the given TDMA frame number. > > > * ability to enable only the receiver for the main channel > > (SDCCH/FACCH), but suppress any reception (or passing up > > of received) SACCH. > > So this is only needed for handover, right? If yes, we can extend > the 'l1ctl_info_ul' (which is included in L1CTL_DM_FREQ_REQ) with > such information. Fortunately, there are two padding bytes in it. I don't like such hacks, sorry. > > * ability to transmit RACH burst[s] in uplink on that > > new dedicated channel > > So there is no warranty that the new dedicated channel would contain > RACH slots, right? That's another limitation of trxcon: it can send > RACH bursts on RACH slots only, and only on TS0. The new dedicated channel is a normal SDCCH or TCH/F or TCH/H and there are no "rach slots". > The second limitation can be easily fixed by indicating a proper > timeslot in the 'l1ctl_info_ul' header of L1CTL_RACH_REQ. Currently > the higher layers leave this header empty, so we always assume > 'chan_nr' == 0x88, which corresponds to RACH on TS0. ACK. > The 'layout-based' approach does not allow us to schedule any tasks, > such as frequency redefinition, TDMA parameters change, or Access > Burst transmission, on a given frame number. Therefore, we either > need to completely switch (i.e. rewrite) trxcon to the 'task-based' > architecture, or extent the existing scheduler with the ability to > schedule some tasks, so we would have a mixed architecture. I think a complete rewrite might be too much work. > > * ability to later on enable full Rx/Tx of all logical channels > > on that dedicated channel > > It looks like we need a new L1CTL message for (de)activating TDMA > timeslots on the current channel, and (de)activate particular > logical channels on them. That would be also useful for other > tests, e.g. multi-TS transmission in (E)GPRS. I would like to think of it as "Layer 1 SAPIs", which could be activated and deactivated on the given dedicated channel. We have the same concept in osmo-bts-{sysmo,lc15,oc2g}, where one can e.g. activate SDCCH independent of SACCH, and do that independently for UL and DL. So I would completely decouple the different domains of: 1) changing the 'sync' (clock + TDMA) to a cell This can either be achieved by a) the classic FBSB_REQ during cell search / cell selection, or b) with a some new primitive which allows us to switch to one of the neighbors (whose clock + TDMA sync has to be established during the idle slots in dedicated mode). In Jolly's work, this is done with a special parameter to DM_EST_REQ, but I would make that a separate primitive. 2) changing the frequency while retaining sync This is used whenever channels on different ARFCN (or HSN/MAIO) on the same BTS are assigned to the MS. Changing frequency *without* also changing the timeslot (like our existing DM_FREQ_REQ) only happens in case of frequency changes/redefinitions, which I would consider rather rare and unusual events during normal operation. But yes, best to leave the DM_FREQ_REQ for this purpose unmodified. 3) establishing dedicated mode (DM_EST_REQ). It currently automatically activates all L1 SAPSs, but see below for my idea there. 4) returning back to idle mode (DM_REL_REQ). Care has to be taken about the situation where we fist hand-over to a new cell in dedicated mode, and then switch back to idle mode *on the new cell with its clock/tdma*. 4) activating/deactivating L1 SAPIs within that logical channel. this is where we can e.g. activate SACCH or not - or even activate RACH or not on a dedicated channel. The bit-masks of initial L1 sapis for UL and DL could be part of L1CTL_DM_EST_REQ. We could then modify that later using a L1CTL_DM_MOD_REQ (modify request)? So a typical hand-over scenario would then be FBSB_REQ - establish sync to first cell RACH_REQ DM_EST_REQ - establishing initial channel DM_REL_REQ - release old channel SYNC_NEIGH_REQ - change clock + tdma sync to a specific neighbor cell DM_EST_REQ - establish new channel on that neighbor cell; * ARFCN can be different from C0 of that cell! * initial L1 SAPI bitmask contains only DL DCCH + FACCH RACH_REQ DM_MOD_REQ - activate UL DCCH + ACCH > > I've looked at the jolly/handover branch from 2013, and rebased > > that on top of current master, the result can be seen in > > laforge/jolly_handover_rebase > > I had a quick look so far, and in general it looks good to me. > We just need to conclude on the L1CTL changes (see above). ACK. > > > We should also use that opportunity to introduce some kind of > > versioning support to L1CTL, to ensure future extensions of the > > protocol can be made in a way where incompatibility can at least > > be detected at runtime [...] > > A very early / draft implementation can be found > in a separate branch 'fixeria/l1ctl_nego': > > https://git.osmocom.org/osmocom-bb/log/?h=fixeria/l1ctl_nego > > this branch actually depends on: > > https://gerrit.osmocom.org/#/c/libosmocore/+/10034/ > > I wish I had more time to finish it... I know the feeling... > > If so, what is the suggested/recommended way to get trxcon to > > support at least the minimum of what's required for handover > > in a virtual environment? > > Let's resume everything, so that would be the answer: > > - We should not abuse L1CTL_DM_FREQ_REQ for handover, it should > be used for a single purpose: switch from IDLE to DEDICATED. I guess you're referring to DM_EST_REQ here? See above. > - Let's instead use both L1CTL_DM_FREQ_REQ and L1CTL_DM_TDMA_REQ > (to be introduced) for handover remated manipulations. I would argue L1CTL_DM_FREQ_REQ is for frequency changes while on an active dedicated channel on a given BTS. For hand-over, it's actually almost like we're establishing a completely new dedicated L1 channel. The higher-layer state (L3+) is retained, but L1 and L2 are completely new. So I don't think this is just a frequency + TDMA change. > - Alternatively, we can introduce L1CTL_DM_HANDOVER_REQ that > would contain both FDMA and TDMA parameters. I would think that's too specific. I would say we release the old channel and establish a new one. And if the new one fails to establish, we re-establish the old one using the freq + TDMA sync information we've kept around for the old cell. > - Let's introduce a new L1CTL message for (de)activating TDMA > timeslots on the current channel, I would consider this part of DM_EST_REQ + DM_REL_REQ - for both the Assignment and the Handover case. The only difference is whether we stay with freq+TDMA sync on the current cell, or on a new cell. > and (de)activating its logical channels. bitmask of L1 SAPI in DM_EST_REQ and new DM_MOD_REQ. > - We need to implement the ability to schedule tasks at the given > TDMA frame number in trxcon, so it would be possible to change > the FDMA and TDMA parameters, and send Access Bursts > on non-RACH slots. Not sure how much of that we really need beyond ability to send RACH on normal traffic channels... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue May 28 22:06:31 2019 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 29 May 2019 00:06:31 +0200 Subject: =?utf-8?B?5Zue5aSN?= =?utf-8?B?77ya?= Perfect module (D751749ZHH) In-Reply-To: References: <20190528123423.GZ22070@nataraja> Message-ID: <20190528220631.GH22070@nataraja> Hi! thanks for sharing the pictures. Can you please submit your patches / changes to OsmocomBB, so we can officially support this module from OsmcoomBB? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu May 30 08:38:16 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 30 May 2019 10:38:16 +0200 Subject: L1CTL extension (was Re: hand-over in L1CTL / trxcon) In-Reply-To: <20190528220103.GG22070@nataraja> References: <20190523111512.GQ30189@nataraja> <20190528220103.GG22070@nataraja> Message-ID: <20190530083816.GW22070@nataraja> Hi Vadim and others, given how long L1CTL has been around, and how many programs implement it by now, I really would like to ensure backwards compatibility without introducing weird breakage all over the place. The good news: I think it's possible to extend L1CTL in a backwards-compatible way, and I started with a related implementation. Some of my raw notes below: --- Extension of L1CTL in a compatible way * enhance l1ctl_reset with version and feature bitmap ** used by L1CTL_RESET_CONF, possibly also REQ, IND ** old implementation ignores trailer ** new implementation recognizes new format due to longer message (and enables use of new features) * new DM_EST_2_REQ ** sent by L23 only if feature-bit was set in RSEET_CONF ** contains additional fields *** L1 SAPI bitmask *** sync_source member to select own cell or neighbor cell sync info * new DM_EST_2_CONF ** response to _REQ (which is currently missing from DM_EST_REQ) * extend l1ctl_neigh_pm_ind with new fields at end ** L23 can use size to determine if new fields exist or not * new DM_MODIFY_REQ ** sent by L23 to change L1 SAPI bitmask * new DM_MODIFY_CONF to confirm it /* bit definitions for individual features communicated in RESET_CONF */ enum l1ctl_feature { L1CTL_FT_DM_EST2_MODIFY, /* DM_EST_2 and DM_MODIFY procedures */ L1CTL_FT_RACH_DM, /* RACH can be sent in dedicated mode */ L1CTL_FT_EXT_RACH_REQ, /* Extended RACH (11bit) support */ L1CTL_FT_SPKR_MIC, /* Hardware Speaker + Microphone supported */ L1CTL_FT_TRAFFIC_IND, L1CTL_FT_BURST_IND, L1CTL_FT_TBF, /* support for TBF_CFG and DATA_TBF procedures */ L1CTL_FT_SIM_SLOT, /* physical SIM slot exists */ L1CTL_FT_SIM_SLOT, /* physical SIM slot exists */ L1CTL_FT_BAND_850, L1CTL_FT_BAND_900, L1CTL_FT_BAND_1800, L1CTL_FT_BAND_1900, L1CTL_FT_CIPH_A51, L1CTL_FT_CIPH_A52, L1CTL_FT_CIPH_A53, }; --- I won't go "full steam ahead" on this, but will try to get it implemented within the next week or so. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Fri May 31 14:55:22 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 31 May 2019 21:55:22 +0700 Subject: hand-over in L1CTL / trxcon In-Reply-To: <20190528220103.GG22070@nataraja> References: <20190523111512.GQ30189@nataraja> <20190528220103.GG22070@nataraja> Message-ID: Hi Harald, > Sounds like we need a DM_REL_REQ - and we actually have one. I would > normally expect that to be used to release dedicated mode? Oh, right! L1CTL_DM_REL_REQ magically slipped my mind. Of course, this one is used to release dedicated mode, and trxcon does support it already. Sorry for confusion. >> The main problem of this approach is that the new ARFCN the MS >> is requested to switch needs to be C0 (i.e. transmit both FCCH >> and BCCH). Otherwise L1CTL_FBSB_REQ would fail. > > You are referring to trxcon or calypso-layer1 here? [...] > >> That's a poor man's (I would even say ugly) approach, and as it >> turns out, there is L1CTL_DM_FREQ_REQ, which allows to schedule >> frequency change at the given TDMA frame number! But not the >> timeslot change :/ > > I actually think it's not ugly at all. You release the old > dedicated channel and establish a new one. Nevermind. This is a result of my delusion. See above. > Looking at layer23, it seems we have DM_REL_REQ, then RESET, > then a new DM_EST_REQ during assignment. Right. I am now wondering, wouldn't this intermediate L1CTL_RESET_REQ cause an additional delay for handover? >> So there is no warranty that the new dedicated channel would contain >> RACH slots, right? That's another limitation of trxcon: it can send >> RACH bursts on RACH slots only, and only on TS0. Fortunately, I found a work around, please see: https://gerrit.osmocom.org/#/c/osmocom-bb/+/14274/ I've just confirmed that trxcon properly sends Access Bursts on any (activated by L1CTL_DM_EST_REQ) time-slot, please see: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14291/ ... and of course discovered a problem of OsmoBTS ;) In short, it doesn't detect handover RACH. The problem seems to be here: https://git.osmocom.org/osmo-bts/tree/src/common/scheduler.c#n986 An Access Burst is merely ignored if a logical channel is not active. King regards, Vadim Yanitskiy.