OpenBSC October 2017

openbsc@lists.osmocom.org

21 participants
47 discussions

by Martin Nagy

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

1 week

Re: Help with sccp library

by mosbah abdelkader

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

1 month, 2 weeks

dynamic traffic channels

by Neels Hofmeyr

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 months

GAPK status update

by Vadim Yanitskiy

Dear Osmocom community, I have been working on GAPK (GSM Audio Packet Knife) for some time, and now I would like to share some achievements. Previously GAPK was represented as a single binary that could be called with some command line arguments in order to perform required operations. This is only handy for humans, but not for other programs, which may also need to perform some format / codec conversations or audio capture / playback. One of such programs is the mobile from OsmocomBB project. Currently, when you're making a voice call, both audio capture and playback are only possible on the L1 side, i.e. on a Calypso based phone. Of course, the audio stream can be redirected via MNCC socket, but this is not what a regular OsmocomBB user would like to do. Moreover, there is a lack of AMR codec support. Also, there is another GNURadio based project named GR-GSM. In short, this is a set of blocks for GSM signal reception, demodulation and further processing. At the moment, one has TCH Full Rate decoding capabilities only. Audio playback is not supported yet. Having these projects in my mind, I have got an idea of creating a shared library from the GAPK source code. And, a few days ago I was managed to get the audio playback working in OsmocomBB. I hope, this library will be also usable for other projects. Brief list of changes were made: - Composed a shared library named libosmogapk - All exposed symbols have got an 'osmo_gapk' prefix - Added a pkg-config manifest and a symbol export map - Integrated the Osmocom logging framework - Benchmarking is now disabled by default - Processing queue now based on the linuxlist - Fixed program exit due to ALSA buffer underrun - Fixed ALSA audio playback from file - Old gapk application was renamed to 'osmo-gapk' and linked against the library - Adjusted verbosity level (normal / debug) - Fixed I/O combinations (ALSA, RTP, file...) check All changes could be found at the fixeria/lib branch of GAPK. I hope to see them merged, and open for discussions ;) With best regards, Vadim Yanitskiy.

7 years, 8 months

GPRS EXperiments

by Keith

Hi List! As there isn't so much about GPRS on here, I though I might write something about experiments over the last couple of weeks with data inside and outside of the lab. I've installed up to date versions of osmo-bts and osmo-pcu on sysmobts 2050 hardware and it's working great! Dynamic channels are really nice, with half rate TCH and AMR working perfectly. Thanks for all that work! The question for this experiment was if it was going to be feasible to actually do anything with several hundred data hungry spying devices.... I mean mobile phones on the network. For the traffic control, I setup a local blacklisting or whitelisting dns server. I've tried both. Blacklisting the worst culprits would be nice, but in practice I think I'll have to go for whitelisting only the intended permitted services. I configured pcodns1 in the ggsn to point to this DNS server, AND I setup a port 53 redirect to catch quite a lot of traffic from android that likes to just talk directly to 8.8.8.8 anyway. In the wild, some dns request analysis reveals the worst culprits (this is a very basic analysis) appear to be all the google update stuff, play store etc, facebook iCloud, (all to be expected) , and certain CDNs. Some research shows that these CDN companys specialize in delivery of advertising content inside apps such as mobile platform games. Such is the sad state of affairs on today's internet. Fortunately, we have iptables and ip sets and we have AS blocks assigned to certain bandwidth hungry corporations :-) So turns out it seems quite feasible to supply service for text messages with certain popular IM services to many phones. Short voice clips worked quite well in the lab tests, although support for media such as pictures and videos was not so great. I have yet to successfully send an image (sourced via device camera within the app) over a "secret" chat with Telegram messenger. As this is not a very low level report, rather intended as some light reading :) I also have a question in a similar light vein. I'm still getting to grips with the log messages available in the pcu , the sgsn and not so much the ggsn, and I'm observing and learning the sequence of events, so at some point I should be able to present a better report about this with some relevant traces and better analysis. For now, In the lab tests I am constantly monitoring the RF uplink; I observe that a phone will attach and then go quiet. A foreground running app may report that it is "connecting" or some such, and the little arrows may be flashing to show that apparently we are transmitting data, but there is nothing on the uplink. My guess here is the OS has sent something and the baseband is saying yes yes doing it.. but the baseband at the same time is waiting for something from the network (and not getting it)? This situation can persist for some time.. several minutes. I have observed that if I initiate any data transfer from the network side then the uplink is established. By the same token, If I transfer a file from the network (http download or some such), the same applies. The link stays active and the IM chat session is very responsive alongside the file transfer. Shortly after the file transfer completes, the uplink is quiet again and the latency in the IM session becomes a problem. >From a UX point of view.. Let me put it this way.. I can start an IM chat, send a message.. but then we get to this quiet uplink sitation and the messages stop sending.. so from the user's point of view it's frustrating. the phone looks like it's transmitting.. until there are timeouts and disconnections and the app may show some indication to the user that it is having trouble connecting to the network. However if I run something on the network side like a script that sends one ping to the phone every ten seconds, this keeps the connection 'alive' and the IM session is much more satisfactory for the user. I should note I believe I observe this also on commercial networks in some places like certain Berlin U-bahn stations where you can still find (only) GPRS data coverage. Also, a more scientific report is needed, but I seem to observe some phones behaving "better" than others, as in being a little more active on the uplink. Maybe it is related to power saving configuration? The not very low level and scientific question here is: Is this kind of thing tunable with gprs parameters? Any tips on which ones to play with? ( Quite happy to wait until I can send a more useful report too! ) Thanks! Keith.

