OpenBSC October 2020

openbsc@lists.osmocom.org

17 participants
23 discussions

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

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

4 3

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

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

3 5

Problem while running NIB on Open Cellular Base sation
by Brackley Casinga 31 Jan '24

31 Jan '24

Hi, My name is Brackley Cassinga Form DRC, we run a community network called pamoja net where we offer gsm services using osmocom open source software and OC Base station. Recently I have tried to install another base station as the same installed but I could not find any resource guiding through all the steps to take to run NIB on a base station. I'm currently running Ubuntu and I will appreciate if you could guide me on the installation of BSC,hlr,MSC , in order to run a basic gsm network. Thank you. Regards -- *Ir Brackley heshima Casinga **Pacifique* *CEO and Founder of kwanzatechnologie* KwanzaTechnologies ,GlobalElectronics +243977265291 | +243977265291 | Pcassinga(a)gmail.com/ brackley(a)ensemblepourladifference.org www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> | Skype: Brackley cassinga <https://webapp.wisestamp.com/#> Av Semliki N 43

2 1

GSUP <> MAP Conversion
by a.valizadeh＠sinacomsys.com 29 Oct '20

29 Oct '20

Hi! i'm very interested about GSUP <-> GSM MAP protocol conversion to perform HLR interrogation. Do you suggest a suitable solution for this problem? is there some related activity at OSMOCOM project?

2 1

Re: OpenBSC Digest, Vol 72, Issue 18
by Sipos Csaba 29 Oct '20

29 Oct '20

