June 2017 - OpenBSC - lists.osmocom.org

osmo-bts-trx fails frequently on osmo-gsm-tester

by Neels Hofmeyr

We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. I have run a tcpdump on the ntp port for the past days, and nothing is doing ntp besides the actual ntp service. Today I started ntp while an osmo-bts-trx run was active and what do you know, the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx shouldn't use wall clock time for precise timing needs. Besides that, I have no idea what could cause the clock skews, except maybe that the CPU or the USB are not fast enough?? I'm wondering, is there still such a thing as a separate linux realtime kernel? We will soon take to productive use another main unit which will be a cleanly installed OS. If we see the same problems on that system and can't find a software fix, we may need to reconsider the tester for osmo-bts-trx... ~N

6 years, 6 months

8
26
0 0

catch-22 VTY error

by Neels Hofmeyr

I'd like to share a VTY config error analysis that has a tricky solution: I started osmo-bsc -c osmo-bsc.cfg with, according to openbsc/doc/examples/osmo-bsc: net [...] bts 0 [...] periodic location update 30 trx 0 [...] and get this error: There is no such command. Error occurred during reading below line: trx 0 what? 'net / bts / trx' is no command?? Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on this branch, I've actually moved the 'periodic location update N' command a level up, from net / bts / periodic to net / periodic (background: assuming that OsmoMSC does not have individual BTS info, we moved some settings up to network level; whether this makes sense for osmo-bsc is a different question, it's just what happens to be on the vlr_3G branch now). So there is no net / bts / periodic command. Why do I get an error for net / bts / trx instead? two reasons: 1. 'trx 0' was the line following the 'periodic' command, 2. since 'periodic' exists one level above, the vty code goes to the parent node automatically. About 2: we tend to indent our VTY config files, but in fact the indentation has no effect whatsoever, it is just eye candy (very useful eye candy). The code in question: If a command does not exist, try 'vty_go_parent()' and see if the command exists there. That's what allows us to omit 'exit' in our config files to go to the parent node explicitly: libosmocore/src/vty/command.c: int config_from_file(struct vty *vty, FILE * fp) { int ret; vector vline; while (fgets(vty->buf, VTY_BUFSIZ, fp)) { vline = cmd_make_strvec(vty->buf); /* In case of comment line */ if (vline == NULL) continue; /* Execute configuration command : this is strict match */ ret = cmd_execute_command_strict(vline, vty, NULL); /* Try again with setting node to CONFIG_NODE */ while (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO && is_config_child(vty)) { HERE -----> vty_go_parent(vty); ret = cmd_execute_command_strict(vline, vty, NULL); } cmd_free_strvec(vline); if (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO) return ret; } return CMD_SUCCESS; } In this case the 'periodic...' command does in fact now exist one level above, so the vty_go_parent() is successful and running that command works. But, the vty config parsing then sits above on the 'network' level, is no longer in 'bts 0' and hence refuses to accept the following bts-level command, in this case 'trx 0'. Confusing! So it's not a bug, it's a feature. But it's a feature we might see quite often if we move the 'periodic' command up to network level and users attempt to use their old config files. Same goes for the 'timezone' command, BTW, so we might want to rename commands, or re-consider moving commands one level up in the first place. Maybe we should leave backward compat catchers in place that print a warning. ~N -- - Neels Hofmeyr <nhofmeyr(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 * Geschäftsführer / Managing Directors: Harald Welte

6 years, 7 months

2
4
0 0

Creating GSM Users Association (GSMUA)

by Mychaela Falconia

Hello FreeCalypso and Osmocom communities, I am in the process of creating an informal organisation representing the interests of those members of the GSM universe whose interests are not represented by GSMA etc, and I am inviting you to join me in this venture. I propose that we name our informal organisation GSMUA, standing for GSM Users Association, and my vision for this GSMUA is to be a counter-body (antibody?) to the official GSMA. I just registered the gsmua.org domain name, but there is no website or mailing list set up yet. If someone from the Osmocom camp would like to host the server infrastructure for gsmua.org, I will happily point the DNS to you, otherwise the FreeCalypso family can host it on our server. My vision for GSMUA is to represent the interests of GSM end users (empowered end users who wish to fully own and control all aspects of their user equipment while operating on public mobile networks in a fully spec-compliant manner), small boutique manufacturers of GSM devices (both MS/user equipment and network infrastructure), small community network operators and others whose interests are not represented by GSMA etc, especially in cases where our interests are in direct conflict with the interests of big players such as giant device manufacturers, giant commercial network operators and governments. A key goal of GSMUA is to be project-neutral, that is, every person and every small company belonging to any of the categories listed above (empowered end user, small boutique device manufacturer, small community network operator etc) should be fully welcome regardless of which specific project they are associated with. As of today there are at least two different projects offering GSM MS implementations (OsmocomBB and FreeCalypso) and at least two different projects offering network-side GSM implementations (Osmocom and OpenBTS), and I hope that this number of available alternatives will continue to grow: freedom of choice is always a good thing. But at the present time there exists no neutral soil on which members of different projects with a common interest (GSM networks and devices serving the interests of end users rather than big corporations and governments) and a common enemy (just named) can meet, and this lack of neutral meeting ground is the problem which GSMUA is meant to solve. I also have one practical application for GSMUA in mind already: to manage and legitimize recycling of wasted IMEI number ranges. By the official rules of GSMA etc each different *type* of GSM mobile equipment requires a different TAC, i.e., a range of at least 1 million IMEI numbers. So if a small boutique GSM device manufacturer makes a boutique MS device of which no more than 100 units will ever be made, 999900 IMEI numbers have to be wasted by the official rules. While I don't know of any manufacturer who got a range of 1 million IMEIs and only made 100 devices, we do have examples like Openmoko GTA01/02 and Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that about 15 thousand units were made in total; in the case of Pirelli DP-L10 it appears that the total number produced was somewhere under 100 thousand. In each case a full range of 1 million IMEIs was allocated, and at least 900 thousand numbers out of each range are currently unused and wasted. If a small boutique manufacturer wishes to offer a boutique GSM MS product to the general public and wishes to ship each unit with a world-unique IMEI that stands a good chance of being accepted as valid by common GSM networks, and the product in question does not qualify for IMEI allocation by the official rules (e.g., the product is a development board specifically intended for users to run their own firmware and connect to live public networks with it, taking full personal responsibility for their actions) - the situation I found myself in with my GSM MS development board - I feel that the small boutique manuf in question should be empowered to squat on a small subrange of someone else's IMEI range if it is known beyond reasonable doubt to be wasted and unused. However, this recycling of wasted IMEI number ranges could be better organized and given at least some aura of semi-legitimacy if there were a community body set up to manage it, and this is where my proposed GSMUA can come in. Once we get our GSMUA up and running and assign a group of volunteers to be IMEI recycling managers, any small GSM or 3G+ device manufacturer who needs a small range of IMEI numbers will be able to request one from GSMUA, and we will allocate and assign these small subranges out of whatever wasted range we decide to squat on, ensuring that each requestor gets a different subrange. So these are my ideas, and I would like to see them turn into reality. We are going to need a simple website and a community mailing list at gsmua.org, and for the IMEI recycling service we will need a small group of volunteers to serve as its managers - I and Das Signal from FreeCalypso will be happy to serve on that panel, but it would be nice to also have someone from the Osmocom camp for better neutrality. Bright Blessings, Mychaela Falconia, Mother of FreeCalypso

6 years, 9 months

5
6
0 0

openBSC encryption

by robert

Hi, Till now I have always worked with simcards without knowing their ki so I was not using any encryption. I have recently bought some programmable simcards and gave them an IMSI and KI and tried to have them working with ‘encryption a5 1’ and ‘encryption a5 3’ and I faced some problems. First if I choose 'a5 3' the phone cannot connect to the BTS and nothing can be done, while if I set the encryption to 'a5 1’, the phone connects normally and can make and receive calls but sometimes the call fails for a reason that I don’t know. I have then tried the following setup: I have connected 3 phones A, B and C. A and B have no KI related to them so no encryption is applied while C was given a KI. If I call from A to B or from B to A, the call is done successfully every time, while if I call from either A or B to C or from C to A or B the call might work and might not. Is there something in the configuration that should be changed when adding the encryption support ? And how to enable the a5 3 encryption ? Best regards,

6 years, 10 months

2
1
0 0

SS7 / SCCP design question: one or several SCCP instances?

by Neels Hofmeyr

We need to decide which way to go with point codes, sccp- and ss7-instances. pmaier and I have reached different conclusions and wrote patches going in opposite directions, now we need to decide and cosolidate: The MSC has various connections over SCCP: it serves BSSAP for several BSCs, and RANAP for several HNBGWs. BSC - A MSC: BSC -}----------> BSSAP BSC - -----> RANAP / HNBGW -}-/ IuCS HNBGW - 1) I went for exactly one point code at the MSC (say PC=1). There is exactly one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up(). When comparing to the TCP/IP model, the paradigm here is that a PC is like an IP address and the SSN like a port number. At the server, the MSC, I have one PC (IP address) and listen on one SSN (port) per protocol served, and clients all connect to the same PC+SSN, receiving separate connection IDs. I can also use the calling address to know which client I'm talking to. Hence I moved the osmo_sccp_instance creation up to "the top" and created two sccp_user_bind()s, one for BSSAP and one for RANAP. This works in practice. I can tear down and set up individual sccp_users (i.e. disable/enable IuCS or A separately), and handling different clients is done by the conn_ids and possibly keeping distinct osmo_sccp_addresses. An pseudocode MSC VTY config for this scenario could look something like this: msc sccp local-pc 0.0.1 ssn-iucs $OSMO_SSN_RANAP ! -> to IuCS rx cb ssn-a $OSMO_SSN_BSSAP ! -> to A rx cb remote-bsc 1 pc 1.0.1 remote-bsc 2 pc 1.0.2 remote-hnbgw 1 pc 2.0.2 i.e. one local PC is configured, each protocol has its separate SSN, each sccp_user_bind() serves all clients for that SSN. This is the direction I took to add IuCS to AoIP. 2) pmaier added VTY configuration for various point codes, and went the other way: the MSC creates a separate osmo_sccp_instance per BSC connection. (The MSC is told the addresses of all known BSCs and) every time a BSC is configured via VTY, a new osmo_sccp_simple_client() is created. IIUC the MSC then has a distinct local PC for each BSC, and for each HNBGW. In this model there still is a code problem I noticed while adding IuCS to AoIP in OsmoMSC: if I call osmo_sccp_simple_client() a second time with a different PC, the osmo_ss7_instance used is still the same (still id=1), and notes this second PC as its global local PC. The messages received for the first client's PC are then seen as remote and routed back out -> infinite message loop. A solution here would be to either a) use a separate osmo_ss7_instance per osmo_sccp_simpe_client() (simply add an ss7 instance id parameter to osmo_sccp_simpe_client() and increment by one each time) or b) implement the routing algorithm so that it notices the local PCs of several local SCCP clients. A VTY config for this scenario so far looks like this: ! define some addresses, referenced below cs7 instance 1 sccp-address msc_local subsystem-number 254 point-code 0.0.1 routing-indicator PC sccp-address bsc_remote subsystem-number 254 point-code 0.0.2 routing-indicator PC sccp-address bsc_remote2 subsystem-number 254 point-code 0.0.3 routing-indicator PC msc bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote2 (I'm not sure whether it is possible to have several sccp_instances with the same msc_local address, but we would find solutions for these petty issues once we've decided which way to go.) (I also think 'calling-addr' and 'called-addr' should rather be named 'local-addr' and 'remote-addr': depending on who calls who, the calling-addr can be the remote or the local one. That's also besides the point for now.) My personal idea is that 1) is simpler: we have one ss7 instance per program, no matter how many clients are served. I can still tear down and set up individual sccp_users (i.e. disable/enable IuCS or A separately), and handling different clients per SSN is done by the conn_ids and possibly keeping distinct osmo_sccp_addresses of the clients. 2) seems to me easier to misconfigure and it sounds to me like a paradigm of creating a whole new server for each client that connects, so instead of using an ss7_instance's routing, we create separate instances, each sending to only one counterpart. But is 2) maybe the correct way to go for reasons I'm not aware of? I notice that what I wrote is biased towards 1) because that's my POV, but this is indended to be a neutral question. We need a choice for 1) or 2) so that pmaier and I can adjust and merge our patches accordingly. Can you help us decide, hopefully with some background knowledge on how an SCCP network is intended to be set up? Thanks! ~N

6 years, 10 months

3
5
0 0

aoip branch

by Neels Hofmeyr

I successfully tested some new patches on the AoIP branch locally and pushed them to the openbsc.git/aoip branch. They allow using 3G with AoIP. @pespin: if aoip tester runs fail now, that's probably the cause. @pmaier: I tried to apply all patches found on the pmaier/aoip branch, but excluded the commits started with "MSC side reset" because of build failure. The failure is the same I saw a few days ago, still unchanged: CCLD osmo-bsc_nat ../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_go_parent': /n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:130: undefined reference to `osmo_ss7_vty_go_parent' ../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_is_config_node': /n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:140: undefined reference to `osmo_ss7_is_config_node' collect2: error: ld returned 1 exit status I suspect you still have some of your work not pushed to libosmo-sccp? I can't find a private branch or patches on gerrit about osmo_ss7_vty. In general I think it would be good to always keep your work on a private branch and push it frequently (doing anything you like on it, amending and so forth). For collaboration, but also to have a backup of your patches...? If you like, we can have a call soon to figure out a rebase of your work onto aoip. A merge conflict is solved on the neels/pmaier_aoip branch ('git fetch' first), but I get above build failure. ~N

6 years, 10 months

3
3
0 0

.deb build as jenkins test

by Max

Hi. In a light of https://projects.osmocom.org/issues/2340 I'd like to add .deb build as an additional step for jenkins jobs triggered by gerrit push. It'll mean longer build times but it'll prevent breaking changes from reaching master. It won't guarantee that we won't see occasional arch/version specific breakage in https://build.opensuse.org/project/monitor/network:osmocom:nightly but it should make nightly builds more stable and easier to maintain. What do you think? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

6 years, 10 months

2
1
0 0

osmo-trx -m is broken

by Max

Hi. I've got following error in latest osmo-trx: ./Transceiver52M/osmo-trx -x -c 2 -m -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. ALERT 139666585152384 10:32:48.8 UHDDevice.cpp:642:open: Channel setting failed - map::at ALERT 139666585152384 10:32:48.8 UHDDevice.cpp:642:open: Channel setting failed - map::at ALERT 139666585152384 10:32:48.8 osmo-trx.cpp:454:main: Failed to create radio device ALERT 139666585152384 10:32:48.8 osmo-trx.cpp:454:main: Failed to create radio device Shutting down transceiver... If I remove -m than it starts as expected. -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

6 years, 10 months

3
3
0 0

access grant channel on osmo(-bts)-trx

by Max

Hi. The number of blocks reserved for access grant channel is determined by BS-AG-BLKS-RES sent by BSC in SI3: see 3GPP TS 44.018 Table 10.5.2.11.1. In case of sysmobts and lc15 it's used as lch_par->agch.u8NbrOfAgch. Unfortunately, I'm unable to find appropriate counterpart for scheduler.c/osmo-bts-trx. Any ideas as to how can we apply BS-AG-BLKS-RES to osmo-bts-trx (and, of course test that the proper setting was indeed applied) would be appreciated. -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

6 years, 10 months

1
0
0 0

Error encountered using osmo-trx=0.1.9.20170621

by Ron

Hi All, We encountered an error upon running the "osmo-trx” using Ubuntu 16.04 OS. We have an existing "osmo-trx” in one of our server and running just fine. Upon checking for the version, the working “osmo-trx” is running at “0.1.9.20170530”, while the new one with an error is running at “0.1.9.20170621”. Kindly see below error for your reference: # osmo-trx osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_GAINSE Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

6 years, 10 months

2
2
0 0

jenkins plugin question

by Max

Hi. I've got add few more parameters to OsmoBTS and OsmoPCU gerrit jobs in jenkins. So far this has been done by manually adding parameter axis and writing combination filter for axis parameters. It's error prone and rather ugly. Much better way would be to use JobDSL and declare entire job programmatically but until that happens there's nice intermediate solution: https://plugins.jenkins.io/matrix-combinations-parameter I'd like to install this plugin onto our jenkins and convert above mentioned jobs to use it. Opinions, other ideas? On a related note: who's responsible for jenkins config/update? Shall I just contact that person directly if I need some plugin in jenkins, or shall I ask in ML? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

6 years, 10 months

3
2
0 0

osmo-bts revert: osmo-bts-trx regression detected by osmo-gsm-tester

by Neels Hofmeyr

Today we faced consistent osmo-bts-trx failures and I submitted a revert of commit "RSL: receive and send multiple SI2q messages". See https://osmocom.org/issues/2338. Why did we not catch it earlier? There was a bug in the osmo-gsm-tester build where the build could get stuck on a local branch instead of building newly pulled changes. That was fixed about a day ago, so we saw the breakage today. ~N

6 years, 10 months

1
0
0 0

AddressSanitizer in FreeBSD jenkins builds

by Pau Espin Pedrol

Hi, Some of you may have noticed that I have been lately fixing compilation warnings + enabling -Wall and -Werror on jenkins build for several osmocom libraries. While doing so, I noticed that the following lines trying to enable AddressSanitizer support are actually failing when building with the FreeBSD jenkins slave, probably due to it using some other shell without bash support: ./configure: CFLAGS+= -fsanitize=address -fsanitize=undefined: not found ./configure: CPPFLAGS+= -fsanitize=address -fsanitize=undefined: not found The source lines are: CFLAGS+=" -fsanitize=address -fsanitize=undefined" CPPFLAGS+=" -fsanitize=address -fsanitize=undefined" After changing them to support sh and submitting the change in gerrit [1], AddressSanitizer was enabled in FreeBSD for first time, but I started getting lots of link issues with AdressSanitizer (asan) related symbols. I read in several places that there seems to be a known issue with FreeBSD 10.3 and clang-3.4.1 (what we are using) regarding use of AddressSanitizer [2, 3]. I then tried configuring CC in the jenkins slave to use clang37 instead of cc (clang-3.4.1), and then the linking issue seems to be solved, but again a new compiler bug related to usage of __builtin_cpu_supports shows up, preventing compilation of libosmocore [4]. I think the best solution is to disable explicitly AddressSanitizer in contrib/jenkins.sh when running from FreeBSD, so the behaviour is actually the same as before, in which it was implicitly not enabled due to a syntax error. Once we move to FreeBSD11 and clang-3.8 we can try enabling it again. If nobody comes with a better solution or is against this, I will proceed to do so during next hours/days. [1] https://gerrit.osmocom.org/#/c/3024/2/configure.ac [2] https://stackoverflow.com/questions/30085036/linking-clang-address-sanitize… [3] https://webcache.googleusercontent.com/search?q=cache:CZmrK35zigEJ:ea5faa5p… [4] https://bugs.llvm.org//show_bug.cgi?id=25510 -- - 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

6 years, 10 months

1
0
0 0

heads up: no more \brief in libosmocore

by Neels Hofmeyr

I've just merged a patch that enables the AUTOBRIEF function of doxygen, in libosmocore. Every API doc's first sentence up to the first full-stop '.' is now automatically its \brief description. You may omit the \brief. This is so far only in libosmocore, since I'm not aware of us generating doxygen in any other repositories. Either way we can and should avoid the \brief, and in doubt enable the AUTOBRIEF everywhere. I've also shifted around the \file directives across libosmocore, and wrote a wiki page that describes it among other things: https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_AP… Related: the series of "doxygen:" commits that just came into libosmocore master. http://git.osmocom.org/libosmocore/commit/?id=87e4550585c643e97e0003119b254… http://git.osmocom.org/libosmocore/commit/?id=17518fe393a37781c84d09836256b… Do any other code trees need this switching? ~N

6 years, 10 months

1
0
0 0

SCCP/M3UA: PC and routing questions

by Neels Hofmeyr

Trying to get the HNBGW to communicate with the MSC. I receive Iuh from the femto cell as usual, send to the MSC, and end up in an infinite loop where osmo-stp and osmo-hnbgw send the same message back and forth to each other. osmo-hnbgw's local IuCS PC is 23, the MSC is PC 1. It seems when osmo-hnbgw receives a message to PC 23, i.e. to itself, it thinks that its own PC isn't local, finds its own as-clnt-CS in the table of routes, and feeds it to m3ua_tx_xua_as(). osmo-stp then sends it back. repeat. It seems overkill that a "client" like osmo-hnbgw should be capable of routing in the first place. It could switch off routing entirely and receive & handle every message it receives itself. But assuming that this were nonsense: IIUC it should rather decide that its own PC 23 is local, in: bool osmo_ss7_pc_is_local(struct osmo_ss7_instance *inst, uint32_t pc) { OSMO_ASSERT(ss7_initialized); if (pc == inst->cfg.primary_pc) return true; /* FIXME: Secondary and Capability Point Codes */ return false; } Apparently this global primary_pc is set in osmo_sccp_simple_client(). Since in the osmo-hnbgw I'm (so far) creating two simple clients with distinct PCs (IuCS is 23, IuPS is 24), the primary_pc is overwritten with 24. After that we always fail to notice 23 as a local PC and bounce messages for self right back down the SCCP stack, because apparently we find a route for 23 instead. A "matching" route is recognised by osmo_ss7_route_find_dpc(): if ((dpc & rt->cfg.mask) == rt->cfg.pc) My own local client gets entered as route, with rt->cfg.mask == 0 and rt->cfg.pc == 0, so an arbitrary dpc & 0 == 0, matches always. It seems awfully easy to create a fatal infinite loop flooding the network and CPU -- simply send a message to a DPC neither side sees as local. Anyway... Which way to go to serve more than one PC in a program? It appears that either an osmo_sccp_simple_client() call's local PC or an osmo_sccp_user_bind_pc()'s PC should be stored&found as a local PC. ... or both. Is the "right" way to have two PCs: having two osmo_sccp_simple_client()s with an sccp_user each; or rather one osmo_sccp_simple_client with two users? Or, should we for the OsmoHNBGW just have one osmo_sccp_simple_client() and one user, i.e. only one PC to receive both IuCS and IuPS messages? All we do is feed both of them out to Iuh anyway... (This seems an easy way out of the multi PC problem, but our MSC wants to serve one PC for BSSAP=2G and one PC for RANAP=3G, so we will need to solve the multi-PC problem anyway.) There are many directions I could head to, is any one better than the others? Thanks! ~N

6 years, 10 months

2
4
0 0

osmo_sock_get_name() order

by Neels Hofmeyr

In january, osmo_sock_get_name() was introduced and prints the connection info for a given fd, which looks like this: 127.0.0.1:2905<->127.0.0.1:60661 However, when I first saw this in a log, I was confused: I expect the local address and port to be on the left, while in this string it is on the right. Is it only me and I should get used to it, or can we reverse that so the local part is on the left? I could argue that in most GSM graphics and ladder diagrams, the client side is on the left, and that we would typically use this string on the client side to indicate where we connected to. Is this even true? Should there be an arg to pick the preferred order? :P I'll submit a patch if anyone agrees. ~N

6 years, 10 months

3
4
0 0

knowing connected subscribers

by robert

Hello, Is there a way in openBSC to know if a certain phone that previously connected to my BTS is still connected at a given time ?

6 years, 10 months

3
4
0 0

jenkins and osmo-ci

by Max

Hi. I've problem figuring out how to use osmo-ci in jenkins: the build steps for osmo-bts-gerrit and osmo-pcu-gerrit look pretty-much the same but osmo-pcu fails with: osmo-layer1-headers.sh: command not found while osmo-bts (which uses other scripts from osmo-ci) works fine. Any ideas where this difference might come from? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

6 years, 10 months

3
5
0 0

how to use the CTRL interface to set TRAPs.

by emily mcmilin

Hi all, I have some uncertainty about how to use the CTRL interface to set TRAPs. In the OsmoBSC user manual (for example), the example provided doesn't specify an option to set for the 'var' I might be particularly interested in monitoring: `$ ./bsc_control.py -d localhost -m` Is this the default to monitor all? Can I go about narrowing this? Also, I don't feel like I quite understand the TRAP portion of "Table 2: Variables available over control interface" in the OsmoBSC user manual: For example, the 'name' column seems to generally indicate the 'var' that one would pass in a GET/SET command, so I'm assuming the 'name' associated with the TRAP-enabled rows has the same significance. But these 'names' have no real meaning to me in terms of my experience with VTY, for example 'notification'. I have tried to look toward the osmo-nitb unit tests for inspiration, as there is fantastic coverage for GET/SET, out haven't seen similar for TRAP. Can someone please point me in the right direction? Thanks, Emily

6 years, 10 months

3
9
0 0

jenkins: Osmocom_Sanitizer build fails

by Neels Hofmeyr

Today I noticed that the Osmocom_Sanitizer build has been broken for a long time, failing at libosmocore/src/viterbi_sse.c. But that seems like the fault of the way the Osmocom_Sanitizer builds: When I build libosmocore with --enable-sanitize, everything works out. When I instead build with `make CFLAGS+="..."', some CFLAGS are dropped and the build fails. The working commandline is: ./configure --enable-sanitize make V=1 [...] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -g -O2 -fsanitize=address -fsanitize=undefined -msse3 -msse4.1 -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o The failing one is: ./configure make CFLAGS+="-fsanitize=address -fsanitize=undefined" V=1 [...] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -fsanitize=address -fsanitize=undefined -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o i.e. in the failing build, these cmdline args are missing: -O2 -g -msse3 -msse4.1 So it seems that the CFLAGS+="stuff" is not working as intended. The alternative is to build with the ./configure --enable-sanitize, which I added at some point. But not all libs have this switch, AFAIR. I have added the --enable-sanitize configure option to libosmocore, and asked others to follow up in other repositories in the same fashion. I think this hasn't worked out everywhere yet. Does it make sense to refresh the sanitize build effort?: switch the Osmocom_Sanitizer build to using this configure flag and add it where it is missing. But I guess we should instead add the sanitize switch to each individual build script for the various *osmo* build jobs and switch off the Osmocom_Sanitizer build instead. I repeat myself, but adding --enable-sanitize is not a lot of effort. See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da5… I created https://osmocom.org/issues/2330 ~N

6 years, 10 months

3
5
0 0

core/conv: further Viterbi decoder optimizations

by Vadim Yanitskiy

Dear all, I would like to know your opinions about some optimizations of Viterbi decoder, which were already discussed previously. First of all, I would like to share some benchmarking results. I used the test cases ("osmo-conv-test"), written by Tom Tsou, to ensure that SIMD optimization is integrated correctly. And, shortly speaking, the results are almost equal. Older version of decoder is a little bit faster, but I think it's because one is being compiled with "-march=native". Returning back to the subject, as we allocate and free some memory on every osmo_conv_decode_acc() call, what may happen very frequently and tear down performance on some hardware, there was the following suggestions: 1) Use static memory allocation where it's possible. 2) Use talloc for dynamic allocation. 3) Internal caching: Fri May 9 18:23:03 UTC 2014, Tom Tsou wrote: > Internal caching was in the original implementation, but > stripped from the submitted version mainly for simplicity > and avoiding the need for global variables, though we seem > to be having that discussion anyway ;-) The trellis values > can be cached based on pointer or hashed code. That works well > until threading is involved and cache access needs to be locked. > Those are features I need, but can probably be ignored in this > case. > > Again, I think the API should be kept intact. Internal caching, > can be a topic for later discussion. So, I am open for your ideas, opinions and remarks. With best regards, Vadim Yanitskiy.

6 years, 10 months

4
6
0 0

aoip branch in openbsc.git

by Neels Hofmeyr

Hi Philipp, I have rebased the 'aoip' branch onto openbsc master. A test by the osmo-gsm-tester of this state was successful. Pending is to also verify voice and all of 3G still works there (will then update vlr_2G and vlr_3G branches). Some commits have been amended to, a) adjust libsmpp changes to use vlr_subscr, b) fix the msc_vlr unit tests after your rename of a_tx() and a_page() (don't really know why I didn't hit that earlier). c) add one comment So beware, if you rebase your most recent patches onto the 'aoip' branch, git may want to apply a few patches again because they slightly differ, even though their commit logs are identical. You need to sanity-check with 'rebase -i'. ~N

6 years, 10 months

1
0
0 0

osmo-bts-trx: "No clock from osmo-trx"

by Neels Hofmeyr

Hi Tom and others, in our testing setup, we have sporadic failures (~2 out of 10 times) with: DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx What would be possible reasons for this failure, and how can we go about fixing it? Some more logging around it: 20170614032014399 DRSL <0000> rsl.c:2333 (bts=0,trx=0,ts=0,ss=2) Fwd RLL msg EST_IND from LAPDm to A-bis 20170614032018533 DL1C <0006> scheduler_trx.c:1451 PC clock skew: elapsed uS 4136730 20170614032018533 DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx 20170614032018533 DL1C <0006> scheduler.c:240 Exit scheduler for trx=0 20170614032018533 DL1C <0006> scheduler.c:216 Init scheduler for trx=0 20170614032018533 DOML <0001> oml.c:280 OC=RADIO-CARRIER INST=(00,00,ff) AVAIL STATE OK -> Off line [...] Shutdown timer expired (We're using an external 10MHz OCXO timing source) It appears there's four seconds of nothing from osmo-trx? Most curious is that the next run will be completely fine, until some time later we get this same failure. We wait until osmo-trx logs -- Transceiver active with 1 channel(s) and then we "immediately" or up to a second later launch osmo-bts-trx. Would it help to give it more grace time?? Thanks! ~N

6 years, 10 months

4
4
0 0

Re: osmo-bts-trx: "No clock from osmo-trx"

by Vadim Yanitskiy

Neels, > What would be possible reasons for this failure, > and how can we go about fixing it? As I know, this happens when scheduler detects, that system time is changed. For example, it might be caused by NTP time correction. - Do you have NTP enabled? - Have you specified process realtime priority? With best regards, Vadim Yanitskiy.

6 years, 10 months

3
3
0 0

osmo-gsm-tester - voice call

by Sudhanthiradasan R

Hi, Is it possible to perform end-to-end testing like voice calls, sms etc with current osmo-gsm-tester version. I do not see any suites for voice call testing in the suites directory. Thanks Sudhanthiradasan R ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------

6 years, 10 months

3
4
0 0

Re: New Defects reported by Coverity Scan for Osmocom

by Neels Hofmeyr

Max, you fixed the coverity issue in https://gerrit.osmocom.org/2885, but a few lines above that, there is another +1 that seems one +1 too many: if (m_id_len > MAX_BTS_FEATURES/8 + 1) { LOGP(DNM, LOGL_NOTICE, "BTS%u Get Attributes Response: feature vector is truncated to %u bytes\n", bts->nr, MAX_BTS_FEATURES/8); m_id_len = MAX_BTS_FEATURES/8; } I can't claim I understand why this size check is necessary on top of the other one, but certainly "> MAX_BTS_FEATURES/8 + 1" doesn't match setting "m_id_len = MAX_BTS_FEATURES/8". ~N

6 years, 10 months

1
0
0 0

Voice audio testing in osmo-gsm-tester

by Harald Welte

Dear all, osmo-gsm-tester is currently capable of setting up an entire network with one or more BTSs, Modems, NITB, etc. and test signaling + SMS. Voice testing has always been on the wishlist, but further down on the TODO list. One issue here is that a) many modems don't do voice at all (data-only modems for laptops) b) some modems expose voice only as analog audio (difficult to interface, would require custom hardware next to the modem, e.g. using USB soundcard, calibrate the levels, ...) c) some modems expose the voice as PCM bus. Similarly, would require some external codec chip and/or USB soundcard or the like, plus a custom circuit d) some modems expose voice as "GSM codec frames over UART" or other highty proprietary formats e) some modems expose voice as USB audio device. Most convenient, but only found in some Qualcomm LE based devices such as Sierra Wireless or Quectel. Over the weekend I was thinking of yet another method to make this much simpler: Every phone is supposed to include a voice loop-back mode. In this mode, the phone siply loops back all voice frames received in the downlink and sends them back in the uplink. This functionality is mandatory by the spec, and used to test the receiver performance of the phone during development, manufacturing and service. IT is specified in 3GPP TS 44.014 (http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_144…) which used to be GSM TS 04.04 (http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_101…) before. The idea is that one puts a special "Test SIM" (as specified in TS 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this context) into the phone, and then sends some specific commands on Layer3 to activate the loop. So if we can activate that loop-back functionality from the Osmocom stack, we could test if we get back the same voice data that we send in downlink (minus some occasional bit error, but those should be super low given we're operating omso-gsm-tester over coaxial cabling between MS and BTS). 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)

6 years, 10 months

4
8
0 0

Re: vty talloc report

by Vadim Yanitskiy

Hi Neels, > If you submitted a patch for it I would probably +vote it. Not yet. > I guess it would actually be a whole bunch of patches, > a common part in libosmocore and using it in each osmo* program? Probably, it would be a whole bunch of patches for osmo* programs only. I was wondering about modifying libosmovty to enable a new VTY command in all projects, like Harald did in osmo-fsm implementation. But in case of FSM, all state machines are being registered before use, so libosmovty "knows" about them. What is impossible in case of talloc contexts right now. Of course, we can write a new function and register every root talloc context using it. What about that? Regarding to the commands to add, I think show ctx all - Show list of all registered talloc contexts. show ctx NAME - Find specified context and call talloc_report_full. With best regards, Vadim Yanitskiy. 2017-06-01 4:34 GMT+07:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>: > re "what do you guys think about having a special VTY command to get a > talloc report?" > > If you submitted a patch for it I would probably +vote it. I guess it would > actually be a whole bunch of patches, a common part in libosmocore and > using it > in each osmo* program? > > ~N > >

6 years, 10 months

2
2
0 0

Proposal: Usage of stow in jenkins build scripts

by Alexander Huemer

Hi, The osmocom software that I do not install via apt but build myself gets installed in $HOME/usr and I do things like: export PATH="${PATH}:${HOME}/usr/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib" export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig MANPATH="${MANPATH}:${HOME}/usr/man" Therefore I don't have to install to a destination outside my home directory which in turn means I can avoid some sudo calls. But that actually does not matter so much, you can mentally substitute $HOME with '/' and append '/local' in the following if you want. I don't install to $HOME/usr directly but use stow for 'managing' the installations, so an installation goes like this: $ mkdir -p $HOME/src/telco/osmo/libosmo-abis $ cd $HOME/src/telco/osmo/libosmo-abis $ git clone git://git.osmocom.org/libosmo-abis $ autoreconf -i $ ./configure --prefix=$HOME/usr/stow/libosmo-abis $ make $ make install $ STOW_DIR=$HOME/usr/stow stow libosmo-abis This has two advantages: * Good visibility of what is installed by a package. $ tree $HOME/usr/stow/libosmocore * Possibility of uninstalling a package even if the Makefile is not present. For me those two advantages outweigh the small additional effort of using stow. Because of that workflow I sometimes run into situations in which make runs fail because either header files are not found during compilation or libraries are not found during linking. The reason is that autotools variables pointing to pkgconfig supplied directories point to a destination under the prefix path with which configure was called. If a dependency was not mentioned in a Makefile.am the required files are not found because the other dependencies are in other directories. For a system on which the osmocom-own dependency libs are installed in distinct directories, current openbsc master HEAD requires the attached patch for a build to succeed. I admit that in most situations the dependencies are installed in the same directory so this does not matter, but it is still a small bug. Therefore I propose to modify the jenkins build scripts so that they use distinct, stow managed directories for the dependencies. That should help to detect oversights, although admittedly developers would have to adapt their workflows to use stow as well in their daily hacking. Otherwise an oversight would be detected by jenkings and not locally which in turn would require additional cleanup commits which is not so nice. What is your gut feeling? Does the increased correctness of Makefiles.am contents justify the (IMO rather small) additional effort of using stow? Kind regards, -Alex

6 years, 10 months

2
5
0 0

osmo-trx rach question

by Max

Hi. I'm troubleshooting peculiar use case with packet access and osmo-bts-trx. There are 2 options for ME to acknowledge reception of control packet to PCU according to 3GPP TS 44.060 § 11.2.2: 1) Packet Control Acknowledgement message 2) 4 identical access bursts The latter can be both 8-bit RACH and 11-bit RACH (not supported by osmo-bts-trx yet). The choice of response format is defined by OpenBSC in SI: 1) is default, 2) can be activated with "gprs control-ack-type-rach" option. The problem is that I don't understand how 2) will be handled by OsmoTRX? Shall I expect 4 consecutive RACH messages via rx_rach_fn() in scheduler_trx.c in osmo-bts-trx? Shall it be some other message/function? Will it be ignored/dropped altogether by OsmoTRX? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

6 years, 10 months

2
1
0 0

osmo-trx: GSM signal generator

by Tom Tsou

Hi All, I wrote a GSM signal generator application based on osmo-trx. The new osmo-siggen allows random GSM or EDGE burst generation without using special configurations of osmo-trx or the socket control interface. Frame trigger output through GPIO is also available. I use the application for testing modulation parameters and other PHY level testing. Hopefully it's useful to other developers beyond myself. $ ./osmo-siggen -h Options: -h, --help This text -a, --args UHD device args -l --log Logging level ('err', 'warn', 'notice', 'info', 'debug') -b, --burst Burst type ('normal', 'access', 'freq', 'sync', 'edge') -r, --ref Frequency reference ('internal', 'external', 'gps') -f, --freq Tx RF frequency -g, --gain Tx RF gain -s, --sps Tx samples-per-symbol (only 4 supported) -m, --mod GSMK modulator type ('laurent4', 'laurent2', 'laurent1', 'nco') -p, --ampl Tx amplitude (0.0 - 1.0) -o, --offset Baseband frequency offset -t, --tsc Normal and EDGE burst training sequence (0-7) -S, --swap Swap channels Currently osmo-siggen is located in the below branch. I've tested solely with B210. C++14 availability is also required for now. git://git.osmocom.org/osmo-trx ttsou/siggen -TT

6 years, 10 months

1
0
0 0

osmo-trx: Generating frame sync output on GPIO?

by Harald Welte

Hi all, I was wondering if it is possible to generate a TDMA frame sync output on a GPIO line of a USRP device (and/or any other SDR supported by osmo-trx). This way it would be much easier to do e.g. BER testing by using a pure waveform/pattern generator for the "MS side". Such devices (Like an E4433B) can only generate the uplink bursts with pseudo-random sequence, but they don't have any receiver, so they're not able to receive the downlink from the BTS in order to lock on the TDMA frame and transmit the uplink in sync to that. There are of course specialized devices (CMU-300, ...) or hardware options that add such receivers for synchronization on the signal generators, equipment side, but why go there if there would be an easy way to generate some kind of a frame sync output. I would appreciate to know even if there's a way to introduce such "synchronous GPIO toggles" or the like in the command stream to UHD devices. If that existed, it should be rather simple to insert those whenever a new burst for TS0 is sent. A rather computationally (and bandwidth) expensive other option might be to use the second RF output to generate such a signal, but I was hoping not having to abuse the 2nd channel for that ;) 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)

6 years, 10 months

2
1
0 0

Accelerate3g5 Problem in cellphone attach procedure

by Lin HUANG

Hello, We met a problem during the cellphone trying to attach to the network. The modules we ran are: Nano femtocell <- LAN -> osmo-hnbgw <--> osmo-msc <--> osmo-hlr. The cellphone with sysmcom USIM searched the network 90170 and then tried to register in it. The authentication was passed but the connection was released. The cellphone automatically repeated the attach again and again, but always failed. In the output of HLR, it seems the authentication is OK: ---------------------- 20170606183004032 DAUC <0003> db_auc.c:222 901700000014922: Generated 5 vectors 20170606183004032 DAUC <0003> db_auc.c:227 901700000014922: Updating SQN=1728 in DB ... 20170606183005665 DMAIN <0000> luop.c:148 LU OP state change: NULL -> LU RECEIVED 20170606183005665 DMAIN <0000> luop.c:148 LU OP state change: LU RECEIVED -> ISD SENT ---------------------- But in the output of MSC: ---------------------- 20170606183005665 DMM <0002> gsm_04_08.c:3798 <- SECURITY MODE COMPLETE IMSI:901700000014922 ... 20170606183005666 DMM <0002> gsm_04_08.c:201 -> MSISDN:333 LOCATION UPDATE ACCEPT ... 20170606183005666 DMSC <000a> msc_ifaces.c:44 msc_tx 17 bytes to MSISDN:333 via RAN_UTRAN_IU 20170606183005666 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP DT (SUA link 0xcacde0 conn_id 0) 20170606183005666 DSUA <001b> sua.c:506 Received SCCP User Primitive (N-DATArequest) 20170606183005666 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 14 00 1e 00 00 02 00 10 40 12 11 05 02 09 f1 89 28 b6 17 08 99 10 07 00 00 10 94 22 00 3b 40 01 00 00 00 ) 20170606183005666 DVLR <001d> vlr_lu_fsm.c:321 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE 20170606183005666 DVLR <001d> vlr_lu_fsm.c:355 vlr_lu_fsm(901700000014922)[0xcd5250]{VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_PARENT) 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(901700000014922)[0xcd5250] 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Freeing instance 20170606183005666 DVLR <001d> fsm.c:275 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Deallocated 20170606183005666 DVLR <001d> vlr_lu_fsm.c:700 vlr_lu_fsm(901700000014922)[0xcd5250]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE 20170606183005666 DMM <0002> vlr_lu_fsm.c:692 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: Received Event SUBSCR_CONN_E_ACCEPTED 20170606183005666 DMM <0002> subscr_conn.c:77 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: SUBSCR_CONN_FROM_LU 20170606183005666 DMM <0002> subscr_conn.c:84 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: state_chg to SUBSCR_CONN_S_ACCEPTED 20170606183005668 DMM <0002> subscr_conn.c:132 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: Received Event SUBSCR_CONN_E_BUMP 20170606183005668 DMM <0002> subscr_conn.c:168 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: bump: releasing conn 20170606183005668 DMM <0002> subscr_conn.c:169 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: state_chg to SUBSCR_CONN_S_RELEASED 20170606183005668 DMM <0002> subscr_conn.c:255 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR) ---------------------- Why is there a 'Received Event SUBSCR_CONN_E_BUMP'? Regards Lin

6 years, 10 months

4
5
0 0

ericsson rbs2308

by Rajitha peiris

hello everyone ...... anyone doingwith rbs2308 ? i am doing with dhai and E1 interface but it doesn't come to operational mode ....if anyone got any output from rbs 2308 pls let me thanks rajitha

6 years, 10 months

1
0
0 0

images

by Neels Hofmeyr

People keep posting images to this list. I saw that mailman allows to remove image attachments by file suffix and/or by mime type. I suggest we put jpg, png, bmp on the list of attachments to remove. AFAICT there was zero need for a legitimate image post, and if we'd want to we can always create a wiki page or redmine ticket and attach the image there. It would be nicer to bounce messages with such attachments completely, but dropping the attachments is the next best thing. Opinions? I don't have access to the list admin, so (if we agree) someone else would need to effect this / give me the pw: mailman admin / "MIME-/HTML-Filter" / tick 'yes' on top and add image suffixes to the reject list ~N

6 years, 10 months

1
0
0 0

ipaccess 1800/1900 model

by Albert Paijmans

Hello, In the Netherlands the free gsm channel for private gsm networks is; 1875 - 1879,9 MHz 200 mW e.r.p. 200 kHz 875 - 1879,8 MHz 50 mW/MHz e.r.p. ≤4,5 MHz But I am a little bit confused as to how to set up an ipacces nanobts with those frequencies In OsmoBTS configuration file find bts 0 and set band to GSM1800 Also set frequencies to right value arfcn The example says ( https://osmocom.org/projects/openbsc/wiki/Multi-BTS_with_handover) trx 0 rf_locked 0 arfcn 74 ... trx 1 rf_locked 0 arfcn 84 --------------- I am not sure what to put at arfcn as the correct frequency with the mentioned frequency.. A second question, the nanoBTS comes in 1800 for GSM1800, and GSM1900 variant thereof (almost identical hardware) Well I can get 2 of the 1900 version very cheap from the USA but setting the configuration file bts 0 band GSM1800 won´t change the frequeny of the 1900 model to 1800MHz? Or can I only use the 1900 version in the free 1900MHz DECT frequency range? I have attached the official document of the Dutch regulatory body with the allowed frequencies, see page 28 for DECT frequencies in 1900 band and page 29 for picocell frequencies in the 1800 band. To me it seems both bands 1800 and 1900 are allowed, 1800Mhz is the official private gsm but for testing purposes using a 1900 model on the DECT band should be ok to. If the nanobts 1900 US model could also operate on the 1800 band that would be even better. Thanks, Albert

6 years, 10 months

3
2
0 0

osmo-gsm-manuals DRAFT

by Neels Hofmeyr

In our osmo-gsm-manuals, there are various code listings that one would like to copy-paste from the PDF. That would theoretically work, but practically, the 'DRAFT' watermark in the backdrop confuses the text marking, hence making copy-pasting some text from the manuals very very cumbersome. Though I'm not that sure why we need a 'DRAFT' watermark in an open source manual (it's implicitly a draft), I am fine with having such a marking. But I would like the marking to be less obtrusive. We could experiment with putting a bitmap image in the backdrop instead of text, or even better IMHO would be to put it in the page header next to the version. We could also add a generic "DRAFT" disclaimer near the beginning of each document. (Same goes for the sysmocom internal manuals, for which it isn't so easy to get the asciidoc source to paste from.) Any opinions on this? ~N

6 years, 10 months

2
3
0 0

libosmo-sccp: Build breakage on --disable-static

by Holger Freyther

Hi, I just looked into a build breakage when --disable-static is passed. The first failure is because of: libosmo_sigtran_la_LDFLAGS = -version-info $(LIBVERSION) \ -no-undefined \ -export-symbols-regex '^osmo_' The testcases use xua_* sua_ symbols but they are not exported. Shall we export them or shall we forbid --disable-static on libosmo-sccp? The second part is that I had preferred the sccp library to be static only to avoid having to do proper ABI checking/versioning. If we fix the above, maybe we have to fix this part too? holger

6 years, 10 months

2
2
0 0

Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB

by Gerard Lawrence Pinto

Greetings, Congrats on OsmoCon 2017! I have been working with OsmocomBB, osmo-sim-auth, mncc-python projects in Osmocom. I would like to contribute some code snippets with your acceptance. To begin with I have committed: I) MNCC with OsmocomBB - *https://github.com/GerardPinto/call-control-mncc-sap <https://github.com/GerardPinto/call-control-mncc-sap>* (Has both implementations in Python and C + Tested voice with gsm-fr with gsm audio file - works great). - Some of which can be committed to mncc-python? (In order to support MNCC with OsmocomBB too) Although, Harald told me it was built for OpenNITB - I'm not sure, the relevance of this contribution to this repo? Reason: 1. Solves some mailing list questions: Some questions on mailing list are pertaining sending voice from PC to phone and receive. 2. Useful for test cases: In the future, if 'gsm-efr' codec is implemented, we can use these snippets and send audio with gsm-efr sample, instead of connecting to LCR (Am I correct?) *Issues faced*: File: l23api.c | function: l1ctl_rx_traffic_req() 264 bits (33 bytes) of voice codec are interleaved into 456 bits. The DAC, ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 = 456. So Layer23 sends 4 - 114 bits into the queue to Layer1 in function => l1ctl_rx_traffic_req *Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC]) if num > 4 dropping traffic frame. (114 x 4) The code above indicates if queue has any (114 x 4) bits drop the incoming voice request. So I faced the issue of voice packets getting dropped, but that was just twice/thrice and then it did not give me any trouble (I'm not sure how it got fixed), I could hear *clear* voice gsm-fr on the called party cell phone. *My Question is*: If I happened to send voice packets 33 bytes really fast. There should be some kind of buffer rather than a check (Code) and drop frame? - OR this case can never happen? My apologies, if my understanding is incorrect, I just tried to reverse engg. from code and GSM codec available online! II) osmo-sim-auth with added other SIM related API's (still needs code clean up, SIM response check, code re-usable, README.md etc,) * https://github.com/GerardPinto/osmo-sim-auth <https://github.com/GerardPinto/osmo-sim-auth> * - I did check out PySIM (I think I can add some code to the existing repository, with your permission). Could you please let me know if my osmo-sim-auth repo? If it is correct to combine with PySIM, with the changes done below? Files modified: 1. SIM.py - Added more API's. 2. osmo-sim-auth.py - Options parser. Thanks, Gerard.

6 years, 10 months

3
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2017