- OpenBSC - lists.osmocom.org

by Harald Welte

Hi Xaver, On Fri, Sep 11, 2020 at 07:51:50AM +0200, Xaver Zu wrote: > I created a short Wiki page. Please see if it's enough as a link to a > commit message. > https://osmocom.org/projects/sdr/wiki/PCIeSDR Thanks. For sure it is sufficient in terms of content. I did some minor reformatting while reading. However, I found a major problem. You state: > The higher-level driver (in userspace) includes a DSP, a calibration stage, and the gateware update. It is in the form of a closed source dynamic library named libsdr.so. The C API for Linux / x86 is in the form of a header file libsdr.h which also serves as brief documentation. This is incompatible with the strong copyleft licensing (AGPLv3) of osmo-trx! You cannot directly link with a proprietary library. The only way I can see a PCIeSDR backend for osmo-trx would be via osmo-trx-ipc, which provides a general-purpose sharde memory interface to another process. The other process can then use the non-free library, if you want that. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 years, 8 months

1
0
0 0

OsmoDevCon / COVID-19

by Harald Welte

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 years, 8 months

3
2
0 0

Re: New Defects reported by Coverity Scan for Osmocom

by nhofmeyr＠sysmocom.de

On Tue, Aug 25, 2020 at 02:49:39AM +0000, scan-admin(a)coverity.com wrote: > *** CID 212862: Error handling issues (CHECKED_RETURN) > /source-Osmocom/osmo-pcu/src/pdch.cpp: 211 in gprs_rlcmac_pdch::packet_paging_request()() > 205 > 206 /* loop until message is full */ > 207 while (pag) { > 208 if (log_check_level(DRLCMAC, LOGL_DEBUG)) { > 209 struct osmo_mobile_identity omi = {}; > 210 char str[64]; > >>> CID 212862: Error handling issues (CHECKED_RETURN) > >>> Calling "osmo_mobile_identity_decode" without checking return value (as is done elsewhere 20 out of 22 times). > 211 osmo_mobile_identity_decode(&omi, pag->identity_lv + 1, pag->identity_lv[0], true); > 212 osmo_mobile_identity_to_str_buf(str, sizeof(str), &omi); > 213 LOGP(DRLCMAC, LOGL_DEBUG, "Paging MI - %s\n", str); > 214 } I'd like to let you guys know that I intentionally don't check the return value here. This is only for logging the mobile identity, and if decoding fails, the logging should just show "NONE". ~N

3 years, 9 months

2
1
0 0

Patches and Packaging for Erlang Components

by Matthew Johnson

Hello! I was able to use the experimental osmo_dia2gsup converter to successfully enable circuit switched fallback in a test network, but have a couple fixes for it and osmo_ss7 needed to work with the latest 2G CN components. I would open a change request in gerrit, but I see that the rebar.conf of osmo_dia2gsup already depends on a WIP branch from osmo_ss7. How best should I provide patches for review? Is there ongoing work in http://git.osmocom.org/erlang/osmo_ss7/log/?h=laforge/wip that needs to be merged first, and is there a reason it has not been merged already? Otherwise should I open a change request towards the WIP branch? Also, do folks have any opinions on how best to package erlang components? I was going to generate a Debian package for a stand-alone erlang “release” of osmo_dia2gsup, and am happy to contribute the debian metadata and build files upstream, but I am not an erlang expert and want to make sure it’s structured in the correct way if there is a convention I should follow. >From a random sample it looks like none of the other erlang components are packaged, so I don’t have a good example to go from. If there is no opinion I will make an attempt, but I wanted to ask first! Thanks for your help and patience! -Matt J.

3 years, 9 months

2
2
0 0

openBSC with commercial BTS

by Ivan Babanov

Hello, I see that currently openBSC/osmoBSC works with a number of old commercial BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis. My question is, did somebody try something newer than Nokia UltraSite? I have an ability to try with FlexiBTS rel.3 with Abis over IP. I'm trying to find out if maybe it was already tried and had some unresolveable problems? Please let me know if any. Thank you Ivan

3 years, 9 months

4
5
0 0

Support for new SDR devices

by Xaver Zu

Hi all, What are the plans to expand support for new SDR devices? When I check the contents of osmo-trx/Transceiver52M/device/ on the git master I see the supported lms, uhd and usrp1 devices. For example the XTRX SDR was presented at OsmoDevCon 2018. I expected it to be included in the master soon. At this point I see its addition in the fairwaves / libxtrx-wip branch from 2018. That doesn't give me much encouragement for my next question. Would it be possible to add support for PCIe SDR from Amarisoft? Some information about SDR is here https://discourse.myriadrf.org/t/amarisoft-sdr-integration-with-oai/2288 Based on the https://media.ccc.de/v/osmocon2018-82-osmotrx-status-support-for-more-drive… I tried to create support by myself. I've gotten into a state that some MS with weak requirements for signal quality and timing can connect. My branch is here https://github.com/XK1ZU/osmo-trx/tree/PCIeSDR-LMSstyle gr-osmosdr support is here https://github.com/XK1ZU/gr-osmosdr/commits/PCIeSDR This osmo-trx is able to run for a few tens of seconds then it quits and I have to restart it, so I would need a deeper understanding of the timing and scheduling of processes within osmo-trx. Who should be a clock master SW stack or SDR device? I see a lot of log error messages as 0000> Transceiver.cpp:422 [tid=140137319651072][chan=0] dumping STALE burst in TRX->SDR interface (1:1408722 vs 7:1408723), retrans=0 <0000> Transceiver.cpp:1122 [tid=140137311258368] ClockInterface: sending IND CLOCK 1408899 or 0000> Transceiver.cpp:280 [tid=140137328043776] Starting the transceiver <0000> radioInterface.cpp:181 [tid=140137328043776] Starting radio device <0000> PCIESDRDevice.cpp:199 [tid=140137328043776] PCIESDRDevice::start <0000> PCIESDRDevice.cpp:205 [tid=140137328043776] starting PCIeSDR..., sample rate:1.08333e+06 <0000> PCIESDRDevice.cpp:234 [tid=140137328043776] PCIESDRDevice::flush <0000> PCIESDRDevice.cpp:219 [tid=140137328043776] msdr_start ok: <0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment <0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment <0000> radioInterface.cpp:202 [tid=140137328043776] Radio started <0000> Threads.cpp:119 [tid=140137294472960] Thread 140137294472960 (task 18522) set name: TxLower <0000> Threads.cpp:119 [tid=140137311258368] Thread 140137311258368 (task 18524) set name: RxUpper0 <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP POWERON 0' <0000> Threads.cpp:119 [tid=140137302865664] Thread 140137302865664 (task 18523) set name: RxLower <0002> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0 <0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested timestamp is not valid <0000> Threads.cpp:119 [tid=140137319651072] Thread 140137319651072 (task 18525) set name: TxUpper0 <0002> PCIESDRDevice.cpp:365 [tid=140137302865664] timestamp = 10960, length = 262144, time_start = 6765960, time_end = 6766960, data_start = 223320, data_end = 224320 <0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:3 rx_overflow_count:0 <0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun ts_tmp:10976 ts:10960 hwts:6762040 <0000> radioInterface.cpp:334 [tid=140137302865664] Receive error 0 <0000> Transceiver.cpp:1162 [tid=140137302865664] Something went wrong in thread RxLower, requesting stop <0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:4 rx_overflow_count:0 <0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun ts_tmp:13476 ts:13460 hwts:6762278 <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETRXGAIN 40' <0000> PCIESDRDevice.cpp:318 [tid=140137328043776] Setting RX gain to 40 dB. <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETRXGAIN 0 40' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETPOWER 0' <0000> PCIESDRDevice.cpp:297 [tid=140137328043776] Setting TX gain to 60 dB. device:0x1f6e0e0 chan:0 <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETPOWER 0 0' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 0 5' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 0 5' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 1 7' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 1 7' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 2 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 2 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 3 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 3 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 4 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 4 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 5 8' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 5 8' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 6 8' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 6 8' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 5 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 5 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 7 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 7 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 6 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 6 13' <0000> osmo-trx.cpp:485 [tid=140137400406720] Shutting down transceiver... <0000> Transceiver.cpp:338 [tid=140137400406720] Stopping the transceiver <0000> Transceiver.cpp:351 [tid=140137400406720] Stopping the device <0000> PCIESDRDevice.cpp:254 [tid=140137400406720] PCIESDRDevice::stop <0000> PCIESDRDevice.cpp:261 [tid=140137400406720] PCIESDR stopped <0000> Transceiver.cpp:364 [tid=140137400406720] Transceiver stopped <0000> PCIESDRDevice.cpp:78 [tid=140137400406720] Closing PCIESDR Device Yours XK1Zu

3 years, 9 months

5
7
0 0

Re: osmo-mslookup-client.c

by Neels Hofmeyr

Hi Edgard, thanks for your interest in the Osmocom project. On Sat, Aug 08, 2020 at 08:56:08PM +0100, Edgard Ndassimba wrote: > I have difficulte to implemente osmo-mslookup-client.c I'm sorry, I don't understand the question... I looked, and I notice that osmo-mslookup-client is missing from the binary packages. I opened a bug tracker for it: https://osmocom.org/issues/4706 If you want to use osmo-mslookup-client, you need to build osmo-hlr manually. For that, please look at https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source MSLookup and DGSM are explained in http://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf chapter "12 Distributed GSM / Multicast MS Lookup" If you have more questions about this, please write an email to openbsc(a)lists.osmocom.org or ask on IRC: FreeNode #osmocom Please write to the mailing list, and not to me personally. That way you have more people that can help you, and more people can learn from your progress. Thanks! ~N > > I use ubuntu 16.04 LTS amd64 > > Could you help me please? > > Best Regards > > -- > Edgard NDASSIMBA

3 years, 9 months

1
0
0 0

ttcn3-bsc-test-latest status

by Neels Hofmeyr

I recently broke ttcn3-bsc-test-latest for a couple of builds, which is fixed now. Still it appears like some 'latest' tests remain damaged, but that is actually not the case. Here a summary of those that look like failures but are expected: TC_chan_rel_rr_cause: the test is new and tests a feature not implemented in 'latest' yet. TC_chan_rqd_emerg_deny: the test is new and I'm not sure of its 'latest' status. TC_si2quater_2_earfcns, TC_si2quater_3_earfcns: osmo-ttcn3-hacks just now merged a patch that also tests EARFCN presence in a Channel Release message. Since 'latest' still has a bug that causes only the first EARFCN to appear in that message, these two tests now fail in 'latest'. TC_cbsp_emerg_write_bts_cgi_cchan: This used to fail, then during the massive failures it suddenly passed for a bit, and now fails again. The passes must have been flukes. ~N

3 years, 9 months

1
0
0 0

build trigger thunder cloud

by Neels Hofmeyr

Today I noticed that osmo-msc-master was being built several times in a row and I found there are multiple redundant ricocheting downstream builds of the same original upstream build timer. All of: https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18894/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18895/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18896/ show: Started by upstream project master-libosmocore build number 1624 And then there are: https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18897/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18898/ showing: Started by upstream project master-libosmo-abis build number 2611 So there are two timers launching master-libosmocore and launching master-libosmo-abis, and each of these cause multiple downstream build triggers of osmo-msc. Then there is also the osmo-msc timer, independently launching more nightly master-osmo-msc builds. It is not necessary to depend these builds on each other, because none of them depends on artifacts built in another job, each of them in turn builds the entire chain of libosmocore up to that build's target project. Upon a libosmocore *code change*, it makes sense to trigger downstream builds, but not when caused by a timer or for other jenkins trigger or user reasons. I vaguely remember discussing this before, but now I realize we could solve this and have less redundant builds: Do not configure libosmocore to trigger downstream builds of master-libosmo-abis (and so on), but instead trigger master-libosmo-abis upon each libosmocore patch merge. That can be done by adding a "Gerrit trigger" on the master-libosmo-abis build job config, making a patch-merge to the gerrit libosmocore.git cause a master-libosmo-abis build. At that point, jenkins timers no longer cause downstream builds, but merges to master on upstream git repositories do still cause builds. (maybe there is also a normal git SCM way that doesn't require gerrit.osmocom.org?) For projects like osmo-msc, we would add multiple projects as upstream git repositories, like libosmocore, libosmo-abis, libosmo-netif, ... , osmo-iuh, osmo-mgw, ... Basically all of the projects with more than one dependency get retriggered redundantly every night, some doing their entire build matrix over several times for no good reason. I'm not sure that it's really worth the effort, but I thought I'd mention it since seeing so many redundant builds on various osmo source trees at night seems avoidable stupidity. Should someone spend cycles to implement this? ~N

