Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://projects.osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://projects.osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> OsmoGSMTester - Feature #5839 (New): Ability to switch off the osmo-trx machinehttps://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.osmocom.org/projects/osmosgsn/wiki">osmo-sgsn</a></p> OsmoSGSN - Bug #5398 (New): Null pointer access at "uectx" in ranap_iu_txhttps://projects.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> libosmocore - Bug #5346 (New): osmo-release.sh doesn't work with %{sover} macro in spec.inhttps://projects.osmocom.org/issues/53462021-12-09T07:26:09Zlaforge
<p>When trying to release a new version of osmo-remsim, I run into the following error:</p>
<pre>
make REL=major release 415/0/0
Releasing 0.2.2.126-7382 -> 1.0.0...
OK: dependency specific versions in configure.ac and debian/control match
OK: dependency specific versions in configure.ac and contrib/*.spec.in match
OK: Found matching debian/lib*2.install for LIBVERSION=2:0:0
OK: Found 'Package: lib*2' in debian/control for LIBVERSION=2:0:0
ERROR: Found no matching '%files -n lib*2' in contrib/*.spec.in for LIBVERSION=2:0:0
make: *** [osmo-release.mk:9: release] Error 1
</pre>
<p>this seems to relate to the spec.in file using a %{sover} macro. This seems to be the case ever since this spec file was introduced to osmo-remsim, so I suppose the check in osmo-release.sh is more recent and didn't consider this situation?</p> OsmoPCU - Bug #5309 (New): osmo-pcu: Support rejecting multiple TBFs upon tx of Packet Access Rejecthttps://projects.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://projects.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 - Bug #5212 (New): apparently T3193 is by default not set to its defined default valuehttps://projects.osmocom.org/issues/52122021-08-12T13:04:36Zneelsnhofmeyr@sysmocom.de
<p>When I run osmo-pcu and launch a ttcn3 test (PCU_Tests.TC_mt_ping_pong) so that a BTS is present,<br />'show bts-timers' lists:</p>
<pre><code>OsmoPCU# show bts-timer<br /> BTS0:<br /> ...<br /> T3193 = 1600 ms Reuse of TFI(s) after reception of final PACKET DOWNLINK ACK/NACK from MS for TBF (default: 100 ms)<br /> ...</code></pre>
<p>Notice that T3193 is set to 1600 ms, although its default says 100 ms.<br />I looked for anything that might alter the timeout in the ttcn3 code, but could not find anything.</p> OsmoPCU - Bug #5149 (New): osmo-pcu fails to allocate all DL-TBF possible slots under specific sc...https://projects.osmocom.org/issues/51492021-05-10T12:57:58Zpespin
<p>The issue is shown by TTCN3 PCU_Tests.TC_dl_multislot_tbf_ms_class_from_sgsn, where 4 slots are allocated to the DL TBF despite the PCU knowing at that time that the MS_CLASS supports concurrent 8-TX/8-RX.</p>
<p>The scenario is quite corner case, hence I'm marking the ticket as "Lower" priority. It can only happen if pcu is configured to not force two-phase access, then MS starts a UL TBF 1-phase access (hence without ms_class info) and without having interacted recently with the network (MS not in the MS cache in PCU).<br />In this case, when the UL TBF is allocated and slots for both UL and DL are reserved, since ms_class is unknown (0), DEFAULT_MSLOT_CLASS (12) is picked to reserve the slots. Hence, if afterwards we send some data SGSN->MS (containing MS Radio Access Capability), the DL TBF is created but the DL slots were already reserved before (using the default class 12), hence not all possible slots are used.</p>
<p>The main problem is that osmo-pcu allocator reserves both UL and DL for an MS whenever 1 TBF is created, and that's expected to have whenever the 1st TBF is created (see alloc_algorithm_b() when it calls find_multi_slots()).</p>
<p>In order to fix this case, we'd need to do, upon ms_set_ms_class()/ms_set_egprs_ms_class():<br /><pre>
if (ms->ms_class == 0 && ms_class_ > 0) {
if (ms->dl_tbf && !ms->ul_tbf) {
/* update reserved mask for reserved_ul_slots */
} else {
/* update reserved mask for reserved_dl_slots */
}
}
</pre></p>
<p>In order to implement the "/* update reserved mask for reserved_dl_slots */" part, one could split find_multi_slots() into pieces and try to reuse some of that, or simply copy-paste the function and change it to select the best slot set for a direction while keeping the direction already having a TBF in the current fixed size.</p>
<p>I'm still not sure though if we can really have this sort of scenario in real life, that's also another point why I mark the ticket as low.<br />If we ever find such a case in real life capture or we figure out an exact test which really makes sense, we can go on implementing what I mentioned above.</p> OsmoPCU - Feature #5122 (New): Choose SBA allocation offset based on AGCH queue load in the BTShttps://projects.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://projects.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://projects.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> OsmoMGW - Bug #5044 (New): potential null pointer dereferenceshttps://projects.osmocom.org/issues/50442021-02-24T11:48:29Zlaforge
<p>gcc on OpenSUSE_Factory warns as follows:<br /><pre>
[ 69s] CCLD osmo-mgw
[ 70s] ../libosmo-mgcp/mgcp_osmux.c: In function 'osmux_conn_lookup.constprop':
[ 70s] ../libosmo-mgcp/mgcp_osmux.c:218:23: warning: potential null pointer dereference [-Wnull-dereference]
[ 70s] 218 | for (i = 0; i < trunk->number_endpoints; i++) {
[ 70s] | ^
[ 70s] ../libosmo-mgcp/mgcp_osmux.c:218:23: warning: potential null pointer dereference [-Wnull-dereference]
[ 70s] ../libosmo-mgcp/mgcp_vty.c: In function 'cfg_mgcp_omit_rtcp':
[ 70s] ../libosmo-mgcp/mgcp_vty.c:782:19: warning: potential null pointer dereference [-Wnull-dereference]
[ 70s] 782 | trunk->omit_rtcp = 1;
[ 70s] | ^
[ 70s] ../libosmo-mgcp/mgcp_vty.c:782:19: warning: potential null pointer dereference [-Wnull-dereference]
[ 73s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/osmo-mgw-1.8.1/src/osmo-mgw'
[ 73s] make[3]: Entering directory '/home/abuild/rpmbuild/BUILD/osmo-mgw-1.8.1/src'
[ 73s] make[3]: Nothing to be done for 'all-am'.
[ 73s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/osmo-mgw-1.8.1/src'
[ 73s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/osmo-mgw-1.8.1/src'
[ 73s] Making all in tests
[ 73s] make[2]: Entering directory '/home/abuild/rpmbuild/BUILD/osmo-mgw-1.8.1/tests'
[ 73s] Making all in mgcp_client
[ 73s] make[3]: Entering directory '/home/abuild/rpmbuild/BUILD/osmo-mgw-1.8.1/tests/mgcp_client'
[ 74s] CC mgcp_client_test.o
[ 74s] CCLD mgcp_client_test
[ 75s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/osmo-mgw-1.8.1/tests/mgcp_client'
[ 75s] Making all in mgcp
[ 75s] make[3]: Entering directory '/home/abuild/rpmbuild/BUILD/osmo-mgw-1.8.1/tests/mgcp'
[ 75s] CC mgcp_test.o
[ 76s] CCLD mgcp_test
[ 77s] mgcp_test.c: In function 'test_packet_loss_calc':
[ 77s] mgcp_test.c:1074:21: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1074 | packets_rx = &conn->rate_ctr_group->ctr[RTP_PACKETS_RX_CTR];
[ 77s] | ^
[ 77s] mgcp_test.c:1076:28: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1076 | state->stats.initialized = 1;
[ 77s] | ^
[ 77s] mgcp_test.c:1077:25: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1077 | state->stats.base_seq = pl_test_dat[i].base_seq;
[ 77s] | ^
[ 77s] mgcp_test.c:1078:24: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1078 | state->stats.max_seq = pl_test_dat[i].max_seq;
[ 77s] | ^
[ 77s] mgcp_test.c:1079:23: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1079 | state->stats.cycles = pl_test_dat[i].cycles;
[ 77s] | ^
[ 77s] mgcp_test.c:1074:21: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1074 | packets_rx = &conn->rate_ctr_group->ctr[RTP_PACKETS_RX_CTR];
[ 77s] | ^
[ 77s] mgcp_test.c:1076:28: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1076 | state->stats.initialized = 1;
[ 77s] | ^
[ 77s] mgcp_test.c:1077:25: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1077 | state->stats.base_seq = pl_test_dat[i].base_seq;
[ 77s] | ^
[ 77s] mgcp_test.c:1078:24: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1078 | state->stats.max_seq = pl_test_dat[i].max_seq;
[ 77s] | ^
[ 77s] mgcp_test.c:1079:23: warning: potential null pointer dereference [-Wnull-dereference]
[ 77s] 1079 | state->stats.cycles = pl_test_dat[i].cycles;
[ 77s] | ^
[ 78s] ../../src/libosmo-mgcp/mgcp_osmux.c: In function 'osmux_conn_lookup.constprop':
[ 78s] ../../src/libosmo-mgcp/mgcp_osmux.c:218:23: warning: potential null pointer dereference [-Wnull-dereference]
[ 78s] 218 | for (i = 0; i < trunk->number_endpoints; i++) {
[ 78s] | ^
[ 78s] ../../src/libosmo-mgcp/mgcp_osmux.c:218:23: warning: potential null pointer dereference [-Wnull-dereference]
</pre></p>
<p>we should check if there's any truth to it.</p> libosmocore - Feature #5034 (Stalled): logging: Enable category name instead of hex val by defaulthttps://projects.osmocom.org/issues/50342021-02-18T18:06:59Zpespin
<p>Discussion started in this patch:<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/12095">https://gerrit.osmocom.org/c/libosmocore/+/12095</a></p>
<p>Summary/outcome:<br /><pre>
As a reference, I think it makes more sense to change it for all log targets this way:diff --git a/src/logging.c b/src/logging.c
index a40008e9..f878be5a 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -918,7 +918,8 @@ struct log_target *log_target_create(void)
target->use_color = 1;
target->print_timestamp = 0;
target->print_filename2 = LOG_FILENAME_PATH;
- target->print_category_hex = true;
+ target->print_category_hex = false;
+ target->print_category = true;
So here actually by default we disable the hex output and we enable the string representation. Once this is applied, some tests will need to be adapted since they may not set those fields explicitly and use default ones.
</pre></p>
Steps:
<ul>
<li>Apply change in libosmocore locally</li>
<li>Build other projects and see if a test in any projects fails. For each test failing, make sure to set explicit values for log_set_print_category{_hex} to match current expectancies.</li>
<li>Once those patches are merged, submit + merge libosmocore patch changing the default.</li>
</ul> osmo-uecups - Feature #5012 (New): use osmo-uecups from GGSN_Tests.ttcnhttps://projects.osmocom.org/issues/50122021-02-06T10:02:49Zlaforge
Historically, we
<ol>
<li>developed GGSN_Tests.ttcn against osmo-ggsn, where the GTP-U plane is handled inside the tests itself
<ul>
<li>this limits the testing to very simple cases like sending single user IP packets back and forth</li>
</ul>
</li>
<li>much later developed PGW_Tests + osmo-uecups, where only the control plane is handled in TTCN3 and the user-plane goes via osmo-uecups
<ul>
<li>this allows to create one tun device per PDP context, each in a separate netns and then start any arbitrary test program (e.g. iperf) inside that netns</li>
</ul></li>
</ol>
<p>It would be great to also start using osmo-uecups from the GGSN_Tests.ttcn. Not really to replace the existing tests, but to add new tets that can do more in terms of user plane testing. See e.g. PGW_Tests.TC_createSession_ping4_256, which starts 256 concurrent Sessions (== pdp contexts) each with its tun device, netns and ping command inside. Of course "ping" is not neccessarily the best test program, but it illustrates what can be done with very few lines of TTCN3 code. Result codes of the ping commands are checked, so we see whether multiple concurrent PDP contexts work as expected.</p>