- OpenBSC - lists.osmocom.org

[PATCH] rrlpd: fix asn1c API misuse (NativeInteger/NativeEnumerated) in RRLP assistance handling
by Daumantas Balakauskas 03 Nov '26

03 Nov '26

we maintain a vendored copy of rrlpd inside a GSM test network and ran the RRLP assistance path against real handsets. With skeletons generated by asn1c 0.9.28, the RRLP assistance delivery is broken in several ways, all of them API misuse from the days when these fields were generated as INTEGER_t octet strings instead of the plain native types asn1c emits today: 1. MoreAssDataToBeSent_t is a NativeEnumerated (typedef long). _rrlp_create_gps_assist_pdu() calls asn_long2INTEGER() on a calloc(1, sizeof(long)) allocation: asn_long2INTEGER writes an INTEGER_t {buf, size} (16 bytes) past the 8-byte chunk and leaves the enum holding garbage (we observed 829434072 where 0..1 is valid). uper_encode_to_new_buffer() then rejects every AssistanceData PDU, so rrlp_gps_assist_pdus() always fails and the MS never receives any assistance data. 2. The same type confusion crashes rrlpd outright on incoming MsrPosition-Rsp messages: asn_INTEGER2long() on locationError->locErrorReason (NativeInteger, typedef long) reads the error value itself as an {buf, size} struct pointer. A handset answering a position request with locationError gpsAssDataMissing (= 6) segfaults the daemon dereferencing address 0x6. The protocolError/errorCause path has the same bug. 3. _rrlp_add_almanac() and _rrlp_add_ephemeris() attach their Almanac/NavigationModel container even when there is nothing to put in it (no almanac content, or no SV passing the MS's satellite mask). An attached but empty almanacList/navModelList violates its SIZE(1..32) / SIZE(1..16) constraint and the PER encoder rejects the whole message. They now attach only when at least one element is added; the callers keep a PDU with no content open for the next element, and still send it as an (empty but valid) assistance answer so the MS is never left waiting. 4. If no PDU survives (all requested elements skipped), the "set last message flag" code indexed lst_pdu[-1]. That case now returns -ENOENT instead. 5. 1ULL << (sv_id - 1) is undefined for sv_id 0 or > 64; the mask test in _rrlp_add_ephemeris() now bounds sv_id first. Fix 1 is the interesting one for anyone vendoring this code: it means rrlp_gps_assist_pdus() has never produced a single valid assistance PDU under modern asn1c, and RRLP ms-based sessions stall after the MS answers locationError gpsAssDataMissing asking for assistance. Verified on the host against the 0.9.28 skeletons and on a live GSM network: an MS answering with locationError 6 + additionalAssistanceData now gets its ephemeris/almanac/UTC/ionosphere assistance in several AssistanceData messages and proceeds to an actual position attempt. rrlpd/src/rrlp.c | 69 ++++++++++++++++++--------- rrlpd/src/main.c | 28 ++++++++-------- 2 files changed, 95 insertions(+), 49 deletions(-) Signed-off-by: Daumantas <daumantas.balakauskas(a)gmail.com> Also available as a branch, in case pulling is easier than applying the pasted patch: https://github.com/translibrius/osmocom-lcs/tree/rrlpd-fix-asn1c-api-misuse --- --- a/rrlpd/src/rrlp.c +++ b/rrlpd/src/rrlp.c @@ -417,14 +417,10 @@ free(pdu); return NULL; } - /* last message or more messages ? */ - if(iLast) { - if(asn_long2INTEGER(moreAssDataToBeSent, MoreAssDataToBeSent_noMoreMessages) != 0) - fprintf(stderr, "encode error\n"); - } else { - if(asn_long2INTEGER(moreAssDataToBeSent, MoreAssDataToBeSent_moreMessagesOnTheWay) != 0) - fprintf(stderr, "encode error\n"); - } + /* MoreAssDataToBeSent is a NativeEnumerated (plain long); asn_long2INTEGER + * would treat it as an INTEGER_t and write past the 8-byte allocation. */ + *moreAssDataToBeSent = iLast ? MoreAssDataToBeSent_noMoreMessages + : MoreAssDataToBeSent_moreMessagesOnTheWay; if (o_gps_ad) *o_gps_ad = gps_ad; @@ -642,6 +638,12 @@ if (!(gps_ad->fields & GPS_FIELD_ALMANAC)) return -EINVAL; + /* Nothing (left) to add: leave the Almanac absent. An attached but + * empty almanacList violates its SIZE(1..32) constraint and the PER + * encoder rejects the whole message. */ + if (*start >= gps_alm->n_sv) + return 0; + rrlp_alm = calloc(1, sizeof(*rrlp_alm)); if (!rrlp_alm) return -ENOMEM; @@ -676,6 +678,21 @@ if (!(gps_ad->fields & GPS_FIELD_EPHEMERIS)) return -EINVAL; + /* Find the first SV that passes the MS's satellite mask. Without a + * match, leave the NavigationModel absent: an attached but empty + * navModelList violates its SIZE(1..16) constraint and the PER + * encoder rejects the whole message. Also keeps sv_id outside + * 1..64 away from the shift below. */ + for (i = *start; i < gps_eph->n_sv; i++) { + if (gps_eph->svs[i].sv_id >= 1 && gps_eph->svs[i].sv_id <= 64 && + (mask & (1ULL << (gps_eph->svs[i].sv_id - 1)))) + break; + } + if (i >= gps_eph->n_sv) { + *start = i; + return 0; + } + rrlp_nav = calloc(1, sizeof(*rrlp_nav)); if (!rrlp_nav) return -ENOMEM; @@ -683,8 +700,9 @@ if (count == -1) count = gps_eph->n_sv - *start; - for (i=*start,j=0; (j<count) && (i<gps_eph->n_sv); i++) { - if (!(mask & (1ULL<<(gps_eph->svs[i].sv_id-1)))) /* Dieter: CHECK */ + for (j=0; (j<count) && (i<gps_eph->n_sv); i++) { + if (gps_eph->svs[i].sv_id < 1 || gps_eph->svs[i].sv_id > 64 || + !(mask & (1ULL<<(gps_eph->svs[i].sv_id-1)))) /* Dieter: CHECK */ continue; struct NavModelElement *nme; nme = calloc(1, sizeof(*nme)); @@ -795,8 +813,12 @@ if (rv < 0) goto error; - lst_pdu[lst_cnt++] = rrlp_pdu; - rrlp_pdu = NULL; + /* keep the PDU open when no element was added; the + * next element may still fill it */ + if (rrlp_gps_ad->controlHeader.almanac) { + lst_pdu[lst_cnt++] = rrlp_pdu; + rrlp_pdu = NULL; + } } while (rv); } #endif @@ -824,16 +846,35 @@ #elif 0 /* all sets in one PDU, too large */ rv = _rrlp_add_ephemeris(rrlp_gps_ad, gps_ad, &i, -1, req->eph_svs); #endif - lst_pdu[lst_cnt++] = rrlp_pdu; - rrlp_pdu = NULL; + if (rv < 0) + goto error; + /* keep the PDU open when no element was added */ + if (rrlp_gps_ad->controlHeader.navigationModel) { + lst_pdu[lst_cnt++] = rrlp_pdu; + rrlp_pdu = NULL; + } } while (rv); } #endif - /* set last message flag */ - if(asn_long2INTEGER(lst_pdu[lst_cnt - 1]->component.choice.assistanceData.moreAssDataToBeSent, MoreAssDataToBeSent_noMoreMessages) != 0) - fprintf(stderr, "encode error\n"); + /* A skipped element may have left its PDU open with no content; send + * it anyway so the MS still gets an assistance answer. */ + if (rrlp_pdu) { + lst_pdu[lst_cnt++] = rrlp_pdu; + rrlp_pdu = NULL; + } + + /* All requested elements were skipped or had no content: nothing to + * send. Fail rather than indexing lst_pdu[-1] below. */ + if (lst_cnt == 0) { + rv = -ENOENT; + goto error; + } + + /* set last message flag (NativeEnumerated: plain long, see above) */ + *lst_pdu[lst_cnt - 1]->component.choice.assistanceData.moreAssDataToBeSent = + MoreAssDataToBeSent_noMoreMessages; /* Serialize & Release all PDUs */ for (i=0; i<lst_cnt && i<o_max_pdus; i++) { --- a/rrlpd/src/main.c +++ b/rrlpd/src/main.c @@ -350,21 +350,19 @@ if(msrPositionRsp->locationError) { printd("---- locationError\n"); - if(asn_INTEGER2long(&msrPositionRsp->locationError->locErrorReason, &l) == 0) { - asn_INTEGER_specifics_t *specs = (asn_INTEGER_specifics_t *)asn_DEF_LocErrorReason.specifics; - const asn_INTEGER_enum_map_t *el; - el = INTEGER_map_value2enum(specs, l); - if(el) { - printd("---- locErrorReason = %ld (%s)\n", l, el->enum_name); - sprintf(reply, "locationError %ld (%s)", l, el->enum_name); - } else { - printd("---- locErrorReason = %ld\n", l); - sprintf(reply, "locationError %ld", l); - } + /* LocErrorReason is a NativeInteger (plain long), not an + * INTEGER_t; asn_INTEGER2long would read the value itself + * as a {buf,size} struct pointer and crash. */ + l = msrPositionRsp->locationError->locErrorReason; + asn_INTEGER_specifics_t *specs = (asn_INTEGER_specifics_t *)asn_DEF_LocErrorReason.specifics; + const asn_INTEGER_enum_map_t *el; + el = INTEGER_map_value2enum(specs, l); + if(el) { + printd("---- locErrorReason = %ld (%s)\n", l, el->enum_name); + sprintf(reply, "locationError %ld (%s)", l, el->enum_name); } else { - printd("---- locErrorReason: decode error\n"); - strcpy(reply, "locationError ??"); - l = 9999; + printd("---- locErrorReason = %ld\n", l); + sprintf(reply, "locationError %ld", l); } if(msrPositionRsp->locationError->additionalAssistanceData) { printd("------ additionalAssistanceData\n"); @@ -582,20 +580,17 @@ case RRLP_Component_PR_protocolError: printd("-- protocolError\n"); ProtocolError_t *protocolError = &pdu->component.choice.protocolError; - if(asn_INTEGER2long(&protocolError->errorCause, &l) == 0) { - asn_INTEGER_specifics_t *specs = (asn_INTEGER_specifics_t *)asn_DEF_ErrorCodes.specifics; - const asn_INTEGER_enum_map_t *el; - el = INTEGER_map_value2enum(specs, l); - if(el) { - printd("---- errorCause = %ld (%s)\n", l, el->enum_name); - sprintf(reply, "protocolError %ld (%s)", l, el->enum_name); - } else { - printd("---- errorCause = %ld\n", l); - sprintf(reply, "protocolError %ld", l); - } + /* ErrorCodes is a NativeInteger (plain long), like LocErrorReason */ + l = protocolError->errorCause; + asn_INTEGER_specifics_t *specs = (asn_INTEGER_specifics_t *)asn_DEF_ErrorCodes.specifics; + const asn_INTEGER_enum_map_t *el; + el = INTEGER_map_value2enum(specs, l); + if(el) { + printd("---- errorCause = %ld (%s)\n", l, el->enum_name); + sprintf(reply, "protocolError %ld (%s)", l, el->enum_name); } else { - printd("---- errorCause: decode error\n"); - strcpy(reply, "protocolError ??"); + printd("---- errorCause = %ld\n", l); + sprintf(reply, "protocolError %ld", l); } rrlp_sub_state->state = RRLP_ERROR;

1 0

Small tool for daily puzzle breaks + thanks for the AMR/CSD thread
by wa7k3q9x＠screwdom.org 14 Oct '26

14 Oct '26

Hi all, Slightly off-topic for the AMR/E1 discussion, but the "what do you keep around while working on this gear" tangent in this thread reminded me of something small that quietly helps every morning: Wordle answer today at https://wordanswer.today/ — it offers hints first and then the full answer for the daily puzzle, plus published puzzles, clue explanations and archives for the days a word simply refuses to come. Nice little break between BTS builds. Thanks Csaba and Mychaela for the detailed CSD and OML notes; the explanation of the nokia_site dialect covering equipment beyond the *Site family was genuinely useful for anyone still running legacy Nokia hardware. Regards

1 0

OsmoBSC - lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH
by cristi.live＠yahoo.com 13 Oct '26

13 Oct '26

Hello guys, I found an interesting issue. After I place a call to a number which is not existent in HLR DB I am not able to make a call to an existing one anymore. Seems the timeslot is not released properly. If I am doing a BSC config adjustment like channel allocator mode assignment to descending (assuming it was ascending before) I am able to make a call again (until i call a wrong number and the lchan gets stucked). Im using an ipaccess nanoBTS (fw version 168d502_v206b17d0) as hardware and latest versions of Osmocom packages (BSC, MSC, HLR, MGW and STP) with minimal changes of example configuration (from /etc/osmocom). Do you have any idea if could be an issue related to nanoBTS firmware? Regards, Cristian

2 1

Nokia AirScale GSM Packet Abis/IUA support in OsmoBSC ? working lab hardware available
by Ciccio Franco 05 Oct '26

05 Oct '26

Hello, we are trying to bring up a Nokia AirScale GSM BTS in an isolated laboratory using OsmoBSC 1.15.0. Hardware: Nokia AirScale ASIB + ABIA + FXDA GSM900 radio (472083A). BTS software: SBTS25R2, GSM RAT 25R2. The BTS is configured for Nokia Packet Abis over IP. BTS GSM IP: 172.19.107.97 BSC IP: 172.17.208.121 SCTP/IUA port: 49152 We developed a small IUA ↔ libosmo-abis bridge and currently achieve: SCTP association OK ASPUP / ASPUP_ACK OK ASPAC / ASPAC_ACK OK IUA AS ACTIVE OK Nokia uses one SCTP stream and PPID 1. The Routing Context / Interface Identifier observed is 0x00028e00 (BCF ID 654). OsmoBSC establishes its local LAPD link using SAPI 62 / TEI 1 and starts Nokia OML bootstrap. However the AirScale never establishes OMUSIG at application level. WebEM reports: Fault 2412: OMU signaling connection failure in Abis interface. We tested both sending the Nokia RESET_REQ after AS ACTIVE and an IUA TEI-first procedure. SCTP acknowledges the packets, but no Nokia OML response is received. The same behavior has been reproduced with two SBTS25R2 software builds, and an unrelated software-fallback alarm has now been eliminated. We understand that current OsmoBSC Nokia support is nokia-e1, including recent Flexi Multiradio support, while Nokia Packet Abis/IP support is not yet implemented. We have a complete Nokia AirScale GSM laboratory setup available and can provide remote access, packet captures, WebEM logs and test patches if somebody is interested in implementing/debugging nokia-ip support. Our immediate objective is to bring at least one GSM TRX/BCCH on air in the isolated RF laboratory. We can provide: PCAP of the SCTP/IUA association complete iua bridge source code OsmoBSC logs AirScale configuration and runtime exports Nokia alarm information interactive access to the physical AirScale BTS Is anyone interested in helping us identify the missing Packet Abis/IUA bootstrap procedure or in working on Nokia IP Abis support in OsmoBSC? Thank you.

2 1

[RFC] libosmocore port to macOS Apple Silicon (ARM64)
by Andrei Gosman 14 Sep '26

14 Sep '26

Hello, I have put together a working port of libosmocore for macOS on Apple Silicon (M1/M2/M3/M4), and I would like guidance on whether the Osmocom project would consider accepting it upstream, and if so, in what form. Current state, published as a standalone fork: https://github.com/AndreiGosman/libosmocore-macos-arm64 The port enables native compilation and runtime of libosmocore and its submodules (libosmovty, libosmocodec, libosmogsm, libosmocoding, libosmoisdn) on Darwin/ARM64. On top of it I have gr-gsm building and running natively, with grgsm_decode functional on IQ captures from a LibreSDR B220 Mini via UHD. The rest of the stack (grgsm_scanner, grgsm_livemon, gr-osmosdr) is not yet addressed. The current patchset is pragmatic rather than idiomatic. Approach: - Six files that include Linux-only headers or use Linux-only APIs (linux/if.h, linux/tcp.h, cpu_set_t + sched_setaffinity, linux/if_tun.h) are wrapped whole in #ifdef __linux__: cpu_sched_vty, netdev, serial, stats_tcp, tun, gprs_ns2_fr. - A new src/core/darwin_stubs.c exports no-op public symbols for the wrapped files (osmo_tcp_stats_config, osmo_stats_tcp_*, osmo_timerfd_*, osmo_tundev_*), so consumers link cleanly on Darwin. - A darwin_compat.h is included via CFLAGS -include and provides dummy values for SO_PRIORITY, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME, plus a gettid() alias to getpid(). - src/core/exec.c sed-patched to substitute setresgid/setresuid (Linux) with setregid/setreuid (Darwin) for the specific 3-arg-equal use case. - configure invoked with --disable-uring --disable-libmnl --disable-libsctp. - LDFLAGS "-Wl,-undefined,dynamic_lookup" applied at make only, not at configure (to avoid false-positive detection of gettid/setns/unshare). I am aware this shape is unlikely to be acceptable as-is: whole-file wrapping is coarse, the compat header injection through CFLAGS bypasses your feature-detection model, and stubs that unconditionally return NULL/-1 have degraded semantics for real callers. My question: would upstream accept a refactored version of this? And if yes, in what shape: (1) Inline per-function or per-block #ifdef __linux__ conditionals within the existing files (no wraps, no separate stubs file). (2) Autoconf feature detection (AC_CHECK_HEADERS / AC_CHECK_FUNCS) with HAVE_* macros driving conditional compilation in .c files, and a proper compat header included from public headers rather than via -include. (3) A combination: (2) for portable features, (1) with clear comments for the rest, and darwin_stubs.c kept as a small explicit file referenced from Makefile.am rather than added implicitly. If any of the above is acceptable, I am willing to invest the time to refactor, submit via Gerrit, and iterate on review. If macOS support is out of scope for the project by policy, I will keep the fork as a standalone resource for the Mac community and close this thread. Testing environment for the current patchset: - macOS Tahoe (Darwin 25.5.0), Apple Silicon M4 - Homebrew 6.0.21, GNU Radio 3.10.12, Python 3.14 - libosmocore tag 1.14.2.4-2a26b Full patch details and rationale are in the fork README: https://github.com/AndreiGosman/libosmocore-macos-arm64/blob/master/README.… Thanks for your time, and for the project. Andrei Gosman

2 1

On the use of 'decmatch' in TTCN-3
by Harald Welte 31 Aug '26

31 Aug '26

Hi, I know that TTCN-3 is still new to a lot of you, but we are writing tons of integration testing against the various osmocom programs in it. It is quite amazing technology, and I would like to ask you to bear with me reading this mail :) Pau was stating the question earlier today on not finding an example on how to use decmatch. Indeed, it took me some months to find that gem in the TTCN-3 world. It solves the problem that you often have during test of layered protocol stacks: you have separate encoders/decoders for each protocol layer, and now you want to match on some of the *inner* payload. So normally, you have some kind of header definition + a binary (octetstring) payload. This happens in RSL with the L3_INFO IE, and just the same on BSSAP/DTAP where again the L3 message (for example call control) is encapsulated inside one information element. Now you have multiple options of addressing the problem: a) hand-written calls to the decoder function b) write na 'emulation' for the entire protocol layer c) use decmatch. a) would look like this (pseudo-code): var octetstring l3oct; var RSL_Message rsl RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, ?)) -> value rsl { var PDU_ML3_MS_NW l3 := dec_PDU_ML3_MS_NW(rsl.payload); if (match(l3, some_template)) { ... do something } ... } Which uses the built-in pattern-matching on the RSL port to match any message that matches the tr_RSL_DATA_REQ template, and stores the resulting RSL message in a variable. It then uses an explicit call to the decoder function of the L3 message, and then uses regular conditional expressions for further matching on that inner L3 payload. This is more or less how you would write in C, python or any other quite imperative programming languages. It's very verbose, time consuming and un-abstract/elegant. TTCN-3 has many declarative aspects to it. Code like the above is a waste of your time :) b) would mean that you implement some test component that handles the RSL messages on its bottom side test port, and the L3 messages on its top side test port. That is a possible way, and if you need a lot of state/logic of RSL, it maeks sense. But what if you really simply want to have a match? Then it would be a lot of effort and a large detour. c) decmatch to the rescue! You can write RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_STATUS)) which means: * do a receive on the RSL test port, and match on an incoming RSL message that matches the tr_RSL_DATA_REQ template, with channel number specified, link_id any (?), *and* if the octetstring payload, if decoded, matches the template tr_RRM_RR_STATUS ! This is *extremely* powerful and expressive. It allows you to condense complex, parametric template matching over multiple proocol layers. It would in the end match RSL DATA REQUEST, only if they contained a [valid] encoded RR STATUS. See https://gerrit.osmocom.org/6229 for the actual test case I used for the above examples. Please also note that I never had to even write the function name of the decoder (dec_PDU_ML3_MS_NW), but TTCN-3 *automatically* figures out which decoder function it must call in order to decode from the binary octetstring. Happy (TTCN-3) hacking + Osmocom bugfixing, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 4

Splitting out M3UA and MTP3 out of Open BSC
by max1987martin＠outlook.com 18 Aug '26

18 Aug '26

The HLR we were targeting only supported a SCTP/M3UA/SCCP/TCAP/MAP stack, so we couldn't use SUA. Ripping the M3UA/MTP3 code out of OpenBSC worked surprisingly well. We ended up running the event loop in a separate thread to work around the threading issues. Unfortunately the HLR implements the ANSI variant of everything, whereas OpenBSC and supporting libraries seem to have been written to be compatible with the ITU standards.

1 0

OsmoBSC - lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH
by Ionut Cristian CIOC 14 Jun '26

14 Jun '26

Hello guys, I found an interesting issue. After I place a call to a number which is not existent in HLR DB I am not able to make a call to an existing one anymore. Seems the timeslot is not released properly. If I am doing a BSC config adjustment like channel allocator mode assignment to descending (assuming it was ascending before) I am able to make a call again (until i call a wrong number and the lchan gets stucked). The error looks like: <000f> lchan_select.c:454 lchan(0-0-1-TCH_F-0)[0x55babd2a89c0]{UNUSED}: (type=TCH_F) Selected <0011> assignment_fsm.c:709 assignment(msc0-conn79_subscr-IMSI- xxxxxxxxxxxxxxxx-TMSI-0x63d29a26_0-0-1-TCH_F- 0)[0x55babd2a69a0]{WAIT_LCHAN_ACTIVE}: (bts=0,trx=0,ts=1,ss=0) Starting Assignment: chan_mode=SPEECH_V1, chan_type=FR, aoip=yes MSC- rtp=127.0.0.1:4382 (osmux=no) <000f> lchan_fsm.c:838 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_TS_READY}: (type=TCH_F) Activation requested: ACTIVATE_FOR_ASSIGNMENT rtp=yes MGW-ci=new type=TCH_F tch- mode=SPEECH_V1 encr-alg=A5/0 ck=none <000f> lchan_fsm.c:1027 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_ACTIV_ACK}: (type=TCH_F) Rx Activ ACK SPEECH_V1 <000f> lchan_rtp_fsm.c:369 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) lchan-rtp failure in state WAIT_IPACC_CRCX_ACK: Received NACK on IPACC CRCX <000f> lchan_fsm.c:1147 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Failed to setup RTP stream: LCHAN_EV_RTP_ERROR in state WAIT_RLL_RTP_ESTABLISH <000f> lchan_fsm.c:160 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) Signalling Assignment FSM of error (lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Failed to setup RTP stream: LCHAN_EV_RTP_ERROR in state WAIT_RLL_RTP_ESTABLISH) <0011> assignment_fsm.c:1043 assignment(msc0-conn79_subscr-IMSI- xxxxxxxxxxxxxxxx-TMSI-0x63d29a26_0-0-1-TCH_F- 0)[0x55babd2a69a0]{WAIT_RR_ASS_COMPLETE}: (bts=0,trx=0,ts=1,ss=0) Assignment failed in state WAIT_RR_ASS_COMPLETE, cause RADIO INTERFACE MESSAGE FAILURE: Failed to activate lchan (bts=0,trx=0,ts=1,ss=0) <0007> osmo_bsc_sigtran.c:624 (msc=0) Tx MSC: BSSMAP: ASSIGNMENT FAIL Im using an ipaccess nanoBTS (fw version 168d502_v206b17d0) as hardware and latest versions of Osmocom packages (BSC, MSC, HLR, MGW and STP) with minimal changes of example configuration (from /etc/osmocom). Do you have any idea if could be an issue related to nanoBTS firmware? Regards, Cristian

1 0

E1 to IP with iCE40 E1 USB interface
by Alina Androne 28 May '26

28 May '26

Hello, How can I utilize the iCE40 E1 USB adapter to transition from E1 to IP in a GSM network, connecting a physical Siemens BSC (which has a BTS connected) to OsmoMSC? Only the BTS and BSC are physical. I already have osmo-e1d installed. Should I use osmo-e1d or dahdi version for this transition? What would be the best approach to begin the process? Regards, Alina

6 12

GSM Silent call
by samir 04 May '26

04 May '26

Hi, I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC ?

4 3