3 years, 9 months

1
0
0 0

osmo-bts-trx + osmo-trx: dummy burst filling

by Vadim Yanitskiy

Hi all, as some of you may know, I am currently working on baseband frequency hopping implementation for osmo-bts-trx (see OS#4546). I've already submitted more or less final implementation to Gerrit [1], and in general it works fine [2]. The idea is quite simple: you have several RF carriers (transceivers) with fixed frequencies, so on hopping timeslots osmo-bts-trx distributes bursts between them according to the configured hopping sequence. However, when it comes to hopping timeslots on C0, the burst distribution algorithm gets a bit more complicated. The problem is that on C0 the BTS has to maintain constant power level, even if there is nothing to transmit, so the phones can detect it reliably during the power scan. This is achieved by sending dummy bursts. When frequency hopping is not in use, the scheduler in osmo-bts-trx sends a dummy burst immediately. When it is in use, sending dummy bursts needs to be postponed until all transceivers are processed, because some other transceiver might need to send a normal burst on the frequency of C0, and there would be no need to send a dummy burst in that case. So I came up with [3] (any comments regarding potential optimizations and further improvements are welcome). While working on this, I stumbled upon the burst filling feature in osmo-trx [4], that is disabled by default. If enabled, osmo-trx would be sending dummy bursts itself, so there is no need to send them from osmo-bts-trx, and thus no need to complicate the burst distribution logic. I am now wondering why don't we enable this feature by default? From the VTY reference: > Send a dummy burst when there is nothing to send on C0 (TRX0) and > empty burst on other channels. Use for OpenBTS compatibility only, > don’t use with OsmoBTS as it breaks encryption. it's unclear how sending dummy bursts would break encryption... [1] https://gerrit.osmocom.org/c/osmo-bts/+/19030 [2] https://www.youtube.com/watch?v=tGMVNYo9s7E [3] https://gerrit.osmocom.org/c/osmo-bts/+/19029 [4] http://ftp.osmocom.org/docs/latest/osmotrx-vty-reference.pdf#subsection.1.9… Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

3 years, 10 months

2
1
0 0

libosmocore / osmo_fd / select() / performance

by Harald Welte

Hi all, it has been coming up in at least two contexts recently: Select is showing up a lot in system-level profiles particularly on osmo-bts. This is hardly surprising, as select() is not particularly known for efficiency. It was used back in 2008 for the *BSC*, in a context where we were talking about 1-10 BTS with each no more than 1-2 TRX. Now we are using the same osmo_fd abstraction on the BTS, where the number of messages per second is much higher, particularly in osmo-bts-trx with its TRXD protocol, and particularly with higher number of TRX per BTS. There is an older feature request to introduce epoll support in https://osmocom.org/issues/1579 but unfortunately nobody has been finding the resources and/or time to implement it. Meanwhile, 1.5 years ago, the Linux kernel received a new sub-system called io_uring, which I would personally love to support. Here are some pointers for those who are interested: https://lwn.net/Articles/776703/ https://kernel.dk/io_uring.pdf https://lwn.net/Kernel/Index/#io_uring As unfortunately not everyone is using half-way recent kernels, we will likely have to fall back to epoll or something like that. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 years, 10 months

1
0
0 0

Osmocom scheduled outage on *2020-07-19 9am CEST*

by Harald Welte

There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on *Sunday, July 19 2020*, starting about 9am CEST. The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit. In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law. Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate. In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 years, 10 months

1
1
0 0

OsmoCBC Status?

by Nick Jones

Hi all, Just wondering what the status of OsmoCBC is? I started compiling from source, but I couldn't find any docs on interfacing with it other than that it's via a HTTP REST API, If there aren't any docs are there packet captures or examples I can work from that'd be quicker than trying to reverse it from the source code, Happy to contribute some docs once I work it out, Cheers, Nick

3 years, 11 months

2
2
0 0

Ericsson RBS 6402

by Caleb Pal

Good Afternoon, I recently acquired a NIB Ericsson RBS 6402. The specific model number appears to be KRD 901 060/83. I see that the osmocom crew has integrated this RBS with NextEPC at the 2019 CCC Camp event. I have used other vendors eNodeB's with NextEPC, and would like to try the RBS with it as well. So far, I have booted up the RBS, and set my machine with a 10.1.1.1/24 IP address. The limited documentation I found online said the RBS should respond to http at 10.1.1.11, at which point an XML site configuration file can be uploaded. I see arp responses in WireShark from 10.1.1.11, but cannot ping, or access http @ 10.1.1.11. If I place the RBS on a network with a DHCP server, it obtains an address, but in the same state, no response to pings, and no http access. Also tried ssh on the standard port, with no response. I see the wiki has information that appears to be output from a terminal. Is that SSH or serial to the board itself? I do have a rasbpi available on the network with a GPS/1PPS source for timing. Is this as simple as setting opt 042 in the DHCP server that the RBS will use? Any guidance is appreciated! v/r, Caleb

3 years, 11 months

1
0
0 0

shutdown FSM breaks ttcn3-bsc-test

by Neels Hofmeyr

dear Pau, please fix either osmo-bts or ttcn3-bsc-tests so that running ttcn3-bsc-tests works again. The failure I get for each and every BSC test: Verdict: fail reason: "Timeout waiting for BTS0 oml-connection-state ""degraded" When I downgrade osmo-bts to 580a27e97c3f0e139dfd7b0c10de24463d4b5294 (just before the shutdown FSM was introduced), the tests work again. (I didn't bisect, just picked that commit.) This failure is particularly harmful now because we're currently struggling with quite a couple of other reasons that cause the ttcn3-bsc-tests to fail. So when we fix those, jenkins won't show the fix, but yet a different error. I'm reluctant to revert your patches now, hopefully you can find a fix quickly to move forward instead. BTW, I also have introduced another new segfault in osmo-bsc myself, testing the fix now and merging it directly when successful, so that we don't all go insane. ~N

3 years, 11 months

2
1
0 0

Introducing E1 / Abis support to osmo-mgw

by Harald Welte

Hi Philipp (and lurkers on this list), I've just pushed an update to the @laforge/trau@ branch of libosmo-abis, which contains the new code modules for E1 / TRAU usage, and also a small test program and test data. The test program takes a raw binary dump created from an E1 timeslot with TRAU frames captured of a BS-11 and converts that to RTP packets. You can feed those RTP packets into osmo-gapk to play them back. The audio is clear, there are just a few seconds of quiet at the beginning before anything is audible. The patches also add an "I460" mode to e1_input. So from the osmo-mgw side, I think we need to * link against libosmo-abis and call e1inp_init + e1inp_vty_init() * use existing VTY code to configure E1 line numbers / drivers / ports * call e1inp_ts_config_i460() on every timeslot we want to use (this should *not* happen on all timeslots, as some of them are used for signalling by the BSC) * call osmo_i460_subchan_add() / osmo_i460_subchan_del() for each i.460 sub-slot we want to use * build the processing chain like in libosmo-abis/contrib/trau2rtp/trau2rtp.c via i460 -> trau_sync -> osmo_trau_frame_decode_16k/osmo_trau_frame_decode_8k -> osmo_trau2rtp I believe this should be at a stage where it can be integrated into osmo-mgw. The API may not be 100% stable yet, but it shouldn't change completely. The main missing bits are: * allow selection of sync pattern in trau_sync.c (or auto-detect?) * handling of T-bits for alignment of air-interface timing with downlink TRAU frame timing I will next be hacking on a small tool that will speak the 'osmo-e1d' protocol but use binary capture files that are looped over and over again. This way you should be able to use libosmo-abis e1_input without any physical card and still get TRAU frame data. At a lower priority, I'd like to look into support for HRv1 and AMR TRAU frames on 16k sub-slots. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 years, 11 months

1
0
0 0

updated videos / presentations on setting up Osmocom CNI

by Harald Welte

Hi! I just realized that since OsmoCon was discontinued after 2018 didn't result in sufficient turn-out, and only the 2017 incarnation contained some entry-level talks, we actually only have introductory level presentations / videos about a setup that still covers OsmoNITB. (https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmo…) This may or may not be a reason why some people still want to set up OsmoNITB in 2020. While our wiki and user manuals all have deprecated OsmoNITB years ago, people who only look for videos might be mislead. Also, I'm sure that several other presentation (like the one about 3G / osmo-iuh before the CNI split) would similarly benefit from an update. So I think we should try to create/update some slide decks and record related lectures / tutorials at some point this year. I wouldn't bother setting up a virtual conference or some kind of remote interaction at this point. Recording some talks and/or screencasts allows us to create and release them one-by-one. I would like to get started by collecting a list of topics at https://osmocom.org/issues/4578 before we start to actually work on the presentations. One question is also how to record, but let's first work on the content before we worry about recording and publication. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 years, 12 months

1
0
0 0

ttcn3-bsc-test: LCLS test cases broken since build #987 (May 29)

by Vadim Yanitskiy

Hi all, as was noticed during the weekly review, all TTCN-3 BSC test cases from LCLS group are failing since build #987 (May 29) [1], so I am trying to investigate this. Until now I thought that it's somehow related to my IPA/RSL refactoring patch set, so I spent half of a day reading the code of those test cases and trying to figure out what could be the reason. But then I checked ttcn3-bsc-test-latest [2]. I should have done this first, of course. Magically all LCLS test cases are green there. So I assume that it's not related to the recent IPA/RSL changes, and most likely caused by recent changes to osmo-bsc and/or libosmo-*. I already tried to downgrade osmo-bsc to v1.6.0 (Jan 3) with no luck. If anyone was working on something related to RSL, MGCP or LCLS, please let me know - this might help to find the problem faster. Thanks! [1] https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/ [2] https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-latest/ -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

3 years, 12 months

1
1
0 0

Osmo-SIP-Connector Version 6

by Sonny Lafuente

Hi Community, Does anyone here tried to upgrade the your working OSMO environment to its latest version? I have the experience where I upgraded my working osmo to the latest version and I have encountering some problem between the connection of osmo-nitb and osmo-sip-connector. For the latest sip connector update it will communicate the connection going to osmo-msc. Since I don’t use the osmo-msc instead I am using the osmo-nitb for the standalone project. Below is the error I have experiencing right now in the osmo-sip-connector and osmo-nitb. SIP Connector Logs: <0001> mncc.c:845 Incompatible version(5) expected 6 <0001> mncc.c:936 Reconnected to /tmp/msc_mncc <0001> mncc.c:841 Got hello message version 5 <0001> mncc.c:845 Incompatible version(5) expected 6 <0001> mncc.c:936 Reconnected to /tmp/msc_mncc <0001> mncc.c:841 Got hello message version 5 <0001> mncc.c:845 Incompatible version(5) expected 6 OSMO-NITB Logs: Fri May 29 13:13:16 2020 <0006> mncc_sock.c:84 MNCC Socket has LOST connection Fri May 29 13:13:16 2020 <0001> gsm_04_08.c:463 Clearing all currently active transactions!!! Fri May 29 13:13:21 2020 <0006> mncc_sock.c:271 MNCC Socket has connection with external call control application Fri May 29 13:13:21 2020 <0006> mncc_sock.c:84 MNCC Socket has LOST connection Fri May 29 13:13:21 2020 <0001> gsm_04_08.c:463 Clearing all currently active transactions!!! Here are the configuration file of osmo-nitb and osmo-sip-connector and how we run the command. SIP Connector: Command to run: ./osmo-sip-connector -c ~/osmo-sip-connector.cfg Config File: # sip local 192.168.1.166 5062 remote 192.168.1.166 5060 sofia-sip log-level 2 mncc socket-path /tmp/msc_mncc app OSMO NITB: Command to run: ./osmo-nitb -C -c ~/osmo-nitb.cfg -T -P -l /home/hlr.sqlite3 -M /tmp/msc_mncc Config File: line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive network network country code 94 mobile network code 1 short name 1 long name 1 auth policy accept-all authorized-regexp .* location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3109 1 timer t3105 1 timer t3113 60 timer t3103 1 timer t3122 10 timer t3101 10 dyn_ts_allow_tch_f 0 subscriber-keep-in-ram 1 bts 0 type sysmobts band GSM900 cell_identity 1 location_area_code 1 base_station_id_code 63 ms max power 0 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 radio-link-timeout 32 channel allocator descending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden ip.access unit_id 1000 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr hr efr amr amr tch-h modes 0 amr tch-h start-mode auto gprs mode gprs gprs 11bit_rach_support_for_egprs 0 gprs routing area 1 gprs network-control-order nc0 gprs cell bvci 2 gprs cell timer blocking-timer 3 gprs cell timer blocking-retries 3 gprs cell timer unblocking-retries 3 gprs cell timer reset-timer 3 gprs cell timer reset-retries 3 gprs cell timer suspend-timer 10 gprs cell timer suspend-retries 3 gprs cell timer resume-timer 10 gprs cell timer resume-retries 3 gprs cell timer capability-update-timer 10 gprs cell timer capability-update-retries 3 gprs nsei 101 gprs ns timer tns-block 3 gprs ns timer tns-block-retries 3 gprs ns timer tns-reset 3 gprs ns timer tns-reset-retries 3 gprs ns timer tns-test 30 gprs ns timer tns-alive 3 gprs ns timer tns-alive-retries 10 gprs nsvc 0 nsvci 101 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 127.0.0.2 gprs nsvc 1 nsvci 0 gprs nsvc 1 local udp port 0 gprs nsvc 1 remote udp port 0 gprs nsvc 1 remote ip 0.0.0.0 no force-combined-si trx 0 rf_locked 0 arfcn 74 nominal power 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 trx 1 rf_locked 0 arfcn 65 nominal power 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 mncc-int default-codec tch-f fr default-codec tch-h amr nitb subscriber-create-on-demand subscriber-create-on-demand random 100000 199999 no assign-tmsi smpp local-tcp-ip 127.0.0.1 2776 system-id password policy closed smpp-first esme root password password default-route Thank you. Sonny

4 years

4
5
0 0

How to 'POWERON' the osmo-trx

by cruise

hello: I installed the osmo-NITB on ubuntu18.04, including osmo-trx,osmo-bts,and openbsc. The following is the print messages when these three applications start up. *1.osmo-trx* $ sudo osmo-trx-uhd -C osmo-trx-usrp_b200.cfg Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Tue May 5 12:36:27 2020 DLGLOBAL <0007> telnet_interface.c:104 Available via telnet 127.0.0.1 4237 Tue May 5 12:36:27 2020 DLCTRL <000e> control_if.c:911 CTRL at 127.0.0.1 4236 Tue May 5 12:36:27 2020 DMAIN <0000> osmo-trx.cpp:484 [tid=139758118945664] Config Settings Log Level............... 0 Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM BTS Address......... 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ 0 Extended RACH support... 0 Reference............... 1 Filler Burst Type....... Empty bursts Filler Burst TSC........ 0 Filler Burst RACH Delay. 0 Multi-Carrier........... 0 Tuning offset........... 0 RSSI to dBm offset...... 28 Swap channels........... 0 Tx Antennas............. '<default>' Rx Antennas............. '<default>' Tue May 5 12:36:27 2020 DMAIN <0000> osmo-trx.cpp:438 [tid=139758118945664] Setting SCHED_RR priority 18 Tue May 5 12:36:27 2020 DDEVDRV <0006> log.cpp:460 [tid=139758008424192] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.14.0.HEAD-0-g6875d061 Tue May 5 12:36:27 2020 DDEV <0005> UHDDevice.cpp:470 [tid=139758118945664] Using discovered UHD device type=b200,name=Lab_B210,serial=86680AA,product=B210 Tue May 5 12:36:28 2020 DDEVDRV <0006> b200_impl.cpp:386 [tid=139758008424192] [B200] Detected Device: B210 Tue May 5 12:36:29 2020 DDEVDRV <0006> b200_iface.cpp:441 [tid=139758008424192] [B200] Loading FPGA image: /home/cruise/openBSC/osmo-trx/usrp_b210_fpga.bin... Tue May 5 12:36:45 2020 DDEVDRV <0006> b200_impl.cpp:433 [tid=139758008424192] [B200] Operating over USB 3. Tue May 5 12:36:45 2020 DDEVDRV <0006> b200_impl.cpp:484 [tid=139758008424192] [B200] Detecting internal GPSDO.... Tue May 5 12:36:46 2020 DDEVDRV <0006> gps_ctrl.cpp:253 [tid=139758008424192] [GPS] No GPSDO found Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:587 [tid=139758008424192] [B200] Initialize CODEC control... Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:650 [tid=139758008424192] [B200] Initialize Radio control... Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:957 [tid=139758008424192] [B200] Performing register loopback test... Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:966 [tid=139758008424192] [B200] Register loopback test passed Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:957 [tid=139758008424192] [B200] Performing register loopback test... Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:966 [tid=139758008424192] [B200] Register loopback test passed Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:758 [tid=139758008424192] [B200] Setting master clock rate selection to 'automatic'. Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:1013 [tid=139758008424192] [B200] Asking for clock rate 16.000000 MHz... Tue May 5 12:36:46 2020 DDEVDRV <0006> b200_impl.cpp:1024 [tid=139758008424192] [B200] Actually got clock rate 16.000000 MHz. Tue May 5 12:36:47 2020 DMAIN <0000> UHDDevice.cpp:211 [tid=139758118945664] Antennas configured successfully Tue May 5 12:36:47 2020 DDEVDRV <0006> multi_usrp.cpp:502 [tid=139758008424192] [MULTI_USRP] Setting master clock rate selection to 'manual'. Tue May 5 12:36:47 2020 DDEVDRV <0006> b200_impl.cpp:1013 [tid=139758008424192] [B200] Asking for clock rate 26.000000 MHz... Tue May 5 12:36:47 2020 DDEVDRV <0006> b200_impl.cpp:1024 [tid=139758008424192] [B200] Actually got clock rate 26.000000 MHz. Tue May 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:275 [tid=139758118945664] Rates configured for B210 4 SPS Tue May 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:235 [tid=139758118945664] Supported Tx gain range [0; 89.75] Tue May 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:240 [tid=139758118945664] Supported Rx gain range [0; 76] Tue May 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:244 [tid=139758118945664] Default setting Tx gain for channel 0 to 44.875 Tue May 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:251 [tid=139758118945664] Default setting Rx gain for channel 0 to 38 Tue May 5 12:36:47 2020 DDEV <0005> UHDDevice.cpp:569 [tid=139758118945664] Device configuration: Single USRP: Device: B-Series Device Mboard 0: B210 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: FE-RX2 TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: FE-TX2 Tue May 5 12:36:47 2020 DMAIN <0000> osmo-trx.cpp:532 [tid=139758118945664] -- Transceiver active with 1 channel(s) *_/when the osmo-bts-trx launched later, the following messages will arise, shows that the osmo-trx received the 'POWEROFF' command and feed back the 'RESPONSE' to osmo-bts-trx./_* Tue May 5 12:42:44 2020 DTRXCTRL <0002> Transceiver.cpp:832 [tid=139758118945664][chan=0] command is 'POWEROFF' Tue May 5 12:42:44 2020 DTRXCTRL <0002> Transceiver.cpp:977 [tid=139758118945664][chan=0] response is 'RSP POWEROFF 0' ** *_/POWERON command was not launched. and the USRP TX/RX LED was not lighted./_* *2.osmo-bts-trx* $ sudo osmo-bts-trx ((*)) | / \ OsmoBTS <0017> control_if.c:911 CTRL at 127.0.0.1 4238 <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 <0012> input/ipaccess.c:1024 enabling ipaccess BTS mode, OML connecting to 192.168.122.1:3002 <000b> trx_if.c:1174 phy0.0: Open transceiver ** *_/About one minutes later, the osmo-bts-trx will exit automatically, and the following messages was printed./_* <0012> e1_input.c:243 abis_sendmsg: msg->dst == NULL: 0c 12 01 90 0f 00 c8 <0012> e1_input.c:243 abis_sendmsg: msg->dst == NULL: 0c 12 01 88 12 06 00 00 00 00 00 00 <000d> abis.c:143 Signalling link down <0001> bts.c:293 Shutting down BTS 0, Reason Abis close Shutdown timer expired *3. osmo-nitb* $ sudo osmo-nitb -c osmo-nitb-ipa.cfg <001e> telnet_interface.c:104 Available via telnet 127.0.0.1 4242 <0020> input/ipaccess.c:985 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports <0025> control_if.c:911 CTRL at 127.0.0.1 4249 DB: Database initialized. DB: Database prepared. In a word, the hardware USRP TX/RX LED has not been lighted, it seems not work. How to poweron it?

4 years

4
6
0 0

DGSM merge: need feedback on open questions

by Neels Hofmeyr

Hi all, we need to wrap up the DGSM work and get it to a state that can be merged to master. There are still open issues that I am not sure how to solve, which I've mentioned on some occasions, but it seems to not have been loud enough. I would easily choose one way, but am not sure about others' opinions. (1) One open point is the GSUP peer identification. I've added a comment explaining it in https://gerrit.osmocom.org/c/osmo-hlr/+/16459/9 Me personally, I would strip down basically all of that complexity again and go with the simplest solution, a nul terminated size limited char string for GSUP peer id. The patch became what it is because vague requirements were thrown in the mix and I tried to accomodate them, and now it ended up being a rather ugly shim around a simple char string, really. (2) Another open question is the freeing behavior in osmo_gsup_req (for proper async handling of DGSM, and to ensure proper GSUP responses). I've added a comment explaining that in https://gerrit.osmocom.org/c/osmo-hlr/+/16205/29 The gist for both issues is that I could write patches that would have a large ripple effect throug many files and follow-up patches, but if we again disagree on the outcome, the work would multiply. So, DGSM works and is ready, except that we need to agree on what will be accepted by review. I need opinions to be able to complete this (or possibly a "go" to do whatever I think is right and merge that). Thanks! ~N

4 years, 1 month

3
4
0 0

POWEROFF after the osmo-NITB has been installed

by cruise

Hello: I installed the osmo-NITB on ubuntu18.04, including osmo-trx,osmo-bts,and openbsc. I run these three applications in three terminals successively, it seems ok, but the tx/rx leds on usrp-b210 hardware platform are not lighted, and the print message in the osmo-trx terminal shows : Thu Apr 30 15:28:28 2020 DTRXCTRL <0002> Transceiver.cpp:832 [tid=139871716352896][chan=0] command is 'POWEROFF' Thu Apr 30 15:28:28 2020 DTRXCTRL <0002> Transceiver.cpp:977 [tid=139871716352896][chan=0] response is 'RSP POWEROFF 0' I try to send some commands on another terminal which launch a telnet session which connects to the osmo-bts control interface(port number is 4238) , but it not working. what can i do next? thanks a lot.

4 years, 1 month

2
1
0 0

version problem of libosmocore during installing osmoTRX

by cruise

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

4 years, 1 month

2
1
0 0

Docker containers.

by Andrew Back

Appreciate that the Osmocom Docker configurations exist principally for automated testing and here it may not make sense, but I wondered if builds are published to a registry? The Makefile in the make project located in the docker-playground repo sets docker.io as registry and has a target for docker push. Also see OBS Release.key files in project sub-directories, but couldn't find container builds being published anywhere. Was hoping I could just pull containers for the latest project versions, without cloning and building the containers in docker-playground. Also saw the comments from 2017 on Docker shortcomings and assuming SCTP works OK now in Docker networking? Regards, Andrew

4 years, 1 month

2
5
0 0

GSUP client

by Reza Hosseini

Dear Mr. Welte, In order to be more familiar with the further development of the osmo-euse file, I need to know which libraries and which programming style I should use to be on the right track. Is it possible to provide me please the some lines of your code which is sending the USSD code via the GSUP client to hlr and called up data from OSMO-HLR? I need this for my master's thesis (Education Purpose), so I don't need a license for it. Many thanks for your consideration, Reza

4 years, 1 month

2
1
0 0

Fwd: OSMOCOM TRX_BTS_BSC Connection Issue

by Aalto Koskinen

Hi, I looked at the forum for answers before posting, but I unfortunately couldn't get answers to what I was looking for. I looked into particular https://www.mail-archive.com/openbsc@lists.osmocom.org/msg09819.html for solving my issue. Setup: USRP B210 as radio head. NITB modules as components for 2G Network and BTS-TRX and TRX-UHD modules. Issue: - TRX-UHD and BTS-TRX fail. NITB Module works. Components of NITB network are able to connect to each other. - I have the RSP POWEROFF message originating in log from TRX-UHD module and the BTS module is shuttiing down. - BTS connects via OML but fails to connect RSL. - As per the previous email archive, I wanted to login to VTY and check the logs, but, it logs out as the BTS module shuts down (I cannot connect and see what's happening). I looked through the configuration files and seem correct to me. Any suggestions would be appreciated on solving the issue. I am trying to create a test 2G OSMOCOM network. Logs are written below and configuration as attachments. Thanks for your help! *OSMO_BTS_TRX log:* systemd[1]: Started Osmocom osmo-bts for osmo-trx. osmo-bts-trx[23221]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238 osmo-bts-trx[23221]: <0010> telnet_interface.c:104 Available via telnet 127.0.0.1 4241 osmo-bts-trx[23221]: <0012> input/ipaccess.c:1024 enabling ipaccess BTS mode, OML connecting to 192.168.0.9:3002 osmo-bts-trx[23221]: <000b> trx_if.c:1174 phy0.0: Open transceiver osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: <000d> abis.c:142 Signalling link down osmo-bts-trx[23221]: <0001> bts.c:292 Shutting down BTS 0, Reason Abis close osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response from transceiver(CMD POWEROFF) osmo-bts-trx[23221]: Shutdown timer expired osmo-bts-trx[23221]: ((*)) osmo-bts-trx[23221]: | osmo-bts-trx[23221]: / \ OsmoBTS *OSMO_TRX_UHD log:* ubuntu-HP-EliteBook-8470p systemd[1]: Started Osmocom SDR BTS L1 Transceiver (UHD Backend). ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:21 2020 DLGLOBAL <0007> telnet_interface.c:104 Available via telnet 127.0.0.1 4237 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:21 2020 DLCTRL <000e> control_if.c:911 CTRL at 127.0.0.1 4236 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:21 2020 DMAIN <0000> osmo-trx.cpp:485 [tid=140554411180864] Config Settings ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Log Level............... 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Device args............. ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: TRX Base Port........... 5700 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: TRX Address............. 127.0.0.1 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: GSM BTS Address......... 127.0.0.1 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Channels................ 1 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Tx Samples-per-Symbol... 4 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Rx Samples-per-Symbol... 4 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: EDGE support............ 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Extended RACH support... 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Reference............... 1 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Filler Burst Type....... Empty bursts ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Filler Burst TSC........ 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Filler Burst RACH Delay. 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Multi-Carrier........... 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Tuning offset........... 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: RSSI to dBm offset...... 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Swap channels........... 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Tx Antennas............. '<default>' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Rx Antennas............. '<default>' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:21 2020 DMAIN <0000> osmo-trx.cpp:439 [tid=140554411180864] Setting SCHED_RR priority 18 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.14.1.1-release ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:21 2020 DDEV <0005> UHDDevice.cpp:470 [tid=140554411180864] Using discovered UHD device type=b200,name=MyB210,serial=31A92EA,product=B210 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:22 2020 DDEVDRV <0006> b200_impl.cpp:386 [tid=140554300024576] [B200] Detected Device: B210 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:22 2020 DDEVDRV <0006> b200_impl.cpp:433 [tid=140554300024576] [B200] Operating over USB 2. ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:22 2020 DDEVDRV <0006> b200_impl.cpp:587 [tid=140554300024576] [B200] Initialize CODEC control... huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:650 [tid=140554300024576] [B200] Initialize Radio control... huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:957 [tid=140554300024576] [B200] Performing register loopback test... huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:966 [tid=140554300024576] [B200] Register loopback test passed huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:957 [tid=140554300024576] [B200] Performing register loopback test... huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:966 [tid=140554300024576] [B200] Register loopback test passed huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:758 [tid=140554300024576] [B200] Setting master clock rate selection to 'automatic'. huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:1013 [tid=140554300024576] [B200] Asking for clock rate 16.000000 MHz... huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:1024 [tid=140554300024576] [B200] Actually got clock rate 16.000000 MHz. huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DMAIN <0000> UHDDevice.cpp:214 [tid=140554411180864] Antennas configured successfully huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> multi_usrp.cpp:502 [tid=140554300024576] [MULTI_USRP] Setting master clock rate selection to 'manual'. huhti 09 11:22:23 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:23 2020 DDEVDRV <0006> b200_impl.cpp:1013 [tid=140554300024576] [B200] Asking for clock rate 26.000000 MHz... ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DDEVDRV <0006> b200_impl.cpp:1024 [tid=140554300024576] [B200] Actually got clock rate 26.000000 MHz. ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DDEV <0005> UHDDevice.cpp:275 [tid=140554411180864] Rates configured for B210 4 SPS ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DDEV <0005> UHDDevice.cpp:235 [tid=140554411180864] Supported Tx gain range [0; 89.75] ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DDEV <0005> UHDDevice.cpp:240 [tid=140554411180864] Supported Rx gain range [0; 76] ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DDEV <0005> UHDDevice.cpp:244 [tid=140554411180864] Default setting Tx gain for channel 0 to 44.875 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DDEV <0005> UHDDevice.cpp:251 [tid=140554411180864] Default setting Rx gain for channel 0 to 38 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DDEV <0005> UHDDevice.cpp:569 [tid=140554411180864] Device configuration: Single USRP: ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Device: B-Series Device ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Mboard 0: B210 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: RX Channel: 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: RX DSP: 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: RX Dboard: A ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: RX Subdev: FE-RX2 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: TX Channel: 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: TX DSP: 0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: TX Dboard: A ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: TX Subdev: FE-TX2 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DMAIN <0000> Threads.cpp:119 [tid=140554180474624] Thread 140554180474624 (task 8317) set name: CtrlService0 ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DMAIN <0000> osmo-trx.cpp:533 [tid=140554411180864] -- Transceiver active with 1 channel(s) ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:24 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:28 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:28 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:33 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:33 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:38 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:38 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:43 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:43 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:49 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:49 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:54 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:54 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:59 2020 DTRXCTRL <0002> Transceiver.cpp:778 [tid=140554180474624][chan=0] command is 'POWEROFF' ubuntu-HP-EliteBook-8470p osmo-trx-uhd[8282]: Thu Apr 9 11:22:59 2020 DTRXCTRL <0002> Transceiver.cpp:923 [tid=140554180474624][chan=0] response is 'RSP POWEROFF 0'

4 years, 1 month

3
9
0 0

Asterisk - Osmosom connection issue

by Laurent Kza

Hi all, I am new to the use of the Osmocom project, it is indeed a very nice job. I am currently trying to set up a configuration with a Asterisk PBX server and I have 2 questions: 1/ RTP configuration The SIP part (sip-connector vs Asterisk connection) works well so far, the communication starts but with no audio. I noticed that the RTP flux is sent to localhost instead of my server address (set as remote in sip-connector.cfg) and I was wondering if there is any possibility to send the RTP flow to an address which is not localhost ? sip local 0.0.0.0 5069 remote 127.0.0.1 5060 2/ codec issue In a configuration where all the Osmocom servers (MSC, MGW, BSC…) and Asterisk are on the same machine, it got a message from my asterisk server, saying that no codec can be found to start a communication. By default, the wiki/manuals states that gsm has to be used but perhaps I am missing something in the BSC configuration, especially in the codec choice. <--- SIP read from UDP:10.184.10.162:5069 ---> INVITE sip:899@127.0.0.1:5060 SIP/2.0 Via: SIP/2.0/UDP 10.184.10.162:5069;rport;branch=z9hG4bKpe1UXZU1amUja Max-Forwards: 70 From: <sip:422@0.0.0.0:5069>;tag=vyQKX32r72ZyQ To: <sip:899@127.0.0.1:5060> Call-ID: cd65c5a0-fdbf-1238-51a9-000c29cfd753 CSeq: 949096397 INVITE Contact: <sip:10.184.10.162:5069> User-Agent: sofia-sip/1.12.11devel Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE Supported: timer, 100rel Content-Type: application/sdp Content-Length: 133 v=0 o=Osmocom 0 0 IN IP4 127.0.0.1 s=GSM Call c=IN IP4 127.0.0.1 t=0 0 m=audio 4016 RTP/AVP 3 a=rtpmap:3 GSM/8000 a=sendrecv <-------------> --- (13 headers 8 lines) --- Sending to 10.184.10.162:5069 (no NAT) Sending to 10.184.10.162:5069 (no NAT) Using INVITE request as basis request - cd65c5a0-fdbf-1238-51a9-000c29cfd753 No matching peer for '422' from '10.184.10.162:5069' == Using SIP RTP CoS mark 5 Got SDP version 0 and unique parts [Osmocom 0 IN IP4 127.0.0.1] Found RTP audio format 3 Found audio description format GSM for ID 3 [2020-04-20 17:38:19] NOTICE[14918][C-00000015]: chan_sip.c:10957 process_sdp: No compatible codecs, not accepting this offer! Thanks for your help Laurent

4 years, 1 month

2
1
0 0

GSUP client

by Reza Hosseini

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

4 years, 1 month

2
1
0 0

pcsc_scan not reading

by michael schumi

i am trying to read the sim card using sim reader but not able to read i used command pcsc_scan but its taking huge time for scanning and only scanning waiting for the first reader... like this please check whats the issue

4 years, 1 month

2
1
0 0

pysim contributions

by Sebastián Viviani

Hello, apologies for the generic question, but how can I contribute to the pysim project? I made a couple of fixes and added some stuff I needed for some tests, but looks like github rejects the pull requests, project is not listed in gerrit, there is no specific mail list, and the osmocom git repo rejects any push :-( Kind regards

4 years, 1 month

2
1
0 0

open source mobile communications in the context of search and rescue

by Philipp Borgers

Hi, we are looking for some help creating open source mobile communication infrastructure in the context of a search and rescue (SAR) mission at sea. We would like to use the osmocom stack as sensing and communication infrastructure at sea. How precise is the timing advance for localization? Neels mentioned that "modern" mobile stations equipped with a GPS receiver can report the location to the operator. Could you point me to the right standard? Is there any reliable and open source tooling to determine the direction of the signal with multiple receivers (e.g. SDRs) in close proximity? You can find out more about the project here: https://www.hs-augsburg.de/searchwing/ Sorry for the mostly German content. Thanks for your help! Best Regards Philipp Borgers

4 years, 1 month

2
1
0 0

debug call failure on new nitb setup please?

by Craig Comstock

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

4 years, 1 month

4
4
0 0

Hello

by Reza Hosseini

Dear Developers, I am trying to build the osmo-euse-demo on the Osmocom VM, executing the following commands: #Install required development libraries: sudo apt-get install libosmo-gsup-client-dev #Get the source code and a missing header file wget https://raw.githubusercontent.com/osmocom/osmo-hlr/master/src/osmo-euse-dem… wget https://raw.githubusercontent.com/osmocom/osmo-hlr/master/include/osmocom/h… mkdir -p osmocom/hlr/ mv logging.h osmocom/hlr/ #Compile source gcc -I. -o osmo-euse-demo osmo-euse-demo.c -losmocore -losmo-gsup-client -losmogsm -ltalloc #Run ./osmo-euse-demo But i am now facing this error : E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it? Can you please tell me what is the reasin behind this error !? And how can i solve it ? Many thanks for your consideraion, Reza

4 years, 1 month

2
1
0 0

OsmoSTP connection

by Igor Kim

Hello dears! I try to connect 2 STPs to each other via Sigtran M3UA protocol. But I don't understand, why my connection is fault. Could you please check my configuration? STP1 STP2 point-code 0.12.4 point-code 0.12.4 port 2905 port 2906 IP 172.18.141.1 IP 172.18.142.2 Me configuration is: STP1 cs7 instance 1 network-indicator reserved point-code 0.12.4 asp stp2 2906 2905 m3ua local-ip 172.18.141.1 remote-ip 172.18.142.2 role asp sctp-role client as stp2 m3ua asp stp2 traffic-mode override routing-key 0 0.25.0 route-table system STP2 cs7 instance 1 network-indicator reserved point-code 0.25.0 asp stp1 2905 2906 m3ua local-ip 172.18.142.2 remote-ip 172.18.141.1 role sg as stp1 m3ua asp stp1 traffic-mode override routing-key 0 0.12.4 route-table system listen m3ua 2906 accept-asp-connections dynamic-permitted Thanks in advance!

4 years, 1 month

2
1
0 0

“osmo-euse-demo.c“

by Reza Hosseini

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

4 years, 1 month

2
1
0 0

OpenMSC: validity_minutes not set when sms is from SMPP + SMS not added in pending list.

by Denis Artru

Hello all, 1) When an SMS is received from SMPP, the validity_minutes is not set (value 0). The consequence is that email is deleted from database too early in case of failure. In file: src/libmsc/smpp_openbsc.c function submit_to_sms translate convert from submit_sm_t to gsm_sms. But some field of gsm_sms are not filled, in particularly validity_minutes. I think that validity_minutes must be computed from submit_sm_t.schedule_delivery_time or submit_sm_t.validity_period. Sorry I don’t know exactly content of these values. 2) In file src/libmsc/sms_queue.c function sub_ready_for_sm, before sending SMS using the function gsm411_send_sms, the SMS is not place in pending list. Like it is done in functions sms_submit_pending and sms_send_next. The consequence is that when handset do a Location Updating Request, only one SMS is send if they are many SMS for this subscribers. Because in function sms_sms_cb call of pending = sms_find_pending(network->sms_queue, sig_sms->sms->id); will always return 0. I try the following fix and was working but I don’t know if it possible that an SMS was already in the list? + struct gsm_sms_queue *smsq = net->sms_queue; + struct gsm_sms_pending *pendingSms = sms_pending_from(smsq, sms); + if (!pendingSms) { + LOGP(DLSMS, LOGL_ERROR, + "Failed to create pending SMS entry.\n"); + sms_free(sms); + return 0; + } + llist_add_tail(&pendingSms->entry, &smsq->pending_sms); gsm411_send_sms(net, vsub, sms); return 0; } Thanks you, Denis