7 years, 9 months

Build failed in Jenkins: Coverity-Upload » linux_amd64_debian8 #1653

by jenkins＠lists.osmocom.org

See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_de…> ------------------------------------------ [...truncated 1.84 MB...] test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory, test_apps/Makefile.am:17: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory, test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory, test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory, test_apps/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory, test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory, test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory, test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory, test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here binaries/Makefile.am: installing 'aux_config/depcomp' test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo) test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo) test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo) test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo) + ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for pkg-config... /usr/bin/pkg-config checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.20... yes checking for ANSI C header files... (cached) yes checking for stdlib.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for LIBXML2... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for memset... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating def_frame/Makefile config.status: creating def_list/Makefile config.status: creating binaries/Makefile config.status: creating test_apps/Makefile config.status: creating libsmpp34.pc config.status: creating aux_config/config.h config.status: executing depfiles commands config.status: executing libtool commands + make -j 3 echo 1.12.10-05bc > .version-t && mv .version-t .version make all-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Making all in binaries make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1 mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c mv -f .deps/core.Tpo .deps/core.Po gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'. Stop. make[2]: *** Waiting for unfinished jobs.... libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1 mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34' Makefile:368: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 454 C/C++ compilation units (100%) successfully 454 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure

7 years, 9 months

New "osmocom:latest" package feed

by Harald Welte

Dear Osmocom community, since the NITB-split has completed, and we have integrated 3G fully into master, and also merged nitb-split and nitb packages in one feed, the next step on the agenda was to create packages/feeds that are more stable than "nightly". After a long day of "release engineering" work and related fixes, starting from today, Osmocom not only has the "osmocom:nightly" feed tracking the "master of the day" of all repositories. We now also have a "osmocom:latest" feed for various Debian and Ubuntu GNU/Linux distributions which contains packages for the last tagged version of each source code repository. The setup is fairly similar to that of the "osmocom:nightly" packages and is described at https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds I've also removed all known references to Nightly_Builds on the wiki and replaced it with a reference to the new Binary_Packages page explaining the differences between Nightly_Builds and Latest_Builds: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages As you can see at https://build.opensuse.org/project/monitor/network:osmocom:latest almost all the packages are building already. I intend to fix the remaining three (osmo-bsc, osmo-msc and osmo-pcu) shortly. -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 9 months

.deb updates in Debian/Ubuntu repos

by Max

Hi. For quite some time Osmocom packages are available in Debian [1] and Ubuntu [2] repositories. That's a really nice thing although there're only minor distro-specific updates between different releases so far. In addition to usual "fix old bugs, add new features (and bugs :)" progress, there're bigger changes happening in Osmocom [3] projects. Most notably: we now have multiple repositories for BSC/MSC/SGSN instead of single OpenBSC repo. The process is not finished yet (doc/manuals update is still under way for example) but I think it's already a good time to discuss how can we bring those changes into Debian/Ubuntu repositories. We already have nightly builds for all packages from new repositories [4] as well as old ones [5]. The basic question is - what shall we do to get the packages built from new repositories into Debian/Ubuntu? Is there something we (upstream) can do, to facilitate the process? Are there some notable .deb-specific patches you'd like to see merged? Should I have used some other channel to communicate instead of emails I've fetched from changelogs? [1] https://packages.debian.org/search?keywords=osmocom&searchon=names&suite=st… [2] https://packages.ubuntu.com/search?suite=all&section=all&arch=amd64&keyword… [3] https://osmocom.org/issues/2257 [4] https://build.opensuse.org/project/monitor/network:osmocom:nitb-split:night… [5] https://build.opensuse.org/project/monitor/network:osmocom:nightly -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 9 months

Want to do paid work on Osmocom? sysmocom is hiring

by Harald Welte

Dear Osmocom community, I would like to point out that at sysmocom, we're currently (again) hiring [1]. If you happen to have an interest in open source cellular communications and are fluent in C language development, we would love to hear from you. sysmocom probably doesn't need any introduction here, but just in case: The company was founded by Holger Freyther and Harald Welte, two of the leading OpenBSC and Osmocom developers from the very early days of the project. Today we are responsible for by far the largest number of commits to the Osmocom GSM/3G infrastructure related git repositories. Among our current priorities are automatic testing for the GPRS PCU, generalization of the OsmoMGW media gateway, support for load-based hand-over, inter-BSC hand-over as well as various improvements on the lower layers of the GPRS protocol stack. We're very dedicated to the cause in furthering the capabilities of open source cellular infrastructure from 2G to 4G. We believe in working upstream, no open core or dual licensing. If you have an interest working with an enthusiastic, strong technical and dedicated team of Osmocom hackers, please don't hesitate to let me know, best by e-mail to jobs(a)sysmocom.de Thanks, Harald p.s.: I hope this kind of message is not disturbing to anyone. I think it is important to the Osmocom project to have more paid people working on the stack, so it is justified. The positions we are seeking to fill will work [almost exclusively] on Osmocom, so it's not a random job ad but in the very interest of Osmocom, and hence on-topic for this list. [1] https://www.sysmocom.de/jobs/ -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 9 months

OsmoNITB Migration Guide

by Alexander Chemeris

Hi Neels, I was reading the subj and I have a couple questions: > Note that not all information is copied to the hlr.db, just IMSI and 2G auth tokens. Are at least extension values migrated as well? Could you explicitly list what is not migrated? Maybe just list exact list of values migrated to make sure there is no confusion by users? > # ---------- to OsmoBSC: Is '#' a valid comment for Osmocom files? I always saw ';' used instead. And one note: Not sure if you have time for that, but what would be really helpful is a table with all OsmoNITB, OsmoBSC and OsmoMSC configuration values listed and three columns showing where the value belongs. That would make it much easier to users to migrate and (I would expect) reduce the number of questions on the mailing list. Something like this: Configuration value OsmoNITB OsmoBSC OsmoMSC network / network country code 901 yes no yes msc / msc-addr msc_remote no yes no PS Great work! Keep it up! -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co

7 years, 9 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2017