Hi Andreas, Fixed the patch. Yes there is a gap in the middle, that is why it is split to two: 1..72 and 132..239 is the correct one and it uses a reverse numbering like the Slovak or Czech networks. This is the reason the NMT phones in Hungary was not compatible with any other country, and the phones country settings were locked to Hungary only. For example in my MCR4800XL the country cannot be set, yet if you read out the EPROM, it contains the country settings for all country, but it is locked down to Hungary only. Regards, Csaba <openbsc-request(a)lists.osmocom.org> ezt írta (időpont: 2020. okt. 28., Sze, 13:00): > 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. [PATCH] Adds country specific settings for Hungary. (Sipos Csaba) > 2. Re: [PATCH] Adds country specific settings for Hungary. > (Andreas Eversberg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Oct 2020 19:08:46 +0100 > From: Sipos Csaba <dchardware(a)gmail.com> > To: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> > Subject: [PATCH] Adds country specific settings for Hungary. > Message-ID: > <CALQr=E9WMDr_-KBwWdQAH=UgB88nd= > ph2p1G2dOSG8F_CtY_Jg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > This is the final patch for Hungary specific settings for the > osmocom-analog project. > > Tested against a locked Motorola MCR4800XL, it works on all channels and > TAs. > > Please let me know if any more work needs to be done. > > Regards, > Csaba >

2 1

[PATCH] Adds country specific settings for Hungary.
by Sipos Csaba 27 Oct '20

27 Oct '20

This is the final patch for Hungary specific settings for the osmocom-analog project. Tested against a locked Motorola MCR4800XL, it works on all channels and TAs. Please let me know if any more work needs to be done. Regards, Csaba

2 1

Fwd: NMT-450 - partial success
by Sipos Csaba 27 Oct '20

27 Oct '20

Hi, I know it is a bit off topic, but as osmocom-analog has no dedicated mail list and my every attempt to contact Andreas lead to silence, I thought this is the closest one to discuss it. I try to create an NMT-450 network with Motorola MCR4800XL phones, and a LimeSDR-mini. As the phones are locked to "Hungary" using a specific raster and a large gap in the middle, first I needed to dig out the details, find out the country code and create a patch so at least the phone is willing to lock onto the DS signal. I managed to do all that, so now the phone is actually able to decode the network and lock onto the signal. My issue is with the uplink: when the phone tries Traffic Area update (the phone's uplink transmission burts is clearly seen with a spectrum analyzer), the network side is not able to detect the uplink burst at all. Not even as bad, or incorrectly formatted frame. Andreas has a site which describes how to set up the uplink side and do some tests: http://osmocom-analog.eversberg.eu/docs/sdr.html I followed that guide and when the uplink burst from the phone arrives, the RX IQ constellation monitor indicates a correct burst with proper power (the burst is nicely round and in the green area). If I try to set up a call to the phone using the correct country code and phone number, the phone clearly responds to the paging request, as the 3 paging attempt generates 3 uplink bursts. Again, with no reception/decoding on the network side. Tried with two phones of the same type, the effect is the same. I have two questions: 1. Where to send patches for the osmocom-analog project? 2. Does anyone have an idea what can be wrong with my setup? One more thing I noticed: compared to the channel frequency used to set the NMT network up, the uplink is a couple kHz shifted: http://www.imagebam.com/image/d17e881357285965 As it can be seen, the uplink burst appears 3-4kHz left relative to the downlink signal. The network is started with the following command: nmt -k 239 -k 235 -Y HU,1 --limesdr-mini --sdr-rx-gain 20 Any and all help is appreciated. Regards, Csaba

3 6

[PATCH 0/1] pysim: make random seed function python3 compatible
by Jeremy Herbert 27 Oct '20

27 Oct '20

Currently the random seed function _digits is not python3 compatible as it passes a unicode string to the sha1 function. It generates the following exception: Using PC/SC reader interface Card programming failed with an execption: ---------------------8<--------------------- Traceback (most recent call last): File "./pySim-prog.py", line 718, in <module> rc = process_card(opts, first, card_handler) File "./pySim-prog.py", line 643, in process_card cp = gen_parameters(opts) File "./pySim-prog.py", line 342, in gen_parameters iccid += _digits(opts.secret, 'ccid', ml, opts.num) File "./pySim-prog.py", line 228, in _digits s = hashlib.sha1(secret + usage + '%d' % num) TypeError: Unicode-objects must be encoded before hashing ---------------------8<--------------------- This patch fixes this problem. Jeremy Herbert (1): make random seed function python3 compatible pySim-prog.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.25.1

2 4

libosmocore: macOS support?
by Ludovic Rousseau 14 Oct '20

14 Oct '20

Hello, I try to build utils/osmo-sim-test.c on macOS. For that I need to build the complete libosmocore project. I already patched/hacked some source code file to make them compile on macOS but now the compiler fails on src/vty/cpu_sched_vty.c because cpu_set_t is Linux-specific. The problem is that src/vty/cpu_sched_vty.c contains *a lot* of use of cpu_set_t usage. I am pretty sure utils/osmo-sim-test.c will not need the functions defined in cpu_sched_vty.c. Is it possible to build utils/osmo-sim-test.c without building the complete libosmocore project? Any interest in macOS support (even partial & unofficial support)? Yes, the easiest option is to use Linux. But my main computer uses macOS. And I like challenges :-) Regards, -- Dr. Ludovic Rousseau

2 1

E1 line debug L1/L2
by Ivan Babanov 13 Oct '20

13 Oct '20

Hello all, Brief question. Is it possible to debug E1 line by connecting it to the 2nd port of the same NIC making a wired loop? Is it enough to open->ioctl->read from /dev/dahdi/channel to get a stream of LAPD SABME messages transmitted by BSC? A bit more details for those interested I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC. I'm using an E1 card Digium TE405P on the server side. OSMO-BSC is connected with Nokia BTS via a single E1 line. Looks like on Level1 everything is ok because BTS can detect the link and raise an alarm if the wire is getting disconnected. I can observe some data from timeslots on BTS side and if some channel is configured as D-Channel in /etc/dahdi/system I see transmission of block "01111110". But the problem is that LAPD link is not establishing. I can't find any tries on BTS side and BSC does not receive anything from BTS, just set of SABME messages in PCAP file. T200 expires and so on. I tried various T200 values. So, now it looks for me like L1 does not receive anything from L2 on BSC side and nothing is transmitted over the wire to BTS. dahdi_tool shows status "OK" So, my nearest plan to check data transmission over wired loopback. Thank you Babanov Ivan

4 10

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2020