4 years, 1 month

2
2
0 0

GSUP protocol

by Reza Hosseini

Dear Osmocom developpers, I already installed osmocomnitb and now i am trying to Show the core Network vulnerablites in Wireshark. In order to use existing Osmocom libraries for GSUP protocol processing and USSD coding / decoding, I have to use the file "osmo-hlr / src / osmo-euse-demo.c" in my osmocom directory, the " http: // git "contains. osmocom.org/osmo-hlr/tree/src/osmo-euse-demo.c "Pool. But i don’t find the following libarries to patch it. #include <string.h> #include <stdio.h> #include <errno.h> #include <signal.h> #include <osmocom/core/msgb.h> #include <osmocom/core/select.h> #include <osmocom/core/application.h> #include <osmocom/core/utils.h> #include <osmocom/core/logging.h> #include <osmocom/gsm/gsup.h> #include <osmocom/gsm/gsm0480.h> #include <osmocom/gsm/protocol/gsm_04_80.h> #include <osmocom/gsupclient/gsup_client.h> #include <osmocom/hlr/logging.h> How can i have Access to the .exe (already maked) of this library. Kind regads, Reza

4 years, 1 month

1
0
0 0

New Mobile Phone Models - Latching Issue using OSMO-NITB - Connection Drops approx after 3 Minutes

