Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-02-27T17:53:18ZOpen Source Mobile Communications
Redmine erlang/osmo_ss7 - Bug #6377 (Feedback): ipa: Failure decoding ipa frames split between several tc...https://osmocom.org/issues/63772024-02-27T17:53:18Zpespin
<p>This happens when a lot of IPA concurrent clients send messages and end up in the same TCP packet due to naggle algorithm.<br />When that happens, ipa code in osmo_ss7 fails to decode in osmo-epdg:</p>
<pre>
*DBG* epdg_ue_fsm_262424287925697 receive call {auth_request,33,"internet"} from <0.204.0> in state state_new
*DBG* epdg_ue_fsm_262424287925697 send ok to <0.204.0>
*DBG* gsup_server new state {gsups_state,#Port<0.16>,4222,#Port<0.19>,
{ipa_ccm_options,"EPDG-00-00-00-00-00-00",
"0/0/0","00:00:00:00:00:00","00:00:00:00:00:00",
"00:00:00:00:00:00","00:00:00:00:00:00",
"00:00:00:00:00:00","EPDG-00-00-00-00-00-00",
false},
{set,6,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],
[]},
{{[],[],[],[],
[{gsups_ue,<<"262429242370912">>,<0.240.0>}],
[],
[{gsups_ue,<<"262423473100631">>,<0.243.0>}],
[],[],
[{gsups_ue,<<"262423491582839">>,<0.244.0>}],
[],[],
[{gsups_ue,<<"262424287925697">>,<0.248.0>}],
[{gsups_ue,<<"262426121377808">>,<0.245.0>}],
[{gsups_ue,<<"262426512097609">>,<0.246.0>}],
[]}}}}
*DBG* epdg_ue_fsm_262424287925697 consume call {auth_request,33,"internet"} from <0.204.0> in state state_new => state_wait_auth_res
p
*DBG* gsup_server got {ipa,#Port<0.19>,
{osmo,5},
#{imsi => <<"262425921669062">>,
message_type => send_auth_info_req,
pdp_info_list =>
[#{access_point_name => "internet",
pdp_address =>
#{address => #{},pdp_type_nr => 33,
pdp_type_org => 241},
pdp_context_id => 0}]}}
*DBG* epdg_ue_fsm_262425921669062 enter epdg_ue_fsm in state state_new
17:39:21.043 [error] Error in process <0.222.0> with exit value:
{{badmatch,<<0,32,238,5,8,1,8,98,66,98,68,72,146,87,244,5,18,16,1,0,17,2,241,33,18>>},[{ipa_proto,split_ipa_msg,1,[{file,"/tmp/osmo-
epdg/_build/default/lib/osmo_ss7/src/ipa_proto.erl"},{line,135}]},{ipa_proto,process_rx_ipa_msg,4,[{file,"/tmp/osmo-epdg/_build/defa
ult/lib/osmo_ss7/src/ipa_proto.erl"},{line,182}]},{ipa_proto,loop,3,[{file,"/tmp/osmo-epdg/_build/default/lib/osmo_ss7/src/ipa_proto
.erl"},{line,269}]}]}
</pre> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6361 (Feedback): open5gs-upfd: Fix open5gs ...https://osmocom.org/issues/63612024-02-15T19:50:49Zpespin
<p>From <a class="external" href="https://osmocom.org/issues/6235?issue_count=13&issue_position=5&next_issue_id=6229&prev_issue_id=6289#note-26">https://osmocom.org/issues/6235?issue_count=13&issue_position=5&next_issue_id=6229&prev_issue_id=6289#note-26</a>:</p>
<blockquote>
<p>Also, I had to tweak broken open5gs setup where open5gs-upfd ogtsun gets assigned IP address "10.45.0.1/16", but that IP address is actually also assigned to the first MS (my SWu emulator), and that creates problems in the network stack when the inner packet is decapsulated from GTP. In order to fix it:</p>
<pre>
> root@epc:~# ip addr del 10.45.0.1/16 dev ogstun
> root@epc:~# ip route add 10.45.0.0/24 dev ogstun
> </pre>
<p>According to lynxis this is a problem coming from open5gs package (file /etc/systemd/network/99-open5gs.network). The IP address is set in order to get the routing entry for free. Instead, it should only add the routing entry.</p>
</blockquote>
<p>We should look into fixing the open5gs package to avoid having to apply those changes every time open5gs-upf is restarted.</p> OsmoPCU - Bug #6359 (Feedback): TbfTest: sporadic SEGV in https://osmocom.org/issues/63592024-02-13T09:37:52Zpespin
<p>This error showed up today in raspbian11 test:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=master,WITH_MANUALS=0,label=rpi4-raspbian11,with_dsp=none,with_vty=False/6448/console">https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=master,WITH_MANUALS=0,label=rpi4-raspbian11,with_dsp=none,with_vty=False/6448/console</a></p>
<pre>
../../../tests/testsuite.at:28: $OSMO_QEMU $abs_top_builddir/tests/tbf/TbfTest
--- experr 2024-02-13 07:37:47.768562611 +0000
+++ /build/osmo-pcu-1.4.0.1-b04e1/_build/sub/tests/testsuite.dir/at-groups/4/stderr 2024-02-13 07:37:48.558541306 +0000
@@ -11580,18 +11580,16 @@
TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN} Starting timer X2001 [assignment (PACCH)] with 2 sec. 0 microsec
DL_TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}: Received Event ASSIGN_PCUIF_CNF
TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN} Ignoring event ASSIGN_PCUIF_CNF from BTS (CCCH was not requested on current assignment)
-DL_ASS_TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){SEND_ASS}: Received Event CREATE_RLCMAC_MSG
-PDCH(bts=0,trx=0,ts=2) POLL scheduled at FN 0 + 13 = 13
-TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN} start Packet Downlink Assignment (PACCH) for TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}
-+++++++++++++++++++++++++ TX : Packet Downlink Assignment +++++++++++++++++++++++++
-------------------------- TX : Packet Downlink Assignment -------------------------
-PDCH(bts=0,trx=0,ts=2) Reserving FN 13 for type POLL
-TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN} Scheduled DL Assignment polling on PACCH (FN=13, TS=2)
-DL_ASS_TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){SEND_ASS}: state_chg to WAIT_ACK
-PDCH(bts=0,trx=0,ts=2) FN=0 Scheduling control message at RTS for TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}
-=== end test_ms_merge_dl_tbf_different_trx ===
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0:UL:DL) Destroying MS object
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0:UL:DL) Detaching TBF: TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0:DL): - tbf: now used by 1 (tbf)
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0:DL) Detaching TBF: TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0): - tbf: now used by 0 (-)
+UL_TBF(UL:TFI-0-0-0:G){ASSIGN}: Timeout of X2002
+UL_TBF(UL:TFI-0-0-0:G){ASSIGN}: Received Event ASSIGN_READY_CCCH
+../../../src/tbf_ul_fsm.c:173:3: runtime error: member access within null pointer of type 'struct GprsMs'
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==1984==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000c (pc 0x00687b8e bp 0x1d52b65d sp 0xbeeb12b0 T0)
+==1984==The signal is caused by a READ memory access.
+==1984==Hint: address points to the zero page.
+ #0 0x687b8e in st_assign (/build/osmo-pcu-1.4.0.1-b04e1/_build/sub/tests/tbf/TbfTest+0x227b8e)
+
+AddressSanitizer can not provide additional info.
+SUMMARY: AddressSanitizer: SEGV (/build/osmo-pcu-1.4.0.1-b04e1/_build/sub/tests/tbf/TbfTest+0x227b8e) in st_assign
+==1984==ABORTING
stdout:
../../../tests/testsuite.at:28: exit code was 1, expected 0
4. testsuite.at:25: 4. tbf (testsuite.at:25): FAILED (testsuite.at:28)
</pre>
<p>At first sight it seems that something took longer than usual to run (due to load?) and then some event triggered which caused a SEGV.</p>
<p>I marked the job above as "Keep this build forever". It can be unmarked once this issue is looked at.<br />I also upload here the build artifacts of the job just in case.</p> libosmo-sccp + libosmo-sigtran - Bug #6356 (New): DLGLOBAL ERROR Trying to dispatch event 17 to n...https://osmocom.org/issues/63562024-02-08T22:27:51Zneelsnhofmeyr@sysmocom.de
<p>ML reports:</p>
<p>DLGLOBAL ERROR Trying to dispatch event 17 to non-existent FSM instance! (osmo_ss7_as.c:118)</p>
<p>during startup of both osmo-msc and osmo-bsc.<br />Probably related: <a class="external" href="https://gerrit.osmocom.org/c/libosmo-sccp/+/35348">https://gerrit.osmocom.org/c/libosmo-sccp/+/35348</a></p> Linux Kernel GTP-U - Bug #6212 (In Progress): GTP extension headershttps://osmocom.org/issues/62122023-10-06T11:11:59Zpablo
<p>GTP packets are dropped in the presence of extension header, add support for GTP driver to deal with this.</p> OsmoDia2GSUP - Bug #6148 (New): config file not installed not used by systemd service in debianhttps://osmocom.org/issues/61482023-08-24T16:37:25Zpespin
<ul>
<li>The config file under examples/sys.config is not being installed by debian/ rules afaict.</li>
<li>We should actually move that under doc/examples like the other osmocom projects, and install it under /usr/share and /etc like we do in other osmocom projects.</li>
<li>Probably also rename the file s/sys.config/osmo_dia2gsup.config/</li>
<li>Also, the systemd service under contrib/systemd doesn't seem to be using the config file. It should be passed as env var in the systemd file:<br /><pre>
ERL_FLAGS='-config /etc/osmocom/osmo_dia2gsup.config' osmo-dia2gsup
</pre></li>
</ul> OsmoHNBGW - Feature #6127 (Feedback): Submit RAB Modification Req towards HNB to udpate its peer ...https://osmocom.org/issues/61272023-08-01T16:27:43Zpespin
<p>Due to ip probing used at MGW and specific/complex routing in place between RAN and CN, it may happen that, on the RAN-side endpoint connection, the MGW first selects a local IP address.<br />Then, after the HNBGW signalling it to the HNB with the patched RabAssReq and receiving the HNB local IP address through RabAssResp, then applying it to MGW through MDCX, it can happen that the MDCX ACK contains a changed local IP address at the MGW, due to IP probing after learning the remote address.</p>
<p>This change is so far not announced to the HNB in anyway, ending up in the HNB sending IuUP packets to the wrong IP/port, which is rejected with ICMP due to osmo-mgw having no socket open there anymore.</p>
<p>The sequence goes like this:<br /><pre>
HNBGW <- MSC: RAB-AssignmentRequest [A.A.A.A:35932]
HNBGW -> MGW: CRCX
HNBGW <- MGW: CRCX ACK [IN IP4 B.B.B.B audio 3806 RTP/AVP 96]
HNBGW -> HNB: RUA-RAB-AssignmentRequest [B.B.B.B:3806]
[IuUP INIT + INIT ACK on C.C.C.C:16400 <-> B.B.B.B:3806]
HNBGW <- HNB: RUA-RAB-AssignmentResponse [C.C.C.C:16400]
HNBGW -> MGW: MDCX [C.C.C.C:16400]
HNBGW <- MGW: MDCX ACK [IN IP4 D.D.D.D audio 3808 RTP/AVP 96] !!!! HERE THE IP+PORT AT MGW CHANGES!!!! PROBABLY DUE TO ROUTING CONFIG AND IP PROBE!
</pre></p>
<p>We should at least, in osmo-hnbgw, if detecting the local MGW IP address changed during MDCX, tear down the call setup.</p>
<p>The best would be, though to signal the change of IP address to the HNB, using Rab Modify Req. See related spec in 3GPP TS 25.413 section 8.2:<br /><pre>
For the CS domain, when an ALCAP is used, UTRAN shall report the successful outcome of a specific RAB to
establish or modify only after the Iu user plane at RNL level is ready to be used in UL and DL. At a RAB
establishment, the transport network control plane signalling required to set up the transport bearer shall use the
Transport Layer Address IE and Iu Transport Association IE. At a RAB modification when Transport Layer Address
(IE) and Iu Transport Association IEs are included, the RNC shall establish a new transport bearer. The transport
network control plane signalling shall then use the included Transport Layer Address IE and Iu Transport Association
IE. Then the switch over to this new transport bearer shall be done immediately after transport bearer establishment and
initialisation of the user plane mode. If Transport Layer Address (IE) and Iu Transport Association IEs are not included,
then the RNC may modify the already existing transport bearer.
For the PS domain or for the CS domain when an ALCAP is not used, when they are present at a RAB modification, the
RNC shall use the embedded Transport Layer Address IE and Iu Transport Association IEs as the termination point of
the new transport bearer.
For the PS domain or for the CS domain when an ALCAP is not used, for each RAB successfully modified, if the RNC
has changed the Transport Layer Address IE and/or the Iu Transport Association IE, it shall include the new value(s) in
the RAB ASSIGNMENT RESPONSE message.
</pre></p> OsmocomBB - Bug #6125 (New): LLC GIA/GEA (auth/encryption) not yet testedhttps://osmocom.org/issues/61252023-07-31T14:34:12Zpespin
<p>Ms-side gprs ("modem" app) still has the LLC auth/encryption algos untested (not known to work yet).</p>
<p>The code in libosmo-gprs-llc ported from osmo-pcu is there, but passing/filling the proper params in related primitives.<br />Also, some code in libosmo-gprs-llc needs to be updated/fixed.</p> OsmoPCU - Bug #6118 (New): osmo-pcu assigns multi-slot TBFs over PACCH to MS with unknwon ms_classhttps://osmocom.org/issues/61182023-07-28T15:06:48Zpespin
<p>When the DL/UL TBF assignment happens over CCCH (PCH, AGCH) we don't have this problem, since assignment over CCH can only assign a single TS.<br />However, once that TBF is assigned and MS jumps to packet-active mode (PDCH), new TBF assignment can happen over PACCH.</p>
<p>It can be that at that point in time, the PCU doesn't know the MultiSlot Class of the MS, because the MS used 1phase access (aka no PktResourceReq containing RadioAccessCap) and the SGSN didn't provide the PCU with it during BSSGP-DL-UNITDATA (because it neither knows it).</p>
<p>As a result, when allocating a DL TBF at that time, the current alloc_algo, if the ms_class is not known (=0), it assumes ms_class=12:<br /><pre>
#define DEFAULT_MSLOT_CLASS 12
</pre></p>
<p>As a result, it ends up assigning up to 4 TS to an MS which may not support it (eg. because it's ms_class=1 but didn't inform the PCU about it, like "modem" osmocom-bb app currently).</p>
<p>Current behavior basically breaks proper operation of MS with ms_class<12 (fortunately most MS nowadays are ms_class=12 or higher).</p> OsmocomBB - Feature #6115 (Feedback): modem: MTU not set properly on tun ifacehttps://osmocom.org/issues/61152023-07-26T15:59:05Zpespin
<p>tested using iperf3 client in the netns + tun created by the "modem" app, against an iperf3 server running in the IP address of the GGSN outside the netns:<br /><pre>
iperf3 -c 176.16.222.1 -u -V
iperf3 -s -B 176.16.222.1
</pre></p>
<p>The iperf3 tries to fill in the MTU when sending packets, but there seems to be a problem when enqueueing them:<br /><pre>
20230726174215423 DLLC ERROR llc.c:359 LLE(c34b1498/c914945e,SNDCP3){ASSIGNED_ADM} Cannot Tx 1480 bytes (N201-U=500)
20230726174215433 DTUN DEBUG app_modem.c:121 APN(internet): system wants to transmit IPv4 pkt to 176.16.222.1 (1476 bytes)
20230726174215433 DSNDCP INFO sndcp_prim.c:424 Rx from upper layers: SN-UNITDATA.request
20230726174215434 DSNDCP DEBUG sndcp.c:130 modem_sndcp_prim_down_cb(): Rx LL-UNITDATA.request TLLI=0xc914945e SAPI=SNDCP3 L3=[66 00 05 d5 45 00 05 c4 78 bc 40 00 40 11 a0 47 b0 10 de 02 b0 10 de 01 aa 53 14 51 05 b0 3b dd 00 00 2a ed 00 0a f5 b0 00 00 01 8c 21 52 df 52 61 ce 27 d9 5b ea e8 ec 6d fe 02 45 1b 9c cc dc ec 38 8f e5 29 e9 b0 a0 1c 01 2b 3b 39 e1 9c 51 2f c5 79 14 de c8 b6 13 23 c5 b1 ff 79 d0 5e 1b 04 b2 4e 3f 90 a3 3a 00 df 13 ab 43 8c b7 d3 a8 45 39 a2 70 06 76 c1 fe 19 95 76 3a 74 51 18 6c 5c 4d c1 a0 4b 80 51 3d 73 c6 95 14 e3 76 f9 af 1c f4 28 70 0d 4e 78 21 83 32 a8 12 82 a6 76 01 f3 75 36 77 08 8d 0f 16 c7 be 7a 1b 51 bf 64 9b 0f fc c3 86 bd 1f 0a b0 8c 6f f7 d2 01 da 5b 07 72 72 66 4e 80 55 a6 77 86 bb 76 5c 9c 48 85 a3 5f 97 70 ce b0 ff 79 f9 e0 10 92 f3 e0 bc a0 ee d2 08 90 55 04 6c 8a 28 31 fb 00 66 24 54 67 36 c9 1d 0c 71 ff 09 52 7a 1b 4d 77 02 87 47 89 9f 62 ae da 4c 14 88 8b f5 cc 28 0a df 59 89 e2 72 64 28 dc 0e b2 59 10 57 ae 60 70 9c 31 ee 5d 55 c1 66 82 70 aa 4c 3b aa 79 45 8f e1 06 3c 68 66 8f 0b 86 90 4e 73 fd a9 f3 2e 9b 4a 3f 58 69 82 b1 c1 c2 4e af 5a dc d0 5b 6b 22 17 4f 74 8b 17 6e 0d 23 13 23 c2 1b f3 b0 56 ec fa 3b 48 98 bd 9b 7e e4 c9 a5 37 3f ed 05 d2 0e 0f f4 21 af 9e d0 83 31 70 12 8b 14 96 46 bf b9 3a 64 0a 75 da 0f 8d 83 d9 8a 9b 26 0b 4c 65 1d 26 f1 9e 75 08 8a 48 03 64 c0 a1 de d6 59 ad 9f 6b f6 cf 4a 65 08 cf 18 68 54 16 8f af 61 8c 06 fb 6a 09 93 c9 4a fb 00 94 16 9c 2f f3 a6 5e 90 55 29 7e 3a b9 04 2d 69 06 f7 89 2e 53 52 67 c4 73 43 05 9a ce af f9 7d 77 26 c1 a5 aa c8 8e 0f 80 c4 00 be 71 3f 1a f8 38 f1 4c 06 59 07 ac 06 32 eb 5a d2 35 db 3d 11 0c fa af 04 8c 56 d0 a8 3a 2f 50 9f cb 0d 44 10 38 f9 ab 79 97 0a 11 8a 21 4a d1 0d 4b 8c ea f4 79 2b ac f0 48 52 67 b8 36 05 1f 2e bb e4 c5 d1 8c 35 d4 8e fb 8d 8d 8d 15 26 fe 37 fd bb 6b af 2a b4 11 97 24 b0 28 15 ce 95 97 d5 7f 62 8b 73 77 d7 7f a6 72 23 35 fb 60 65 de 84 54 b9 a0 30 21 3e 87 f2 a7 9c 82 0c 92 6a 28 e4 06 6e 84 e9 6a 1c 20 5c 30 dd 1b 80 71 88 9f 5b 3b 74 2d 18 ed 6e f7 8c 67 ba ed 05 06 13 76 58 c0 7b 1b 1d d9 23 14 30 ef 97 4c 1d 48 a2 8e 83 49 1b 6b 75 90 b6 a0 98 e9 7d b1 c7 fa 39 6e a5 18 9a 94 ab 6d 18 d2 1f 61 39 a1 2e ca 7f b9 23 73 7d 29 a1 6a bd f6 9b e2 d9 cf fa 0f ca 46 c3 be 4a cc 7d 19 9e 23 be 74 65 7c cc e8 d7 f7 6c 8a 64 7b 0b 14 d3 b5 3f 19 47 94 08 70 23 02 01 2f 4d 09 07 4d 1f a6 6f b0 3b b3 7d 14 75 74 e5 1b 93 0a 52 0e 2a 02 e2 60 a9 dd 52 42 c9 c7 ee ab fb 7f fb 81 09 07 7a e7 64 1d bf 56 ad 68 c6 bc 73 81 a9 5a 03 4d 3f 02 66 73 87 01 11 dc f2 ab f9 a6 77 f2 db f3 4b 1f 32 05 4f ea 96 bc 7b e3 a5 e0 b4 de 3b ed 34 1f 95 9e ed f9 aa a6 ef 56 ea 17 a4 1a ad ea 64 8c f3 4b 05 a1 cd 31 92 82 c4 fa 43 07 f2 01 a4 9c e4 ae 4c cd ad f0 34 ec cb 4b 4d 3a b3 c1 3f b5 1f 0c 6a 8b d1 fb 2f 4e d6 59 c1 a3 61 1c cf 01 26 32 5b 97 a9 9a 31 16 b3 11 10 e6 ec 0f 74 d4 9e eb 57 ae 95 30 bc 8b 2f 41 fc fc 73 46 f8 1b 06 c6 b6 9c e7 a9 c3 13 2c 9d 93 f8 cc 61 d5 ff 09 4e 67 dc 79 60 80 67 00 86 83 d5 45 ad 5c f0 21 2b 81 29 98 19 85 cc 70 2c 43 0f bb 13 4d 31 41 5c 49 af d1 3d 82 fc 72 74 6b 81 a9 d4 d8 4a 75 8e 2c 54 f8 b1 1c 21 5e d6 f5 f8 0d 51 13 bc 6b 09 e9 d6 a0 bf 62 f8 b0 a7 64 39 fb 71 a1 b3 53 b9 c2 4c 9d 93 3a 78 9f 73 12 5f 3a f3 c7 73 73 20 bc 82 59 79 f2 b5 b7 13 43 0e 73 f7 fd 4a df 51 9b 44 78 e7 7f 18 5a a0 fb 88 94 e6 3a 27 23 bf e7 10 bb 50 6e 4d 59 a9 9c 83 ca 67 d7 60 92 99 e5 5e a4 86 42 7e 7b 3a b7 4b c0 4f 85 71 52 0c 42 35 30 46 e8 62 85 96 42 d8 77 5c 9a f8 ab 74 52 a8 17 03 cf 16 34 18 fb e1 85 00 83 e8 b1 83 0e 4f 43 25 40 b5 29 2c e1 c1 8f 61 0d a2 63 2e 41 06 97 66 1a a6 38 db f4 bc 0d 70 c7 af 53 cd e6 be 00 bc 2b df 2a 15 98 dc 05 30 cd 25 bd 0f 59 74 ba cd ba 2d 67 c3 69 c4 72 00 40 76 7e 0f d9 95 bc 25 34 e6 30 89 f6 fa 6e d4 10 98 2d 32 b5 91 2e 4a e6 01 0f e2 34 d5 0f 91 b6 cb 49 e1 d2 86 6c 9b d4 06 16 59 93 86 68 d5 01 0b 47 ac 4b 92 fa a1 5d f4 46 a4 bc 89 3b 06 54 be e4 77 b6 0d 89 47 9d 70 9b 97 9e 0b 04 03 88 96 1b 63 31 81 3d 6d da 86 c8 a6 af 43 31 1f 99 7f da fa b9 44 a2 6c 31 ff 1d 3d 41 67 78 9f bb e3 2b 8b 7c dc 20230726174215434 DLLC INFO llc_prim.c:157 Rx from upper layers: LL-UNITDATA.request
20230726174215434 DLLC ERROR llc.c:359 LLE(c34b1498/c914945e,SNDCP3){ASSIGNED_ADM} Cannot Tx 1480 bytes (N201-U=500)
20230726174215441 DRLCMAC INFO rlcmac.c:789 TS=6 FN=93231 Rx Pkt DL Dummy Ctrl Block
20230726174215444 DTUN DEBUG app_modem.c:121 APN(internet): system wants to transmit IPv4 pkt to 176.16.222.1 (1476 bytes)
20230726174215445 DSNDCP INFO sndcp_prim.c:424 Rx from upper layers: SN-UNITDATA.request
20230726174215445 DSNDCP DEBUG sndcp.c:130 modem_sndcp_prim_down_cb(): Rx LL-UNITDATA.request TLLI=0xc914945e SAPI=SNDCP3 L3=[66 00 05 d6 45 00 05 c4 78 bd 40 00 40 11 a0 46 b0 10 de 02 b0 10 de 01 aa 53 14 51 05 b0 10 db 00 00 2a ed 00 0b 20 b1 00 00 01 8d 21 52 df 52 61 ce 27 d9 5b ea e8 ec 6d fe 02 45 1b 9c cc dc ec 38 8f e5 29 e9 b0 a0 1c 01 2b 3b 39 e1 9c 51 2f c5 79 14 de c8 b6 13 23 c5 b1 ff 79 d0 5e 1b 04 b2 4e 3f 90 a3 3a 00 df 13 ab 43 8c b7 d3 a8 45 39 a2 70 06 76 c1 fe 19 95 76 3a 74 51 18 6c 5c 4d c1 a0 4b 80 51 3d 73 c6 95 14 e3 76 f9 af 1c f4 28 70 0d 4e 78 21 83 32 a8 12 82 a6 76 01 f3 75 36 77 08 8d 0f 16 c7 be 7a 1b 51 bf 64 9b 0f fc c3 86 bd 1f 0a b0 8c 6f f7 d2 01 da 5b 07 72 72 66 4e 80 55 a6 77 86 bb 76 5c 9c 48 85 a3 5f 97 70 ce b0 ff 79 f9 e0 10 92 f3 e0 bc a0 ee d2 08 90 55 04 6c 8a 28 31 fb 00 66 24 54 67 36 c9 1d 0c 71 ff 09 52 7a 1b 4d 77 02 87 47 89 9f 62 ae da 4c 14 88 8b f5 cc 28 0a df 59 89 e2 72 64 28 dc 0e b2 59 10 57 ae 60 70 9c 31 ee 5d 55 c1 66 82 70 aa 4c 3b aa 79 45 8f e1 06 3c 68 66 8f 0b 86 90 4e 73 fd a9 f3 2e 9b 4a 3f 58 69 82 b1 c1 c2 4e af 5a dc d0 5b 6b 22 17 4f 74 8b 17 6e 0d 23 13 23 c2 1b f3 b0 56 ec fa 3b 48 98 bd 9b 7e e4 c9 a5 37 3f ed 05 d2 0e 0f f4 21 af 9e d0 83 31 70 12 8b 14 96 46 bf b9 3a 64 0a 75 da 0f 8d 83 d9 8a 9b 26 0b 4c 65 1d 26 f1 9e 75 08 8a 48 03 64 c0 a1 de d6 59 ad 9f 6b f6 cf 4a 65 08 cf 18 68 54 16 8f af 61 8c 06 fb 6a 09 93 c9 4a fb 00 94 16 9c 2f f3 a6 5e 90 55 29 7e 3a b9 04 2d 69 06 f7 89 2e 53 52 67 c4 73 43 05 9a ce af f9 7d 77 26 c1 a5 aa c8 8e 0f 80 c4 00 be 71 3f 1a f8 38 f1 4c 06 59 07 ac 06 32 eb 5a d2 35 db 3d 11 0c fa af 04 8c 56 d0 a8 3a 2f 50 9f cb 0d 44 10 38 f9 ab 79 97 0a 11 8a 21 4a d1 0d 4b 8c ea f4 79 2b ac f0 48 52 67 b8 36 05 1f 2e bb e4 c5 d1 8c 35 d4 8e fb 8d 8d 8d 15 26 fe 37 fd bb 6b af 2a b4 11 97 24 b0 28 15 ce 95 97 d5 7f 62 8b 73 77 d7 7f a6 72 23 35 fb 60 65 de 84 54 b9 a0 30 21 3e 87 f2 a7 9c 82 0c 92 6a 28 e4 06 6e 84 e9 6a 1c 20 5c 30 dd 1b 80 71 88 9f 5b 3b 74 2d 18 ed 6e f7 8c 67 ba ed 05 06 13 76 58 c0 7b 1b 1d d9 23 14 30 ef 97 4c 1d 48 a2 8e 83 49 1b 6b 75 90 b6 a0 98 e9 7d b1 c7 fa 39 6e a5 18 9a 94 ab 6d 18 d2 1f 61 39 a1 2e ca 7f b9 23 73 7d 29 a1 6a bd f6 9b e2 d9 cf fa 0f ca 46 c3 be 4a cc 7d 19 9e 23 be 74 65 7c cc e8 d7 f7 6c 8a 64 7b 0b 14 d3 b5 3f 19 47 94 08 70 23 02 01 2f 4d 09 07 4d 1f a6 6f b0 3b b3 7d 14 75 74 e5 1b 93 0a 52 0e 2a 02 e2 60 a9 dd 52 42 c9 c7 ee ab fb 7f fb 81 09 07 7a e7 64 1d bf 56 ad 68 c6 bc 73 81 a9 5a 03 4d 3f 02 66 73 87 01 11 dc f2 ab f9 a6 77 f2 db f3 4b 1f 32 05 4f ea 96 bc 7b e3 a5 e0 b4 de 3b ed 34 1f 95 9e ed f9 aa a6 ef 56 ea 17 a4 1a ad ea 64 8c f3 4b 05 a1 cd 31 92 82 c4 fa 43 07 f2 01 a4 9c e4 ae 4c cd ad f0 34 ec cb 4b 4d 3a b3 c1 3f b5 1f 0c 6a 8b d1 fb 2f 4e d6 59 c1 a3 61 1c cf 01 26 32 5b 97 a9 9a 31 16 b3 11 10 e6 ec 0f 74 d4 9e eb 57 ae 95 30 bc 8b 2f 41 fc fc 73 46 f8 1b 06 c6 b6 9c e7 a9 c3 13 2c 9d 93 f8 cc 61 d5 ff 09 4e 67 dc 79 60 80 67 00 86 83 d5 45 ad 5c f0 21 2b 81 29 98 19 85 cc 70 2c 43 0f bb 13 4d 31 41 5c 49 af d1 3d 82 fc 72 74 6b 81 a9 d4 d8 4a 75 8e 2c 54 f8 b1 1c 21 5e d6 f5 f8 0d 51 13 bc 6b 09 e9 d6 a0 bf 62 f8 b0 a7 64 39 fb 71 a1 b3 53 b9 c2 4c 9d 93 3a 78 9f 73 12 5f 3a f3 c7 73 73 20 bc 82 59 79 f2 b5 b7 13 43 0e 73 f7 fd 4a df 51 9b 44 78 e7 7f 18 5a a0 fb 88 94 e6 3a 27 23 bf e7 10 bb 50 6e 4d 59 a9 9c 83 ca 67 d7 60 92 99 e5 5e a4 86 42 7e 7b 3a b7 4b c0 4f 85 71 52 0c 42 35 30 46 e8 62 85 96 42 d8 77 5c 9a f8 ab 74 52 a8 17 03 cf 16 34 18 fb e1 85 00 83 e8 b1 83 0e 4f 43 25 40 b5 29 2c e1 c1 8f 61 0d a2 63 2e 41 06 97 66 1a a6 38 db f4 bc 0d 70 c7 af 53 cd e6 be 00 bc 2b df 2a 15 98 dc 05 30 cd 25 bd 0f 59 74 ba cd ba 2d 67 c3 69 c4 72 00 40 76 7e 0f d9 95 bc 25 34 e6 30 89 f6 fa 6e d4 10 98 2d 32 b5 91 2e 4a e6 01 0f e2 34 d5 0f 91 b6 cb 49 e1 d2 86 6c 9b d4 06 16 59 93 86 68 d5 01 0b 47 ac 4b 92 fa a1 5d f4 46 a4 bc 89 3b 06 54 be e4 77 b6 0d 89 47 9d 70 9b 97 9e 0b 04 03 88 96 1b 63 31 81 3d 6d da 86 c8 a6 af 43 31 1f 99 7f da fa b9 44 a2 6c 31 ff 1d 3d 41 67 78 9f bb e3 2b 8b 7c dc 20230726174215445 DLLC INFO llc_prim.c:157 Rx from upper layers: LL-UNITDATA.request
20230726174215445 DLLC ERROR llc.c:359 LLE(c34b1498/c914945e,SNDCP3){ASSIGNED_ADM} Cannot Tx 1480 bytes (N201-U=500)
20230726174215453 DTUN DEBUG app_modem.c:121 APN(internet): system wants to transmit IPv4 pkt to 176.16.222.1 (53 bytes)
</pre></p>
<p>These are all inside the netns used by "modem":<br /><pre>
# ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: modem4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 176.16.222.3/30 scope global modem4
valid_lft forever preferred_lft forever
inet6 fe80::75d:7419:9433:6fee/64 scope link stable-privacy proto kernel_ll
valid_lft forever preferred_lft forever
# ip l
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: modem4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
link/none
</pre></p>
<p>"Activate PDP Context Accept" sent to the MS contains:<br /><pre>
Maximum SDU size: 1520 octets (153)
</pre></p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6045 (Feedback): report erlang diameter pro...https://osmocom.org/issues/60452023-05-26T11:49:29Zlynxis
<p>Somehow is the erlang diameter code not generating all AVPs. I've the feeling it doesn't have enough inherits layer. e.g. when a dia spec inherits from another spec, from another spec, .. it comes to a limit without a failure. In the end the decoding of messages fails.</p>
<p>Create a test case with github repo to report the issue.</p> OsmoGSMTester - Feature #5839 (New): Ability to switch off the osmo-trx machinehttps://osmocom.org/issues/58392022-12-20T17:27:00Zlaforge
<p>So far we have (partial) support to switch off the power to a physical BTS / rf transceiver hardwrae.</p>
<p>Wht we don't yet have is support to power down the osmo-trx machine when it's not needed.</p>
<p>In the osmo-gsm-tester prod setup, it is possible to switch power to that machine via intellinet at 10.42.42.250 port 6.</p>
<p>I'm not sufficiently familiar with the code to judge if we can just treat it like power-switching the actual RF hardware (B200, limesdr, ...) or not.</p> OsmoPCU - Feature #5827 (New): osmo-pcu: Hardcoded limit of maximum number of 8 TRX per BTShttps://osmocom.org/issues/58272022-12-13T16:45:21Zpespin
<p>osmo-pcu has hardcoded the maximum number of expected TRX per BTS in several places. This means bigger BTS cannot be used by osmo-pcu or could even make it crash.</p>
<p>pcuif_proto.h limits it to 8 TRX:<br /><pre>
struct gsm_pcu_if_info_ind {
uint32_t version;
uint32_t flags;
struct gsm_pcu_if_info_trx trx[8]; /* TRX infos per BTS */
</pre></p>
<p>bts.h struct gprs_rlcmac_bts limits it to 8:<br /><pre>
struct gprs_rlcmac_trx trx[8];
</pre></p>
<p>bts.cpp bts_add_paging() limits the TRX amount to 8 in slot_mask:<br /><pre>
/* ms is NULL if no specific taget was found */
int bts_add_paging(struct gprs_rlcmac_bts *bts, const struct paging_req_cs *req, struct GprsMs *ms)
{
...
uint8_t slot_mask[8];
...
/* break, if we already marked a slot */
if ((slot_mask[tbf->trx->trx_no] & (1 << ts)))
break;
...
}
</pre></p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> OsmocomBB - Feature #5503 (Feedback): expose GPRS user plane via tun devicehttps://osmocom.org/issues/55032022-03-29T12:37:23Zlaforge
<p>In order to expose the GPRS user plane data from within LLC/SNDCP to the host system running OsmocomBB, we should create a <code>tun</code> device. The local IP and point-to-point peer IP should be configured based on the information received from the network during PDP context establishment.</p> OsmocomBB - Feature #5502 (Stalled): MS-side LLC implementationhttps://osmocom.org/issues/55022022-03-29T12:35:40Zlaforge
<p>The LLC + SNDCP protocols are rather symmetrical, so the existing code from the network side (in <a class="wiki-page" href="https://osmocom.org/projects/osmosgsn/wiki">osmo-sgsn</a> should be possible to generalize rather easily</p> OsmocomBB - Feature #5501 (Stalled): MS-side GPRS Mobility Management (GMM) + Session Management ...https://osmocom.org/issues/55012022-03-29T12:32:56Zlaforge
<p>In order to support GPRS from the MS side, we will need a GMM + SM implementation on the mobile side.</p>
<p>The network side is already implemented as part of <a class="wiki-page" href="https://osmocom.org/projects/osmosgsn/wiki">osmo-sgsn</a></p> OsmoSGSN - Bug #5398 (New): Null pointer access at "uectx" in ranap_iu_txhttps://osmocom.org/issues/53982022-01-10T12:45:11Zpespin
<p>It seems the timer sending RAU accept is kept ongoing even after the Iu conn has been released. Then apparently due to that msg->dst is NULL.</p>
<pre>
20220110121956305 DMM <0000> /git/osmo-iuh/src/ranap_common_cn.c:240 Received unsupported RANAP unsuccessful outcome procedure Security Mode Control (CO) from RNC, ignoring
20220110121956305 DMM <0000> /git/osmo-iuh/src/ranap_common_cn.c:309 Not calling cn_ranap_handle_co() due to rc=-1
20220110121956305 DMM <0000> /git/osmo-iuh/src/ranap_common_cn.c:270 Not freeing unsupported RANAP unsuccessful outcome procedure (CO) from RNC
20220110121958657 DMM <0000> /git/osmo-sgsn/src/sgsn/gprs_gmm.c:1491 MM(901700000043320/ccec2b9d) <- GMM ROUTING AREA UPDATE ACCEPT
20220110121958657 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:464 Transmitting L3 Message as RANAP DT (SCCP conn_id 5)
20220110121958657 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1731 Received SCCP User Primitive (N-DATA.request)
20220110121958657 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1772 SCCP-SCOC(5)[0x612000006220]{ACTIVE}: Received Event N-DATA.req
20220110121958657 DLSS7 <001f> /git/libosmo-sccp/src/sccp_scrc.c:401 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CODT,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Destination Reference,L=4,D=000003f0), PART(T=Data,L=36,D=0014402000000200104014130809002a32f40728b6631805f4ccec2b9d1716003b400100)
20220110121958657 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:280 m3ua_hmdc_rx_from_l2(): dpc=189=0.23.5 not local, message is for routing
20220110121958658 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:227 Found route for dpc=189=0.23.5: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoSGSN proto=m3ua
20220110121958658 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:235 rt->dest.as proto is M3UA for dpc=189=0.23.5
20220110121958658 DLSS7 <001f> /git/libosmo-sccp/src/m3ua.c:508 XUA_AS(as-clnt-OsmoSGSN)[0x612000003e20]{AS_ACTIVE}: Received Event AS-TRANSFER.req
20220110121958658 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110121958658 DLINP <0015> /git/libosmo-netif/src/stream.c:352 [CONNECTED] osmo_stream_cli_write(): sending 76 bytes of data
20220110121958658 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110122000787 DLGSUP <001d> /git/osmo-hlr/src/gsupclient/gsup_client.c:266 GSUP ping callback (connected, got PONG)
20220110122000788 DLGSUP <001d> /git/osmo-hlr/src/gsupclient/gsup_client.c:288 GSUP sending PING
20220110122000788 DLINP <0015> /git/libosmo-abis/src/input/ipa.c:139 127.0.0.1:4222 connected write
20220110122000788 DLINP <0015> /git/libosmo-abis/src/input/ipa.c:89 127.0.0.1:4222 sending data
20220110122000788 DLINP <0015> /git/libosmo-abis/src/input/ipa.c:139 127.0.0.1:4222 connected write
20220110122000788 DLINP <0015> /git/libosmo-abis/src/input/ipa.c:89 127.0.0.1:4222 sending data
20220110122000788 DLINP <0015> /git/libosmo-abis/src/input/ipa.c:135 127.0.0.1:4222 connected read
20220110122000788 DLINP <0015> /git/libosmo-abis/src/input/ipa.c:56 127.0.0.1:4222 message received
20220110122000788 DLMI <0017> /git/libosmocore/src/gsm/ipa.c:524 PONG!
20220110122000788 DLGSUP <001d> /git/osmo-hlr/src/gsupclient/gsup_client.c:225 GSUP receiving PONG
20220110122001489 DLINP <0015> /git/libosmo-netif/src/stream.c:445 [CONNECTED] osmo_stream_cli_fd_cb(): connected read
20220110122001489 DLINP <0015> /git/libosmo-netif/src/stream.c:324 [CONNECTED] osmo_stream_cli_read(): message received
20220110122001489 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7.c:1906 0: asp-asp-clnt-OsmoSGSN: xua_cli_read_cb(): sctp_recvmsg() returned 52 (flags=0x80)
20220110122001489 DLM3UA <0022> /git/libosmo-sccp/src/m3ua.c:714 0: asp-asp-clnt-OsmoSGSN: Received M3UA Message (XFER:DATA)
20220110122001489 DLM3UA <0022> /git/libosmo-sccp/src/m3ua.c:543 0: asp-asp-clnt-OsmoSGSN: m3ua_rx_xfer
20220110122001489 DLM3UA <0022> /git/libosmo-sccp/src/m3ua.c:566 0: asp-asp-clnt-OsmoSGSN: m3ua_rx_xfer(): M3UA data header: opc=189=0.23.5 dpc=188=0.23.4
20220110122001489 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:276 m3ua_hmdc_rx_from_l2(): found dpc=188=0.23.4 as local
20220110122001489 DLSS7 <001f> /git/libosmo-sccp/src/sccp_scrc.c:472 scrc_rx_mtp_xfer_ind_xua: HDR=(CO:CODT,V=0,LEN=0), PART(T=Destination Reference,L=4,D=00000005), PART(T=Segmentation,L=4,D=00000000), PART(T=Data,L=13,D=000b40090000010004400209c0)
20220110122001489 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1664 Received CO:CODT for local reference 5
20220110122001489 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1698 SCCP-SCOC(5)[0x612000006220]{ACTIVE}: Received Event RCOC-DT1.ind
20220110122001489 DLSCCP <0020> /git/libosmo-sccp/src/sccp_user.c:175 Delivering N-DATA.indication to SCCP User 'OsmoSGSN-IuPS'
20220110122001490 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:818 sccp_sap_up(N-DATA.indication)
20220110122001490 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:869 N-DATA.ind(5, 00 0b 40 09 00 00 01 00 04 40 02 09 c0 )
20220110122001490 DMM <0000> /git/osmo-iuh/src/ranap_common_cn.c:42 Rx CO IM (Iu Release Request)
20220110122001490 DMM <0000> ranap_decoder.c:2422 Decoding message RANAP_Iu_ReleaseRequestIEs (ranap_decoder.c:2422)
20220110122001490 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:577 handle_co(dir=1, proc=11)
20220110122001490 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:519 Received Iu Release Request, Sending Release Command
20220110122001490 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1731 Received SCCP User Primitive (N-DATA.request)
20220110122001490 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1772 SCCP-SCOC(5)[0x612000006220]{ACTIVE}: Received Event N-DATA.req
20220110122001490 DLSS7 <001f> /git/libosmo-sccp/src/sccp_scrc.c:401 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CODT,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Destination Reference,L=4,D=000003f0), PART(T=Data,L=13,D=000100090000010004400209c0)
20220110122001490 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:280 m3ua_hmdc_rx_from_l2(): dpc=189=0.23.5 not local, message is for routing
20220110122001490 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:227 Found route for dpc=189=0.23.5: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoSGSN proto=m3ua
20220110122001490 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:235 rt->dest.as proto is M3UA for dpc=189=0.23.5
20220110122001490 DLSS7 <001f> /git/libosmo-sccp/src/m3ua.c:508 XUA_AS(as-clnt-OsmoSGSN)[0x612000003e20]{AS_ACTIVE}: Received Event AS-TRANSFER.req
20220110122001491 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110122001491 DLINP <0015> /git/libosmo-netif/src/stream.c:352 [CONNECTED] osmo_stream_cli_write(): sending 52 bytes of data
20220110122001491 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110122001497 DLINP <0015> /git/libosmo-netif/src/stream.c:445 [CONNECTED] osmo_stream_cli_fd_cb(): connected read
20220110122001497 DLINP <0015> /git/libosmo-netif/src/stream.c:324 [CONNECTED] osmo_stream_cli_read(): message received
20220110122001497 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7.c:1906 0: asp-asp-clnt-OsmoSGSN: xua_cli_read_cb(): sctp_recvmsg() returned 52 (flags=0x80)
20220110122001497 DLM3UA <0022> /git/libosmo-sccp/src/m3ua.c:714 0: asp-asp-clnt-OsmoSGSN: Received M3UA Message (XFER:DATA)
20220110122001498 DLM3UA <0022> /git/libosmo-sccp/src/m3ua.c:543 0: asp-asp-clnt-OsmoSGSN: m3ua_rx_xfer
20220110122001498 DLM3UA <0022> /git/libosmo-sccp/src/m3ua.c:566 0: asp-asp-clnt-OsmoSGSN: m3ua_rx_xfer(): M3UA data header: opc=189=0.23.5 dpc=188=0.23.4
20220110122001498 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:276 m3ua_hmdc_rx_from_l2(): found dpc=188=0.23.4 as local
20220110122001498 DLSS7 <001f> /git/libosmo-sccp/src/sccp_scrc.c:472 scrc_rx_mtp_xfer_ind_xua: HDR=(CO:RELRE,V=0,LEN=0), PART(T=Destination Reference,L=4,D=00000005), PART(T=Source Reference,L=4,D=000003f0), PART(T=Cause,L=4,D=00000300), PART(T=Data,L=7,D=20010003000000)
20220110122001498 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1664 Received CO:RELRE for local reference 5
20220110122001498 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1698 SCCP-SCOC(5)[0x612000006220]{ACTIVE}: Received Event RCOC-RELEASED.ind
20220110122001498 DLSCCP <0020> /git/libosmo-sccp/src/sccp_user.c:175 Delivering N-DISCONNECT.indication to SCCP User 'OsmoSGSN-IuPS'
20220110122001498 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:818 sccp_sap_up(N-DISCONNECT.indication)
20220110122001498 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:843 N-DISCONNECT.ind(5)
20220110122001498 DMM <0000> /git/osmo-iuh/src/ranap_common_cn.c:136 Rx CO SO (Iu Release)
20220110122001498 DMM <0000> ranap_decoder.c:68 Decoding message RANAP_Iu_ReleaseCompleteIEs (ranap_decoder.c:68)
20220110122001498 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:577 handle_co(dir=2, proc=1)
20220110122001498 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:122 Submit Iu event to upper layer: RANAP_IU_EVENT_IU_RELEASE
20220110122001498 DMM <0000> /git/osmo-sgsn/src/sgsn/gprs_ranap.c:137 MM(901700000043320/ccec2b9d) IU release (cause=RANAP_IU_EVENT_IU_RELEASE)
20220110122001498 DMM <0000> /git/osmo-sgsn/src/sgsn/gprs_ranap.c:138 MM_STATE_Iu(3)[0x612000005920]{Idle}: Received Event E_PMM_PS_CONN_RELEASE
20220110122001498 DMM <0000> /git/osmo-sgsn/src/sgsn/gprs_ranap.c:138 MM_STATE_Iu(3)[0x612000005920]{Idle}: Event E_PMM_PS_CONN_RELEASE not permitted
20220110122001498 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1731 Received SCCP User Primitive (N-DISCONNECT.request)
20220110122001498 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1772 SCCP-SCOC(5)[0x612000006220]{ACTIVE}: Received Event N-DISCONNECT.req
20220110122001498 DLSS7 <001f> /git/libosmo-sccp/src/sccp_scrc.c:401 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:RELRE,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Destination Reference,L=4,D=000003f0), PART(T=Source Reference,L=4,D=00000005), PART(T=Cause,L=4,D=00000300)
20220110122001498 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:280 m3ua_hmdc_rx_from_l2(): dpc=189=0.23.5 not local, message is for routing
20220110122001499 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:227 Found route for dpc=189=0.23.5: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoSGSN proto=m3ua
20220110122001499 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:235 rt->dest.as proto is M3UA for dpc=189=0.23.5
20220110122001499 DLSS7 <001f> /git/libosmo-sccp/src/m3ua.c:508 XUA_AS(as-clnt-OsmoSGSN)[0x612000003e20]{AS_ACTIVE}: Received Event AS-TRANSFER.req
20220110122001499 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1057 SCCP-SCOC(5)[0x612000006220]{ACTIVE}: state_chg to DISCONN_PEND
20220110122001499 DLSS7 <001f> /git/libosmo-sccp/src/sccp_scrc.c:401 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:RELCO,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Destination Reference,L=4,D=000003f0), PART(T=Source Reference,L=4,D=00000005)
20220110122001499 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:280 m3ua_hmdc_rx_from_l2(): dpc=189=0.23.5 not local, message is for routing
20220110122001499 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:227 Found route for dpc=189=0.23.5: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoSGSN proto=m3ua
20220110122001499 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:235 rt->dest.as proto is M3UA for dpc=189=0.23.5
20220110122001499 DLSS7 <001f> /git/libosmo-sccp/src/m3ua.c:508 XUA_AS(as-clnt-OsmoSGSN)[0x612000003e20]{AS_ACTIVE}: Received Event AS-TRANSFER.req
20220110122001499 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1073 SCCP-SCOC(5)[0x612000006220]{DISCONN_PEND}: state_chg to IDLE
20220110122001499 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:520 SCCP-SCOC(5)[0x612000006220]{IDLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST)
20220110122001499 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:520 SCCP-SCOC(5)[0x612000006220]{IDLE}: Freeing instance
20220110122001499 DLSCCP <0020> /git/libosmocore/src/fsm.c:568 SCCP-SCOC(5)[0x612000006220]{IDLE}: Deallocated
20220110122001499 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110122001500 DLINP <0015> /git/libosmo-netif/src/stream.c:352 [CONNECTED] osmo_stream_cli_write(): sending 44 bytes of data
20220110122001500 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110122001500 DLINP <0015> /git/libosmo-netif/src/stream.c:352 [CONNECTED] osmo_stream_cli_write(): sending 40 bytes of data
20220110122001500 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110122002291 DMM <0000> /git/osmo-sgsn/src/sgsn/gprs_gmm.c:1491 MM(901700000015259/f634a4dd) <- GMM ROUTING AREA UPDATE ACCEPT
20220110122002291 DRANAP <000b> /git/osmo-iuh/src/iu_client.c:464 Transmitting L3 Message as RANAP DT (SCCP conn_id 6)
20220110122002292 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1731 Received SCCP User Primitive (N-DATA.request)
20220110122002292 DLSCCP <0020> /git/libosmo-sccp/src/sccp_scoc.c:1772 SCCP-SCOC(6)[0x6120000063a0]{ACTIVE}: Received Event N-DATA.req
20220110122002292 DLSS7 <001f> /git/libosmo-sccp/src/sccp_scrc.c:401 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CODT,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Destination Reference,L=4,D=000003f1), PART(T=Data,L=36,D=0014402000000200104014130809002a32f40728b6631805f4f634a4dd1716003b400100)
20220110122002292 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:280 m3ua_hmdc_rx_from_l2(): dpc=189=0.23.5 not local, message is for routing
20220110122002292 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:227 Found route for dpc=189=0.23.5: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoSGSN proto=m3ua
20220110122002292 DLSS7 <001f> /git/libosmo-sccp/src/osmo_ss7_hmrt.c:235 rt->dest.as proto is M3UA for dpc=189=0.23.5
20220110122002292 DLSS7 <001f> /git/libosmo-sccp/src/m3ua.c:508 XUA_AS(as-clnt-OsmoSGSN)[0x612000003e20]{AS_ACTIVE}: Received Event AS-TRANSFER.req
20220110122002292 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110122002292 DLINP <0015> /git/libosmo-netif/src/stream.c:352 [CONNECTED] osmo_stream_cli_write(): sending 76 bytes of data
20220110122002292 DLINP <0015> /git/libosmo-netif/src/stream.c:449 [CONNECTED] osmo_stream_cli_fd_cb(): connected write
20220110122004659 DMM <0000> /git/osmo-sgsn/src/sgsn/gprs_gmm.c:1491 MM(901700000043320/ccec2b9d) <- GMM ROUTING AREA UPDATE ACCEPT
/git/osmo-iuh/src/iu_client.c:464:2: runtime error: member access within null pointer of type 'struct ranap_ue_conn_ctx'
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff679e94a in ranap_iu_tx (msg_nas=msg_nas@entry=0x61d00004b0e0, sapi=sapi@entry=1 '\001') at /git/osmo-iuh/src/iu_client.c:464
464 LOGPIU(LOGL_INFO, "Transmitting L3 Message as RANAP DT (SCCP conn_id %u)\n",
(gdb) bt
#0 0x00007ffff679e94a in ranap_iu_tx (msg_nas=msg_nas@entry=0x61d00004b0e0,
sapi=sapi@entry=1 '\001')
at /git/osmo-iuh/src/iu_client.c:464
#1 0x00005555556a1587 in gsm48_gmm_sendmsg (msg=msg@entry=0x61d00004b0e0,
command=command@entry=0, mm=mm@entry=0x617000003560,
encryptable=encryptable@entry=true)
at /git/osmo-sgsn/src/sgsn/gprs_gmm.c:137
#2 0x00005555556a8190 in gsm48_tx_gmm_ra_upd_ack (mm=mm@entry=0x617000003560)
at /git/osmo-sgsn/src/sgsn/gprs_gmm.c:1536
#3 0x00005555556b0ee6 in mmctx_timer_cb (_mm=0x617000003560)
at /git/osmo-sgsn/src/sgsn/gprs_gmm.c:2181
#4 0x00007ffff51aad35 in osmo_timers_update ()
at /git/libosmocore/src/timer.c:269
#5 0x00007ffff51ae70a in _osmo_select_main (polling=polling@entry=0)
at /git/libosmocore/src/select.c:394
#6 0x00007ffff51ae778 in osmo_select_main (polling=polling@entry=0)
at /git/libosmocore/src/select.c:438
#7 0x00005555556f7826 in main (argc=<optimized out>, argv=0x7fffffffe128)
at /git/osmo-sgsn/src/sgsn/sgsn_main.c:542
(gdb) l
459 {
460 struct ranap_ue_conn_ctx *uectx = msg_nas->dst;
461 struct msgb *msg;
462 struct osmo_scu_prim *prim;
463
464 LOGPIU(LOGL_INFO, "Transmitting L3 Message as RANAP DT (SCCP conn_id %u)\n",
465 uectx->conn_id);
466
467 msg = ranap_new_msg_dt(sapi, msg_nas->data, msgb_length(msg_nas));
468 msgb_free(msg_nas);
(gdb) print uectx
$1 = (struct ranap_ue_conn_ctx *) 0x0
</pre> OsmoPCU - Bug #5309 (New): osmo-pcu: Support rejecting multiple TBFs upon tx of Packet Access Rejecthttps://osmocom.org/issues/53092021-11-15T13:40:44Zpespin
<p>According to TS 44.060 Table 11.2.1, Packet Access Reject can contain multiple "Reject struct".<br />Hence, we can reject several TBFs in a single Dl RLCMAC block, which may come really handy in the case where all resources are allocated and hence we are congested.</p>
<p>In order to do that, I'd probably do it in 2 steps:<br />1- Get rid of "dummy UL TBF" used to handle Packet Access Reject through tbf_ul_ass_fsm. It's a nightmare maintaining those specially allocated TBFs which end up behaving differently that usual TBFs. Let's rather introduce some some "struct reject_req", hence a differenatiated structure and add specific handling for it in gprs_rlcmacn_sched.cpp, similar to what we do with SBA.<br />2- Add some sort of reject_pool, where the new reject_req are stored when we nowadays create a dummy tbf, and make the scheduler use that to request whether it should schedule any. Then, inside reject_pool implementation, we can keep a list of pending requests and generate a message adding as many requests as possible each time. Probably the best is to have a reject_pool per pdch object, since the reject are expected at some specific "control" Ts.</p> OsmoPCU - Bug #5227 (New): osmo-pcu: Attempt recovery of TBF when one of its assigned PDCH TS bec...https://osmocom.org/issues/52272021-09-03T17:55:52Zpespin
<p>Currently, when a PDCH TS becomes disabled (eg: dynamic TS is required for a voice call), we are currently freeing immediately all existing TBFs which were attached to that TBF.</p>
<p>This looks really rude and simple way to overcome the scenario. By doing so, it means all ongoing TBFs cease to transmit or receive data, hence breaking all connections and keeping them broken for a while.<br />Even worse: The MS with active TBF will stay listening on that TS and trying to decode whatever is sent to another MS (be it TCH, SDCCH, etc.).</p>
<p>Hence, we should try to find a way to attempt some sort of recovery for as many MS as possible, by telling the MS that PDCH is no longer available and it shouldn't listen on it. Even better, we should try to relocate the MS to a potential better set of PDCH TS.</p>
That probably involves sending some RLCMAC DL Control Block to the MS. Hence, we should check during pdch disable:
<ul>
<li>If MS has only 1 PDCH TS assigned and it's the one we are disabling, we can do nothing, keep the tbf_free().</li>
<li>If MS has more than 1 PDCH TS assigned and the PDCH being disabled is its control_ts, change the control_ts to another PDCH TS.</li>
<li>Internally mark to avoid RX/TX on the PDCH being disabled, and do all the process to change the active PDCH set.</li>
</ul>
<p>Related code in osmo-pcu which may be of interest:<br /><pre>
gprs_rlcmac_pdch::disable()
gprs_rlcmac_pdch::free_resources()
pdch_free_all_tbf()
tbf_free()
handle_timeout_X2002()
tbf_assign_control_ts()
tbf_update()
gprs_rlcmac_tbf::update()
tbf_dl_trigger_ass()
tbf_assign_control_ts()
</pre></p> OsmoPCU - Feature #5122 (New): Choose SBA allocation offset based on AGCH queue load in the BTShttps://osmocom.org/issues/51222021-04-20T12:51:14Zpespin
<p>During all the improvements done recently in the SBA and TBF poll infrastructure (<a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: osmo-pcu: Poll and SBA allocation improvements and fixes (Resolved)" href="https://osmocom.org/issues/5020">#5020</a>), it was noticed that there are still some shortcomings in the SBA allocation process that may forbid MS to allocate an SBA (Single Block Allocation), specially under high subscriber load on the BSS where lots of channels are assigned.</p>
<p>Background:<br />The MS sends a RACH req on CCC requesting an SBA. The RACH req is passed over PCUIF to the PCU, which allocates the SBA and sends the Imm Ass message containing the time at which the block is allocated (and hence when the MS can transmit data to the PCU). This Imm Ass is queued in the BTS and eventually sent.<br />As it can be noted, the PCU has no way to know the exact timing that will take for the Imm Ass to reach the MS, since it has to move over PCUIF, then queued in the BTS (with variable number of other Imm Ass queued before it), then needs to be scheduled over CCCH.<br />Hence, it is important for the PCU to allocate a time for the SBA which is long enough in the future to arrive to the MS (via Imm Assign ewxplained above) before it expires. Otherwise, the MS has no time to transmit the UL block since the timing is too tight or in the past.<br />On the other hand, it is important for better service to make this time lapse as small as possible, in order to avoid huge delays when setting up a TBF, hence improving connection latency at startup. This can be directly seen with an MS starting a "ping" command: First ping will usually nowadays take in the order of 1000-1200ms, while follow up pings take around 450ms (because the TBF is already established).<br />So, in summary, the timing needs to be the shortest possible, but long enough to make sure the MS has time to answer to it.</p>
Right now, osmo-pcu uses a hardocded "empirically found to be good enough in usually tested scenarios" timing of AGCH_START_OFFSET=52 (FNs). Recent improvements made this value to be "52 or higher if for whatever reason 52 was already allocated". However, this current situation doesn't garantee:
<ul>
<li>That 52 FNs is big enough in all cases (high Imm Ass load, hence queue size)</li>
<li>That 52 FNs is a good starting poing if there's no load at all. Can it be lower? (counting delays of PCUIF, Um/AGCH scheduling, etc.)</li>
</ul>
<p>The idea to improve this situation would be to make this AGCH_START_OFFSET be low enough for 0 load on the BTS (empty AGCH queue), and then monitor the AGCH of the BTS from the PCU somehow in order to be able to predict (with certain margin) the extra amounf of delay to add to AGCH_START_OFFSET.</p>
<p>Related previous commits improving the situation:<br /><pre>
commit 2f59e673ebe06e159d2a6bf685edf88d62446eaa
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Mon Mar 29 12:13:13 2021 +0200
Pick unreserved UL FN when allocating an SBA
Make sure an unreserved FN is picked and reserved when allocating and
scheduling an SBA.
In practice this has no change in behavior right now, since anyway using
an offset of 52 FNs ensure no USF or POLL has alredy been scheduled that
far in the future. Since it's also impossible to allocate more than 1
SBA per PDCH and RTS FN, we are also safe about multiple SBAs being
allocated, because we use a hardcoded offset of 52.
However, that could change in the future, when we dynamically tweak the
current offset of 52 FN based on information from BTS about its AGCH
queue load:
* If load is high, we may need to increase the offset since it
will take more time for the BTS to transmit the TBF and hence we must
reserve a TBF starting time further in the future (higher FN).
* If load turns low, we may schedule next SBA a bit more nearby in time
than the previously allocated SBA, hence here there could be a
collision.
Related: OS#5020
Change-Id: I2d4e21e2307de6c17748e8da5c7e149c947a7eb9
</pre></p>
<pre>
commit 8238739a745c6064e3b84619f21a98c21010e4b8
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Mar 26 20:44:48 2021 +0100
sba: Document AGCH_START_OFFSET after some experimental tests
Related: OS#5020
Change-Id: Id1460207be25750aeb5c1d7af2fac6591cf5e424
diff --git a/src/sba.c b/src/sba.c
index 2c3519d..4b878b7 100644
--- a/src/sba.c
+++ b/src/sba.c
@@ -33,8 +33,24 @@
#include "pdch.h"
#include "pdch_ul_controller.h"
-/* starting time for assigning single slot
- * This offset must be a multiple of 13. */
+/* TBF Starting Time for assigning SBA.
+ * See TS 44.060 12.21 "Starting Frame Number Description".
+ * According to spec, k=0 (offset=4) "should not be used, so as to leave time
+ * for the MS to analyse the message and get ready to receive or transmit".
+ * Hence, k=1 (offset=8-9) is hteoretically the minimum offset which could be
+ * used.
+ *
+ * However, it was found, empirically, that it takes around 30-40 FNs time for
+ * the Immediate Assignment message created with this "TBF Starting Time" to
+ * travel from PCU->BTS and be transmitted over CCCH on the Um interface. Hence,
+ * we must account for this delay here, otherwise the MS would be receiving eg.
+ * a TBF Starting Time of FN=40 while the Imm Assigned containing it is sent in
+ * eg. FN=50, which would be too late for the MS to answer to it.
+ *
+ * The situation described above, can even get worse on high BTS load for AGCH,
+ * since the Immediate Assignment will queue in the BTS waiting to be
+ * transmitted one after the other, hence increasing the required delay.
+ */
#define AGCH_START_OFFSET 52
</pre> Cellular Network Infrastructure - Feature #5045 (New): write libversion "major" on build files au...https://osmocom.org/issues/50452021-02-24T12:41:58Zpespin
<p>As a reminder:<br /><a class="external" href="https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html">https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html</a></p>
<p>LIBVERSION = current:revision:age<br />LIBVERSION_MAJOR = current - age</p>
Right now we usually use the form "{*_}LIBVERSION = 1:2:3" in Makefile.am, and we hardcode the resulting LIBVERSION_MAJOR in lots of files, namely:
<ul>
<li>debian/control</li>
<li>debian/rules</li>
<li>contrib/*.spec.in</li>
</ul>
<p>The idea here would be to generate LIBVERSION_MAJOR automatically as a autconf/automake variable which can be fed into those files automatically, so we don't have to update them every time LIBCERSION_MAJOR changes (and hence potentially avoid breakage during release time).</p>
So, I'd follow these steps for each project:
<ul>
<li>Normalize the LIBVERSION variable to follow a standardized naming, so that we can track it later better on osmo-release.sh, for instance ${LIBNAME}_LIBVERSION (replacing "-" with "_"). Example: LIBOSMO_NETIF_LIBVERSION. Or even better, LIBVERSION_LIBOSMO_NETIF.</li>
<li>Have LIBVERSION variable be generated out of 3 new variables (also following normalized name with LIBNAME), example: <br /><pre>
LIBVERSION_CURRENT_LIBOSMO_NETIF = 3
LIBVERSION_REVISION_LIBOSMO_NETIF = 2
LIBVERSION_AGE_LIBOSMO_NETIF = 1
LIBVERSION_MAJOR_LIBOSMO_NETIF = LIBVERSION_CURRENT_LIBOSMO_NETIF - LIBVERSION_AGE_LIBOSMO_NETIF
</pre></li>
</ul>
<ul>
<li>Use $LIBVERSION_MAJOR_LIBOSMO_NETIF in the files mentioned above</li>
<li>Update osmo-release.sh to follow new naming</li>
</ul>
Considerations:
<ul>
<li>We may need to move debian/control to debian/control.in so we can template it? That means also configure must be run before generating the package, I guess that's expected?</li>
</ul> OsmoPCU - Bug #4947 (Stalled): osmo-pcu: Handling for Pkt Resource Req using Global TFI not imple...https://osmocom.org/issues/49472021-01-14T10:42:00Zpespin
<p>Related function (pdch.cpp):<br /><pre>
void gprs_rlcmac_pdch::rcv_resource_request(Packet_Resource_Request_t *request, uint32_t fn, struct pcu_l1_meas *meas)
</pre></p>
<p>In there, osmo-pcu correctly handles Pkt resource Request if the MS identifies using TLLI, but it does not if MS used Global TFI (for instance if the MS has already a Downlink TBF established).</p>
<p>There exists already a log ERROR to warn about it not being implemented, I just run through it on my local setup a few seconds after turning on my phone:<br /><pre>
20210114113407714 DL1IF pcu_l1_if.cpp:459 RACH request received: sapi=1 qta=-1, ra=0x75, fn=1169311, cur_fn=1169315, is_11bit=0 <--- first MS message after pcu started
20210114113408011 DTBF tbf_ul.cpp:107 Allocating UL TBF: MS_CLASS=12/12
20210114113408011 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Setting Control TS 6
20210114113408011 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = 00
20210114113408011 DTBFUL tbf_ul.cpp:766 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) setting EGPRS UL window size to 64, base(64) slots(1) ws_pdch(0)
20210114113408028 DTBF tbf.cpp:1028 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
20210114113408029 DTBFDL tbf.cpp:603 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=ASSIGN EGPRS) Scheduled UL Assignment polling on PACCH (FN=1169402, TS=7)
20210114113408153 DTBF tbf.cpp:360 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=FLOW EGPRS) Changing Control TS 7 -> 6
20210114113408275 DTBF tbf_dl.cpp:133 Allocating DL TBF: MS_CLASS=12/12
20210114113408276 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=NULL EGPRS) Setting Control TS 6
20210114113408276 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = e0
20210114113408276 DTBFDL tbf_dl.cpp:1496 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=NULL EGPRS) setting EGPRS DL window size to 64, base(64) slots(3) ws_pdch(0)
20210114113408276 DTBF tbf_dl.cpp:616 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=ASSIGN EGPRS) set ass. type PACCH [prev CCCH:0, PACCH:0]
20210114113408286 DTBF tbf.cpp:924 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=ASSIGN EGPRS) start Packet Downlink Assignment (PACCH)
20210114113408287 DTBFDL tbf.cpp:609 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=FINISHED EGPRS) Scheduled DL Assignment polling on PACCH (FN=1169458, TS=6)
20210114113408449 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169493, TS=6
20210114113408550 DTBF tbf.cpp:303 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=FINISHED EGPRS) free
20210114113408587 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169523, TS=6
20210114113408711 DTBF tbf_ul.cpp:107 Allocating UL TBF: MS_CLASS=12/12
20210114113408711 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Setting Control TS 6
20210114113408711 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = 00
20210114113408712 DTBFUL tbf_ul.cpp:766 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) setting EGPRS UL window size to 64, base(64) slots(1) ws_pdch(0)
20210114113408725 DTBF tbf.cpp:1028 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
20210114113408726 DTBFDL tbf.cpp:603 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled UL Assignment polling on PACCH (FN=1169553, TS=6)
20210114113408868 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169584, TS=6
20210114113409007 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169614, TS=6
20210114113409053 DTBF tbf.cpp:303 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=FINISHED EGPRS) free
20210114113409131 DTBF tbf_ul.cpp:107 Allocating UL TBF: MS_CLASS=12/12
20210114113409131 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Setting Control TS 6
20210114113409131 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = 00
20210114113409132 DTBFUL tbf_ul.cpp:766 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) setting EGPRS UL window size to 64, base(64) slots(1) ws_pdch(0)
20210114113409145 DTBF tbf.cpp:1028 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
20210114113409146 DTBFDL tbf.cpp:603 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled UL Assignment polling on PACCH (FN=1169644, TS=6)
20210114113409288 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169675, TS=6
20210114113409427 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169705, TS=6
20210114113409473 DTBF tbf.cpp:303 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=FINISHED EGPRS) free
20210114113409551 DTBF tbf_ul.cpp:107 Allocating UL TBF: MS_CLASS=12/12
20210114113409552 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Setting Control TS 6
20210114113409552 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = 00
20210114113409552 DTBFUL tbf_ul.cpp:766 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) setting EGPRS UL window size to 64, base(64) slots(1) ws_pdch(0)
20210114113409565 DTBF tbf.cpp:1028 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
20210114113409566 DTBFDL tbf.cpp:603 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled UL Assignment polling on PACCH (FN=1169735, TS=6)
20210114113409708 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169766, TS=6
20210114113409847 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169796, TS=6
20210114113409893 DTBF tbf.cpp:303 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=FINISHED EGPRS) free
20210114113409971 DTBF tbf_ul.cpp:107 Allocating UL TBF: MS_CLASS=12/12
20210114113409972 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Setting Control TS 6
20210114113409972 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = 00
20210114113409972 DTBFUL tbf_ul.cpp:766 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=NULL EGPRS) setting EGPRS UL window size to 64, base(64) slots(1) ws_pdch(0)
20210114113409985 DTBF tbf.cpp:1028 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
20210114113409986 DTBFDL tbf.cpp:603 TBF(TFI=0 TLLI=0xb01b4cd5 DIR=DL STATE=FLOW EGPRS) Scheduled UL Assignment polling on PACCH (FN=1169826, TS=6)
20210114113410128 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169857, TS=6
20210114113410313 DTBF tbf.cpp:303 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=FINISHED EGPRS) free
20210114113410405 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169917, TS=6
20210114113410548 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169948, TS=6
20210114113410687 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1169978, TS=6
20210114113410825 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170008, TS=6
20210114113410968 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170039, TS=6
20210114113411107 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170069, TS=6
20210114113411245 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170099, TS=6
20210114113411388 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170130, TS=6
20210114113411526 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170160, TS=6
20210114113411665 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170190, TS=6
20210114113411808 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170221, TS=6
20210114113411947 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170251, TS=6
20210114113412085 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170281, TS=6
20210114113412228 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FINISHED EGPRS) Scheduled Ack/Nack polling on FN=1170312, TS=6
20210114113413953 DTBF tbf.cpp:466 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=WAIT RELEASE EGPRS) T3193 timeout expired, freeing TBF
20210114113413953 DTBF tbf.cpp:473 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=WAIT RELEASE EGPRS) T3193 timeout expired, freeing TBF
20210114113413953 DTBF tbf.cpp:303 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=RELEASING EGPRS) free
20210114113414240 DL1IF pcu_l1_if.cpp:459 RACH request received: sapi=1 qta=-1, ra=0x70, fn=1170725, cur_fn=1170728, is_11bit=0
20210114113414550 DTBF tbf_ul.cpp:107 Allocating UL TBF: MS_CLASS=12/12
20210114113414551 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=NULL EGPRS) Setting Control TS 6
20210114113414551 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = 00
20210114113414551 DTBFUL tbf_ul.cpp:766 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=NULL EGPRS) setting EGPRS UL window size to 64, base(64) slots(1) ws_pdch(0)
20210114113414563 DTBF tbf.cpp:1028 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
20210114113414564 DTBFDL tbf.cpp:603 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=ASSIGN EGPRS) Scheduled UL Assignment polling on PACCH (FN=1170819, TS=7)
20210114113414693 DTBF tbf.cpp:360 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=FLOW EGPRS) Changing Control TS 7 -> 6
20210114113414815 DTBF tbf_dl.cpp:133 Allocating DL TBF: MS_CLASS=12/12
20210114113414815 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=NULL EGPRS) Setting Control TS 6
20210114113414815 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = e0
20210114113414815 DTBFDL tbf_dl.cpp:1496 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=NULL EGPRS) setting EGPRS DL window size to 64, base(64) slots(3) ws_pdch(0)
20210114113414815 DTBF tbf_dl.cpp:616 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=ASSIGN EGPRS) set ass. type PACCH [prev CCCH:0, PACCH:0]
20210114113414822 DTBF tbf.cpp:924 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=ASSIGN EGPRS) start Packet Downlink Assignment (PACCH)
20210114113414823 DTBFDL tbf.cpp:609 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=FINISHED EGPRS) Scheduled DL Assignment polling on PACCH (FN=1170875, TS=6)
20210114113414984 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170910, TS=6
20210114113415089 DTBF tbf.cpp:303 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=FINISHED EGPRS) free
20210114113415122 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1170940, TS=6
20210114113415251 DTBF tbf_ul.cpp:107 Allocating UL TBF: MS_CLASS=12/12
20210114113415251 DTBF tbf.cpp:357 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=NULL EGPRS) Setting Control TS 6
20210114113415251 DTBF tbf.cpp:762 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=NULL EGPRS) Allocated: trx = 0, ul_slots = 40, dl_slots = 00
20210114113415251 DTBFUL tbf_ul.cpp:766 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=NULL EGPRS) setting EGPRS UL window size to 64, base(64) slots(1) ws_pdch(0)
20210114113415260 DTBF tbf.cpp:1028 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
20210114113415261 DTBFDL tbf.cpp:603 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled UL Assignment polling on PACCH (FN=1170970, TS=6)
20210114113415408 DTBFDL tbf_dl.cpp:998 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=DL STATE=FLOW EGPRS) Scheduled Ack/Nack polling on FN=1171001, TS=6
20210114113415473 DTBFUL pdch.cpp:661 TBF(TFI=0 TLLI=0xe8bfe3d8 DIR=UL STATE=FLOW EGPRS) RX: [PCU <- BTS] FIXME: Packet resource request <------------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
</pre></p> OsmoPCU - Bug #4867 (Stalled): Cinterion BGS2T failing to attach (no Attach Complete ever sent)https://osmocom.org/issues/48672020-11-24T17:33:50Zpespin
<pre>
AT+CGDCONT=1,"IP","internet"
AT+CGATT=1
</pre>
<p>using osmocom network master with osmo-bts-trx-uhd + osmo-pcu</p>
<p>I see Attach procedure going on until GPRS Attach Accept is sent to the MS, then the MS never answers to it with a GPRS Attach Complete but still keeps interacting with the network ACKing all the DL data block (llc dummy frames) sent by the network, until it eventually tries to begin the whole GPRS Attach procedure again.</p>
<p>I attach a pcap file showing the issue.</p> OsmoGSMTester - Bug #4542 (Stalled): ofono: crash in drivers/qmimodem/gprs.c:extract_ss_info()https://osmocom.org/issues/45422020-05-11T10:09:16Zpespin
<pre>
----------------------------------------------
trial-2115 nitb_smpp esme_ms_sms_transaction.py
----------------------------------------------
23:41:26.470917 tst nitb_smpp: Using 1 x ip_address (candidates: 1)
23:41:26.485698 tst nitb_smpp: Using 1 x bts (candidates: 1)
23:41:28.228938 tst esme_ms_sms_transaction.py: using LAC 8882
23:41:28.343204 tst esme_ms_sms_transaction.py: using RAC 212
23:41:28.454695 tst esme_ms_sms_transaction.py: using CellId 8882
23:41:28.566672 tst esme_ms_sms_transaction.py: using BVCI 8883
23:41:28.671100 tst nitb_smpp: Using 1 x modem (candidates: 1)
23:41:28.705811 tst esme_ms_sms_transaction.py:15: ERR: Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files (2) [trial-2115↪nitb_smpp↪esme_ms_sms_transaction.py:15]
23:41:28.715436 tst esme_ms_sms_transaction.py:15: Test FAILED (2.2 sec)
</pre>
<pre>
/usr/local/sbin/ofonod --version
1.31
</pre>
<p>So ofono version is our osmo-gsm-tester branch of ofono.git (git.sysmocom.de) currently based on top of upstream 1.31 release.<br /><a class="external" href="https://git.sysmocom.de/ofono/commit/?h=osmo-gsm-tester&id=73e7f8bec0c3dd77dc4f41ee7bd9fa3275f94a39">https://git.sysmocom.de/ofono/commit/?h=osmo-gsm-tester&id=73e7f8bec0c3dd77dc4f41ee7bd9fa3275f94a39</a></p>
<p>ofono is crashing a lot lately when using modems to run gprs related tests:<br /><pre>
May 10 23:41:08.612586 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:get_ss_info_cb()
May 10 23:41:08.612612 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:handle_ss_info()
May 10 23:41:08.612635 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:extract_ss_info()
May 10 23:41:08.612659 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:extract_ss_info() radio in use 4
May 10 23:41:08.612685 osmo-gsm-tester-prod ofonod[22747]: src/gprs.c:registration_status_cb() /gobi_2 error 0 status 1
May 10 23:41:08.612711 osmo-gsm-tester-prod ofonod[22747]: src/gprs.c:ofono_gprs_status_notify() /gobi_2 status registered (1)
May 10 23:41:08.612736 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:qmi_set_attached() attached 0
May 10 23:41:08.612901 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/qmibridge.c:ask_qmi() _REQ: QMI QMUX:
QMI length = 16
QMI flags = 0x00
QMI service = "nas"
QMI client = 3
QMI QMI:
QMI flags = "none"
QMI transaction = 339
QMI tlv_length = 4
QMI message = (0x0023)
QMI TLV:
QMI type = 0x10
QMI length = 1
QMI value = 02
May 10 23:41:08.754412 osmo-gsm-tester-prod ofonod[22747]: src/modem.c:get_modem_property() modem 0x55eab5d78930 property AlwaysOnline
May 10 23:41:08.754483 osmo-gsm-tester-prod ofonod[22747]: plugins/gobi.c:gobi_set_online() 0x55eab5d78930 offline
May 10 23:41:08.754755 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/qmibridge.c:ask_qmi() _REQ: QMI QMUX:
QMI length = 16
QMI flags = 0x00
QMI service = "dms"
QMI client = 4
QMI QMI:
QMI flags = "none"
QMI transaction = 340
QMI tlv_length = 4
QMI message = "Set Operating Mode" (0x002E)
QMI TLV:
QMI type = "Mode" (0x01)
QMI length = 1
QMI value = 01
QMI translated = low-power
May 10 23:41:11.428304 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/qmibridge.c:ask_qmi() READ: QMI QMUX:
QMI length = 19
QMI flags = 0x80
QMI service = "nas"
QMI client = 3
QMI QMI:
QMI flags = "response"
QMI transaction = 339
QMI tlv_length = 7
QMI message = (0x0023)
QMI TLV:
QMI type = 0x02
QMI length = 4
QMI value = 00:00:00:00
May 10 23:41:11.428369 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:attach_detach_cb()
May 10 23:41:11.428397 osmo-gsm-tester-prod ofonod[22747]: src/gprs.c:gprs_attach_callback() /gobi_2 error = 0
May 10 23:41:11.428424 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:qmi_attached_status()
May 10 23:41:11.428580 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/qmibridge.c:ask_qmi() _REQ: QMI QMUX:
QMI length = 12
QMI flags = 0x00
QMI service = "nas"
QMI client = 3
QMI QMI:
QMI flags = "none"
QMI transaction = 341
QMI tlv_length = 0
QMI message = "Get Serving System" (0x0024)
May 10 23:41:11.460431 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/qmibridge.c:ask_qmi() READ: QMI QMUX:
QMI length = 19
QMI flags = 0x80
QMI service = "dms"
QMI client = 4
QMI QMI:
QMI flags = "response"
QMI transaction = 340
QMI tlv_length = 7
QMI message = "Set Operating Mode" (0x002E)
QMI TLV:
QMI type = "Result" (0x02)
QMI length = 4
QMI value = 00:00:00:00
QMI translated = SUCCESS
May 10 23:41:11.460495 osmo-gsm-tester-prod ofonod[22747]: plugins/gobi.c:set_online_cb()
May 10 23:41:11.460882 osmo-gsm-tester-prod ofonod[22747]: src/modem.c:modem_change_state() old state: 3, new state: 2
May 10 23:41:11.460906 osmo-gsm-tester-prod ofonod[22747]: src/modem.c:flush_atoms()
May 10 23:41:11.460938 osmo-gsm-tester-prod ofonod[22747]: src/gprs.c:gprs_context_unregister() 0x55eab5deb320, 0x55eab5deb100
May 10 23:41:11.460967 osmo-gsm-tester-prod ofonod[22747]: src/gprs.c:gprs_context_remove() atom: 0x55eab5deb360
May 10 23:41:11.460998 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs-context.c:qmi_gprs_context_remove()
May 10 23:41:11.461078 osmo-gsm-tester-prod ofonod[22747]: src/gprs.c:gprs_unregister() 0x55eab5deb100
May 10 23:41:11.473859 osmo-gsm-tester-prod ofonod[22747]: src/network.c:__ofono_netreg_remove_status_watch() 0x55eab5eee220
May 10 23:41:11.473929 osmo-gsm-tester-prod ofonod[22747]: src/gprs.c:gprs_remove() atom: 0x55eab5deb1b0
May 10 23:41:11.473998 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:qmi_gprs_remove()
May 10 23:41:11.474049 osmo-gsm-tester-prod ofonod[22747]: src/ussd.c:ussd_remove() atom: 0x55eab5e8a0f0
May 10 23:41:11.474069 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/ussd.c:qmi_ussd_remove()
May 10 23:41:11.474109 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/netmon.c:qmi_netmon_remove()
May 10 23:41:11.482561 osmo-gsm-tester-prod ofonod[22747]: src/sim.c:ofono_sim_remove_spn_watch() 0x55eab5e73700
May 10 23:41:11.482636 osmo-gsm-tester-prod ofonod[22747]: src/network.c:netreg_remove() atom: 0x55eab5eee120
May 10 23:41:11.482657 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/network-registration.c:qmi_netreg_remove()
May 10 23:41:11.482901 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/qmibridge.c:ask_qmi() _REQ: QMI QMUX:
QMI length = 16
QMI flags = 0x00
QMI service = "ctl"
QMI client = 0
QMI QMI:
QMI flags = "none"
QMI transaction = 11
QMI tlv_length = 5
QMI message = "Release CID" (0x0023)
QMI TLV:
QMI type = "Release Info" (0x01)
QMI length = 2
QMI value = 1A:01
QMI translated = [ service = 'wda' cid = '1' ]
May 10 23:41:11.494316 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/qmibridge.c:ask_qmi() READ: QMI QMUX:
QMI length = 94
QMI flags = 0x80
QMI service = "nas"
QMI client = 3
QMI QMI:
QMI flags = "response"
QMI transaction = 341
QMI tlv_length = 82
QMI message = "Get Serving System" (0x0024)
QMI TLV:
QMI type = "Result" (0x02)
QMI length = 4
QMI value = 00:00:00:00
QMI translated = SUCCESS
QMI TLV:
QMI type = "MNC PCS Digit Include Status" (0x27)
QMI length = 5
QMI value = 85:03:46:00:00
QMI translated = [ mcc = '901' mnc = '70' includes_pcs_digit = 'no' ]
QMI TLV:
QMI type = "Call Barring Status" (0x25)
QMI length = 8
QMI value = 00:00:00:00:00:00:00:00
QMI translated = [ cs_status = 'normal-only' ps_status = 'normal-only' ]
QMI TLV:
QMI type = "Detailed Service Status" (0x21)
QMI length = 5
QMI value = 02:03:04:01:00
QMI translated = [ status = 'available' capability = 'cs-ps' hdr_status = 'power-save' hdr_hybrid = 'yes' forbidden = 'no' ]
QMI TLV:
QMI type = "DTM Support" (0x20)
QMI length = 1
QMI value = 00
QMI translated = no
QMI TLV:
QMI type = "CID 3GPP" (0x1d)
QMI length = 4
QMI value = B0:22:00:00
QMI translated = 8880
QMI TLV:
QMI type = "LAC 3GPP" (0x1c)
QMI length = 2
QMI value = B0:22
QMI translated = 8880
QMI TLV:
QMI type = "Roaming Indicator List" (0x15)
QMI length = 3
QMI value = 01:04:01
QMI translated = { [0] = '[ radio_interface = 'gsm' roaming_indicator = 'off' ] '}
QMI TLV:
QMI type = "Current PLMN" (0x12)
QMI length = 5
QMI value = 85:03:46:00:00
QMI translated = [ mcc = '901' mnc = '70' description = '' ]
QMI TLV:
QMI type = "Data Service Capability" (0x11)
QMI length = 2
QMI value = 01:01
QMI translated = { [0] = 'gprs '}
QMI TLV:
QMI type = "Roaming Indicator" (0x10)
QMI length = 1
QMI value = 01
QMI translated = off
QMI TLV:
QMI type = "Serving System" (0x01)
QMI length = 6
QMI value = 01:01:01:02:01:04
QMI translated = [ registration_state = 'registered' cs_attach_state = 'attached' ps_attach_state = 'attached' selected_network = '3gpp' radio_interfaces = '{ [0] = 'gsm '}' ]
May 10 23:41:11.494370 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:get_ss_info_cb()
May 10 23:41:11.494391 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:handle_ss_info()
May 10 23:41:11.494410 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:extract_ss_info()
May 10 23:41:11.494430 osmo-gsm-tester-prod ofonod[22747]: drivers/qmimodem/gprs.c:extract_ss_info() radio in use 4
May 10 23:41:11.494475 osmo-gsm-tester-prod ofonod[22747]: Aborting (signal 11) [/usr/local/sbin/ofonod]
May 10 23:41:11.496177 osmo-gsm-tester-prod ofonod[22747]: ++++++++ backtrace ++++++++
May 10 23:41:11.517527 osmo-gsm-tester-prod ofonod[22747]: #0 0x7fe57ef27060 in /lib/x86_64-linux-gnu/libc.so.6
May 10 23:41:11.532526 osmo-gsm-tester-prod systemd[1]: ofono.service: Main process exited, code=exited, status=1/FAILURE
May 10 23:41:11.535204 osmo-gsm-tester-prod systemd[1]: ofono.service: Unit entered failed state.
May 10 23:41:11.535321 osmo-gsm-tester-prod systemd[1]: ofono.service: Failed with result 'exit-code'.
May 10 23:41:13.766647 osmo-gsm-tester-prod systemd[1]: ofono.service: Service hold-off time over, scheduling restart.
May 10 23:41:13.767895 osmo-gsm-tester-prod systemd[1]: Stopped Telephony service.
May 10 23:41:13.775458 osmo-gsm-tester-prod systemd[1]: Starting Telephony service..
</pre></p> OsmoMGW - Feature #4092 (New): Osmux: Support dynamic allocation of osmux socketshttps://osmocom.org/issues/40922019-07-05T17:02:29Zpespin
<p>Initial idea came from <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: generalization of OSMUX support in osmo-mgw (Resolved)" href="https://osmocom.org/issues/2551">#2551</a> (no need to read all that):<br /><a class="external" href="https://osmocom.org/issues/2551#note-14">https://osmocom.org/issues/2551#note-14</a><br /><a class="external" href="https://osmocom.org/issues/2551#note-15">https://osmocom.org/issues/2551#note-15</a></p>
<p>Right now, we have 1 unique Osmux socket per MGW instance.</p>
<p>Osmux streams (one direction) are identified by tuple: <srcIPaddr, srcPort, dstIPaddr, dstPort, dstCID><br />Since we currently only have 1 socket, dstIPaddr and dstPort are constant, so we identify received messages by: <srcIPaddr, srcPort, dstCID>.</p>
<p>if the other peer is behind a NAT, srcIPaddr and srcPort are not really reliable easily, so we can only rely on dstCID to identify streams, and thus we share the CID range against all BSCs or connections.<br />We actually do something similar for RTP, let's think about it:<br />tuple identified by: <srcIPaddr, srcPort, dstIPaddr, dstPort, dstCID>, but in this case dstPort changes per-conn, so we actually identify streams per dstPort in this case.</p>
<p>So in Osmux streams, we identify based on dstCID, and in RTP, in dstPort. The problem is that dstCID is actually in range 0..255, which means we can get out of CIDs (not like with ports, were range is a lot higher).</p>
<p>In order to improve this situation (only 255 concurrent call legs in MGW using Osmux), here's my proposal:</p>
<p>VTY specifies an osmux IP (IPmsc) and a port range (PORTmsc1..100), or a port to start counting from, and dynamically allocates/binds and closes ports based on demand. These ports are allocated in MGW based on received MGCP <remoteIP,remotePort> tuple. This way we end up having 256 CIDs per <remoteIP,remotePort> tuple, aka per BSC, and which is the same, per <localPort>. Each BSC can actually open new osmux sockets themselves once the first one is full, meaning each BSC can handle also unlimited CIDs, and MSC will be fine because upon receival of this new <remoteIP,remotePort> tuple, a new osmux socket will be created.</p>
<p>All that also plays well with the fact that we want to group Osmux CIDs under same <remotIP,remotePort>, since the trunk frames need to be sent to that same address.</p>
So summary, in MGW:
<ul>
<li>Add a table to match <remoteIP,remotePort> <-> <localPort>, with extra information like: publicRemoteIP, publicRemotePort, Osmux handler.</li>
<li>Upon CRCX/MDCX update table: If an entry <remoteIP,remotePort> doesn't exist, create osmux socket + handler on next empty localPort, and fill the table.</li>
<li>Upon receival of Osmux pkt, take <dstPort>, and use it in the table to lookup based on localPort, then we know the private and public <remoteIPaddr,port>, and we know to which Osmux handler we need to send the message.</li>
<li>When we need to send on an osmux handler, we know localIp, localPort and publicRemoteIP and publicRemotePort, so we can send osmux frames correctly.</li>
</ul>
<p>Drawbacks: We need at least 1 Osmux port per BSC.<br />Wins: We can handle unlimited Osmux call legs per BSC and per MSC (as long as ports are free, each port provides 256 streams). It allows us to support multiple MGWs when using Osmux, since now it's not possible afaict.</p> OsmoPCU - Bug #3928 (Stalled): Missing PCU_Tests.ttcn for various timers / time-outshttps://osmocom.org/issues/39282019-04-15T07:57:37Zlaforge
<p>We should have automatically-executed tests that test the various RLC/MAC related timers and timeouts</p> OsmoPCU - Bug #3926 (Stalled): Missing PCU_Tests.ttcn DL TBF testshttps://osmocom.org/issues/39262019-04-15T07:55:21Zlaforge
<p>We should have a bunch of automatically executed tests in PCU_Tests.ttcn that cover DL TBF establishment</p> OsmoBTS - Feature #3155 (Stalled): execute BTS_Tests.ttcn with real (C123) phone hardware in LTHW...https://osmocom.org/issues/31552018-04-10T16:28:12Zlaforge
<p>We want to execute the BTS_Tests.ttcn against all real hardware BTS models of our LTHW setup.</p>
<a name="Hardware-Setup"></a>
<h2 >Hardware Setup<a href="#Hardware-Setup" class="wiki-anchor">¶</a></h2>
On the hardware side, his means, we need to
<ul>
<li>add a C123 with RF cabling to the "modem ports" of the setup</li>
<li>be able to power cycle this C123 from software</li>
<li>attach the C123 UART via CP2103 USB-UART to the main unit</li>
</ul>
<a name="Software-Setup"></a>
<h2 >Software Setup<a href="#Software-Setup" class="wiki-anchor">¶</a></h2>
<p>We will need to be able to execute the BTS_Tests.ttcn on the gsm tester main unit. This could be done either natively or via the existing docker containers. In any case, we don't want to <strong>build</strong> the ttcn source on the low-power APU, but we want that the compiled test suite is copied/transferred to the APU and then executed there.</p>
<p>We also want to make sure that we have proper locking/exclusivity with the osmo-gsm-tester stack, so that we either run osmo-gsm-tester or BTS_Tests.ttcn.</p>
<p>Finally, this should all be started from jenkins.osmocom.org.</p>
<p>It probably makes sense (as usual) to start with the R&D setup and then replicate the setup in production.</p> OsmoSGSN - Bug #44 (New): TLLI clash possiblehttps://osmocom.org/issues/442016-02-19T22:47:32Z
<p>When we look-up the LLC-LLE we will convert from Foreign to Local TLLI and this might cause a 'clash' (in case a public net has allocated the same P-TMSI as we allocate).</p>
<p>We should somehow use the 'full' TLLI for look-up and remember why/how we created the LLC-LLE (in case of different life-time) and maybe (if possible) assign a new TLLI (probably not possible).</p>
<p>The probability of this event to happen is quite low.</p>