- OpenBSC - lists.osmocom.org

by Sipos Csaba

Dear List, I face the problem that when I am in general using the nightly builds on Ubuntu 20.04, but I want to compile a specific project (Osmo-BSC in this case), the configure script is not able to find the Osmocom libraries which are already installed and available. Output of the configure script: configure: error: Package requirements (libosmocore >= 1.8.0) were not met: Package 'libosmocore', required by 'virtual:world', not found Libosmocore is available on the system: root@openbsc:~/osmo-bsc_bootstrap_mod/osmo-bsc# ldconfig -v|grep libosmocore /sbin/ldconfig.real: Can't stat /usr/local/lib/i386-linux-gnu: No such file or directory /sbin/ldconfig.real: Path `/usr/lib/i386-linux-gnu' given more than once /sbin/ldconfig.real: Can't stat /usr/local/lib/i686-linux-gnu: No such file or directory /sbin/ldconfig.real: Can't stat /lib/i686-linux-gnu: No such file or directory /sbin/ldconfig.real: Can't stat /usr/lib/i686-linux-gnu: No such file or directory /sbin/ldconfig.real: Can't stat /usr/local/lib/x86_64-linux-gnu: No such file or directory /sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once /sbin/ldconfig.real: Path `/lib/x86_64-linux-gnu' given more than once /sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once /sbin/ldconfig.real: Path `/usr/lib' given more than once /sbin/ldconfig.real: /lib/i386-linux-gnu/ld-2.31.so is the dynamic linker, ignoring /sbin/ldconfig.real: /lib/x86_64-linux-gnu/ld-2.31.so is the dynamic linker, ignoring libosmocore.so.20 -> libosmocore.so.20.0.0 Can someone help me with what kind of flags do I need to provide to the configure script and how? Much appreciate the help! Regards, Csaba

7 months, 3 weeks

2
1
0 0

GPRS hardware recommendations

by Ben Huntsman

Hi all- I'm trying to get a GPRS network set up to serve a few old phones I have, but I don't really need anything beyond that. There's a daunting array of choices and scant documentation out there, so I just thought I'd ask, does anyone have any recommendations for what the least expensive hardware solution to implement GPRS would be? In particular though, I'd like to go with commercial non-SDR hardware, and I'd rather spend a tiny bit more if it would get something smaller... Are there any good GPRS-capable femtocells that work well with the Osmo stack? I'm looking at some old Ericsson gear but hoping for something more compact. Thanks in advance! -Ben

7 months, 4 weeks

3
7
0 0

Can I build my own GMR satellite/base station and core network based on OpenBSC?

by 1191595017＠qq.com

Dear Osmocom community, Can I build my own GMR satellite/base station and core network based on open-source software (e.g. osmo-bts) and SDR? GMR is mentioned in the Osmo-bts user manual, but it doesn't say if it is implemented and how to configure it. If Osmo-bts doesn't work, is there any other project to build my own GMR base station and establish a connection with a GMR device? Best regards, Wei

7 months, 4 weeks

1
0
0 0

Manually choose frequencies for osmotrx

by Enzo Damato

Hello. I am working on setting up an osmoTRX based base station. Where I am in the US, between 902 and 928 MHz is part of the ISM spectrum, and unregulated. Therefore, I would like to configure my base station to use both an uplink and down link frequency within this range. However, none of the pre-existing ARFCN options have both the uplink and downlink frequencies within this band. Is it possible to manually shift the frequency used by the base station, or manually select the up/down frequencies so that both remain within this range? Thank you for your help, Enzo Damato

8 months, 1 week

6
14
0 0

Manually choose frequencies for osmotrx

by edamato＠ctc.sh

Hello. I am working on setting up an osmoTRX based base station. Where I am in the US, between 902 and 928 MHz is part of the ISM spectrum, and unregulated. Therefore, I would like to configure my base station to use both an uplink and down link frequency within this range. However, none of the pre-existing ARFCN options have both the uplink and downlink frequencies within this band. Is it possible to manually shift the frequency used by the base station, or manually select the up/down frequencies so that both remain within this range? Thank you for your help, Enzo Damato

8 months, 1 week

1
0
0 0

Re: Welcome SMS for on-demand subscribers

by Sipos Csaba

Hi Keith, > Is it an artwork by any chance? We are saving a Nokia UltraSite and building an as fully functional GSM network as much as it is possible. We have a bit of a LAPD issue on the multi-TRX side of things as the current RSL bootstrap code is really only practical for the InSite units, so that needs some work, but at least the OM data we send is confirmed to be correct, and I can make a single TRX work. One other thing would be nice to have is Cell Broadcast, that part also does not work yet, but lets keep that issue separated. Your second link requires a gitlab login. Is there a more accessible way to get that patch? :-) Thanks! Regards, Csaba

8 months, 3 weeks

2
1
0 0

Welcome SMS for on-demand subscribers

by Sipos Csaba

Dear List, In the good old NITB days, it was possible to set up an "open" network where a foreign IMSI was able to register with the network, and at the first attempt the subscriber received sort of a "welcome" SMS with its random generated MSISDN. I found the on-demand option in the HLR, but I am not sure if the welcome SMS part is even possible since the network elements are now separated, no sign of it in any of the manuals though. I am working on a museum setup where there will be some pre-programmed SIMs in handsets, but it would be nice if the visitors themselves can use their own phone to connect and use the network. Worst case they can use the USSD command to get their MSISDN, but a welcome SMS would be nice to have. Regards, Csaba

8 months, 3 weeks

2
2
0 0

Re: OpenBSC Digest, Vol 105, Issue 5

by Sipos Csaba

Hi Keith, My question was targeting the Osmocom stack and not the (external) PBX. I already found some AMR patches for Asterisk (it seems it is still not part of mainline), will try to do that. The second half of my question was somewhat vaguely tries to ask if it is possible to do AMR when the call is MO-MT directly, or maybe the MGW can do transcoding, so in a nutshell: maybe there is a solution to do GSM FR when the call is outbound from the mobile network and AMR when it is mobile to mobile. Or the transcoding path is also an option. Point is: about these capabilities there is very little information available about what is supported and what is not within the Osmocom domain. Regards, Csaba

9 months

3
3
0 0

SMSC address terminology

by Mychaela Falconia

Hello fellow developers, I am getting ready to implement my own SMSC, connecting to Osmocom CN via GSUP (see OS#6135), and I have a question about SMSC address terminology. In traditional commercial GSM networks, the SMSC address visible to the user (prepended to the TPDU for MT SMs, stored in EF_SMSP record on the SIM for MO SMs) looks like a phone number in full international format, with TON=1 and NPI=1. For example, T-Mobile's SMSC address is +12063130004 (to an uninitiated eye it looks exactly like a regular phone number in Seattle, WA), while the SMSC of Mexican Telcel is +5294100001410 - one digit longer than regular phone numbers in Mexico, and a little irregular in structure. What is the correct term for these SC-address phone-number-thingies? Are they Global Titles - or is GT something different? If I were to make up fake global-looking SMSC addresses of this form, e.g., something like +1xxx55501xx for NANP territory, would it be correct to call such SC-address a fake Global Title? Just wondering... M~

9 months

2
1
0 0

EFR and/or AMR codec with Osmo-BSC/SIP-connector/Asterisk

by Sipos Csaba

Dear list, I managed to set up my E1 based Nokia BTS, the complete Osmo-CNI stack, SIP-connector and Asterisk. MO/MT calls do work as well as external SIP calls to and from mobile as well. But no matter what I do only plain FullRate calls are possible. Under osmo-bsc.conf code support is set like this (the BTS HW do support all of these codecs): codec-support fr efr amr but once I also add "codec-list fr3 fr2 fr1" to the MSC section of the osmo-bsc.conf, the calls wont establish anymore. I watched Neel's OsmoDevCall presentation on this topic, but it is not very clear what codecs are supported when osmo-sip-connector and an external PBX is used? Regards, Csaba

9 months

5
5
0 0

OsmoBTS project

by catalinaelena119＠yahoo.com

I have git-cloned https://gitea.osmocom.org/cellular-infrastructure/osmo-bts this project in order to have a solution for calling 2 mobile phones in my own network. I dont have any experience with this. I have instaled and configured in the past the same solution from PenHerts git but it is a lil bit old. I want to configure and install this solution bu i do not know the exact steps to do that. I dont find any configuration file or i do not know what to do with them. I do not have any experince with this domain and i want to know the steps in order to run this project properly. Could you help me with any directions?

9 months

2
1
0 0

Deprecating support for big endian in Osmocom

by Harald Welte

Hi all, during recent patch review (https://gerrit.osmocom.org/c/osmo-trx/+/33737) the topic of continuing to maintain support for big endian machines has come up. While traditionally I've always been a strong proponent of writing portable code that can run also on big endian systems, it is not the year 2003 or 2008 anymore, and PowerPC (the main big endian platform) is dead by now, as is SPARC. Not just in newly-built processors, but also in existing and still operating machines, at least of the class that would run our code. So unless somebody objects with strong arguments, I'd propose to officially and explicitly drop supporting big endian systems from osmocom CNI projects. From what I can tell, this would primarily mean * drop the struct_endianness check from the commit verification * removing all our struct_endianness-generated or other code that explicitly adds big endian support * adding some kind of #warning or even #error to a common libosmocore header file if anyone tries to build on big endian This obviously doesn't mean we can abandon using [osmo_]{htonl,ntohl}, as network byte order is still network byte order. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

9 months, 1 week

5
6
0 0

Trying to disable the UST service 124.

by Alejandro Blanco Pizarro

Hi all, It's Alejandro Blanco. I would like to disable the UST service 124 so that I connect the smartphone to a gNB based on srsRAN. However, there is an error after trying it. Find a screenshot below that shows the error message. Do you know how to fix this? Thank you. [image: image.png] Best regards, Alejandro ---------------------------------------------------------- *Alejandro Blanco Pizarro, PhD <https://alejandroblancopizarro.github.io/>* *Post-Doc at **The University of Edinburgh* ----------------------------------------------------------

9 months, 1 week

3
4
0 0

Osmocom discourse as alternative to mailing lists

by Harald Welte

Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

9 months, 1 week

1
0
0 0

Re: EFR and/or AMR codec with Osmo-BSC/SIP-connector/Asterisk

by Sipos Csaba

Hi, So, I migrated to today's master, and tried with MNCC local to make sure the PBX is not participating. Using an E1 based Nokia InSite and the target codec is EFR (as the InSite does not support AMR). And the test case is a MO - MT call. On the BSC config: codec-support fr efr codec-list fr2 On the MSC config: mncc-int default-codec tch-f efr default-codec tch-h hr The BSC log say: Tue Jul 25 21:53:45 2023 DCHAN abis_rsl.c:1291 lchan(0-0-2-TCH_F-0)[0x562876541b90]{ESTABLISHED}: (type=TCH_F) CONNECTION FAIL (cause=Remote Transcoder Failure [ 28 ]) Tue Jul 25 21:53:45 2023 DMSC osmo_bsc_bssap.c:1465 SUBSCR_CONN(msc0-conn1_subscr-IMSI-001010101000050-TMSI-0x910bc287)[0x562876543a00]{WAIT_CLEAR_CMD}: Event MT_DTAP not permitted The MSC log say: Jul 25 21:56:46 openbsc osmo-msc[759]: <0001> transaction.c:130 LCLS disabled globally Jul 25 21:56:47 openbsc osmo-msc[759]: <0007> mncc_builtin.c:373 (call 80000007) Message 'MNCC_RTP_CREATE' unhandled Jul 25 21:56:47 openbsc osmo-msc[759]: <0001> transaction.c:130 LCLS disabled globally Jul 25 21:56:48 openbsc osmo-msc[759]: <0007> mncc_builtin.c:373 (call 7) Message 'MNCC_RTP_CREATE' unhandled So this seems to be an issue within the Osmocom stack, the external MNCC connection was disabled. Regards, Csaba

9 months, 1 week

1
0
0 0

<0006> msc_main.c:572 Failed to parse the config file: '/etc/osmocom/osmo-msc.cfg'

by Sivanesh Kumar K

Hi all, I deployed osmomsc in docker in open5gs on raspberry pi4b with ubuntu22.10 OS. I am able to build the oscmomsc but osmomsc is excited having below error: $ docker logs osmomsc There is no such command. Error occurred during reading the below line: sgs <0006> msc_main.c:572 Failed to parse the config file: '/etc/osmocom/osmo-msc.cfg' I followed below steps in docker file to build FROM ubuntu:focal ENV DEBIAN_FRONTEND=noninteractive # Install updates and dependencies RUN apt-get update && \ apt-get -y install wget gnupg telnet RUN wget https://downloads.osmocom.org/packages/osmocom:/latest/xUbuntu_20.04/Releas… && \ mv Release.key /etc/apt/trusted.gpg.d/osmocom-latest.asc && \ echo "deb https://downloads.osmocom.org/packages/osmocom:/latest/xUbuntu_20.04/ ./" > /etc/apt/sources.list.d/osmocom-latest.list && \ apt-get update && apt-get -y install osmo-msc CMD /mnt/osmomsc/osmomsc_init.sh && \ rm -f /mnt/osmomsc/sms.db* && \ cd /mnt/osmomsc && /bin/osmo-msc -c /etc/osmocom/osmo-msc.cfg Please help me to resolve the issue Mobiveil INC., CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain proprietary confidential or privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender and destroy all copies and the original message.

9 months, 2 weeks

1
0
0 0

Assignment of 90170 MCC/MNC withdrawn by ITU.

by Robert Falkenberg

Hi all, this is some info for users of older Sysmocom SIM cards that came with IMSI prefix 90170. The ITU has withdrawn the assignment of the MCC/MNC 901/70, which was initially assigned to "Clementvale Baltic OÜ" back in 2020. Hence, the users of these SIM cards will no longer risk collisions with the public operator. (Newer cards as of 2020 come with an IMSI that starts with 99970 anyway.) Further reading: * https://en.wikipedia.org/wiki/Mobile_country_code#International_operators * https://www.itu.int/pub/T-SP-OB.1240-2022 Best regards Robert -- RobertFalkenberg Senior Engineer Software Radio Systems robert(a)srs.io <mailto:robert@srs.io> www.srs.io <//www.srs.io> Dortmund, Germany twitter <https://twitter.com/srssystems>

9 months, 2 weeks

1
0
0 0

OsmoDevCall on Jul 17, 2023: Building wired cellular test setups

by Harald Welte

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: July 17, 2023 at 20:00 CEST where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @laforge will be presenting on Building wired test setups for mobile communications Particularly in lab and test setup involving cellular technology there is often a need for wired (coaxial) connection of cellular equipment, such as connecting a number of UEs (phones/modems) with one or multiple cellular base stations. For example, this is the only way to get defined power levels and test the actual transmit power or receive sensitivity of a device. The talk will cover how to build such test setups from parts like coaxial cabling, attenuators, RF splitter/combiners, duplexers, etc. This meeting will have the following schedule: 20:00 meet + greet 20:10 topic as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - 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)

9 months, 3 weeks

2
1
0 0

code review

by Neels Hofmeyr

Hi community, I feel a bit frustrated by how code review is going recently at osmocom. Let me compare two larger feature branches: There are weeks of review on 19 patches in osmo-hnbgw/cnpool, and <24h from submit to merge on 14 patches in osmo-msc. That may in some situations be ok and justified, but I feel that it is not: The cnpool patch series for osmo-hnbgw spawned huge discussions and long delays on account of minor issues: log lines, event names and comments. I said so, yet it droned on and even spawned offspring. None of the important features was part of code review: larger design choices of the API, efficiency in handling the actual signalling, correctness of the signalling. Maybe that's because all those were mint perfect and no bugs anywhere, but I doubt that I'm really that good =) And at the same time I was "just now" asked to review some patches for osmo-msc, which changes an API that I have recently added and had ideas and reasons for. Before I get a chance to even glance, I see that all the patches are already merged! It is now basically too late to bring in my feedback, because the patches are in, and why spend more time on it. Suck it up, bygones. This very API that was being changed in osmo-msc in under 24 hours was itself under code review scrutiny for at least three years. Also I have (in my own free time) tried to get an improved logging timestamp into libosmocore. This is tagging along for years and years now, because every time over it is being blocked by minor details that are matters of taste. For years I lose precious moments every time i have to read an 'extended-timestamp' in osmo logging and identify the boundary of hours, minutes and seconds. This I consider important. AFAIR the reasons for blocking the patches were, objectively, all not important. These examples are starkly unbalanced. I'm sure you're aware of the bikeshed phenomenon -- it is a precise description of what is happening. It would be great if we could turn that around a bit? http://www.catb.org/jargon/html/B/bikeshedding.html Let's say, I know from experience that it is hard to give good code review, so count me in on this advice. Let's still give all the code review we can, but let's keep in mind the actual impact the particular code change has. If it goes in the "fringe detail" bucket, let's mention it, but just let it pass if the author disagrees. Hope you understand my frustration and maybe even agree. Thanks, ~N

10 months

2
2
0 0

OsmoBSC located next to OsmoBTS: good idea or not?

by Mychaela Falconia

Hello Community, Quick question: if I have to set up a network where the BTS is physically distant from the MSC, such that either the A link or the Abis link has to be carried across public Internet (or inside an encrypted tunnel running over public Internet), would it be better to colocate OsmoBSC next to OsmoMSC, running Abis across the Internet- based hop, or colocate OsmoBSC next to OsmoBTS and have A running across that long hop instead? I recall hearing that the A interface carries significantly less traffic than Abis, and therefore the recommended config is to have OsmoBSC next to the BTS. However, it is only a vague recollection on my part, without certainty, hence I thought I would ask here to confirm, before I embark on a more detailed design of the proposed production network in this config. TIA, Mychaela

10 months

2
1
0 0

Nokia Site (Ultra, Metro)

by Sipos Csaba

Hi Harald, > Is that patch already in gerrit somewhere? https://github.com/dchard/osmo-bsc/tree/nokia_ultrasite I managed to get some InSite units so now I have the whole range. I tested all units, and this is the result: 1. InSite: it does not initiate the RSL LAPD even when the unit reports: "waiting for lapd", the BSC needs to start the RSL bootstrap. Non the less, multi BTS operation does work (tried it with HDSL cascade), although I have seen some weird behavior between bootstraps (just starting the BSC does not trigger the same behavior). 2. MetroSite: this unit does start the RSL bootstrap on its own when the TRXes reaches "waiting for lapd" state, it does not wait for the BSC to do it. Multi TRX, RF and BB hopping works as expected. 3. UltraSite: it runs exactly the same SW version as the MetroSite, yet this unit also does not start the RSL bootstrap on its own even when the unit reports: "waiting for lapd", the BSC needs to start the RSL bootstrap. Only single TRX works in this case. Also the MetroSite does not spits out garbage on the E1, the InSite and UltraSite does. In general one issue is that even after the BTS reset is ACKed, the BSC allows the RSL LAPDs to be bootstrapped while the unit is already resetting, and that fails obviously. But more importantly, it seems that the whole LAPD logic is not working exactly the same across the unit types. I wonder if we should wait more for the RSL to be triggered by the BTS itself and should not start the RSL bootstrap after CONF_COMPLETE received. I found no info about who should initiate the RSL bootstrap: the BTS or the BSC? Regards, Csaba <openbsc-request(a)lists.osmocom.org> ezt írta (időpont: 2023. jún. 30., P, 14:00): > > Send OpenBSC mailing list submissions to > openbsc(a)lists.osmocom.org > > To subscribe or unsubscribe 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. Re: Nokia Site (Ultra, Metro) (Harald Welte) > 2. Re: code review (Harald Welte) > 3. Re: Nokia Site (Ultra, Metro) (Harald Welte) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 30 Jun 2023 12:08:43 +0200 > From: Harald Welte <laforge(a)osmocom.org> > Subject: Re: Nokia Site (Ultra, Metro) > To: Sipos Csaba <dchardware(a)gmail.com> > Cc: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> > Message-ID: <ZJ6pq/2V9WfA3yDw@nataraja> > Content-Type: text/plain; charset=us-ascii > > Hi Sipos, > > On Fri, Jun 23, 2023 at 11:18:35AM +0200, Sipos Csaba wrote: > > I checked RF and BB hopping with my MetroSite with my patch added, and > > they both seem to work, multi-TRX was tested a couple days ago, that > > also works with 2 TRXes. Obviously I did not tested every possible > > hopping scenarios, but in both cases the node manager reported the > > correct hopping states and I also checked with a spectrum analyzer. > > This is good news. Is that patch already in gerrit somewhere? > > > Anyway, at this point in time I don't see any particular issues that > > indicates a BSC problem. One feature missing is the ability to > > configure sectors (Nokia calls a sector a "BTS" while the base station > > is called "BCF"). My question is, do we have any BTS type that has > > sector configuration support so I can take a look how this was done > > (if any) ? > > I think we never had support for this in OsmoBSC or even before in OpenBSC. > > In GSM/3GPP spec language, every sector is a BTS. The fact that many networks > use sectorized cells is nothing that reflects anywhere in the specification or > the terminology. It's an implementation detail. > > I think from the OsmoBSC point of view, a typical 3-sector site would still be > three logical BTSs (in the data model / structures). It's "just" the respective > manufacturer OML code would have to be adjusted to accomodate a situation where > there are managed objects that only exist once per site, while others > exist per BTS/TRX/... > > We have the same situation with Ericsson OM2000 support: Right now one > can only have a single BTS per RBS, as our OM2000 code doesn't > distinguish between MOs that exist once per site only (CF, TF, IS, ...) > and MOs that exist for each BTS. > > -- > - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > ------------------------------ > > Message: 2 > Date: Fri, 30 Jun 2023 12:02:11 +0200 > From: Harald Welte <laforge(a)osmocom.org> > Subject: Re: code review > To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> > Cc: openbsc(a)lists.osmocom.org > Message-ID: <ZJ6oI2u2l9wAJ2Eo@nataraja> > Content-Type: text/plain; charset=us-ascii > > Hi Neels, > > On Wed, Jun 21, 2023 at 05:37:55AM +0200, Neels Hofmeyr wrote: > > Let me compare two larger feature branches: > > There are weeks of review on 19 patches in osmo-hnbgw/cnpool, > > and <24h from submit to merge on 14 patches in osmo-msc. > > I'm not saying this is good, but I think the difference is likely in terms of > complexity of the related patches. Small patches doing simple to understand > things are easy to review and hence likely to be merged more quickly. > > > The cnpool patch series for osmo-hnbgw spawned huge discussions and long delays > > on account of minor issues: log lines, event names and comments. I said so, yet > > it droned on and even spawned offspring. > > It would be good to have pointers to specific gerrit patches here. I'm trying to > look at it now, but topic:cnpool has so many patches that it's hard to find which > ones you're referring-to exactly. > > https://gerrit.osmocom.org/c/osmo-hnbgw/+/33133 has a discussion about > parsing of routing area identities and using shared code rather than > open-coded implementations in various places. I consider that relevant > and not cosmetic/bikeshedding > > https://gerrit.osmocom.org/c/osmo-hnbgw/+/33173 contains a discussion > about naming. Naming *is* important, particularly if it uses terms > which already have well-established meaning, such as (here) what is a > RANAP RESET and what is a "lost link". Code in maintained software > development projects is written not merely to execute, but for other > developers to read and continue to develop/maintain. If terminology is > used in a wrong way, it is likely misunderstood by other developers, > causing problems down the road when investigating bugs or adding new > functionality. I am seeing quite a lot of questionable naming in > general when it comes to SS7/SIGTRAN. Also, event/state names of FSMs > may end up in log or VTY output, where it has the potential to confuse > not just other developers but users. > > https://gerrit.osmocom.org/c/osmo-hnbgw/+/33178 contains a "maybe add a > log line" spawning a discussion with relatively verbose messages in it. > That might be one of the cases you are referring to? To be fair it was > a "maybe" comment, so a simple one line response might have been > sufficient. > > > None of the important features was part of code review: > > larger design choices of the API, efficiency in handling the actual signalling, > > correctness of the signalling. > > tbh, if there's a series of (it feels like) 30+ patches doing lots of complex > stuff, it's hard to assume anyone is able to grasp those from reading > the diffs. For correctness of signalling the test cases and > associated pcaps are probably a better resource than gerrit patch > review. > > > And at the same time I was "just now" asked to review some patches for > > osmo-msc, which changes an API that I have recently added and had ideas and > > reasons for. > > again, please provide specific pointers. Without that you are expecting > every reader of this e-mail to re-read all osmo-msc patches of the last > few weeks just to find out which specific one[s] you are referring to. > > It might have been https://gerrit.osmocom.org/c/osmo-msc/+/33358/1 where > I overlooked a *resolved* comment "Not merging this one yet to give > Neels a chance to review as well since he wrote the codec filter stuff > that this is now modeled after." which I didn't see as the patch and > many following it had two positive reviews and built correctly and hence > I merged the entire series. > > My workflow is usually to perform code review, and then if I'm done and > there are series or parts of series with V+1/R+2 merge those entire > series/chunks, particularly if there are no unresolved comments. > I'm [obviously] not going through each and every resolved comment of > every patch in a series. Those are *resolved*. > > So while it was me who merged that series, and I'm of course sorry if > that created problems, I acted in good faith (see above). > > I think if anyone wants to hold back a merge for whatever reason, make > sure you put a -1 vote in so it becomes impossible to be merged by > accident. Or at the very least make sure there is an unresolved comment > which will produce a warning when attempting to merge. > > > Before I get a chance to even glance, I see that all the patches > > are already merged! It is now basically too late to bring in my feedback, > > because the patches are in, and why spend more time on it. Suck it up, bygones. > > It's not all lost: One can always send follow-up patches? Or revert the > original patch and replace it? No release has been made in between, so > no stable API has been set in stone that needs to continue to be > supported. > > > Also I have (in my own free time) tried to get an improved logging timestamp > > into libosmocore. This is tagging along for years and years now, because every > > time over it is being blocked by minor details that are matters of taste. For > > years I lose precious moments every time i have to read an 'extended-timestamp' > > in osmo logging and identify the boundary of hours, minutes and seconds. This I > > consider important. AFAIR the reasons for blocking the patches were, > > objectively, all not important. > > I always found it mildly fascinating how many options, choices and > formats (I think primarily you) introduce to the libosmocore logging. > Like file name in front or file at the end? I think osmo* is the only > software with which I've worked where the actual *format* of the log has > many user-configurable options. I'm not talking about sub-systems, > levels and targets! Now we even have multiple different formats for > timestamps, and we are growing more of them. In my opinion, most of > this is bloat. It just adds complexity to things happening at the > runtime of the osmo-* code for something that could just as well be > obtained with log post-processing (like converting from a unix epoch > timestamp to whatever human readable format the reader desires). We've > already merged a lot of this over the years. > > To me, the problem with all those many options is that it becomes > very difficult to have any software parsing/analyzing osmo* logs, as > every deployment might be chosing a different combination of "this is my > personal favorite of ordering the portions of a log line" or "this is my > personal favorite of formatting a timestamp". > > But now introducing *timezones* into the program > (https://gerrit.osmocom.org/c/libosmocore/+/32043) really goes over the > top for me. Timezones are handled at the operating system level / libc. > > > Let's still give all the code review we can, but let's keep in mind the actual > > impact the particular code change has. If it goes in the "fringe detail" > > bucket, let's mention it, but just let it pass if the author disagrees. > > To be honest, I don't really see much of this here. I see a lot of > optional / non-critical stuff like "typo here" or "maybe ..." but I > rarely see "I absolutely demand that you must ...". > > Regards, > Harald > > -- > - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > ------------------------------ > > Message: 3 > Date: Fri, 30 Jun 2023 12:09:27 +0200 > From: Harald Welte <laforge(a)osmocom.org> > Subject: Re: Nokia Site (Ultra, Metro) > To: Sipos Csaba <dchardware(a)gmail.com> > Cc: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> > Message-ID: <ZJ6p15URO27eoMei@nataraja> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jun 25, 2023 at 03:08:51PM +0200, Sipos Csaba wrote: > > I tested up to four TRX with the Metro and that works as well. Once > > everything is tested and working I will provide example files, and try > > to updated the Nokia specific wiki as it is quite outdated (info is > > from the NITB era). > > Thanks in advance! > > > Will try to look at Ericsson and BS-11, maybe there are some clues > > about sectors there. > > See my other mail, unfortunately it's not something implemented. > -- > - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OpenBSC mailing list -- openbsc(a)lists.osmocom.org > To unsubscribe send an email to openbsc-leave(a)lists.osmocom.org > > > ------------------------------ > > End of OpenBSC Digest, Vol 104, Issue 8 > ***************************************

10 months, 1 week

1
0
0 0

Nokia Site (Ultra, Metro)

by Sipos Csaba

Hi Neels, I checked RF and BB hopping with my MetroSite with my patch added, and they both seem to work, multi-TRX was tested a couple days ago, that also works with 2 TRXes. Obviously I did not tested every possible hopping scenarios, but in both cases the node manager reported the correct hopping states and I also checked with a spectrum analyzer. This means that either my UltraSite still has some issues, or that the config logic for it needs a bit of tuning. The one difference I have noticed is that the MetroSite does starts the RSL LAPD when the TRXes reach a configured state, while the UltraSite needs the BSC to start the RSL LAPD links even after the TRXes reach the same configured state. FYI, I am running exactly the same BTS SW release on both units (latest LTS ever released by the vendor), so they should not behave differently from a pure SW point of view. Anyway, at this point in time I don't see any particular issues that indicates a BSC problem. One feature missing is the ability to configure sectors (Nokia calls a sector a "BTS" while the base station is called "BCF"). My question is, do we have any BTS type that has sector configuration support so I can take a look how this was done (if any) ? Regards, Csaba

10 months, 1 week

3
4
0 0

BSC to multiple external MSCs

by Varoon Greedharry

Hello, I know it's quite a dummy question (Beginner) but I'm actually trying the BSC to two external MSCs but the attempt failed. As per the doc, I did configure the cs7 instance. Is there an example configuration file which I could go through. -- Best Regards, Varoon

10 months, 2 weeks

2
2
0 0

Re: OpenBSC Digest, Vol 104, Issue 1

by Sipos Csaba

Hi Neels, Sorry for the late response. As there is still a slight chance that the issue on my side is HW related, I digged out my old MetroSite with 4 TRX as that is a little bit smaller and easier to move compared to the Ultra cabinet :-) So I will conduct some tests with it in the next couple days. Lets say the issue is the same: what exactly do you need from me to maybe look into it? I assume E1 pcap and logs. If you have a specific log mask, or you need something else, please let me know. Regards, Csaba

10 months, 2 weeks

2
2
0 0

OsmoDevCall on Jun 21, 2023: FR/HR/EFR voice codecs in Osmocom RAN

by Harald Welte

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: June 21, 2023 at 20:00 CEST where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @falconia will be leading a discussion on FR/HR/EFR voice codecs in Osmocom RAN This meeting will have the following schedule: 20:00 meet + greet 20:10 topic as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - 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)

10 months, 2 weeks

1
0
0 0

Nokia UltraSite

by Sipos Csaba

Hi Harald, I made some progress with the Nokia UltraSite and managed to fix its backplane, so at least I was able to continue with reintroducing hopping control with the first 2 TRX slots of the cabinet. During this process I realized that apparently even multi-TRX support is broken, which was working on the old OpenBSC codebase in 2016. If only the first TRX is configured the BTS bootstraps fine, but when a second TRX is configured, the unit goes into this weird state: the first TRX loops through configurng and waiting for LAPD states and stays in configuring state, while the second TRX is stuck ad supervisory state where TRX test is possible (it does pass the test). I used my old multi-TRX config file that actually worked with UltraSite (and MetroSite) where the second TRX only has TCH/F so nothing fancy, no hopping or anything like that. I wonder if my modification of moving the RSL bootsrap to after CONF_COMPLETE somehow changed something, maybe the BTS requires the RSL LAPD links to be up during the CONF state? Or the new FSM lchan refactoring might have introduced this in 2018... So apparently we have some more basic issues here then hopping :-) Regards, Csaba

11 months

2
1
0 0

Request for Assistance with GPRS Configuration

by Ahnaf Tahmid

Dear Osmocom Community, I have noticed that the wiki page for OpenBSC GPRS at https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on the GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS on my system. I have attached my configuration files below for your review. ip address 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff 3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0 valid_lft 7152sec preferred_lft 7152sec inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute valid_lft forever preferred_lft forever

11 months, 1 week

3
6
0 0

Enhanced RTP transport of FR & EFR in IP-based GSM RAN

by Mychaela Falconia

Hello Osmocom, I have written a new specification, in the style of 3GPP specs, for enhanced RTP transport of FR and EFR codec frames in an IP-based GSM RAN, addressing problem areas where the general standard RTP format for these codecs creates functional regressions relative to the original T1/E1 Abis architecture with TRAU frames. The new spec has its official home here: https://www.freecalypso.org/specs/tw-ts-001-v010001.txt and here is a pair of patches adding OsmoBTS support for accepting this TW-TS-001 format in RTP input and optionally (per vty config) emitting it in RTP output: https://cgit.osmocom.org/osmo-bts/log/?h=falconia/rtp_traulike The code patches are just for better context - they will go to Gerrit for review later - but right now I am soliciting a review of the specification, rather than code implementation. I am not aware of any established process in Osmocom for reviewing new specifications (different from code review), as writing new 3GPP-style specs is not something this community does often. But in the present case I am genuinely convinced that the Internet standard RTP format for GSM-FR and GSM-EFR (written with VoIP rather than GSM RAN in mind) is truly deficient for GSM RAN purposes, especially for those who wish to deploy their GSM networks in a retronetworking fashion, and the only way to bring back the full set of E1 Abis bells and whistles over IP is to invent our own (completely optional) pseudostandard format that will likely only be used within {Osmocom+Themyscira} community. With this context in mind, I cordially invite all of you, esteemed GSM FOSS developers, to review the new specification linked above. Sincerely, Mother Mychaela

11 months, 1 week

1
0
0 0

Nokia UltraSite

by Sipos Csaba

Hi Harald, I tested and can confirm that the Nokia code cannot handle a situation when the first TRX is not the first physical TRX in the cabinet. This affects MetroSite and UltraSite and all other variants that can handle more than one TRX. Given the fact these units are getting 20+ years old, backplane or other HW issues can force a user to not start with the first physical TRX and in that case the RSL bootstrap fails as the BTS receives a config starting with trx1 while the unit may has trx2 or trx3 etc. Question is how to handle this? One option is that on Nokia, each TRX has its own RSL TEI, and that is a 1:1 match as much as I know. Physical TRX1 has TEI1, TRX2 has TEI2 etc. So we can make a check during fu_config to first determine the first physical TRX based on the RSL TEI, and then check at each iteration which is the next one. For example you can have trx2 and trx4 as well, so we cannot expect that the TRX-es are in a continuous order nor that they always start with trx1. Another option is to introduce a new Nokia specific TRX variable that describes the physical location of the TRX inside the cabinet and do the above mentioned checks with that. Or there is a 3rd option I am not thinking about :-) Any and all opinions are welcome. Regards, Csaba

11 months, 2 weeks

1
0
0 0

Nokia UltraSite

by Sipos Csaba

Dear Harald, Sorry for the delay, the UltraSite cabinet has some massive backplane/interconnect issues, I tried to sort those out in the last couple days (with not much success). I had some time to further investigate the Nokia UltraSite situation, and here are the outstanding issues I faced: 1. 2-3 seconds after BTS_RESET the OML LAPD link is reestablished (coming from the BTS itself), and the signalling logic tries to bootstrap OML (sometimes RSL as well) during the BTS performing the reset. This tries do fail of course. Not sure if this causes any practical error, although it does not look nice. Maybe adding some logic state checks can help? 2. Sometimes on the OML LAPD link (and only on that one) I can see these error messages: DLLAPD lapd_core.c:1315 (0:1-T1-S62) S frame response with F=1 error DLLAPD lapd_core.c:421 (0:1-T1-S62) sending MDL-ERROR-IND cause 6 from state LAPD_STATE_MF_EST Sometimes they arrive in batches, sometimes only a few. FYI the BTS and the TRE both runs the latest SW ever released for UltraSite (CX8.2). 3. Moving the RSL bootstrap to after "NOKIA_BTS_CONF_COMPL" received seems to be working fine, this way we don't need to add another timer, and Osmo-BSC can wait long enough to make sure all the TRXes loaded the SW, configured and waiting for LAPD. In case more than one TRX is used, the TRXes reach the "waiting LAPD" state in different order. Did you had time to maybe try with InSite? I dont think my patch can brake it, but I remember InSite was an odd ball within the Site family. I also started to re-introduce RF/BB hopping control for Nokia, if you - or anyone - can review it that would be lovely: https://github.com/dchard/osmo-bsc/commit/41f6cd4723961700c5e5eceab4c92e7ce… I was not able to try it out yet, as due to my backplane issues with the cabinet, only TRX1 and TRX3 and TRX4 slots are working. And for some reason if I try to use TRX3 and 4, the RSL bootstrap fails. I wonder if the Nokia code has some limitation if the first TRX is not actually the first? I tried to configure Osmo-BSC to start with "trx 2" but it does not want to start anything other than "trx 0". Of course the question is what OsmoBSC sends during OML bootstrap. As much as I can see, the Nokia code does not take into account if the first TRX is not the first physically in the unit, but I am not a 100% sure yet. Some help or hint here would be very welcome. This is where I am now. The HW issues with the unit makes it pretty time consuming to focus on the SW side, for now. If you or anyone has any ideas or comments, please let me know. Regards, Csaba

11 months, 2 weeks

1
0
0 0

How is support for the Ericsson DUS 31/ Ericsson packetAbis/IP

by Enzo D'Amato

Hi! I just purchased a used Ericsson RBS 6000 chassis with a DUS 31 module in it. From what I have read, this module should be compatible with Open5GS for the LTE side, but I wanted to inquire about the status of support for it on the GSM side under OsmoBSC. As far as I know, it should work the same as the DUG series which is supported, with the only difference being it's use of Ericsson packetAbis/IP rather than hardware T1 lines for the voice backhaul connectivity. Will these units work with osmocom for GSM, or will I have to purchase a DUG unit for my enclosure? Is there anything else I should be aware of? Thank you, Enzo D'Amato

11 months, 2 weeks

2
2
0 0

Jenkins Builder spurious failure

by Mychaela Falconia

It looks like there is something wrong with the Jenkins Builder invoked by Gerrit: https://jenkins.osmocom.org/jenkins/job/gerrit-binpkgs-rpm/5274/consoleFull The errors in that log seem like something to do with the build environment (couldn't download RPM for libtalloc-devel?) and nothing to do with the patch which I submitted to Gerrit. Which is: https://gerrit.osmocom.org/c/osmo-bts/+/32788 M~

11 months, 3 weeks

3
2
0 0

OsmoDevCall presentation proposal: FR/HR/EFR speech handling

by Mychaela Falconia

Dear Osmocom community, Over the past several months I've been working almost exclusively on improving FR1 and EFR speech handling in the Osmocom GSM network implementation. All of my Gerrit patches since March have been in this area, and my two Themyscira-branded public domain libraries for GSM codecs are also primarily intended for use together with Osmocom, specifically for implementation of transcoding media gateways that interconnect an Osmocom GSM network with a non-GSM outside world such as G.711 PSTN. Given the knowledge I've gained over months of working in this area, and seeing that many other Osmocom developers aren't particularly familiar with these aspects of the specs (understandable: GSM is huge, can't keep everything in one's head), I would like to do an OsmoDevCall presentation on the topic of GSM speech handling with traditional non-AMR codecs. I would like to cover the following subtopics: * What metadata bits (BFI, UFI, SID, TAF) are defined in the specs for transport of encoded speech between network elements, beyond the familiar speech codec bits themselves. * What exactly are regular speech frames, SID frames, silence frames (a "silence frame" for FR1 codec is NOT the same thing as a SID frame!) and bad frame gaps, and which of these categories are allowed or not allowed to exist at each of the interfaces in the spec-defined GSM architecture. * Which transformations are supposed to happen where: which network elements are responsible for bad frame handling, error concealment, comfort noise insertion or SID propagation. * How these architectural principles, originally defined for the T1/E1 environment with TRAUs, can be carried over to an RTP environment. * Relevant Osmocom components: OsmoBTS and the aspect of OsmoMGW that interfaces from RTP to T1/E1 Abis. * What behavior changes have been effected by my patches to OsmoBTS and supporting libraries that have already been merged, and which behavior changes are still on my wish list or to-do list to implement and hopefully get merged. Looking at the OsmoDevCall wiki page, I see absolutely nothing scheduled past May, and there was no OsmoDevCall in April - are we out of presenters? But we have just one problem: it seems that some people in the senior leadership of Osmocom organization don't want me presenting on OsmoDevCall, and recently even asked specifically for presentation ideas from "anyone other than Mychaela". I see two possible solutions to this problem: Option 1: If the leaders in question could set aside their personal dislike of me and allow me to present on highly Osmocom-relevant topics (such as the FR/HR/EFR codec presentation proposal above) no different from other Osmocom developers, that would be the best solution. Option 2: If those who control the scheduling of presentations on the official OsmoDevCall platform (the official BigBlueButton instance for ODC) are not willing to budge, the alternative will be for me and Das Signal (my dear friend and FreeCalypso sysadmin) to set up our own BBB instance on our own server, configure it to look and feel exactly like the official one used for ODC, hold presentations there during those months when no official ODC presentation takes place due to lack of non-excluded willing presenters, and invite everyone from Osmocom to join those unofficial ODC-like presentations. So - which of the two is it going to be? Sincerely, Mother Mychaela, operator of a non-profit GSM network based on Osmocom, contributing to Osmocom CNI development in conjuction with that network operation.

11 months, 3 weeks

3
3
0 0

gsm-codec-lib-r2 new release

by Mychaela Falconia

Hello GSM community, I just put a new release of Themyscira GSM codec libraries and utilities package: ftp://ftp.freecalypso.org/pub/GSM/codecs/gsm-codec-lib-r2.tar.bz2 ftp://ftp.freecalypso.org/pub/GSM/codecs/gsm-codec-lib-latest.tar.bz2 (symlink) The two libraries in this package (libgsmefr and libgsmfrp) are intended for people who develop gateway software interconnecting Osmocom-based GSM networks to PSTN or other networks, gateways which include a speech transcoding function that terminates the GSM codec leg. If anyone is currently interconnecting an Osmocom GSM voice network to the outside world using software which you did not write yourself (Asterisk, FreeSwitch, Kamailio, whatever) and you care about the plain old FR codec, and/or care about EFR, beyond just AMR, I encourage you to investigate your current non-Osmocom gateway software to see exactly how it implements FR and EFR. Because there were NO pre-existing FOSS libraries that correctly implement FR and EFR decoding prior to my Themyscira gsm-codec-lib development, most pre-existing gateway software probably implements these codecs in a flawed manner: FR codec: Everyone to my knowledge implements this codec using classic libgsm, a library that dates back to 1990s. It's a good library, it's a fully correct implementation of GSM 06.10 spec, and I use it too. However, it implements _only_ a bare 06.10 encoder and a bare 06.10 decoder, without any DTX functions of GSM 06.31 and related specs. In the encoder direction having no DTX isn't really a problem (you won't be able to do DTXd anyway unless you got lots of spectrum and are running multi-ARFCN cells), but the lack of an Rx DTX handler per GSM 06.31 *is* a real problem: if you feed the uplink from a GSM call (RTP stream from a BTS) to a bare GSM 06.10 decoder such as gsm_decode() function in libgsm, you won't get correct handling of SID frames, which every standard GSM MS will transmit, and you won't get correct handling of BFI frame gaps, which will always occur. The correct solution is to insert a call to a GSM 06.31 Rx DTX handler (it is more than an ECU) just before the call to gsm_decode(), and my libgsmfrp offering is that GSM 06.31 Rx DTX handler. EFR codec: Everyone other than me implements EFR (if they support it at all) using an AMR library such as libopencore-amrnb. I have seen totally broken implementations that schlep 244-bit payloads directly between supposed-to-be-EFR RTP and the AMR library, without reordering those bits per gsm690_12_2_bitorder[] - those implementation have exactly zero chance of ever actually working with a real GSM-EFR MS on the other end - and I've also seen implementations that do perform this bit reordering and are thus closer to correct. But even the latter implementations are still wrong when it comes to SID handling: EFR is equivalent to the highest MR122 mode of AMR only for regular speech frames, but not for SID. There does exist a special encoding format for representing GSM-EFR SID in AMR frame interfaces, but libopencore-amrnb does not support GSM-EFR SID in any way at all. If you take the uplink from a GSM-EFR call and feed it to libopencore-amrnb decoder, any time the GSM MS emits a SID frame, strange noise sounds will appear at the output of that decoder, instead of the correct comfort noise. Themyscira libgsmefr is a proper encoder and decoder library for EFR, based on the EFR reference code from ETSI, in exactly the same way how libopencore-amrnb is based on the AMR reference code from ETSI/3GPP. It still has some performance problems which I will be working on later (the goal of getting it to perform no worse than libopencore-amrnb has not been achieved yet), but at least it is correct. Hasta la Victoria, Siempre, Mychaela aka The Mother

11 months, 3 weeks

1
0
0 0

Osmo-BSC with Nokia UltraSite

by Sipos Csaba

Dear Harald, A long time passed since I worked with the Nokia Site family and OpenBSC. I managed to save an UltraSite cabinet from scrap, so I try to revive it for a museum. On the old NITB versions I managed to make this work once, now I am trying with the new (at least to me) Osmo-BSC implementation. To keep it simple, only one TRX is configured: OML <--> E1 TS 1 (64kbit) RSL <--> E1 TS 2 (64kbit) TRXSIG <--> E1 TS 3 and 4 DAHDI is used with a Digium Wildcard TE110P T1/E1 Board. Osmo-BSC is able to do the OML bootstrap, but the RSL waits for LAPD endlessly. My first question is: should Osmo-BSC be able to bootstrap the BTS fully (all the way to "on air" mode) if it is not (yet) connected to any other core element (MGW, MSC, STP) ? This is the Osmo-BSC log (after the NOKIA_BTS_RESET command + the reset_wait_time passed): DLLAPD input/lapd.c:245 (0:1-T1-S62): LAPD Allocating SAP for SAPI=62 / TEI=1 (d l=0x56284cfbd220, sap=0x56284cfbd200) DLLAPD input/lapd.c:255 (0:1-T1-S62): k=1 N200=3 N201=260 T200=1.0 T203=10.0 DLLAPD input/lapd.c:519 (0:1-T1-S62): LAPD DL-ESTABLISH request TEI=1 SAPI=62 DLLAPD input/lapd.c:654 (0:1-T1-S62) LAPD DL-ESTABLISH confirm TEI=1 SAPI=62 DNM bts_nokia_site.c:63 (bts=0) bootstrapping OML DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x82) NOKIA_BTS_OMU_STARTED DNM bts_nokia_site.c:1583 (bts=0) Rx BTS type = 17 (UltraSite GSM 900) DNM bts_nokia_site.c:1098 (bts=0) Sending NOKIA_BTS_START_DOWNLOAD_REQ DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x84) NOKIA_BTS_MF_REQ DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x88) NOKIA_BTS_CONF_REQ DNM bts_nokia_site.c:1098 (bts=0) Sending NOKIA_BTS_ACK DNM bts_nokia_site.c:1260 (bts=0) Sending multi-segment 0 DNM bts_nokia_site.c:1260 (bts=0) Sending multi-segment 1 DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x81) NOKIA_BTS_ACK DNM bts_nokia_site.c:1604 (bts=0) Rx ACK = 1 DLLAPD input/lapd.c:245 (0:2-T1-S0): LAPD Allocating SAP for SAPI=0 / TEI=1 (dl= 0x56284d252a20, sap=0x56284d252a00) DLLAPD input/lapd.c:255 (0:2-T1-S0): k=2 N200=3 N201=260 T200=1.0 T203=10.0 DLLAPD input/lapd.c:519 (0:2-T1-S0): LAPD DL-ESTABLISH request TEI=1 SAPI=0 DLLAPD lapd_core.c:421 (0:2-T1-S0) sending MDL-ERROR-IND cause 1 from state LAPD _STATE_IDLE DLLAPD input/lapd.c:658 (0:2-T1-S0) LAPD DL-RELEASE indication TEI=1 SAPI=0 DLLAPD input/lapd.c:282 (0:2-T1-S0): LAPD Freeing SAP for SAPI=0 / TEI=1 (dl=0x5 6284d252a20, sap=0x56284d252a00) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-0)[0x56284d251770]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-0)[0x56284d251770]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-1)[0x56284d2519b0]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-1)[0x56284d2519b0]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-2)[0x56284d251bf0]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-2)[0x56284d251bf0]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-3)[0x56284d251e30]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-3)[0x56284d251e30]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) Would be nice to make this old beast running again. Much appreciate any and all help. Regards, Csaba

11 months, 3 weeks

2
5
0 0

T1/E1 beyond the BTS - how about BSC and TRAU?

by Mychaela Falconia

Hello Osmocom, I know a lot of people here have salvaged T1/E1 BTS equipment from Nokia, Ericsson etc. But what about the next level up - has anyone been able to salvage a classic T1/E1 BSC that goes with those BTSes? And given the hardware, does anyone in our community know how to get one of those beasts working? I am interested in the TRAU component of the classic GSM BSS architecture, and I would really love to lay my hands (remotely, via OCTOI, would be just fine) on one of those beauties. Specifically, I seek to feed custom-crafted bits to the TRAU's Abis input and capture what it puts out on the A interface G.711 side, and vice-versa. What can be learned from such experiments? Several things: * I would love to play with TFO: see the TFO_REQ in-band signaling messages the TRAU should put out on its own during the first 5 s or so, then send our own TFO_REQ and TFO_ACK to the TRAU, do the whole protocol, and get the TRAU to actually enter TFO mode. Reading the spec is one thing, but seeing it in action would be so much more fun! I've also been wanting to write my own FOSS implementation of in-band TFO within G.711 RTP, but it would be an impractical task without having some other existing implementation to test against. * If we can get TFO to work, we'll be able to see exactly how real TRAUs handled the onerous requirements of TS 28.062 section C.3.2.1.1. Implementing those rules for FR1 would be quite easy, but try doing the same for EFR or HR1 - *very* daunting! It would be lovely to see exactly what actual historical implementations did here. * Outside of TFO, we should be able to get the TRAU into a known state by feeding it spec-defined encoder and decoder homing frames, and then craft our own test sequences (beyond the standard ones it was surely tested with by its designers) to exercise those parts of the codec implementation where the specs allow implementors to innovate, particularly everything to do with error concealment. But doing all of the above requires access to some old-style T1/E1 BSC that contains such a TRAU. Does anyone in our community have access to such hw? M~

11 months, 4 weeks

1
0
0 0

private branches

by Neels Hofmeyr

Should I change the way I do private branches in osmocom? I push a lot of private branches everywhere. I was asked in PM if I could cut down on branches a bit because it clutters other developers' view of the git history. My immediate response was: the other developer should simply not fetch my branches, or invoke tig or gitk in a way that shows only selected branches. But I reflected a bit and would like to ask generally how we want to do it. For osmocom it apparently is mostly me pushing private branches a lot. What if we all did that... In linux kernel development it seems to be more like each developer has her own public repository to make a mess in. So, i could make git clones of our main repositories in gitea and keep my private branches there. It seems like maybe i should do that out of common courtesy. But it also adds a bunch of overhead for me, keeping separate repositories synced. Having multiple remotes affects git commandline behavior. I used to have separate fetch/push URLs for a while, but it was annoying in some ways. I can change my ways, but only if i really have to. Any opinions? Are my branches annoying? Aspects: - backup of my ongoing work. (daily) - offering preliminary work to customers for manual build. (weekly) - seeing what others are up to. (rare but happens) - limiting branch clutter. (all the time for everyone) thanks! ~N

11 months, 4 weeks

3
3
0 0

libosmocodec reference to ECU implementations from ETSI

by Mychaela Falconia

libosmocore/include/osmocom/codec/ecu.h lines 32-44: /* As the developer and copyright holder of the related code, I hereby * state that any ECU implementation using 'struct osmo_ecu_ops' and * registering with the 'osmo_ecu_register()' function shall not be * considered as a derivative work under any applicable copyright law; * the copyleft terms of GPLv2 shall hence not apply to any such ECU * implementation. * * The intent of the above exception is to allow anyone to combine third * party Error Concealment Unit implementations with libosmocodec. * including but not limited to such published by ETSI. * * -- Harald Welte <laforge(a)gnumonks.org> on August 1, 2019. */ Question about "ECU implementations ... published by ETSI": what exactly are they? To the best of my knowledge (I could be wrong, I am a late joiner to this party), ETSI/3GPP never published any ECU implementations - instead what they did publish are reference encoder and decoder implementations for HR1, EFR and AMR codecs. In each of those reference codec implementations, the error concealment function is deeply intertied with the guts of the decoder (the thing that puts out a block of 160 linear PCM samples, *not* a corrected codec frame) and does not exist as a separable piece - thus none of those reference codec implementations can be meaningfully called an ECU implementation, and there is no code in there that could be hooked up to libosmocodec ECU framework in a technically feasible way, no matter what license. So what I am missing? Are there some other code publications from ETSI or 3GPP which I am not aware of, ones that do implement a separate or at least separable ECU, as opposed to a complete decoder that takes potentially-errored codec frames as input and emits linear PCM as output? If any such "true" ECU implementations do exist, I would love to be pointed in the direction of one! M~

1 year

1
0
0 0

i pushed a commit for SCCP_Emulation.ttcn to github

by Neels Hofmeyr

I fixed something in SCCP_Emulation.ttcn (from Ericsson), and trying out what I'm allowed to do, it happened so that I just pushed the fix onto https://github.com/osmocom/titan.ProtocolEmulations.SCCP master See https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc662… The fix is trivial enough, but I'd like to note that I pushed something that no-one reviewed, and hope that's ok. my github user is part of that Osmocom group, I set the remote to a git@... URL, so that's why I could just push onto master. For the future, do we have a process to review fixes for Ericsson's ttcn code? Send it to this ML? ~N

1 year

3
2
0 0

falconia/rtp_traulike branch in osmo-bts

by Mychaela Falconia

Hello GSM community, I just pushed a private feature branch to osmo-bts, implementing a feature of much interest to me: https://cgit.osmocom.org/osmo-bts/log/?h=falconia/rtp_traulike What is it all about? This document, contained inside the branch, explains it all: https://cgit.osmocom.org/osmo-bts/tree/doc/rtp_traulike.txt?h=falconia/rtp_… Some day I would like to see this feature merged (it is enabled with a vty option, and if you don't set that option, nothing changes), but whether it will ever be merged or not, this feature is what I am going to run with in my ThemWi operation, and themwi-mgw (my Osmocom CN to G.711 PSTN transcoder) is going to depend on it. Enjoy! Hasta la Victoria, Siempre, Mychaela aka The Mother

1 year

2
3
0 0

3GPP TS 28.062 section C.3.2.1.1 for EFR: seeking help

by Mychaela Falconia

Hello GSM community, I realize that most of you over in Osmocom land would much rather see me submit Gerrit patches than write lengthy ML posts, but right now I really need some help with the algorithmic logic of a feature before I can develop patches implementing said feature - so please bear with me. The fundamental question is: what is the most correct way for a GSM network (let's ignore divisions between network elements for the moment) to construct the DL speech frame stream for call leg B if it is coming from the UL of call leg A? I am talking about call scenarios where call leg A and call leg B use the same codec, thus no transcoding is done (TrFO), and let me also further restrict this question to old-style FR/HR/EFR codecs, as opposed to AMR. At first the answer may seem so obvious that many people will probably wonder why I am asking such a silly question: just take the speech frame stream from call leg A UL, feed it to call leg B DL and be done with it, right? But the question is not so simple. What should the UL-to-DL mapper do when the UL stream hits a BFI instead of a valid speech frame? What should this mapper do if call leg A does DTXu but there is no DTXd on call leg B? The only place in 3GPP specs where I could find an answer to this question is TS 28.062 section C.3.2.1.1. Yes, I know that it's the spec for in-band TFO within G.711, a feature which I reason no one other than me probably cares about, but that particular section - I am talking about section C.3.2.1.1 specifically, you can ignore the rest of TFO for the purpose of this question - seems to me like it should apply to _any_ scenario where an FR/HR/EFR frame stream is directly passed from call leg A to call leg B without transcoding, including scenarios like a self-contained Osmocom network with OsmoMSC switching from one MS to another without any external MNCC. Let us first consider the case of FR1 codec, which is the simplest. Suppose call leg A has DTXu but call leg B has no DTXd - one can't do DTXd on C0, so if 200 kHz of spectrum is all you got, operating a BTS with just C0, then no one can do DTXd. When Alice on call leg A is silent, her MS will send a SID every 480 ms and have its Tx off the rest of the time, and the frame stream from the BTS serving her call leg will exhibit a SID frame in every 24th position and BFI placemarkers in all other positions. So what should the DL frame stream going to Bob look like in this scenario? My reading of section C.3.2.1.1 (second paragraph from the top is the one that covers this scenario) tells me that the *network* (set aside the question of which element) is supposed to turn that stream of BFIs with occasional interspersed SIDs into a stream of valid *speech* frames going to Bob, a stream of valid speech frames representing comfort noise as produced by a network-located CN generator. The spec says in that paragraph: "The Downlink TRAU Frames shall not contain the SID codeword, but parameters that allow a direct decoding." Needless to say, there is no code anywhere in Osmocom currently that does the above, thus current Osmocom is not able to produce the fancy TrFO behavior which the spec(s) seem to call for. (I said "spec(s)" vaguely because I only found a spec for TFO, not for TrFO, but I don't see any reason why this aspect of TFO spec shouldn't also apply to TrFO when the actual problem at hand is exactly the same.) But no no no guys, I am *not* bashing Osmocom here, I am seeking to improve it! As it happens, fully implementing the complete set of TS 28.062 section C.3.2.1.1 rules (I shall hereafter call them C3211 rules for short) for the original FR1 codec would be quite easy, and I already have a code implementation which I am eyeing to integrate into Osmocom. Themyscira libgsmfrp is a FLOSS library that implements a complete, spec-compliant Rx DTX handler for FR1, and it is 100% my own original work, not based on ETSI or TI or any other sources, thus no silly license issues - and I am eyeing the idea of integrating the same functions, appropriately renamed, repackaged and re-API-ed, into libosmocodec, and then invoking that functionality in OsmoBTS, in the code path that goes from RTP Rx to feeding TCH DL to PHY layers. But while FR1 is easy, doing the same for EFR is where the real difficulty lies, and this is the part where I come to the community for help. The key diff between FR1 and EFR that matters here is how their respective Rx DTX handlers are defined in the specs: for FR1 the Rx DTX handler is a separate piece, with the interface from this Rx DTX handler to the main body of the decoder being another 260-bit FR1 frame (this time without possibility of SID or BFI), and the specs for DTX (06.31 plus 06.11 and 06.12) define and describe the needed Rx DTX handler in terms of emitting that secondary 260-bit FR1 frame. Thus implementing this functionality in Themyscira libgsmfrp was a simple matter of taking the logic described in the specs and turning it into code. But for EFR the specs do not define the Rx DTX handler as a separate piece, instead it is integrated into the guts of the full decoder. There is a decoder, presented as published C source from ETSI, that takes a 244-bit EFR frame, which can be either speech or SID, *plus* a BFI flag as input, and emits a block of 160 PCM samples as output - all Rx DTX logic is buried inside, intertwined with the actual speech decoder operation, which is naturally quite complex. I've already spent a lot of time looking at the reference C implementation of EFR from ETSI - I kinda had to, as I did the rather substantial work of turning it into a usable function library, with state structures and a well-defined interface instead of global vars and namespace pollution - the result is Themyscira libgsmefr - but I am still nowhere closer to being able to implement C3211 functionality for this codec. The problem is this: starting with a EFR SID frame and previous history of a few speech frames (the hangover period), how would one produce output EFR speech frames (not SID) that represent comfort noise, as C3211 says is required? We can all easily look at ETSI's original code that generates CN as part of the standard decoder: but that code generates linear PCM output, not secondary EFR speech frames that represent CN. There is the main body of the speech decoder, and there are conditions throughout that slightly modify this decoder logic in subtle ways for CN generation and/or for ECU-style substitution/muting - but no guidance for how one could construct "valid speech" EFR frames that would produce a similar result when fed to the standard decoder in the MS after crossing radio leg B. This is where I could really use some input from more senior and more knowledgeable GSM-ers: does anyone know how mainstream commercial GSM infra vendors (particularly "ancient" ones of pure T1/E1 TDM kind) have solved this problem? What do _they_ do in the scenario of call leg A with DTXu turning into call leg B without DTXd? Given that those specs were written in the happy and glorious days when everyone used 2G, when GSM operators had lots of spectrum, and when most networks operated large multi-ARFCN BTSes with frequency hopping, I figure that almost everyone probably ran with DTXd enabled when that spec section was written - hence if I wonder if the authors of the TFO spec failed to appreciate the magnitude of what they were asking implementors to do when they stipulated that a UL-to-DL mapping from DTXu-on to DTXd-off "shall" emit no-SID speech frames that represent TFO-TRAU-generated CN. And if I wonder if the actual implementors ignored that stipulation even Back In The Day... Here is one way how we might be able to "cheat" - what if we implement a sort of fake DTXd in OsmoBTS for times when real DTXd is not possible because we only have C0? Here is what I mean: suppose the stream of TCH frames about to be sent to the PHY layer (perhaps the output of my proposed, to-be-implemented UL-to-DL mapper) is the kind that would be intended for DTXd-enabled DL in the original GSM architecture, with all speech pauses filled with repeated SIDs, every 20 ms without fail. A traditional DTXd BTS is supposed to transmit only those SIDs that either immediately follow a speech frame or fall in the SACCH-aligned always-Tx position, and turn the Tx off at other times. We can't actually turn off Tx at those "other" times when we are C0 - but what if we create a "fake DTXd" effect by transmitting a dummy FACCH containing an L2 fill frame at exactly the same times when we would do real DTXd if we could? The end effect will be that the spec-based Rx DTX handler in the MS will "see" the same "thing" as with real DTXd: receiving FACCH in all those "empty" 20 ms frame windows will cause that spec-based Rx DTX handler to get BFI=1, exactly the same as if radio Tx were truly off and the MS were listening to radio noise. Anyway, I would love to hear other people's thoughts on these ideas, especially if someone happens to know how traditional GSM infra vendors handled those pesky requirements of TS 28.062 section C.3.2.1.1 for UL-to-DL mapping. Sincerely, Your GSM-obsessed Mother Mychaela

1 year

2
5
0 0

Traditional T1/E1 TRAUs and TFO

by Mychaela Falconia

(Trying TLDR as asked) Does anyone here happen to live in a country where at least one public GSM network is known to still operate with traditional T1/E1 TRAUs? I would like to try making an international call from my G.711 VoIP system in USA to a GSM MS in whatever country that is served by a traditional TRAU, and see if I can detect TFO in-band signaling within the G.711 PCM sample stream coming from the far end. Or if someone knows for certain some solid technical reason why this idea is doomed, I would appreciate that explanation too. Reason for my interest: I have a desire to implement GSM 08.62 or 3GPP TS 28.062 TFO, and of course publish the source under a public domain license, but the protocol is complex enough to where I don't see any feasible way to test for correctness other than through actual interoperability testing with an existing implementation. M~

1 year, 1 month

1
0
0 0

Requesting ability to push private git branches

by Mychaela Falconia

Hello Osmocom, The Gerrit instructions page in the OsmoCNI wiki says: > If you would like to push private branches to the Gerrit repository, > you also need to be added to the "known users" group. > Please send a short requesting email to openbsc(a)lists.osmocom.org. I am requesting to be added to the just-described "known users" group so I can push private branches to osmo-bts repository. My current reason for desiring such ability is that I am working on a large-ish feature in OS#5975, and I anticipate needing to do a lot of work before my patch series will reach mergeable quality. As I understand it, private branches in Osmocom git repositories of the form $developer_name/$feature_name exist precisely for feature development scenario just like the one I find myself in currently, hence I request the necessary permissions, same as other Osmocom developers. With devotion to GSM Forever, (Hasta la Victoria, Siempre,) Mother Mychaela

1 year, 1 month

2
4
0 0

Running osmo-trx-uhd stalls at trying to detect UHD device

by Keith E. Fleming

Greetings! I have been trying to get osmo-trx-uhd to work with my Ettus B200. Where it gets stuck is: ┌──(root💀kali)-[~/osmo/src/osmo-trx]└─# osmo-trx-uhd -C ./doc/examples/osmo-trx-uhd/osmo-trx-uhd.cfgTue Mar 28 12:39:48 2023 DLGLOBAL <0008> cpu_sched_vty.c:471 Setting SCHED_RR priority 18Tue Mar 28 12:39:48 2023 DLGLOBAL <0008> telnet_interface.c:88 Available via telnet 127.0.0.1 4237Tue Mar 28 12:39:48 2023 DLCTRL <000f> control_if.c:1014 CTRL at 127.0.0.1 4236[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-4+b2Tue Mar 28 12:40:06 2023 DMAIN <0000> osmo-trx.cpp:607 -- Transceiver active with 1 channel(s)Tue Mar 28 12:40:06 2023 DLSTATS <0011> stats.c:169 Stats timer expire_count=4: We missed 3 timersTue Mar 28 12:40:06 2023 DLGLOBAL <0008> rate_ctr.c:350 Stats timer expire_count=17: We missed 16 timers That line in red, above, should be followed by: [INFO] [B200] Detected Device: B200[INFO] [B200] Operating over USB 3.[INFO] [B200] Initialize CODEC control...[INFO] [B200] Initialize Radio control......................etc.. The B200 is plugged in, uhd_find_devices and uhd_usrp_probe discover it without problems. Also, I am able to bring up srsRAN's EnodeB software using it for 4G/LTE testing. What follows is a log of ./configure --with-uhdmake -j4make checkmake install any help appreciated!-KEF ┌──(root💀kali)-[~/osmo/src/osmo-trx]└─# ./configure --with-uhdchecking build system type... x86_64-pc-linux-gnuchecking host system type... x86_64-pc-linux-gnuchecking target system type... x86_64-pc-linux-gnuchecking for a BSD-compatible install... /usr/bin/install -cchecking whether build environment is sane... yeschecking for a race-free mkdir -p... /usr/bin/mkdir -pchecking for gawk... gawkchecking whether make sets $(MAKE)... yeschecking whether make supports nested variables... yeschecking whether make supports nested variables... (cached) yeschecking whether make supports the include directive... yes (GNU style)checking for gcc... gccchecking whether the C compiler works... yeschecking for C compiler default output file name... a.outchecking for suffix of executables...checking whether we are cross compiling... nochecking for suffix of object files... ochecking whether the compiler supports GNU C... yeschecking whether gcc accepts -g... yeschecking for gcc option to enable C11 features... none neededchecking whether gcc understands -c and -o together... yeschecking dependency style of gcc... gcc3checking dependency style of gcc... gcc3checking for gcc... (cached) gccchecking whether the compiler supports GNU C... (cached) yeschecking whether gcc accepts -g... (cached) yeschecking for gcc option to enable C11 features... (cached) none neededchecking whether gcc understands -c and -o together... (cached) yeschecking dependency style of gcc... (cached) gcc3checking for g++... g++checking whether the compiler supports GNU C++... yeschecking whether g++ accepts -g... yeschecking for g++ option to enable C++11 features... none neededchecking dependency style of g++... gcc3checking whether g++ supports C++11 features by default... yeschecking whether ln -s works... yeschecking whether make sets $(MAKE)... (cached) yeschecking for rm... /usr/bin/rmchecking for pkg-config... /usr/bin/pkg-configchecking for pkg-config... /usr/bin/pkg-configchecking pkg-config is at least version 0.20... yeschecking how to print strings... printfchecking for a sed that does not truncate output... /usr/bin/sedchecking for grep that handles long lines and -e... /usr/bin/grepchecking for egrep... /usr/bin/grep -Echecking for fgrep... /usr/bin/grep -Fchecking for ld used by gcc... /usr/bin/ldchecking if the linker (/usr/bin/ld) is GNU ld... yeschecking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -Bchecking the name lister (/usr/bin/nm -B) interface... BSD nmchecking the maximum length of command line arguments... 1572864checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noopchecking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noopchecking for /usr/bin/ld option to reload object files... -rchecking for file... filechecking for objdump... objdumpchecking how to recognize dependent libraries... pass_allchecking for dlltool... dlltoolchecking how to associate runtime and link libraries... printf %s\nchecking for ar... archecking for archiver @FILE support... @checking for strip... stripchecking for ranlib... ranlibchecking command to parse /usr/bin/nm -B output from gcc object... okchecking for sysroot... nochecking for a working dd... /usr/bin/ddchecking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1checking for mt... mtchecking if mt is a manifest tool... nochecking for stdio.h... yeschecking for stdlib.h... yeschecking for string.h... yeschecking for inttypes.h... yeschecking for stdint.h... yeschecking for strings.h... yeschecking for sys/stat.h... yeschecking for sys/types.h... yeschecking for unistd.h... yeschecking for dlfcn.h... yeschecking for objdir... .libschecking if gcc supports -fno-rtti -fno-exceptions... nochecking for gcc option to produce PIC... -fPIC -DPICchecking if gcc PIC flag -fPIC -DPIC works... yeschecking if gcc static flag -static works... yeschecking if gcc supports -c -o file.o... yeschecking if gcc supports -c -o file.o... (cached) yeschecking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yeschecking whether -lc should be explicitly linked in... nochecking dynamic linker characteristics... GNU/Linux ld.sochecking how to hardcode library paths into programs... immediatechecking whether stripping libraries is possible... yeschecking if libtool supports shared libraries... yeschecking whether to build shared libraries... yeschecking whether to build static libraries... nochecking how to run the C++ preprocessor... g++ -Echecking for ld used by g++... /usr/bin/ld -m elf_x86_64checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yeschecking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yeschecking for g++ option to produce PIC... -fPIC -DPICchecking if g++ PIC flag -fPIC -DPIC works... yeschecking if g++ static flag -static works... yeschecking if g++ supports -c -o file.o... yeschecking if g++ supports -c -o file.o... (cached) yeschecking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yeschecking dynamic linker characteristics... (cached) GNU/Linux ld.sochecking how to hardcode library paths into programs... immediatechecking for egrep... (cached) /usr/bin/grep -Echecking for byteswap.h... yeschecking for an ANSI C-conforming const... yeschecking for inline... inlinechecking for size_t... yeschecking for sys/time.h... yeschecking whether byte ordering is bigendian... nochecking for libosmocore >= 1.8.0... yeschecking for libosmovty >= 1.8.0... yeschecking for libosmoctrl >= 1.8.0... yeschecking for libosmocoding >= 1.8.0... yeschecking for uhd >= 003.011... yeschecking for uhd < 004.002... nochecking whether to enable building MS TRX... nochecking whether C++ compiler accepts -msse3... yeschecking whether C++ compiler accepts -msse4.1... yeschecking whether gcc has __builtin_cpu_supports built-in... yeschecking whether gcc has __sync_fetch_and_and built-in... yeschecking whether gcc has __sync_or_and_fetch built-in... yeschecking for libusb-1.0... yeschecking for fftw3f... yesCPPFLAGS=""CFLAGS=" -std=gnu11"CXXFLAGS="-g -O2"LDFLAGS=""checking that generated files are newer than configure... doneconfigure: creating ./config.statusconfig.status: creating Makefileconfig.status: creating CommonLibs/Makefileconfig.status: creating GSM/Makefileconfig.status: creating Transceiver52M/Makefileconfig.status: creating Transceiver52M/arch/Makefileconfig.status: creating Transceiver52M/arch/common/Makefileconfig.status: creating Transceiver52M/arch/arm/Makefileconfig.status: creating Transceiver52M/arch/x86/Makefileconfig.status: creating Transceiver52M/device/Makefileconfig.status: creating Transceiver52M/device/common/Makefileconfig.status: creating Transceiver52M/device/uhd/Makefileconfig.status: creating Transceiver52M/device/usrp1/Makefileconfig.status: creating Transceiver52M/device/lms/Makefileconfig.status: creating Transceiver52M/device/ipc/Makefileconfig.status: creating Transceiver52M/device/bladerf/Makefileconfig.status: creating tests/Makefileconfig.status: creating tests/CommonLibs/Makefileconfig.status: creating tests/Transceiver52M/Makefileconfig.status: creating utils/Makefileconfig.status: creating doc/Makefileconfig.status: creating doc/examples/Makefileconfig.status: creating contrib/Makefileconfig.status: creating contrib/systemd/Makefileconfig.status: creating doc/manuals/Makefileconfig.status: creating contrib/osmo-trx.specconfig.status: creating config.hconfig.status: config.h is unchangedconfig.status: executing tests/atconfig commandsconfig.status: executing depfiles commandsconfig.status: executing libtool commands ┌──(root💀kali)-[~/osmo/src/osmo-trx]└─# make -j4make all-recursivemake[1]: Entering directory '/root/osmo/src/osmo-trx'Making all in CommonLibsmake[2]: Entering directory '/root/osmo/src/osmo-trx/CommonLibs' CXX LinkedLists.lo CXX BitVector.lo CXX Threads.lo CXX Timeval.lo CXX Logger.lo CXX Utils.lo CXX trx_rate_ctr.lo CC trx_vty.lo CC debug.lo CXXLD libcommon.lamake[2]: Leaving directory '/root/osmo/src/osmo-trx/CommonLibs'Making all in GSMmake[2]: Entering directory '/root/osmo/src/osmo-trx/GSM' CXX GSMCommon.lo CXXLD libGSM.lamake[2]: Leaving directory '/root/osmo/src/osmo-trx/GSM'Making all in Transceiver52Mmake[2]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M'Making all in archmake[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'Making all in commonmake[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/common' CC convert_base.lo CC convolve_base.lo CC fft.lo CCLD libarch_common.lamake[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/common'Making all in x86make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/x86' CC convolve.lo CC convert.lo CC libarch_sse_3_la-convert_sse_3.lo CC libarch_sse_3_la-convolve_sse_3.lo CC libarch_sse_4_1_la-convert_sse_4_1.lo CCLD libarch_sse_3.la CCLD libarch_sse_4_1.la CCLD libarch.lamake[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/x86'make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'make[4]: Nothing to be done for 'all-am'.make[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'Making all in devicemake[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device'Making all in commonmake[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device/common' CXX smpl_buf.lo CXXLD libdevice_common.lamake[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device/common'Making all in uhdmake[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device/uhd' CXX UHDDevice.lo CXXLD libdevice.lamake[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device/uhd'make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[4]: Nothing to be done for 'all-am'.make[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M' CXX osmo_trx_uhd-osmo-trx.o CXX radioInterface.lo CXX radioVector.lo CXX radioClock.lo CXX radioBuffer.lo CXX sigProcLib.lo CXX signalVector.lo CXX Transceiver.lo CXX ChannelizerBase.lo CXX Channelizer.lo CXX Synthesis.lo CC proto_trxd.lo CXX Resampler.lo CXX radioInterfaceResamp.lo CXX radioInterfaceMulti.lo CXXLD libtransceiver_common.la CXXLD osmo-trx-uhdmake[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M'make[2]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M'Making all in contribmake[2]: Entering directory '/root/osmo/src/osmo-trx/contrib'Making all in systemdmake[3]: Entering directory '/root/osmo/src/osmo-trx/contrib/systemd'make[3]: Nothing to be done for 'all'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/contrib/systemd'make[3]: Entering directory '/root/osmo/src/osmo-trx/contrib'make[3]: Nothing to be done for 'all-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/contrib'make[2]: Leaving directory '/root/osmo/src/osmo-trx/contrib'Making all in testsmake[2]: Entering directory '/root/osmo/src/osmo-trx/tests'Making all in CommonLibsmake[3]: Entering directory '/root/osmo/src/osmo-trx/tests/CommonLibs'make[3]: Nothing to be done for 'all'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/tests/CommonLibs'Making all in Transceiver52Mmake[3]: Entering directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make[3]: Nothing to be done for 'all'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make[3]: Entering directory '/root/osmo/src/osmo-trx/tests'make[3]: Nothing to be done for 'all-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/tests'make[2]: Leaving directory '/root/osmo/src/osmo-trx/tests'Making all in utilsmake[2]: Entering directory '/root/osmo/src/osmo-trx/utils' CC prbs-tool.o CCLD osmo-prbs-toolmake[2]: Leaving directory '/root/osmo/src/osmo-trx/utils'Making all in docmake[2]: Entering directory '/root/osmo/src/osmo-trx/doc'Making all in examplesmake[3]: Entering directory '/root/osmo/src/osmo-trx/doc/examples'make[3]: Nothing to be done for 'all'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/doc/examples'Making all in manualsmake[3]: Entering directory '/root/osmo/src/osmo-trx/doc/manuals'make[3]: Nothing to be done for 'all'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/doc/manuals'make[3]: Entering directory '/root/osmo/src/osmo-trx/doc'make[3]: Nothing to be done for 'all-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/doc'make[2]: Leaving directory '/root/osmo/src/osmo-trx/doc'make[2]: Entering directory '/root/osmo/src/osmo-trx'make[2]: Leaving directory '/root/osmo/src/osmo-trx'make[1]: Leaving directory '/root/osmo/src/osmo-trx' ┌──(root💀kali)-[~/osmo/src/osmo-trx]└─# make checkMaking check in CommonLibsmake[1]: Entering directory '/root/osmo/src/osmo-trx/CommonLibs'make[1]: Nothing to be done for 'check'.make[1]: Leaving directory '/root/osmo/src/osmo-trx/CommonLibs'Making check in GSMmake[1]: Entering directory '/root/osmo/src/osmo-trx/GSM'make[1]: Nothing to be done for 'check'.make[1]: Leaving directory '/root/osmo/src/osmo-trx/GSM'Making check in Transceiver52Mmake[1]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M'Making check in archmake[2]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'Making check in commonmake[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/common'make[3]: Nothing to be done for 'check'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/common'Making check in x86make[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/x86'make[3]: Nothing to be done for 'check'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/x86'make[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'make[3]: Nothing to be done for 'check-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'make[2]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'Making check in devicemake[2]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device'Making check in commonmake[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device/common'make[3]: Nothing to be done for 'check'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device/common'Making check in uhdmake[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device/uhd'make[3]: Nothing to be done for 'check'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device/uhd'make[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[3]: Nothing to be done for 'check-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[2]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[2]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M'make[2]: Nothing to be done for 'check-am'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M'make[1]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M'Making check in contribmake[1]: Entering directory '/root/osmo/src/osmo-trx/contrib'Making check in systemdmake[2]: Entering directory '/root/osmo/src/osmo-trx/contrib/systemd'make[2]: Nothing to be done for 'check'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/contrib/systemd'make[2]: Entering directory '/root/osmo/src/osmo-trx/contrib'make[2]: Nothing to be done for 'check-am'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/contrib'make[1]: Leaving directory '/root/osmo/src/osmo-trx/contrib'Making check in testsmake[1]: Entering directory '/root/osmo/src/osmo-trx/tests'Making check in CommonLibsmake[2]: Entering directory '/root/osmo/src/osmo-trx/tests/CommonLibs'make BitVectorTest PRBSTest InterthreadTest TimevalTest VectorTest LogTestmake[3]: Entering directory '/root/osmo/src/osmo-trx/tests/CommonLibs' CXX BitVectorTest.o CXXLD BitVectorTest CXX PRBSTest.o CXXLD PRBSTest CXX InterthreadTest.o CXXLD InterthreadTest CXX TimevalTest.o CXXLD TimevalTest CXX VectorTest.o CXXLD VectorTest CXX LogTest.o CXXLD LogTestmake[3]: Leaving directory '/root/osmo/src/osmo-trx/tests/CommonLibs'make[2]: Leaving directory '/root/osmo/src/osmo-trx/tests/CommonLibs'Making check in Transceiver52Mmake[2]: Entering directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make convolve_testmake[3]: Entering directory '/root/osmo/src/osmo-trx/tests/Transceiver52M' CC convolve_test-convolve_test.o CCLD convolve_testmake[3]: Leaving directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make[2]: Leaving directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make[2]: Entering directory '/root/osmo/src/osmo-trx/tests'make check-localmake[3]: Entering directory '/root/osmo/src/osmo-trx/tests'/bin/bash './testsuite'## ---------------------------------- #### osmo-trx 1.5.0.15-8745 test suite. #### ---------------------------------- ## Regression tests. 1: LMSDeviceTest skipped (testsuite.at:6) 2: BitVectorTest ok 3: InterthreadTest ok 4: LogTest ok 5: PRBSTest ok 6: TimevalTest ok 7: VectorTest ok 8: convolve_test ok ## ------------- #### Test results. #### ------------- ## 7 tests were successful.1 test was skipped.make[3]: Leaving directory '/root/osmo/src/osmo-trx/tests'make[2]: Leaving directory '/root/osmo/src/osmo-trx/tests'make[1]: Leaving directory '/root/osmo/src/osmo-trx/tests'Making check in utilsmake[1]: Entering directory '/root/osmo/src/osmo-trx/utils'make[1]: Nothing to be done for 'check'.make[1]: Leaving directory '/root/osmo/src/osmo-trx/utils'Making check in docmake[1]: Entering directory '/root/osmo/src/osmo-trx/doc'Making check in examplesmake[2]: Entering directory '/root/osmo/src/osmo-trx/doc/examples'make[2]: Nothing to be done for 'check'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/doc/examples'Making check in manualsmake[2]: Entering directory '/root/osmo/src/osmo-trx/doc/manuals'make[2]: Nothing to be done for 'check'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/doc/manuals'make[2]: Entering directory '/root/osmo/src/osmo-trx/doc'make[2]: Nothing to be done for 'check-am'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/doc'make[1]: Leaving directory '/root/osmo/src/osmo-trx/doc'make[1]: Entering directory '/root/osmo/src/osmo-trx'make[1]: Leaving directory '/root/osmo/src/osmo-trx' ┌──(root💀kali)-[~/osmo/src/osmo-trx]└─# make installMaking install in CommonLibsmake[1]: Entering directory '/root/osmo/src/osmo-trx/CommonLibs'make[2]: Entering directory '/root/osmo/src/osmo-trx/CommonLibs'make[2]: Nothing to be done for 'install-exec-am'.make[2]: Nothing to be done for 'install-data-am'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/CommonLibs'make[1]: Leaving directory '/root/osmo/src/osmo-trx/CommonLibs'Making install in GSMmake[1]: Entering directory '/root/osmo/src/osmo-trx/GSM'make[2]: Entering directory '/root/osmo/src/osmo-trx/GSM'make[2]: Nothing to be done for 'install-exec-am'.make[2]: Nothing to be done for 'install-data-am'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/GSM'make[1]: Leaving directory '/root/osmo/src/osmo-trx/GSM'Making install in Transceiver52Mmake[1]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M'Making install in archmake[2]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'Making install in commonmake[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/common'make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/common'make[4]: Nothing to be done for 'install-exec-am'.make[4]: Nothing to be done for 'install-data-am'.make[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/common'make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/common'Making install in x86make[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/x86'make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/x86'make[4]: Nothing to be done for 'install-exec-am'.make[4]: Nothing to be done for 'install-data-am'.make[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/x86'make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch/x86'make[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'make[4]: Nothing to be done for 'install-exec-am'.make[4]: Nothing to be done for 'install-data-am'.make[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'make[2]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/arch'Making install in devicemake[2]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device'Making install in commonmake[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device/common'make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device/common'make[4]: Nothing to be done for 'install-exec-am'.make[4]: Nothing to be done for 'install-data-am'.make[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device/common'make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device/common'Making install in uhdmake[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device/uhd'make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device/uhd'make[4]: Nothing to be done for 'install-exec-am'.make[4]: Nothing to be done for 'install-data-am'.make[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device/uhd'make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device/uhd'make[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[4]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[4]: Nothing to be done for 'install-exec-am'.make[4]: Nothing to be done for 'install-data-am'.make[4]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[2]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M/device'make[2]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M'make[3]: Entering directory '/root/osmo/src/osmo-trx/Transceiver52M' /usr/bin/mkdir -p '/usr/local/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-trx-uhd '/usr/local/bin'libtool: install: /usr/bin/install -c osmo-trx-uhd /usr/local/bin/osmo-trx-uhdmake[3]: Nothing to be done for 'install-data-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M'make[2]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M'make[1]: Leaving directory '/root/osmo/src/osmo-trx/Transceiver52M'Making install in contribmake[1]: Entering directory '/root/osmo/src/osmo-trx/contrib'Making install in systemdmake[2]: Entering directory '/root/osmo/src/osmo-trx/contrib/systemd'make[3]: Entering directory '/root/osmo/src/osmo-trx/contrib/systemd'make[3]: Nothing to be done for 'install-exec-am'. /usr/bin/mkdir -p '/lib/systemd/system' /usr/bin/install -c -m 644 osmo-trx-uhd.service '/lib/systemd/system'make[3]: Leaving directory '/root/osmo/src/osmo-trx/contrib/systemd'make[2]: Leaving directory '/root/osmo/src/osmo-trx/contrib/systemd'make[2]: Entering directory '/root/osmo/src/osmo-trx/contrib'make[3]: Entering directory '/root/osmo/src/osmo-trx/contrib'make[3]: Nothing to be done for 'install-exec-am'.make[3]: Nothing to be done for 'install-data-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/contrib'make[2]: Leaving directory '/root/osmo/src/osmo-trx/contrib'make[1]: Leaving directory '/root/osmo/src/osmo-trx/contrib'Making install in testsmake[1]: Entering directory '/root/osmo/src/osmo-trx/tests'Making install in CommonLibsmake[2]: Entering directory '/root/osmo/src/osmo-trx/tests/CommonLibs'make[3]: Entering directory '/root/osmo/src/osmo-trx/tests/CommonLibs'make[3]: Nothing to be done for 'install-exec-am'.make[3]: Nothing to be done for 'install-data-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/tests/CommonLibs'make[2]: Leaving directory '/root/osmo/src/osmo-trx/tests/CommonLibs'Making install in Transceiver52Mmake[2]: Entering directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make[3]: Entering directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make[3]: Nothing to be done for 'install-exec-am'.make[3]: Nothing to be done for 'install-data-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make[2]: Leaving directory '/root/osmo/src/osmo-trx/tests/Transceiver52M'make[2]: Entering directory '/root/osmo/src/osmo-trx/tests'make[3]: Entering directory '/root/osmo/src/osmo-trx/tests'make[3]: Nothing to be done for 'install-exec-am'.make[3]: Nothing to be done for 'install-data-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/tests'make[2]: Leaving directory '/root/osmo/src/osmo-trx/tests'make[1]: Leaving directory '/root/osmo/src/osmo-trx/tests'Making install in utilsmake[1]: Entering directory '/root/osmo/src/osmo-trx/utils'make[2]: Entering directory '/root/osmo/src/osmo-trx/utils'make[2]: Nothing to be done for 'install-exec-am'.make[2]: Nothing to be done for 'install-data-am'.make[2]: Leaving directory '/root/osmo/src/osmo-trx/utils'make[1]: Leaving directory '/root/osmo/src/osmo-trx/utils'Making install in docmake[1]: Entering directory '/root/osmo/src/osmo-trx/doc'Making install in examplesmake[2]: Entering directory '/root/osmo/src/osmo-trx/doc/examples'make[3]: Entering directory '/root/osmo/src/osmo-trx/doc/examples'make[3]: Nothing to be done for 'install-exec-am'. /usr/bin/mkdir -p '/usr/local/etc/osmocom' /usr/bin/install -c -m 644 osmo-trx-uhd/osmo-trx-uhd.cfg '/usr/local/etc/osmocom'make install-data-hookmake[4]: Entering directory '/root/osmo/src/osmo-trx/doc/examples'for f in $(find . -type f -name '*.cfg*' | sed -e 's,^.,,'); do \ j="/usr/local/share/doc/osmo-trx/examples/$f" && \ mkdir -p "$(dirname $j)" && \ /usr/bin/install -c -m 644 ./$f $j; \donemake[4]: Leaving directory '/root/osmo/src/osmo-trx/doc/examples'make[3]: Leaving directory '/root/osmo/src/osmo-trx/doc/examples'make[2]: Leaving directory '/root/osmo/src/osmo-trx/doc/examples'Making install in manualsmake[2]: Entering directory '/root/osmo/src/osmo-trx/doc/manuals'make[3]: Entering directory '/root/osmo/src/osmo-trx/doc/manuals'make[3]: Nothing to be done for 'install-exec-am'.make[3]: Nothing to be done for 'install-data-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/doc/manuals'make[2]: Leaving directory '/root/osmo/src/osmo-trx/doc/manuals'make[2]: Entering directory '/root/osmo/src/osmo-trx/doc'make[3]: Entering directory '/root/osmo/src/osmo-trx/doc'make[3]: Nothing to be done for 'install-exec-am'.make[3]: Nothing to be done for 'install-data-am'.make[3]: Leaving directory '/root/osmo/src/osmo-trx/doc'make[2]: Leaving directory '/root/osmo/src/osmo-trx/doc'make[1]: Leaving directory '/root/osmo/src/osmo-trx/doc'make[1]: Entering directory '/root/osmo/src/osmo-trx'make[2]: Entering directory '/root/osmo/src/osmo-trx'make[2]: Nothing to be done for 'install-exec-am'.make[2]: Nothing to be done for 'install-data-am'.make[2]: Leaving directory '/root/osmo/src/osmo-trx'make[1]: Leaving directory '/root/osmo/src/osmo-trx' ┌──(root💀kali)-[~/osmo/src/osmo-trx]└─# which osmo-trx-uhd/usr/local/bin/osmo-trx-uhd ┌──(root💀kali)-[~/osmo/src/osmo-trx]└─# ls -l /usr/local/bin/osmo-trx-uhd-rwxr-xr-x 1 root root 5199368 Mar 28 12:39 /usr/local/bin/osmo-trx-uhd ┌──(root💀kali)-[~/osmo/src/osmo-trx]└─# osmo-trx-uhd -C ./doc/examples/osmo-trx-uhd/osmo-trx-uhd.cfgTue Mar 28 12:39:48 2023 DLGLOBAL <0008> cpu_sched_vty.c:471 Setting SCHED_RR priority 18Tue Mar 28 12:39:48 2023 DLGLOBAL <0008> telnet_interface.c:88 Available via telnet 127.0.0.1 4237Tue Mar 28 12:39:48 2023 DLCTRL <000f> control_if.c:1014 CTRL at 127.0.0.1 4236[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-4+b2

1 year, 1 month

2
1
0 0

GSM-EFR SID support in libosmo-abis

by SADANAND VISHWAS

Hello, I was going through libosmo-abis codebase to understand how it handles “Rtp to Trau” and vice-versa GSM-EFR conversions. I was able to find “RTP to Trau” and “Trau to Rtp” conversion code of EFR speech frames, but could not find anything related to EFR SID (silence) frames. can you please guide me if above is already present in the library or how can we implement it? Thanks, Sadanand Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

1 year, 1 month

3
3
0 0

Seeking pcap of RTP stream from nanoBTS

by Mychaela Falconia

Hello GSM community, Would anyone in either of the two sub-communities of GSM (OsmoCNI and FC) happen to have a working setup with an ip.access nanoBTS, specifically with working voice calls? For the purpose of this inquiry, that "working setup" can be either with Osmocom CNI sw or with whatever original proprietary sw was once "official" for these ip.access nanoBTS units. If anyone does have a working nanoBTS setup with any sw, would you be willing to produce and share a packet capture (pcap file) of a working voice call, particularly the RTP stream originating from the nanoBTS? I am particularly interested in seeing a nanoBTS-generated RTP stream in either FR1 or EFR codec, as opposed to AMR or HR, coming from a GSM call UL with DTX enabled - having a 'dtx uplink' line in OsmoBSC config under 'bts N' should do it. The reason for my interest? I am looking to see what the pre-existing (before Osmocom) implementation of GSM-UL-to-RTP conversion in nanoBTS does in the two corner cases of (1) the MS exercising DTX during speech pauses and (2) speech frame 20 ms windows on TCH UL being stolen for FACCH. In case 1, does nanoBTS produce an intentional gap in its transmitted RTP stream (no packets sent at all) like OsmoBTS does, or does it do something different? Does it perhaps send RTP packets with zero-length payload, or some in-band bit pattern that is meant to indicate "bad frame, no data"? Case 2 is also interesting: current osmo-bts-trx (based on my reading of code, no hw to test on) invokes FR1 ECU and emits its output in this case, whereas stock (without my hacky patches) osmo-bts-sysmo exhibits an outright bug whereby nothing is emitted on RTP during the FACCH-stolen 20 ms window, and that gap in the RTP stream is NOT accounted for in the timestamps of subsequent RTP packets. Once again, I can only wonder what the pre-Osmocom implementation in nanoBTS does in this case. I would really like to produce a clean, potentially-mergeable patch to OsmoBTS and submit it to Gerrit, a patch that would add vty config settings selecting among several possible behaviours for RTP output in cases of DTX silence, FACCH stealing or bad radio Rx - but I really need to know what the different "reasonable" behaviour choices are, and I feel that we as in FOSS GSM community also need to know what our proprietary predecessors did in this area. I am not able to test this nanoBTS behaviour myself because even though I have nanoBTS hw (one PCS1900 unit and one GSM850), I have had no success in getting it to work with Osmocom - and my troubleshooting attempts hit a brick wall when the misbehaviour appears to be somewhere in the proprietary black box of nanoBTS. Hence I really need help from someone in the community who does have a working nanoBTS setup (with any sw) and who could make some test voice calls (ideally one FR1 and one EFR, but even just one of these two codecs would be interesting to see) with an RTP packet capture running, and then share the resulting pcap file. During that test voice call, it would be ideal if the tester could alternate between speaking and silence, and also cause some FACCH activity, perhaps by pressing DTMF keys. M~

1 year, 1 month

2
5
0 0

ttcn3-bts-test regressions

by Vadim Yanitskiy

Hi all, I was planning to do this long time ago, but somehow kept leaving this for later. Today I revisited the state of ttcn3-bts-test, which shows quite a few regressions. I believe they need to be investigated and eventually fixed, so I created several tickets for tracking these regressions in Osmocom's Redmine: * OS#5951: TC_early_immediate_assignment, * OS#5952: TC_ho_physical_info, * OS#5953: TC_ms_pwr_ctrl_{constant,pf_ewma}, * OS#5954: TC_pcu_data_ind_lqual_cb, * OS#5955: TC_pcu_[ext_]rach_content, TC_pcu_ptcch, * OS#5956: TC_rsl_rf_resource_ind. The following tickets already existed prior to my checkup: * OS#4023: TC_pcu_oml_alert, * OS#5242: TC_ipa_crcx_ack_addr, * OS#5517: TC_tx_power_ramp_adm_state_change. So far this is all about non-hopping configuration: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… The freq. hopping configuration exhibits slightly more red TCs: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… 92% vs 84% passing TCs to be precise, but this is kinda expected because of the limitations we have in fake_trx: FAKE_* CTRL commands are applied to just one transceiver, not affecting others, which are also part of the Mobile Allocation. Mostly the meas related TCs are affected. The following TC groups are quite stable and mostly all green: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… The following two TC groups have never been stable/all green, AFAICT: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/lastCompl… We may want to create more tickets for those, maybe less granular (i.e. one ticket per group). I am not familiar with these two TC groups, so would be nice to get some input from those who write them. What would it take to get them fixed? Are there any tickets already? If could not find any, but I only did a quick search. 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

1 year, 1 month

2
1
0 0

OsmoDevCall on Mar 15, 2023: Circuit Switched Data (CSD) in GSM

by Harald Welte

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: March 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @laforge be presenting on Long range communications in the HF band CSD is the mechanism by which circuit-switched data calls can be made over classic GSM/2G (and later also UMTS/3G) networks. They resembled the modem call of circuit-switched networks, but of course no voiceband modem is involved. For more information, see our CSD wiki page at https://osmocom.org/projects/cellular-infrastructure/wiki/CSD This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - 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)

1 year, 1 month

3
2
0 0

Play RTP packets payload obtained from the mobile phone in a call service

by morteza ali Ahmadi

Hi, I have developed a UMTS core network using a home nodeB (HNB) which the mobile phones (or UEs) can register on my network and get the required services such as call service. I have implemented all the required procedures for call service and I can establish a successful call for my connected UEs. In one of the most important procedures, i.e **Call Proceeding**, I have identified the coding of speech transferred between UEs and core. Here is my coding options (in wireshark): GSM A-I/F DTAP - Call Proceeding Protocol Discriminator: Call Control; call related SS messages (3) .... 0011 = Protocol discriminator: Call Control; call related SS messages (0x3) 1... .... = TI flag: allocated by receiver .000 .... = TIO: 0 00.. .... = Sequence number: 0 ..00 0010 = DTAP Call Control Message Type: Call Proceeding (0x02) Bearer Capability 1 - (Spare) Element ID: 0x04 Length: 6 Octet 3 0... .... = Extension: Extended .11. .... = Radio channel requirement: Spare ...0 .... = Coding standard: GSM standardized coding .... 0... = Transfer mode: circuit .... .000 = Information transfer capability: Speech (0x0) Octets 3a - Speech Versions 0... .... = Extension: Extended .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 0010 = Speech version indication: GSM full rate speech version 2(GSM EFR) (0x2) 0... .... = Extension: Extended .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 1000 = Speech version indication: GSM full rate speech version 5(FR AMR-WB) (0x8) 0... .... = Extension: Extended .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4) 0... .... = Extension: Extended .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5) 1... .... = Extension: No Extension .0.. .... = Coding: octet used for extension of information transfer capability ..00 .... = Spare bit(s): 0 .... 0001 = Speech version indication: GSM half rate speech version 1(GSM HR) (0x1) So I can see the RTP packets transferred between UE and core. An instance is mentioned here (in wireshark): Real-Time Transport Protocol [Stream setup by RANAP (frame 2950)] 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 .... = Extension: False .... 0000 = Contributing source identifiers count: 0 0... .... = Marker: False Payload type: DynamicRTP-Type-96 (96) Sequence number: 56611 [Extended sequence number: 56611] Timestamp: 424448575 Synchronization Source identifier: 0x5c260101 (1545994497) RFC 2198: Redundant Audio Data Header 1: PT=ITU-T G.728 0... .... = Follow: Not set .000 1111 = Payload type: ITU-T G.728 (15) Payload: 0028ba44776b3eee7a050039cdaa521cc20ac08d2bcf1818… I have aggregated all RTP packets payload. How can I convert the aggregated bytes to a hearable audio? -- *When there is much light, The shadow is deep...*

1 year, 2 months

5
5
0 0

Extract and parsing TCAP + CAP parts from SCCP messages

by Hadi Rezaee

Hello there, I was wondering if there is any snippet or sample code for extracting TCAP and then CAP parts from SCCP messages. So, What I've done so far was to connect to SG system as a client and called to 'osmo_sccp_user_bind' function to catch SCCP message: osmo_sccp_user_bind(sccp, 0, handle_sccp_msg, NULL); . . . int handle_sccp_message(struct osmo_prim_hdr *oph, void *ctx) { struct osmo_scu_prim *scu_prim = (struct osmo_scu_prim *)oph; struct osmo_sccp_user *scu = ctx; struct gsm_subscriber_connection *conn; int rc = 0; switch (OSMO_PRIM_HDR(&scu_prim->oph)) { case OSMO_PRIM(OSMO_SCU_PRIM_N_UNITDATA, PRIM_OP_INDICATION): // TCAP parsing ?! break; default: break; } return rc; } Thanks

1 year, 2 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC