OpenBSC

openbsc@lists.osmocom.org

16 participants
4247 discussions

merge conflicts in osmo-msc
by Neels Hofmeyr 14 Mar '19

14 Mar '19

Hi everyone, and in this particular case Sylvain, I know I'm hogging osmo-msc.git and I don't intend to hinder everyone else's work, but I doubt that it was really necessary to merge the silent call channel types patch to master right now. I'm really overloaded with doing the inter-MSC handover work, I'm again postponing my well earned leave that I would have liked to have started two months ago, and I don't want to be burdened with also resolving everyone else's merge conflicts. You all know that pretty much everything changes in osmo-msc, even if only slightly. As a rule of thumb, if you see a 'ran_conn', 'vlr_subscr_get()', a Paging callback function or a 'gsm_trans' in a bit of code, likely there will be merge conflicts with my current branch. Most should be trivial, but they will be stones put in my way. So please, before you merge onto master, consider doing the same work on the tip of my branch 'neels/ho' in osmo-msc, rather than on current master. That would be the ideal situation for me, because then you also test my patches. There still is ongoing work at the tip of neels/ho, if you want a more stable point to apply modifications to, look at the commit 'add LOG_TRANS, proper context for all transactions' and rebase your changes onto that. If you push those changes onto a private branch, I will even see them in tig and can simply incorporate them in by branch, carrying them along until we're ready to merge. If you prefer working on master, still do me a favor: just try to rebase the patch onto neels/ho. All the conflicts that you see in such a rebase will end up on my table and stop me from going forward until I have resolved them. Consider that before you hit that "Submit" button on gerrit in the osmo-msc.git repository. Plus, if I resolve conflicts with *your* code, likely I won't grok some minor detail and introduce bugs. So let's work together on this. Thanks! Working on osmo-msc.git neels/ho branch also needs various patches in other repositories; all these branches are kept up-to-date every day and all the time: libosmocore neels/misc libosmo-sccp neels/conn_id osmo-mgw neels/endpoint_fsm osmo-msc neels/ho Thanks again! ~N

1 1

ttcn3: more than one BSC
by Neels Hofmeyr 12 Mar '19

12 Mar '19

I'm trying to test inter-BSC Handover in ttcn3. At first I had problems grasping the concepts, but in the end it worked pretty nicely to start two distinct BSC handlers like this: testcase TC_ho_inter_bsc() runs on MTC_CT { var BSC_ConnHdlr vc_conn0; var BSC_ConnHdlr vc_conn1; f_init(2); vc_conn0 := f_start_handler(refers(f_tc_ho_inter_bsc0), 53, 0); vc_conn1 := f_start_handler(refers(f_tc_ho_inter_bsc1), 53, 1); vc_conn0.done; vc_conn1.done; } It's walking all the way through inter-BSC Handover now (!) up until the point where I want to discard the call. Now I'm facing the simple problem that I want to call f_call_hangup() in the second f_tc_ho_inter_bsc1() -- but I have no cpars (CallParameters) with a valid MNCC callref nor the CC transaction ID, those are in the first function. How can I share cpars between those functions? The transaction_id and callref determined by the MNCC and CC messages that happened in f_tc_ho_inter_bsc0 need to move over to f_tc_ho_inter_bsc1, much like the MS has moved to the other BSC. So it would make sense to have some global struct representing the MS which both BSC_ConnHdlr instances can access, if that is at all possible ... ? As a bit of a weak workaround, I could inter-BSC handover right back to the first BSC and then f_call_hangup() there :P ~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

2 3

Google Summer of Code 2019
by Vadim Yanitskiy 12 Mar '19

12 Mar '19

Dear Osmocom community, starting from 16th of January (until 7th of February) we can apply Google Summer of Code as an Open source mentor organization. Many well-known projects, such as Debian, FFmpeg, Apache, Git, GCC, GNURadio and others, have been participating last year. Personally, I think it's a great opportunity to move some of our projects forward. I would like to know your opinions about this idea, should we participate? I would be happy to be a mentor. With best regards, Vadim Yanitskiy.

6 13

SCCP connection identifiers on the SCCP User SAP
by Harald Welte 12 Mar '19

12 Mar '19

Hi Neels, from your IRC question today: > when opening a new conn on SCCP, what's the proper way to get a > conn_id? I want to feed OSMO_SCU_PRIM_N_CONNECT into > osmo_sccp_user_sap_down(), but it seems the caller needs to pick a > conn_id?? Whatever way you can think of to cough up a unique identifer for that connection. > I assumed that libosmo-sccp implicitly picks an unused local conn > reference, but that's not the case. Note that in this sentence you're now talking about the "SCCP local reference", which is something communicated on the wire between two SCCP providers (implementations). Hence, it is managed inside the SCCP provider[s] and can be seen in the source local reference / destination local reference field of the SCCP messages. That's *not strictly* the SCCP connection identifier which has significance only across the SCCP User SAP (i.e. between SCCP User and SCCP Provider on the same system), and which never is visible on any SCCP message on the wire. It's just an implementation shortcut of the Osmocom implementation that uses the same identifiers on both sides, rather than allocating separate ones. But getting back to your question: If the SCCP provider was to receive a N-CONNECT.req without some kind of identifier, and simply allocate one, how would that identifier be communicated back to the user? Those primitives work asynchronosuly. You'd have to come up with yet-another-identifier, like a "primitive tag" where that tag then would be eacho'ed back in the N-CONNECT.resp - and you end up again having to allocate some unique identifier :P > sccp_scoc.c has conn_create() which seems to pick an unused id, but > that part is static in a .c file > hnbgw just uses 1:1 the same conn_id from RUA to RANAP and thus doesn't invent new ones Now I'm confused. RUA isn't running over SCCP, right? > osmo-bsc goes through its list of &bsc_gsmnet->subscr_conns to pick an unused id > I can do that in osmo-msc, but it seems to me libosmo-sccp should have common API for that The SCCP User SAP is modelled strictly after the ITU specs. Always imagine yourself in a situation where the SCCP user and SCCP provider are running in different processes and they don't have access to each others's state - and all they can exchange are the SCCP User SAP primitives in some serialized form. While libosmo-sccp doesn't work like this (so far), we should always keep that in mind and keep the SAP boundary clean. As there's no primitive in ITU-T Q.7xx for "allocate me a local reference", we don't have one :/ I'm not sure what we should do here. If we introduce that kind of SCU primitive, then the questions is how are they allocated/released? Who is in charge of that? What kind of object would the SCCP provider use to keep track of allocated IDs for which there is no connection yet, as the N-CONNECT.req was not yet received? The current situation is not great. After all, theoretically there could be an incoming new SCCP connection for which the provider choses the same ID that the user at the same time choses for a new outbound connection -> boom. One could use something like the highest-order bit to distinguish between user-allocated and provider-allocated identifiers. 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)

2 1

3G PS hack (RE: 35c3 feedback)
by Mykola Shchetinin 11 Mar '19

11 Mar '19

Hello Keith, > 2) 3G data instabilities > ( Just a quick observation note, no pcap! ) > I happened to notice that pinging a 3G handset from the network side > (default ping: 1 sec internal, 64 ICMP bytes) keeps the connection > "alive" and using 3G data is then a pleasant experience, IM, email, > browsing, SIP call all working nicely. peak max download speed of 16Mbps > was reported at one time by m.speedof.me Can I ask you to expand a bit more on the topic? Sorry, it's been a while after you sent the original email. >From where did you perform a ping? From the machine where GGSN is running? And that also means that to run 3G PS network now it is needed to make some type of a service which will ping all the handsets registered, right? (Actually, that is what I am going to do now while the SGSN isn't fixed by somebody or us) Thank You! Kind regards, Mykola

1 0

RFC: osmo_ip_port API proposal
by Harald Welte 08 Mar '19

08 Mar '19

Hi all, Neels has recently proposed an osmo_ip_port API, see https://gerrit.osmocom.org/#/c/libosmocore/+/13123 I'm somewhat reluctant to get this merged into libosmocore, as from my point of view, it's reinventing what sockaddr_storage is doing in libc, but storign the address in host byte order and string format. So I would argue we should rather create helper/utility functions around sockaddr_storage and do any string/binary and endianness conversions hidden by/within that API. Irrespective of the above, I would want to hear what other developers think. Do you think that it's worthwhile to 1) have some utility functions / infrastructure (irrespective of the data type) 1a) in libosmocore, or 1b) keep it to osmo-mgw 2) prefer to 2a) have strings for IP adresses and host-byte-order port numbers like the proposed patchset, or 2b) go with native sockaddr_storage? If others think it should be merged, I won't try to veto it. I just want to hear some more voices rather than just my own point-of-view. 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)

1 0

LimeNET Micro
by Keith 06 Mar '19

06 Mar '19

The new product from Lime is marked to start shipping tomorrow. As far as I understand it is basically the LimeSDR mini with a GPS disciplined clock and a Raspberry Pi module, so it /should/ run osmo-bts + osmo-trx-lms fine, and without clocking issues. It also has POE. I was wondering if anybody else has looked at it, has comments, or has or is thinking of ordering one? Thanks!

3 3

static strings -- little fun on the side
by Neels Hofmeyr 04 Mar '19

04 Mar '19

As a bit of relaxation in-between the serious hacking, I gave a little idea of mine a spin, which could improve our use of static string buffers. My idea is to use one common static buffer string, as a ring buffer, for all our osmo_xxx_name() functions, that returns new chunks of static string every time. Why? The point is that we have many osmo_xxx_name() functions that return a string in one single static buffer. When you call it a second time, it overwrites the buffer. So this doesn't work: printf("PLMN changed from %s to %s\n", osmo_plmn_name(old_plmn), osmo_plmn_name(new_plmn)); No matter what, this will always print the same string twice, and probably no-one would notice. For this, I have previously often invented xxx_name2() functions: printf("PLMN changed from %s to %s\n", osmo_plmn_name(old_plmn), osmo_plmn_name2(new_plmn)); With osmo_plmn_name2() being: "Same as osmo_plmn_name(), but returning in a different static buffer." That is bad for these reasons: - each new separate function adds another static buffer to the program size, which remains unused all the other time. - each new separate function adds more API signatures. Alternatively we have xxx_buf() functions, but they are more cumbersome to use: char buf[123]; gsm0808_cell_id_list_name_buf(buf, sizeof(buf), cil); LOGP(DMSC, LOGL_DEBUG, "%s\n", buf); Particularly for logging, that would always run even though the logging category might be switched off. So I came up with these patches, and changing all of current libosmocore's static buffers to using this does work: http://git.osmocom.org/libosmocore/log/?h=neels/static_strings (second last patch introduces the API, last patch changes all libosmocore callers) Also pushed to gerrit for easier review: https://gerrit.osmocom.org/13061 the benefits: - All osmo_xxx_name() functions can be called N times in a single printf() statement, without the need for managing buffers. - No osmo_xxx_name2() functions for "separate static buffer" - Just fire off LOGP() args and the code gets skipped if the category / log level is switched off: LOGP(DMSC, LOGL_DEBUG, "PLMN changed from %s to %s, but Fred says it was %s\n", osmo_plmn_name(old_plmn), osmo_plmn_name(new_plmn), osmo_plmn_name(freds_plmn)); I think it would be nice to have this mechanism for easier string hacking, but not sure if the tradeoffs / vague side effects are worth it. So this might as well remain a fun idea that never made it. Thoughts welcome. Implementation considerations... At first I thought a plain ring buffer returning the next bit of memory every time would suffice, but I didn't like the need to vaguely trust that we never use overlapping memory. The best I could come up with was to guarantee up to N subsequent static strings as non-overlapping. See the semantics around the 'recent' members. But that entails an uncomfortable tradeoff: I kind of expected to reduce the size of static char buffers in libosmocore, but if I want to disallow overlapping N uses, the buffer has to be able to hold N subsequent allocations of the largest buffer, which currently is 4100. So I end up with a larger static char buffer. The advantage however is that every libosmocore using program with its own xxx_name() functions can now use the same static string space and does not need to add more static buffers all over the place. To make the buffer smaller, I considered taking the largest buffer callers out of this, i.e. osmo_hexdump() and msgb_hexdump(). But particularly osmo_hexdump() is one of the functions that I would like to be able to call more than once in a printf() arg list. Actually that would in practice be of smaller size than the maximum 4096 currently allowed. But the 'recent' check above requires the *largest* size to fully fit N times. Consider: if I choose a total buffer of 4096 bytes and print one hexdump of 3084 bytes, then I can't print another such buffer: the osmo_static_string() function can't know that the first printf() has already concluded, and still considers that large chunk as in-use. So to be able to allow any number of subsequent printf()s of the same huge size, I need the number-of-recent-checks times that large size to fit in the static buffer. So there is a tradeoff between how many previous buffers I can guarantee to be unchanged vs. the maximum buffer size allowed per allocation. I would actually like to ensure 10 or more recent buffers, so that a caller can say: I can use up to 10 various osmo_xxx_name() functions in the same printf() statement, and libosmocore will barf if I use too much. I would also like to use less static char buffer -- but is ten times 4096 as static string buffer really a lot? Not for an x86_64 desktop machine, but what about embedded targets? Since in practice the name buffer sizes we use are more like <80 chars each, in practice we would be totally fine with one 4096 char buffer. I have never seen a hexdump of 4Kb in practice. I'm considering actually removing the 'recent' check again and just offloading the responsibilty for name buffer usage to the caller. Or I'm considering to reduce the max hexdump / msgb_hexdump size to something saner like 1024 chars or even 256 chars. (Actually, hexdump could also loop in chunks of 64 bytes or something like that). Another consideration was about how to effect bounds checking. I don't want to evaluate return values in printf() args. So I decided to provide generalized API that returns NULL pointers if the size did not fit, but for convenience use have one osmo_static_string() function that OSMO_ASSERT()s as soon as the size doesn't fit, instead. ~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

2 2

Osmocom-Debian-install-test fails for 10 consecutive days!
by Harald Welte 03 Mar '19

03 Mar '19

Dear Osmocom community, for the last 10 days our "Debian installation test" job is consistently failing, see https://jenkins.osmocom.org/jenkins/job/Osmocom-Debian-install-latest/ It somehow seems to be related to soapySDR mismatching versions where we use a 0.5 package from the debian feed: > Get:358 http://deb.debian.org/debian stretch/main amd64 libsoapysdr0.5-2 amd64 0.5.4-1 [64.4 kB] and mix that with a 0.7 lms7 module from our feed: > Get:425 http://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_9… ./ soapysdr0.7-module-lms7 19.01.0-1 [49.9 kB] > Unpacking soapysdr0.7-module-lms7:amd64 (19.01.0-1) ... > dpkg: error processing archive /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so', which is also in package ... > Errors were encountered while processing: /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) > Build step 'Execute shell' marked build as failure > Finished: FAILURE Does anyone know of any change that would have triggered this? I've created https://osmocom.org/issues/3809 to track this. Regards, Harald -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

4 4

GSUP <-> GSM MAP protocol conversion
by Alex 01 Mar '19

01 Mar '19

Hi ! i'm very interested about GSUP <-> GSM MAP protocol conversion to perform HLR interrogation (at least for plastic roaming support) ... is there some related activity at OSMOCOM project ? Wbr, Alex

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC