OpenBSC April 2019

openbsc@lists.osmocom.org

21 participants
18 discussions

Pysim error: SW match failed
by Martin Nagy 16 Aug '25

16 Aug '25

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

3 3

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

07 Jul '25

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

4 3

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

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

3 5

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

31 Jan '24

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

2 1

OpenBSC on 3rd party MSC
by wyao＠corrections.com 29 Jul '19

29 Jul '19

Hello All, I am working on get OpenBSC connected to a 3rd party MSC, I read from the Osmo document that I can use the bsc only mode and the osm-bsc instead of the osmo-nitb. Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp configured and and running, but I see a lot of below error logs in the osmo-stp console: ``````````````````````````` DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb(): sctp_recvmsg() returned 56 (flags=0x80) DLM3UA <000f> m3ua.c:722 asp-asp-dyn-0: Received M3UA Message (XFER:DATA) DLM3UA <000f> m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer DLM3UA <000f> m3ua.c:580 asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header: opc=337=0.42.1 dpc=185=0.23.1 DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route! ```````````````````````````` On the BSC console, I am seeing a lot of: ``````````````````````````````` <0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP ``````````````````````````````` Can anyone identify what is the issue here? Appreciates! Regards, Weiqi

3 4

osmo_quote_str_c()
by Neels Hofmeyr 07 May '19

07 May '19

I think here is a bug: char *osmo_quote_str_c(const void *ctx, const char *str, int in_len) { char *buf = talloc_size(ctx, OSMO_MAX(in_len+2, 32)); if (!buf) return NULL; return osmo_quote_str_buf2(buf, 32, str, in_len); } We may allocate more than 32 bytes (see OSMO_MAX()) but still allow to write only 32 bytes? Looks like the allocated len should be stored in a local variable to pass to osmo_quote_str_buf2(). And if I'm right, what is the 32 for? At least 32?? ~N

3 2

Hard-dropping a PDP Context (SGSN)
by Mykola Shchetinin 23 Apr '19

23 Apr '19

Dear Osmocom community, A question about this part of code - function sgsn_ggsn_ctx_drop_pdp: http://git.osmocom.org/osmo-sgsn/tree/src/gprs/gprs_sgsn.c#n720 The second branch of the condition (hard-dropping) is called even when the phone is registered, and hence no Deactivate PDP Context Request is sent to the phone. Due to that, the phone doesn't know that the PDP Context was deleted on the network side and keeps acting as if it is still active -> the PS isn't working when this happens. Any suggestions/thoughts on how this can be fixed? Thanks Kind regards, Mykola

2 1

LimeNet Micro for BTS
by Rafael Diniz 15 Apr '19

15 Apr '19

Hi all, Have anyone tried Osmo GSM stack (including the trx) with the LimeNet Micro with the Pi compute module? My question is if it is stable enough for any real deployment or just another toy for the lab. With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, with lots of failure messages... Thanks, Rafael Diniz Rhizomatica

5 7

gsmtap design/extensions?
by Johannes Berg 15 Apr '19

15 Apr '19

Hi, As I'm looking into adding a generic cell modem framework to the linux kernel (to create session netdevs etc.), I started looking for a metadata encapsulation, a la Radiotap (I'm a wifi guy :-) ). So obviously, I found gsmtap, but for my use case it doesn't really address most of the interesting data, and it got me wondering. So a few questions, if I may: 1) Why the design with encapsulating it in UDP? Radiotap is just a raw header without IP etc. in front, and you use it with tcpdump, wireshark or similar tools on the local system. What's the value in having something "network transparent"? 2) The format of gsmtap doesn't seem very extensible, but I guess a new version could be made that has a TLV-based format or so. I'd have argued that a new version isn't even needed, but the length field is only 8 bits right now which seems too short. (speaking of versions - the docs say "version, set to 0x01 currently" but "#define GSMTAP_VERSION 0x02") 3) Does the packet data follow the gsmtap header? It's not really clear to me based on reading the wireshark code. In particular, the data I'm thinking of is higher-level things, like the session ID for a frame when it's going through the kernel, or perhaps a flow label on RX, etc. Also, vendor-specific data would be useful, e.g. to encapsulate the device-specific headers like QMI, where such metadata is encapsulated in a vendor- or device-specific way, which you'd want to see for debugging certain things, but for other things the generic "session ID" type information - encoded in a vendor-agnostic way - would be better to show in wireshark. Since it doesn't seem possible to use gsmtap in the current version, would it make sense to define a new gsmtap that (say) has version 3 or something, followed by an overall length and TLVs? I do note that this wouldn't be compatible with the current wireshark code as it doesn't check the version, just shows it... Or would it make more sense to define a new ARPHDR_WWANTAP like ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in IP/UDP, and then have a completely new (extensible) protocol inside of that? I'm not really sure I see the point of UDP encapsulation anyway. Thanks, johannes

6 22

sccp conn_id weirdness
by Neels Hofmeyr 12 Apr '19

12 Apr '19

I noticed some odd behavior in our SCCP stack, let me outline. Should this become a new issue? Because the osmo_scu_prim conn_id patches aren't merged yet, I put a temporary shim in place like we have in osmo-bsc to figure out new outgoing conn_ids. With this shim I noticed that some conn_ids work better than others: struct ran_conn *ran_conn_create_outgoing(struct ran_peer *ran_peer) { /* FIXME use method being developed in gerrit id Ifd55c6b7ed2558ff072042079cf45f5068a971de */ static uint32_t next_outgoing_conn_id = 0x80000000; uint32_t conn_id = 0; int attempts = 1000; bool already_used = true; while (attempts--) { struct ran_conn *conn; conn_id = next_outgoing_conn_id; next_outgoing_conn_id++; already_used = false; llist_for_each_entry(conn, &ran_peer->sri->ran_conns, entry) { if (conn->sccp_conn_id == conn_id) { already_used = true; break; } } if (!already_used) break; } if (already_used) return NULL; LOG_RAN_PEER(ran_peer, LOGL_DEBUG, "Outgoing conn id: %u\n", conn_id); return ran_conn_create_incoming(ran_peer, conn_id); } The weird thing is that the conn_id of 0x80000000 does *NOT* work and gets me a log line of: DLSCCP NOTICE Cannot find connection for local reference 0 (sccp_scoc.c:1636) where the MSC should be sending out the initial N-CONNECT to osmo-bsc. However, if I set the initial value to: next_outgoing_conn_id = 2342; then everything works out fine. I am at a loss to understand why this would happen, and currently don't have the cycles left to investigate. Maybe someone else wants to investigate why this happens... Logging for the failing case with 0x80000000: (the source file numbers might be a bit off current master) 20190412033755322 DBSSAP DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Outgoing conn id: 2147483648 (ran_conn.c:81) [...] 20190412033755327 DBSSAP DEBUG msc_t(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b220]{WAIT_HO_REQUEST_ACK}: NAS encode: BSSMAP: HANDOVER_REQUEST (nas_a.c:1159) 20190412033755328 DRR DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Received Event RAN_PEER_EV_MSG_DOWN_CO_INITIAL (ran_conn.c:119) 20190412033755328 DLSCCP DEBUG Received SCCP User Primitive (N-CONNECT.request) (sccp_scoc.c:1712) 20190412033755328 DLSCCP DEBUG SCCP-SCOC(2147483648)[0x6120000201a0]{IDLE}: Allocated (fsm.c:423) 20190412033755328 DLSCCP DEBUG SCCP-SCOC(2147483648)[0x6120000201a0]{IDLE}: Received Event N-CONNECT.req (sccp_scoc.c:1753) 20190412033755328 DLSS7 DEBUG sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CORE,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Protocol Class,L=4,D=00000002), PART(T=Source Reference,L=4,D=80000000), PART(T=Destination Address,L=20,D=0002000380020008000008bc80030008000000fe), PART(T=Sequence Control,L=4,D=00000000), PART(T=Source Address,L=20,D=0002000380020008000008b980030008000000fe), PART(T=Data,L=83,D=0051100b07010aa19181a5050a09004ad48954cb991d2912035058a605080062f224002a000005080009f1070046000104010c130a6014042f6500200240422c04080899100700001074507c06c0a80204a418) (sccp_scrc.c:398) 20190412033755328 DLSUA DEBUG sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 08 bc 80 03 00 08 00 00 00 fe (sua.c:385) 20190412033755328 DLSUA DEBUG SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 08 bc 80 03 00 08 00 00 00 fe (sua.c:385) 20190412033755328 DLSUA DEBUG SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 08 b9 80 03 00 08 00 00 00 fe (sua.c:385) 20190412033755328 DLSUA DEBUG SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412033755328 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): dpc=2236=1.23.4 not local, message is for routing (osmo_ss7_hmrt.c:278) 20190412033755328 DLSS7 DEBUG Found route for dpc=2236=1.23.4: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A-Iu proto=m3ua (osmo_ss7_hmrt.c:227) 20190412033755328 DLSS7 DEBUG rt->dest.as proto is M3UA for dpc=2236=1.23.4 (osmo_ss7_hmrt.c:233) 20190412033755328 DLSS7 DEBUG XUA_AS(as-clnt-OsmoMSC-A-Iu)[0x61200000a720]{AS_ACTIVE}: Received Event AS-TRANSFER.req (m3ua.c:507) 20190412033755329 DLSCCP DEBUG SCCP-SCOC(2147483648)[0x6120000201a0]{IDLE}: State change to CONN_PEND_OUT (no timeout) (sccp_scoc.c:829) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{WAIT_MGW_RESPONSE}: rtpbridge/2@msc CI[0] RTP_TO_RAN CI=88A322A7: CRCX: done (rtpbridge/2@msc:192.168.2.4:42008) (mgcp_client_endpoint_fsm.c:651) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{WAIT_MGW_RESPONSE}: rtpbridge/2@msc CI[1] RTP_TO_CN CI=55D5651B: CRCX: done (rtpbridge/2@msc:192.168.2.4:42010) (mgcp_client_endpoint_fsm.c:651) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{WAIT_MGW_RESPONSE}: rtpbridge/2@msc CI in use: 2, waiting for response: 0 (mgcp_client_endpoint_fsm.c:669) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{WAIT_MGW_RESPONSE}: State change to IN_USE (no timeout) (mgcp_client_endpoint_fsm.c:680) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{IN_USE}: rtpbridge/2@msc CI[0] RTP_TO_RAN CI=88A322A7: CRCX: done (rtpbridge/2@msc:192.168.2.4:42008) (mgcp_client_endpoint_fsm.c:651) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{IN_USE}: rtpbridge/2@msc CI[1] RTP_TO_CN CI=55D5651B: CRCX: done (rtpbridge/2@msc:192.168.2.4:42010) (mgcp_client_endpoint_fsm.c:651) 20190412033755329 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412033755329 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412033755329 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412033755329 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412033755332 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected read (stream.c:296) 20190412033755332 DLINP DEBUG [ CONNECTED] osmo_stream_cli_read(): message received (stream.c:210) 20190412033755332 DLSS7 DEBUG asp-asp-clnt-OsmoMSC-A-Iu: xua_cli_read_cb(): sctp_recvmsg() returned 48 (flags=0x80) (osmo_ss7.c:1609) 20190412033755333 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: Received M3UA Message (XFER:DATA) (m3ua.c:722) 20190412033755333 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer (m3ua.c:541) 20190412033755333 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer(): M3UA data header: opc=2236=1.23.4 dpc=2233=1.23.1 (m3ua.c:580) 20190412033755333 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=2233=1.23.1 as local (osmo_ss7_hmrt.c:274) 20190412033755333 DLSUA DEBUG IEI 259: Parsed Addr: RI=2,PC=2236,SSN=254 (sccp2sua.c:333) 20190412033755333 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:COAK,V=0,LEN=0), PART(T=Protocol Class,L=4,D=00000002), PART(T=Destination Reference,L=4,D=00000000), PART(T=Source Reference,L=4,D=00000000), PART(T=Destination Address,L=20,D=0002000380020008000008bc80030008000000fe) (sccp_scrc.c:450) 20190412033755333 DLSCCP NOTICE Cannot find connection for local reference 0 (sccp_scoc.c:1636) 20190412033755333 DLSS7 DEBUG sccp_scrc_rx_scoc_conn_msg: HDR=(CO:COERR,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Destination Reference,L=4,D=00000000), PART(T=Cause,L=4,D=00000500) (sccp_scrc.c:398) 20190412033755333 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): dpc=2236=1.23.4 not local, message is for routing (osmo_ss7_hmrt.c:278) 20190412033755333 DLSS7 DEBUG Found route for dpc=2236=1.23.4: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A-Iu proto=m3ua (osmo_ss7_hmrt.c:227) 20190412033755333 DLSS7 DEBUG rt->dest.as proto is M3UA for dpc=2236=1.23.4 (osmo_ss7_hmrt.c:233) 20190412033755333 DLSS7 DEBUG XUA_AS(as-clnt-OsmoMSC-A-Iu)[0x61200000a720]{AS_ACTIVE}: Received Event AS-TRANSFER.req (m3ua.c:507) 20190412033755333 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412033755333 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412033755334 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412033755334 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412033755337 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected read (stream.c:296) 20190412033755337 DLINP DEBUG [ CONNECTED] osmo_stream_cli_read(): message received (stream.c:210) 20190412033755337 DLSS7 DEBUG asp-asp-clnt-OsmoMSC-A-Iu: xua_cli_read_cb(): sctp_recvmsg() returned 48 (flags=0x80) (osmo_ss7.c:1609) 20190412033755337 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: Received M3UA Message (XFER:DATA) (m3ua.c:722) 20190412033755337 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer (m3ua.c:541) 20190412033755337 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer(): M3UA data header: opc=2236=1.23.4 dpc=2233=1.23.1 (m3ua.c:580) 20190412033755337 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=2233=1.23.1 as local (osmo_ss7_hmrt.c:274) 20190412033755338 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:CODT,V=0,LEN=0), PART(T=Destination Reference,L=4,D=00000000), PART(T=Segmentation,L=4,D=00000000), PART(T=Data,L=6,D=000422040120) (sccp_scrc.c:450) 20190412033755338 DLSCCP NOTICE Cannot find connection for local reference 0 (sccp_scoc.c:1636) The same logging for the exact same code and situation, only with 2342 instead of 0x80000000: 20190412040110445 DBSSAP DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Outgoing conn id: 2342 (ran_conn.c:81) [...] 20190412040110451 DBSSAP DEBUG msc_t(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001a920]{WAIT_HO_REQUEST_ACK}: NAS encode: BSSMAP: HANDOVER_REQUEST (nas_a.c:1159) 20190412040110451 DRR DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Received Event RAN_PEER_EV_MSG_DOWN_CO_INITIAL (ran_conn.c:119) 20190412040110451 DLSCCP DEBUG Received SCCP User Primitive (N-CONNECT.request) (sccp_scoc.c:1712) 20190412040110451 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{IDLE}: Allocated (fsm.c:423) 20190412040110451 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{IDLE}: Received Event N-CONNECT.req (sccp_scoc.c:1753) 20190412040110451 DLSS7 DEBUG sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CORE,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Protocol Class,L=4,D=00000002), PART(T=Source Reference,L=4,D=00000926), PART(T=Destination Address,L=20,D=0002000380020008000008bc80030008000000fe), PART(T=Sequence Control,L=4,D=00000000), PART(T=Source Address,L=20,D=0002000380020008000008b980030008000000fe), PART(T=Data,L=83,D=0051100b07010aa19181a5050a090086dc7f8e3f4115be12035058a605080062f224002a000005080009f1070046000104010c130a6014042f6500200240422c04080899100700001074507c06c0a80204a418) (sccp_scrc.c:398) 20190412040110451 DLSUA DEBUG sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 08 bc 80 03 00 08 00 00 00 fe (sua.c:385) 20190412040110451 DLSUA DEBUG SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412040110451 DLSUA DEBUG SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412040110451 DLSUA DEBUG sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 08 bc 80 03 00 08 00 00 00 fe (sua.c:385) 20190412040110451 DLSUA DEBUG SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412040110452 DLSUA DEBUG SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412040110452 DLSUA DEBUG sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 08 b9 80 03 00 08 00 00 00 fe (sua.c:385) 20190412040110452 DLSUA DEBUG SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412040110452 DLSUA DEBUG SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412040110452 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): dpc=2236=1.23.4 not local, message is for routing (osmo_ss7_hmrt.c:278) 20190412040110452 DLSS7 DEBUG Found route for dpc=2236=1.23.4: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A-Iu proto=m3ua (osmo_ss7_hmrt.c:227) 20190412040110452 DLSS7 DEBUG rt->dest.as proto is M3UA for dpc=2236=1.23.4 (osmo_ss7_hmrt.c:233) 20190412040110452 DLSS7 DEBUG XUA_AS(as-clnt-OsmoMSC-A-Iu)[0x61200000a720]{AS_ACTIVE}: Received Event AS-TRANSFER.req (m3ua.c:507) 20190412040110452 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{IDLE}: State change to CONN_PEND_OUT (no timeout) (sccp_scoc.c:829) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{WAIT_MGW_RESPONSE}: rtpbridge/2@msc CI[0] RTP_TO_RAN CI=D1035D6D: CRCX: done (rtpbridge/2@msc:192.168.2.4:42008) (mgcp_client_endpoint_fsm.c:651) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{WAIT_MGW_RESPONSE}: rtpbridge/2@msc CI[1] RTP_TO_CN CI=A01EF28B: CRCX: done (rtpbridge/2@msc:192.168.2.4:42010) (mgcp_client_endpoint_fsm.c:651) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{WAIT_MGW_RESPONSE}: rtpbridge/2@msc CI in use: 2, waiting for response: 0 (mgcp_client_endpoint_fsm.c:669) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{WAIT_MGW_RESPONSE}: State change to IN_USE (no timeout) (mgcp_client_endpoint_fsm.c:680) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{IN_USE}: rtpbridge/2@msc CI[0] RTP_TO_RAN CI=D1035D6D: CRCX: done (rtpbridge/2@msc:192.168.2.4:42008) (mgcp_client_endpoint_fsm.c:651) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{IN_USE}: rtpbridge/2@msc CI[1] RTP_TO_CN CI=A01EF28B: CRCX: done (rtpbridge/2@msc:192.168.2.4:42010) (mgcp_client_endpoint_fsm.c:651) 20190412040110452 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412040110453 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412040110453 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412040110453 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412040110457 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected read (stream.c:296) 20190412040110457 DLINP DEBUG [ CONNECTED] osmo_stream_cli_read(): message received (stream.c:210) 20190412040110457 DLSS7 DEBUG asp-asp-clnt-OsmoMSC-A-Iu: xua_cli_read_cb(): sctp_recvmsg() returned 48 (flags=0x80) (osmo_ss7.c:1609) 20190412040110457 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: Received M3UA Message (XFER:DATA) (m3ua.c:722) 20190412040110457 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer (m3ua.c:541) 20190412040110457 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer(): M3UA data header: opc=2236=1.23.4 dpc=2233=1.23.1 (m3ua.c:580) 20190412040110457 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=2233=1.23.1 as local (osmo_ss7_hmrt.c:274) 20190412040110457 DLSUA DEBUG IEI 259: Parsed Addr: RI=2,PC=2236,SSN=254 (sccp2sua.c:333) 20190412040110457 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:COAK,V=0,LEN=0), PART(T=Protocol Class,L=4,D=00000002), PART(T=Destination Reference,L=4,D=00000926), PART(T=Source Reference,L=4,D=00000000), PART(T=Destination Address,L=20,D=0002000380020008000008bc80030008000000fe) (sccp_scrc.c:450) [this is where above, the "Cannot find" error occurs] 20190412040110457 DLSCCP DEBUG Received CO:COAK for local reference 2342 (sccp_scoc.c:1645) 20190412040110457 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{CONN_PEND_OUT}: Received Event RCOC-CONNECT_CONFIRM.ind (sccp_scoc.c:1678) 20190412040110457 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{CONN_PEND_OUT}: State change to ACTIVE (no timeout) (sccp_scoc.c:980) 20190412040110458 DLSCCP DEBUG Delivering N-CONNECT.confirm to SCCP User 'OsmoMSC-A' (sccp_user.c:156) 20190412040110458 DBSSAP DEBUG (GERAN-A) sccp_ran_sap_up(N-CONNECT.confirm) (sccp_ran.c:143) 20190412040110464 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected read (stream.c:296) 20190412040110464 DLINP DEBUG [ CONNECTED] osmo_stream_cli_read(): message received (stream.c:210) 20190412040110464 DLSS7 DEBUG asp-asp-clnt-OsmoMSC-A-Iu: xua_cli_read_cb(): sctp_recvmsg() returned 76 (flags=0x80) (osmo_ss7.c:1609) 20190412040110464 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: Received M3UA Message (XFER:DATA) (m3ua.c:722) 20190412040110464 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer (m3ua.c:541) 20190412040110464 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer(): M3UA data header: opc=2236=1.23.4 dpc=2233=1.23.1 (m3ua.c:580) 20190412040110464 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=2233=1.23.1 as local (osmo_ss7_hmrt.c:274) 20190412040110464 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:CODT,V=0,LEN=0), PART(T=Destination Reference,L=4,D=00000926), PART(T=Segmentation,L=4,D=00000000), PART(T=Data,L=34,D=002012170f062bc1660b2366010763410302280821982c0440217c06c0a8020359e4) (sccp_scrc.c:450) 20190412040110464 DLSCCP DEBUG Received CO:CODT for local reference 2342 (sccp_scoc.c:1645) 20190412040110464 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{ACTIVE}: Received Event RCOC-DT1.ind (sccp_scoc.c:1678) 20190412040110464 DLSCCP DEBUG Delivering N-DATA.indication to SCCP User 'OsmoMSC-A' (sccp_user.c:156) 20190412040110464 DBSSAP DEBUG (GERAN-A-2342) sccp_ran_sap_up(N-DATA.indication) (sccp_ran.c:106) 20190412040110464 DRR DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Received Event RAN_PEER_EV_MSG_UP_CO (ran_peer.c:529) 20190412040110464 DMSC DEBUG msc_t(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001a920]{WAIT_HO_REQUEST_ACK}: Received Event MSC_EV_FROM_RAN_UP_L2 (ran_peer.c:346) 20190412040110464 DBSSAP DEBUG msc_t(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001a920]{WAIT_HO_REQUEST_ACK}: NAS decode: BSSMAP: Rx BSSMAP DT1 HANDOVER REQ ACK (nas_a.c:779) I can only suspect that somewhere the value range is stripped?? I have pcaps for these two if anyone is interested. It was tested with current libosmo-sccp master, as well as with the last commit reverted ("sccp_scoc: conn_create{,_id}() user arg, not inst"), identical results. ~N

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC April 2019