by Ron

Hi Community, Does anyone experiences, in newer phone models, that after a successful latched to OSMO-NITB, it will dropped its connection in a few minutes? We have experienced this issue to the following mobile phone models: 1. iPhone X - Software Version - 13.3 (Connection drops approximately after 3 minutes) 2. Samsung S10 (Connection drops after 1 - 3 minutes) 3. Samsung Note 9 Best Regards, Ron Menez

4 years, 2 months

2
1
0 0

Use of anytype in Osmocom TTCN-3 tests / TITAN

by Harald Welte

Hi Vadim, 22:22 < fixeria> LaF0rge: oh, we already have 'template anytype' in pcu/PCUIF_RAW_Components.ttcn 22:23 < fixeria> ... and that's my code :P 22:26 < fixeria> yay, it even compiles 22:39 < fixeria> but does not work as expected: "error: Type mismatch: a value or template of type `(a)Osmocom_Types.anytype' was expected instead of `integer'" 22:41 < fixeria> I am testing against uint8_t which is defined exactly in Osmocom_Types :/ 22:52 < fixeria> LaF0rge: pespin_: https://pastebin.com/EL9JUqq9 Please see https://www.eclipse.org/forums/index.php?t=msg&th=1074288&goto=1721710&#msg… for how to use anytype in TITAN So if I modify the last line of Osmocom_Types.ttcn with your patch from https://pastebin.com/EL9JUqq9 attached to this: } with { encode "RAW"; variant "FIELDORDER(msb)" extension "anytype OCT1" } The errors about the non-existant OCT1 field in anytype are gone. This is of course not nice, but maybe a work-around to explicitly list those types at the end for now? Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 years, 2 months

2
1
0 0

D-GSM merge / open question on GT vs. IPA name

by Harald Welte

Hi Neels, some week[s] ago, you mentioned that the D-GSM merge is blocked around the question on how the Global Title vs. IPA-name is to be resolved. Sorry for not getting back any sooner, but I am simply not finding the required amount of time to investigate this topic at the moment. My personal opinion is that it should be a binary blob (buffer + length) and nobody should make any assumptions about the contents. This way we can store whatever we want in it, and I believe we're increasing possible use cases where our HLR would have to work with "stateless" translators between GSUP and MAP. After all, let's say we receive a LU from a subscriber roaming in MAP-land, then that request arrives with the GT of the MSC/VLR. If we can natively "digest" such values, then the translator would not require any state beyond the currently processed transaction (LU/ISD). If we can not, then the translator would have to keep long-term state such as tables to map MAP-GT to IPA name or the like. And that's of course more effort there, and volatile state that you'd need to synchronize in case of high availability or fail-over scenarios, etc. I of course also know none of this is any current use case that any of the sysmocom customers is funding sysmocom (and hence you) to spend time on. So in the end, I'll leave it to you to decide. If you think the effort for becoming "buffer+length" aware is relatively minimal (let's say up to two days?) then by all means, implement that. If you think it's more work, then please go for the faster route of not considering non-NUL-terminated strings as identifiers for "GSUP" peers. In any case, I am happy to merge the D-GSM patch series once you think it should be merged. I put it in your trusted hands. After all, we had a tagged release only 7 commits ago (well, 5 of those are actually already D-GSM related) in osmo-hlr, and should there be any fall-out from the merge, we still have quite some time until some new tagged release will happen a few months down the road. Thanks! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 years, 3 months

1
0
0 0

Commercial MSs do not see the network

by Tomcsányi, Domonkos

Hi All, I have been dealing with a weird issue in the past couple of days. I needed to quickly check something about some phones, therefore I created an Osmocom CNI based 2G network. I have done this multiple times in the past even with OsmocomBB transceiver, however in the past some years I was not active in 2G, was more focused on 4G. I was very happy to see, that all familiar things I initially liked about osmocom are still in place/improved a lot (meaningful config files, simple VTY interface, a LOT more and better documentation). So the network is up and running fine, the setup consists of a laptop and a USRP B210 without GPSDO. Then I tried to attach some phones to it, and hit an issue: * Samsung S6, S7 - does not detect the network, even if I put in a SIM card that has previously been in a phone that was already attached * iPhone X - does not detect the network I first fiddled with the power settings, basically trying to turn it down a little bit (initially tx attenuation was at 0, so I turned it 10-20), because range is not needed, but I know distortion can happen when driving SDR HW to its max capacity. No change in the above. Then I turned quickly to gr-gsm and rtl-sdr to see if I'm transmitting properly, the network was detected and C0 decoded properly. Next I tried with a Motorola C115 (yeah, I still have some lying around :)), and it attached to the network without any issue. Finally something that works as expected, right? Last but not least I tried with a Nokia 4.2 phone, which also attached to the network immediately without any issue. So the bottom line is: what could cause this behavior? Is it possible that the USRP B210's accuracy is just not enough for newer phones? If yes how come the Nokia still attached, it is quite a recent phone with Qcomm chipset. I was also thinking if it is a Samsung vs Qualcomm thing, but then the iPhone should have at least detected the network. I tried with different SIM cards as well (not that it would make any difference...but I didn't have any better idea), and also with different bands and ARFCNs (900 and 1800). Antenna used is a VERT900. Configuration: unmodified standard config that came with the binary packages - except for MCC, MNC, rx gain, tx attenuation and max_power_red. I also tried to specify valid and also 'invalid' (unknown) MCC-MNC combinations to see if maybe newer Android/iOS only lists networks that advertise a known combination (again this would be very weird, but I just had no better ideas in the end). Anybody have any recent experience with COTS MSs and OsmoBTS(-TRX) based network? Any input is much appreciated, thanks. Cheers, Domi p.s. It is simply awesome to experience the power of opensource when dealing with 2G. Every step of the way above I was using software created and shared by you guys. It is a great feeling, had to share it :-).

4 years, 3 months

5
8
0 0

CBS + ETWS + CMAS + Limesdrmini

by Radiarisainana Sitraka

Hi, I follow this tutorial : Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications for doing CBS with limesdrmini but it doesn't run , is it due to that limesdrmini doesn't support the command telnet to osmo-bsc at port 4242, and enter something likeor i do something wrong. Chears, | | | | Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ... Redmine | | |

4 years, 3 months

2
1
0 0

Re: OpenBSC Digest, Vol 64, Issue 2

by Radiarisainana Sitraka

The commercial MS see the network and i could send sms and call with it. the Limesdrmini doesn't support CBS? Le mercredi 12 février 2020 à 20:57:52 UTC, openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org> a écrit : Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. CBS + Osmocom + LimeSDR-Mini (Radiarisainana Sitraka) 2. CBS + ETWS + CMAS + Limesdrmini (Radiarisainana Sitraka) 3. Re: Commercial MSs do not see the network (Tomcs?nyi) 4. Re: Commercial MSs do not see the network (Joachim Steiger) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Feb 2020 19:12:17 +0000 (UTC) From: Radiarisainana Sitraka <radiarisainanasitraka(a)yahoo.fr> To: "openbsc(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> Subject: CBS + Osmocom + LimeSDR-Mini Message-ID: <647375309.3679103.1581534737485(a)mail.yahoo.com> Content-Type: text/plain; charset="utf-8" Hello, I'm testing CBS LimeSDR-Mini with osmocom by following this Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications | | | | Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ... Redmine | | | h4. make sure your related BTS is configured to use a channel combination with CBCH For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg: network bts 0 trx 0 timeslot 0 phys_chan_config CCCH+SDCCH4+CBCH

4 years, 3 months

1
0
0 0

CBS + Osmocom + LimeSDR-Mini

by Radiarisainana Sitraka

Hello, I'm testing CBS LimeSDR-Mini with osmocom by following this Version 10 - History - Cell Broadcast - Cellular Network Infrastructure - Open Source Mobile Communications | | | | Version 10 - History - Cell Broadcast - Cellular Network Infrastructure ... Redmine | | | h4. make sure your related BTS is configured to use a channel combination with CBCH For using a combined CCCH with SDCCH/4 and CBCH you can use the following example snippet as part of osmo-bsc.cfg: network bts 0 trx 0 timeslot 0 phys_chan_config CCCH+SDCCH4+CBCH

4 years, 3 months

1
0
0 0

Feedback to GSUP Proxy Cache concept

by Oliver Smith

Hi Neels, > D-GSM proxy cache -- if you have the time, feedback on this design document would be appreciated: http://git.osmocom.org/osmo-hlr/commit/?h=neels/dgsm&id=8071c561405a031f204… > (when that commit is checked out, building osmo-hlr with manuals enabled should render the ladder diagrams in proxy_cache.adoc, which illustrate what I'm planning to implement) > (and disregard "(7) Skip the Insert Subscriber Data", as explained in the prose) I like that the key of the home HLR is not shared with the proxy HLRs. All in all, it sounds like a very smart solution! Some notes: * In the ladder diagrams, it shows that the AKAs are cached in both the MSC and the HLR. Why not just cache them in the HLR? * It might be a good idea to make AKA reuse optional with a VTY config option? * Potential use case: phone is home in village A, gets turned off, owner travels to village B with the phone, the link to village A is down. Phone gets turned on, then there will be no AKAs cached in village B's (proxy) HLR and the LU will fail. But there does not seem a way around this without sharing the keys (or without spaming other HLRs with AKAs for all subscribers in the HLR that they might use in the future, but that would just waste traffic). Regards, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://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

4 years, 4 months

2
1
0 0

build2.osmocom.org hardware replacement

by Harald Welte

Dear Osmocom community, in recent weeks (at least since mid-december) we've had some stability issues with build2.osmocom.org, the physical machine that runs the build2-deb8build-ansible and build2-deb9build-ansible LXCs used heavily by our jenkins. I've had to reset the machine, and now we finally have asked the hosting company to perform a hardware replacement. This has happened about 3 hours ago, and I hope the stability problems are gone now. Let me know if you still see anything odd related to build2. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 years, 4 months

1
0
0 0

Osmocom CNI release 202001

by Pau Espin Pedrol

Dear all, I'm pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. libosmocore 1.3.0 osmo-gsm-manuals 0.3.0 osmo-pcap 0.1.2 osmo-ggsn 1.5.0 libosmo-abis 0.8.0 libosmo-netif 0.7.0 libosmo-sccp 1.2.0 osmo-sip-connector 1.4.0 osmo-hlr 1.2.0 osmo-trx 1.2.0 osmo-bts 1.2.0 osmo-pcu 0.8.0 osmo-mgw 1.7.0 osmo-iuh 0.6.0 osmo-bsc 1.6.0 osmo-msc 1.6.0 osmo-sgsn 1.6.0 openbsc 1.3.2 Tags for related Openembedded meta layers have also been updated and are waiting to be merged, hopefully today, and will be available in branch 201705. Other related components such as libgtpnl or libsmpp34 had no development at all since last release cycle so they don't show up here. As a reminder, last release cycle was done around August 2019. Have fun, -- - Pau Espin Pedrol <pespin(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

4 years, 4 months

2
2
0 0

Osmo Bsc (Seperate CNI) with Asterisk network busy!!

by Garrett Allen

Hi All I've used osmo-bsc in non standalone mode ie seperate components and all works fine voice and sms work as should. However when introducing. sip connector with asterisk the handsets will not make voice calls they just constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms on raspbian 10 below is Asterisk config. Any help would be appreciated. Gar [GSM] type=friend host=127.0.0.1 dtmfmode=rfc2833 canreinvite=no disallow=all allow=gsm context=gsmsubscriber port=5062

4 years, 5 months

3
7
0 0

limesdr mini - osmo cni

by ah med

HI I just tried to use limesd mini with osmocom cni and i used this script to launch all the items : #!/bin/sh cmd="${1:-start}" set -ex systemctl $cmd <https://twitter.com/search?q=%24cmd&src=cashtag_click> osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn osmo-stp osmo-bsc osmo-hnbgw osmo-pcu osmo-trx-lms osmo-bts-trx everything seems work fine,only the osmo-trx-lms : osmo-trx-lms[7995]: Sun Dec 8 18:02:03 2019 DLMS <0003> LMSDevice.cpp:94 > [tid=140437169072832] Reference clock 40.00 MHz > osmo-trx-lms[7995]: Sun Dec 8 18:02:03 2019 DDEV <0002> > LMSDevice.cpp:192 [tid=140437169072832] Init LMS device > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002> LMSDevice.cpp:99 > [tid=140437169072832] Sample Rate: Min=100000 Max=3.072e+07 Step=0 > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002> > LMSDevice.cpp:228 [tid=140437169072832] Setting sample rate to 1.08333e+06 4 > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DDEV <0002> > LMSDevice.cpp:234 [tid=140437169072832] Sample Rate: Host=1.08333e+06 > RF=3.46667e+07 > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000> > LMSDevice.cpp:209 [tid=140437169072832] Antennas configured successfully > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000> Threads.cpp:117 > [tid=140437098583808] Thread 140437098583808 (task 8127) set name: > CtrlService0 > osmo-trx-lms[7995]: Sun Dec 8 18:02:04 2019 DMAIN <0000> > osmo-trx.cpp:528 [tid=140437169072832] -- Transceiver active with 1 > channel(s) > osmo-trx-lms[7995]: Sun Dec 8 18:02:05 2019 DTRXCTRL <0001> > Transceiver.cpp:773 [tid=140437098583808][chan=0] command is 'POWEROFF' > osmo-trx-lms[7995]: Sun Dec 8 18:02:05 2019 DTRXCTRL <0001> > Transceiver.cpp:918 [tid=140437098583808][chan=0] response is 'RSP POWEROFF > 0' > i am using the default .cfg files ! Thanks.

4 years, 5 months

3
15
0 0

distributed GSM / some thoughts

by Harald Welte

Hi Oliver, Neels, community, I had some comments on the D-GSM work that didn't really fit directly to the gerrit code review, and I thought I'd post it here. == DNS zone / .msisdn suffix === One question I had was regarding the use of the .{msisdn,imsi} TLD. I would argue it is probably besser to use something that fits within the existing DNS hierarchy without contesting IANA's authority on gTLDs. Historically, ETSI/3GPP made the mistake of using ".gprs" for resolving APNs on the GRX. This was later changed to something with 3gppnetwork.com or the like, hwere that domain would actually be registered by 3GPP with normal domain registrars, but without any publicly accessible zone records. This way the name is reserved in the public hierarchy and no risk of clashes. I'm not sure how much of a concern this is to us, given that our use case is much more niche than the GRX. However, the "cost" is probably rather small to change this to something like .{msisdn,imsi}.dgsm.osmocom.org ? Sure, the packets will get larger by a few bytes, but given all the other overhead I think it's not really going to have any impact? What are your thoughts on that? == MSISDN format == Another thought is whether or not there are any concerns regarding the MSISDN format. Historically, this is one of the weaknesses of OsmoMSC, inherited from the OpenBSC days where we just thought in terms of PBX extension numbers. In reality, a MSISDN consist of a TON (type of number), NPI (numbering plan indicator) and the related digits. IIRC, in the TON one can also specify if it's supposed to be national or international, i.e. if it's prefixed with the country code or not. It would be great to make sure that the format used in the mDNS queries is somewhat standardized, if not at least only by the documentation requiring that all queries should be done in fully qualfiied form with country code present. NPI is sort-of bogus as IMOH E.164 is the only one applicable for MSISDN. Any thoughts? == The use of 'age' vs. absolute timestamp == In my original D-GSM idas I always thought we'd send an absolute UTC timestamp when a given HLR/MSC has ever seen that subscriber. The idea here being that any rural GSM network will have some kind of GNSS recevier for clock stability in the BTS anyway, and one can hence assume that timestamps are synchronized. The advantage of a relative 'age' is obvious: You don't care about the absolute clock value being correct anymore. The potential downside is that propagation delay might matter. If you have a rather slow / loaded geostationary sattelite link from one village, but a faster terrestrial link from another village, the 'age' will be ambiguous while an absolute timesetamp wouldn't have that. Given that the delays we're talking about are probably all sub-second or maybe possible about 1s, it's probably not a problem. == GSUP keepalives / connection loss detection == In the presence of unreliable back-haul mesh between villages, the GSUP connection can also not be seen as reliable. We would expect to see TCP stalls due to packet loss, etc. Have you considered this in your implementation and/or done any testing based on simulated lossy networks to ensure we properly use either TCP keepalives or IPA application-level PING/PONG to detect lost connections and recover from such situations (by closing the old and re-establishing)? Unreliable networks can be easily simulated by Linux built-in 'tc netem' for providing configurable packet loss / latency / jitter. I also saw some comments / code related to "if a second connection using the same IPA ID arrives, we're screwed" (paraphrasing here). I would expect this not to be uncommon even if every MSC/HLR out there is configred correctly exactly because e.g .the remote MSC/HLR has already decided that the TCP/GSUP is dead and starts to reconnect by performing a local-end release, while the "local" MSC/HLR still thinks the old connection is alive. If the old connection "wins" (i.e. is preferred) I see potential trouble here. Situations like that probably warrant some carefully designed tests to create exactly those situations. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 years, 5 months

4
6
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC