Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-15T18:45:50ZOpen Source Mobile Communications
Redmine osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6408 (New): osmo-epdg: Support check IMEIhttps://osmocom.org/issues/64082024-03-15T18:45:50Zpespin
<p>We didn't implement anything IMEI related yet, grep for "IMEI" in TS 29.273.</p>
<p>For instance:<br /><pre>
Specific operator policies may be configured for emergency services, regarding whether to check the IMEI and, if the
IMEI needs to be checked, whether to continue or stop the authentication and authorization procedure upon getting the
IMEI check result or when the IMEI(SV) is not available.
</pre></p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6407 (New): osmo-epdg: Support Emergenc...https://osmocom.org/issues/64072024-03-15T18:43:20Zpespin
<p>Grep for "Emergency" in TS 29.273. We didn't implement any of those yet. We expect an IMSI everywhere.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6406 (Resolved): osmo-epdg: ePDG: missi...https://osmocom.org/issues/64062024-03-15T16:28:31Zpespin
<p>Related specs in 3GPP TS 29.273:<br /><pre>
* 7.1.2.2 Authorization Procedures
* 7.2.2.1.3 Diameter-AA-Request (AAR) Command ePDG --> AAA
* 7.2.2.1.4 Diameter-AA-Answer (AAA) Command ePDG <-- AAA
</pre></p>
<p>This is triggered by "re-authentication procedure as described in clause 7.2.2.4". That basically means that:<br />1- HSS --> AAA-server: Push-Profile-Request (implemented, see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: osmo-epdg: AAA: missing progragation of SWx "HSS Initiated Update of User Profile Procedure" (Resolved)" href="https://osmocom.org/issues/6404">#6404</a>)<br />2- AAA-server --> ePDG: Re-Authorization Request (RAR), 7.1.2.5 (implemented, see <a class="external" href="https://gerrit.osmocom.org/c/erlang/osmo-epdg/+/36305">https://gerrit.osmocom.org/c/erlang/osmo-epdg/+/36305</a>)</p>
<p>At that point, in the ePDG we need to send AAR to the AAA, see 7.1.2.5:<br /><pre>
Upon receiving the re-authorization request, the ePDG shall immediately invoke the authorization procedure
specified in 7.1.2.2 for the session indicated in the request. This procedure is based on the Diameter
commands AA-Request (AAR) and AA-Answer (AAA) specified in IETF RFC 4005 [4]. Information
element contents for these messages are shown in tables 7.1.2.2.1/1 and 7.1.2.2.1/2.
</pre></p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6404 (Resolved): osmo-epdg: AAA: missin...https://osmocom.org/issues/64042024-03-14T17:49:47Zpespin
<pre>
%% TODO: in successful case, we want to validate how this prcoedure extends to other interfaces:
%% """ 3GPP TS 29.273 8.1.2.3.3:
%% After a successful user profile download, the 3GPP AAA Server shall
%% initiate re-authentication procedure as described
%% in clause 7.2.2.4 if the subscriber has previously been authenticated
%% and authorized to untrusted non-3GPP access.
%% """
</pre>
<p>So far we only support answering in SWx as if everything went fine, but we are really not propagating the update.<br />The initial Swx support has been submitted here:<br /><a class="external" href="https://gerrit.osmocom.org/c/erlang/osmo-epdg/+/36284">https://gerrit.osmocom.org/c/erlang/osmo-epdg/+/36284</a> SWx: Answer PPR with PPA<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36285">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36285</a> epdg: Introduce test TC_hss_initiated_update_user_profile(_unknown)</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6400 (Resolved): osmo-epdg: AAA: missing im...https://osmocom.org/issues/64002024-03-13T19:32:14Zpespin
<p>S6b is defined in 3GPP TS 29.273, and is Diameter interface between AAA-Server and PGW (open5gs-smfd).</p>
<p>We still miss the Re-auth procedure (9.1.2.5, 9.2.2.6), which is not really needed for now afaict:</p>
<pre>
9.1.2.5 Service Authorization Information Update Procedures
- S6b Re-authorization request PGW->AAA
- S6b Re-authorization response PGW<-AAA
</pre> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6399 (Resolved): osmo-epdg: S6b ASR encodin...https://osmocom.org/issues/63992024-03-13T19:29:21Zpespin
<p>I couldn't figure out yet why encoding the following message fails when running test EPDG_Tests.TC_hss_initiated_deregister_permanent_termination:</p>
<pre>
18:15:53.642 [debug] S6b Tx ASR: {'ASR',["aaa.localdomain",";","1771858795",";","30",";","nonode@nohost"],undefined,undefined,undefined,undefined,16777272,"262422638508077",1,[]}
18:15:53.642 [debug] S6b prepare_request: {'ASR',["aaa.localdomain",";","1771858795",";","30",";","nonode@nohost"],"aaa.localdomain","localdomain","localdomain","pgw.localdomain",16777272,"262422638508077",1,[]}
18:15:53.643 [error] Error: encode
</pre>
<p>The procedure is introduced here: <a class="external" href="https://gerrit.osmocom.org/c/erlang/osmo-epdg/+/36262">https://gerrit.osmocom.org/c/erlang/osmo-epdg/+/36262</a><br />Grep for "handle_call({asr, Imsi}, _From, State)" in src/aaa_diameter_s6b.erl.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6384 (Resolved): osmo-epdg: SMF IP address ...https://osmocom.org/issues/63842024-03-01T23:25:06Zpespin
<p>So far we are obtaining the SMF IP address in osmo-epdg from the config file:<br /><pre>
config/sys.config
38: {gtpc_remote_ip, "127.0.0.1"},
</pre></p>
<pre>
src/osmo_epdg_sup.erl
13:-define(ENV_DEFAULT_GTPC_REMOTE_IP, "127.0.0.1").
24: GtpcRemoteIp = application:get_env(?ENV_APP_NAME, gtpc_remote_ip, ?ENV_DEFAULT_GTPC_REMOTE_IP),
%% ePDG processes:
GtpcServer = {epdg_gtpc_s2b, {epdg_gtpc_s2b,start_link, [GtpcLocalIp, GtpcLocalPort, GtpcRemoteIp, GtpcRemotePort, GtpuLocalIp, []]},
permanent,
5000,
worker,
[epdg_gtpc_s2b]},
</pre>
<p>We should instead obtain it from the AAA-Server.<br />It still needs to be found out whether AAA-Server in turn also obtains it from HSS.</p> 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> libosmocore - Bug #6374 (New): libosmocore --disable-libsctp not tested by jenkinshttps://osmocom.org/issues/63742024-02-23T15:40:23Zpespin
<p>Right now we are not testing build of libosmocore disabling libsctp support, which means it went broken some time ago and which has recently been fixed by:<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/36055/1">https://gerrit.osmocom.org/c/libosmocore/+/36055/1</a></p>
<pre>
$ ./configure --help | grep sctp
--disable-libsctp Do not enable socket multiaddr APIs requiring
libsctp
--disable-sctp-tests Do not run socket tests requiring system SCTP
</pre>
<p>We should ideally test building with those flags above set in the build matrix of the jenkins job when submitting patches to gerrit (and also probably the master jobs?).</p>
<p>We should ideally test the same when building libosmo-netif and libosmo-sccp (they also have similar configure flags iirc, which in turn relate to --disable-libsctp from libosmocore).</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6369 (Resolved): PCO information from/to UEhttps://osmocom.org/issues/63692024-02-19T15:30:57Zpespin
<p>We are missing the related PCO-kind options ( P-CSCF), like DNS.</p>
<p>The UE will request PCOs over IKEv2 as Config Request.<br />We need to pass it over GSUP towards the erlang osmo-epdg and request those from the PGW.</p>
<p>- RFC7296 <br />- RFC7651<br />- <a class="external" href="https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml">https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml</a><br />- 3GPP TS 29.060 clause 7.7.31<br />- 3GPP TS 24.008 clause 10.5.6.3</p> 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> OsmocomBB - Bug #6351 (Resolved): rlcmac: Bug calculating/encoding 2 LLC frames fitting in 1 CS4 ...https://osmocom.org/issues/63512024-02-02T17:42:39Zpespin
<p>During initial GMM ATTACH + SM PDP ACT procedure, if using CS4 in UL, we end up in a situation where basically the MS, upon receiving GMM Attach Accept, triggers creation of a new UL TBF and wants to send 2 LLC frames one after the other (GMM AttachCompl + SM PDP Act Context Req):<br /><pre>
1242 16:09:52.495676 Feb 2, 2024 17:09:52.495676000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 199 ✓ GRE(91223344) Update TLLI 0x91223344 -> 0xe0083f9b
1243 16:09:52.495750 Feb 2, 2024 17:09:52.495750000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 224 ✓ GMME(IMSI-001010000000101:PTMSI-e0083f9b:TLLI-e0083f9b) Tx GMM ATTACH COMPL
1245 16:09:52.495901 Feb 2, 2024 17:09:52.495901000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 228 ✓ modem_llc_prim_down_cb(): Rx GRR-UNITDATA.request ll=[01 c0 0d 08 03 55 1c ea ]
1247 16:09:52.496061 Feb 2, 2024 17:09:52.496061000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 209 ✓ GRE(e0083f9b) Enqueueing LLC-PDU len=8 SAPI=GMM radio_prio=1
1260 16:09:52.497107 Feb 2, 2024 17:09:52.497107000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 201 ✓ PDP(ID-0:NSAPI-6) Tx SM Activate PDP Context Request
1263 16:09:52.497349 Feb 2, 2024 17:09:52.497349000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 321 ✓ modem_llc_prim_down_cb(): Rx GRR-UNITDATA.request ll=[01 c0 11 8a 41 06 03 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 01 21 28 09 08 69 6e 74 65 72 6e 65 74 9e 49 7a ]
1265 16:09:52.497473 Feb 2, 2024 17:09:52.497473000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 210 ✓ GRE(e0083f9b) Enqueueing LLC-PDU len=39 SAPI=GMM radio_prio=1
</pre></p>
<p>So it's 1 LLC frame of 8 bytes, and 1 LLC frame of 39 bytes, that's 47 bytes of data in total.</p>
<p>Then, in the pcap we can see that only the Attach Compl is transmitted with UL DATA block BSN=0 and CV=0.</p>
<p>However, the Act PDP Context Req is not included in the encoded BSN=0 UL data block, and ofc no extra block is expected because the MS sent the first one with CV=0.</p>
<p>This happens because our gprs_rlcmac_ul_tbf_calculate_cv() function calculates it can fit both in 1 CS4 UL data block:<br /><pre>
20240202172854510 DRLCMAC NOTICE tbf_ul.c:507 TBF(UL:NR-3:TLLI-e172f149) calculate_cv blk_state_init: tx_cs=4 bs_cv_max=15 blk_data_len=50 │ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
20240202172854510 DRLCMAC NOTICE tbf_ul.c:608 TBF(UL:NR-3:TLLI-e172f149) calculate_cv after pq[0][0]: blk_count=0 offset=49 │52: modem4: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 500
20240202172854510 DRLCMAC NOTICE tbf_ul.c:615 TBF(UL:NR-3:TLLI-e172f149) calculate_cv after done: blk_count=0 offset=49 │ link/none
20240202172854510 DRLCMAC NOTICE tbf_ul.c:627 TBF(UL:NR-3:TLLI-e172f149) calculate_cv after adapting: : blk_count=1 offset=0 │root@mssdr-ms:/home/ubuntu# ip addr
20240202172854510 DRLCMAC NOTICE tbf_ul.c:629 TBF(UL:NR-3:TLLI-e172f149) blk_count after adapting: blk_count=1 offset=0 -> x=0 bs_cv_max=15
</pre></p>
<p>Taking into account we are in contention resolution, it's 54-4 bytes which can fit. This whole thing needs to be checked for wrong calculations. Starting by the fact that GPRS may not allow to send multiple LLC frames in one RLC/MAC block? Maybe only in EGPRS it's allowed? I need to check.</p>
<p>So what needs to be done:<br />1- Check if several LLC frames can be put inside 1 RLC/MAC UL data block.<br />2- If answer is no, fix gprs_rlcmac_ul_tbf_calculate_cv() to return CV=1 in this case.<br />3- If answer is yes, then check if the size calculations are correct in gprs_rlcmac_ul_tbf_calculate_cv()<br />4- if everything is fine, then we may have a bug in the block encoder.</p>
<p>The quick hack for now is to avoid using UL CS4, that should prevent this incident to happen since it's the only block size which gprs_rlcmac_ul_tbf_calculate_cv() considers can fit into 1 block.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6345 (New): osmo-epdg: Implement SWm in...https://osmocom.org/issues/63452024-01-25T16:32:08Zpespin
<p>In current architecture of osmo-epdg, the process contains both the ePDG and the AAA Server nodes.</p>
<p>These 2 nodes speak Diameter SWm interface between them.</p>
<p>We may want to split the 2 nodes into 2 processes and properly implement SWm at some point, or use another AAA server implementation.</p>
<p>Anyway, creating the ticket as a reference point to look up/comment on related communication between ePDG and AAA nodes.</p>
Spec references:
<ul>
<li>TS 29.273 section 7</li>
<li>TS 23.402 (grep for "SWm")</li>
</ul> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6333 (Resolved): Describe UE/ePDG-initiated...https://osmocom.org/issues/63332024-01-18T18:50:29Zpespin
<p>Related: 3GPP TS 23.402 section 7.4 "Detach and PDN Disconnection for S2b", and specifically section "7.4.3 UE/ePDG-initiated Detach Procedure and UE-Requested PDN<br />Disconnection with GTP on S2b".</p>
<p>That section explains (vaguely) that the UE can initiate a procedure to detach from ePDG. Sequence diagram Figure 7.4.3-1 refers to "Detach procedure as in Figure<br />7.4.1-1, before step (A)", which state: "IKEv2 tunnel release trigger".</p>
<p><a class="user active" href="https://osmocom.org/users/1741">lynxis</a> can you clarify what does that exactly mean/involve at strongswan side between UE<->strongswan? Not sure if you already looked at / though about this scenario.<br />We probably also need to define messages between strongswan <> osmo-epdg to forward this.<br />Again, not sure if you need a response ePDG->strongswan you can answer the UE, please provide feedback here. According to Figure 7.4.1-1, we need a "6. Non-3GPP specific<br />resource release procedure".</p>
<p>Finally, once we figure the message type in CEAI, we have to implement in osmo-epdg:<br />- Tx DeleteSessionReq to PGW<br />- Rx DeleteSessionResp from PGW</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6332 (New): osmo-epdg: Write User Manualhttps://osmocom.org/issues/63322024-01-18T16:15:34Zpespin
Have an asciidoc user manual documenting:
<ul>
<li>The overall architecture with the different nodes (strongswan, osmo-epdg, PGW, HSS, etc.)</li>
<li>How the iptables and tunnel interface works for user plane.</li>
<li>How to build, configure, run the osmo-epdg program</li>
<li>How to build, configure, run strongswan</li>
<li>Describing the different intefraces: CEAI, SWx, S6b, S2b, etc.</li>
</ul>
It should include some stuff from osmo-gsm-manuals.git:
<ul>
<li>./common/chapters/gsup.adoc</li>
</ul> OsmoGGSN (former OpenGGSN) - Feature #6298 (New): osmo-ggsn not providing MTU of the GTP tunnel t...https://osmocom.org/issues/62982023-12-08T17:50:49Zpespin
<p>MTU is provided by PCO in IPv4 and through SLAAC in IPv6 (see <a class="external" href="https://github.com/open5gs/open5gs/issues/2754">https://github.com/open5gs/open5gs/issues/2754</a> for more info).<br />I think osmo-ggsn is not yet providing it to the MS, hence why one may not see it while looking at pcaps.<br />One can check at open5gs on how to submit it.</p>
<p>We probably also want to have it configurable in the vty and apply it on the created tunnel device too.<br />Probably something to be added through libosmocore ./include/osmocom/core/tun.h ./src/core/tun.c</p> Core testing infrastructure - Feature #6242 (New): Test eUPF against ttcn3-upf-test setuphttps://osmocom.org/issues/62422023-10-31T15:35:48Zpespin
<pre>
P- just stumbled across this, looks like open5gs can work with it: https://github.com/edgecomllc/eupf
P- see open5gs last commit: https://github.com/open5gs/open5gs/commit/9e88579c4f73afcbd41cd9b94a6fda0cf9185c10
L- might be worth setting that up and running our upf testsuite against as a first step to get some feel
L- ttcn3-pgw-test you mean?
P- https://jenkins.osmocom.org/jenkins/job/ttcn3-upf-test/
</pre> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6235 (Resolved): osmo-epdg: gtp tunnel ...https://osmocom.org/issues/62352023-10-25T17:00:28Zpespin
<p>osmo-epdg needs to create GTP tunnels (GTP-U) for each session created against PGW over the S2b interface.<br />The GTPv2C side of things is already more or less in place for CreateSession Req+Resp, but we are not yet setting up the tunnel.</p>
<p>AFAIU the idea is to use netfilter rules to route traffic between the IPsec strongswan tunnel and each of the GTP tunnels, using fwmark iirc.<br />It's still not clear who's in charge to set up the netfilter rules.</p>
<p>From <a class="external" href="https://osmocom.org/issues/5288#note-4">https://osmocom.org/issues/5288#note-4</a>:</p>
<blockquote>
<ul>
<li><a class="external" href="https://github.com/travelping/gen_netlink">https://github.com/travelping/gen_netlink</a> as a generic netlink interface library</li>
<li><a class="external" href="https://github.com/travelping/gtp_u_kmod/blob/master/src/gtp_u_kernel.erl">https://github.com/travelping/gtp_u_kmod/blob/master/src/gtp_u_kernel.erl</a> using gen_netlink to create/update/delete gtp tunnels in the kernel GTP driver</li>
</ul>
<p>It would be an idea to first have a small stand-alone erlang program that uses those libraries to create kernel GTP tunnels whose creation/modification/removal can be confirmed using libgtpnl/tools/gtp-tunnel to display the current in-kernel state.</p>
</blockquote>
<p>We also need to think about the best approach to run the erlang code with NET_ADMIN capabilities which will probably be needed to create the tunnels and set up netfiler rules.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6229 (Resolved): osmo-epdg: Implement s...https://osmocom.org/issues/62292023-10-19T17:04:45Zpespin
<p>Create a S6B diameter module to connect (or listen) to PGW (open5gs-smfd).</p>
<p>S6b is defined in 3GPP TS 29.273 section 9</p>
<p>9.1.2.2 Authorization Procedures when using PMIPv6 or GTPv2:<br />- Authorization Request (AAR) PGW->AAA<br />- Authorization Answer (AAA) PGW<-AAA</p>
<p>9.1.2.3 PDN GW Initiated Session Termination Procedures:<br />- S6b Session Termination Request PGW->AAA<br />- S6b Session Termination Answer PGW<-AAA</p>
<p>9.1.2.4 3GPP AAA Initiated Session Termination Procedures:<br />- S6b Abort Session Request PGW<-AAA<br />- S6b Abort Session Answer PGW->AAA<br />- S6b Session Termination Request PGW<-AAA<br />- S6b Session Termination Answer PGW->AAA</p>
<p>9.1.2.5 Service Authorization Information Update Procedures<br />- S6b Re-authorization request PGW->AAA<br />- S6b Re-authorization response PGW<-AAA</p> libosmo-netif - Bug #6222 (Resolved): Memory leak triggered by stream_testhttps://osmocom.org/issues/62222023-10-17T14:30:25Zpespin
<p>Building libosmo-netif master (106b63907a1d9be56bce7cb4a830b4bf52e7ab51), stream_test fails with ASan enabled:</p>
<pre>
CLICONN(,r=127.0.0.11:1111<->l=127.0.0.1:8977){CONNECTING} connection established
SRV(srv_link_test,127.0.0.11:1112) accept()ed new link from 127.0.0.1:8977
CLICONN(,r=127.0.0.11:1112<->l=127.0.0.1:8977){CONNECTING} connection established
+
+=================================================================
+==235742==ERROR: LeakSanitizer: detected memory leaks
+
+Direct leak of 96 byte(s) in 1 object(s) allocated from:
+ #0 0x7fa93c0e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
+ #1 0x7fa93c6eca76 (/usr/lib/libtalloc.so.2+0x4a76) (BuildId: e0a2f614bd7ebca36cf8a6c88cb544b680fd17dd)
+
+Indirect leak of 96 byte(s) in 1 object(s) allocated from:
+ #0 0x7fa93c0e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
+ #1 0x7fa93c6ecb04 (/usr/lib/libtalloc.so.2+0x4b04) (BuildId: e0a2f614bd7ebca36cf8a6c88cb544b680fd17dd)
+
+Indirect leak of 96 byte(s) in 1 object(s) allocated from:
+ #0 0x7fa93c0e1359 in __interceptor_malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
+ #1 0x7fa93c6eca76 (/usr/lib/libtalloc.so.2+0x4a76) (BuildId: e0a2f614bd7ebca36cf8a6c88cb544b680fd17dd)
+
+SUMMARY: AddressSanitizer: 288 byte(s) leaked in 3 allocation(s).
--- expout 2023-10-17 16:22:21.289194482 +0200
+++ /build/new/tmpdir/libosmo-netif/tests/testsuite.dir/at-groups/1/stdout 2023-10-17 16:22:22.165868993 +0200
@@ -173,17 +173,4 @@
{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): msg buff data: 04 01 01
{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): IPA payload: 04 01 01
{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): Type: IPAC_MSGT_ID_GET
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): (msg dump (including stripped headers): 00 03 fe 04 01 01 )
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): [6-cli] Received message from stream (len = 1)
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): msg buff data: 01
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): IPA payload: 01
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): Type: IPAC_MSGT_PONG
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): (msg dump (including stripped headers): 00 01 fe 01 )
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): [7-cli] Received message from stream (len = 1)
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): msg buff data: 01
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): IPA payload: 01
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): Type: IPAC_MSGT_PONG
-{20.625033} [OK] Client's test_segm_ipa_stream_cli_cli_read_cb(): (msg dump (including stripped headers): 00 01 fe 01 )
-==================================Test test_segm_ipa_stream_cli complete========================================
-
-Stream tests completed
+{20.625033} [OK] Cl
\ No newline at end of file
/git/libosmo-netif/tests/testsuite.at:8: exit code was 1, expected 0
1. testsuite.at:4: 1. stream_test (testsuite.at:4): FAILED (testsuite.at:8)
</pre>
<p>Building with flags:<br /><pre>
opt_enable="--enable-sanitize"
export DISTCHECK_CONFIGURE_FLAGS="$opt_enable"
export CPPFLAGS="-ggdb3 -Og -fno-omit-frame-pointer" #-Wsign-compare -Werror=old-style-definition
export CFLAGS="-ggdb3 -Og -fno-omit-frame-pointer" #-Werror=old-style-definition
export CXXFLAGS="-ggdb3 -Og -fno-omit-frame-pointer"
opt_enable="$opt_enable --disable-doxygen --enable-werror"
</pre></p> Cellular Network Infrastructure - Bug #6214 (Closed): osmo-gsm-tester_virtual regression: Some MS...https://osmocom.org/issues/62142023-10-09T09:58:29Zpespin
<p>Since 27th September 2023 22:48h, osmo-gsm-tester_virtual's massive registration test is failing due to some MS failing to register: <a class="external" href="https://jenkins.osmocom.org/jenkins/job/osmo-gsm-tester_virtual/">https://jenkins.osmocom.org/jenkins/job/osmo-gsm-tester_virtual/</a></p>
<p>We expect >=99% of MS to register, but we get 97%.<br />we need to find out if it's due to some change in CNI or in osmocom-bb.<br />Some hints after looking at log files below.</p>
<p>osmo-bsc:<br /><pre>
Timeout of T3101
</pre><br />This seems to be cancelling the LU. T3101 is "RR Immediate Assignment (default: 3 s)".</p>
<p>osmo-bts:<br /><pre>
"DRSL ERROR Early IA check: unknown chan_nr=0x04 (rsl.c:382)
</pre></p>
<p>osmocom-bb:<br /><pre>
"follow-on proceed not supported. (gsm48_mm.c:2714)
</pre><br /><pre>
Event EVENT_REG_SUCCESS unhandled in state A2 on PLMN. (gsm322.c:3783)
</pre></p>
<p>My bet is there's a regression in any of your osmocom-bb patches in 975351e2508683c7c7b18958b8248cd157400fb0..d95c8f4fa693c4e34bbbdde171fe1ba096e23825</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6205 (Resolved): osmo-epdg.git: Move it to ...https://osmocom.org/issues/62052023-10-04T15:45:16Zpespin
<p><a class="external" href="https://gitea.osmocom.org/acouzens/osmo-epdg">https://gitea.osmocom.org/acouzens/osmo-epdg</a></p>
<ul>
<li>Move it to standard prefix in gitea</li>
<li>Make it available in gerrit</li>
</ul>
<p>I also saw <a class="external" href="https://gitea.osmocom.org/ims-volte-vowifi/strongswan">https://gitea.osmocom.org/ims-volte-vowifi/strongswan</a> , do we need to use it? do we want to have changes there?</p>
<p>Assigning to <a class="user active" href="https://osmocom.org/users/1741">lynxis</a> for feedback. The gerrit repo probably needs to be created by <a class="user active" href="https://osmocom.org/users/7">laforge</a> ?</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6204 (Resolved): Create TTCN-3 testsuit...https://osmocom.org/issues/62042023-10-04T15:42:23Zpespin
<p>Test osmo-epdg using a TTCN3-3 testsuite, similarly to what we do for instal with osmo_dia2gsup (osmo-ttcn3-hacks.git/dia2gsup/, docker-playground.git/ttcn3-dia2gsup-test).</p>
<ul>
<li>Add osmo-ttcn3-hacks.git/epdg/</li>
<li>Add docker-playground.git/osmo-epdg-master/</li>
<li>Add docker-playground.git/ttcn3-epdg-test/</li>
<li>Run it nightly in jenkins.</li>
</ul>
Interfaces to test against it:
<ul>
<li>GSUP (CEAI)</li>
<li>SWx (Diameter)</li>
<li>S6b (Diameter)</li>
<li>S2b (GTPv2C)</li>
<li>Test sending some user data over the GTP tunnel being created (reuse osmo-uecups or similar from ttcn3-pgw-test?)<br />See <a class="external" href="https://osmocom.org/projects/osmo-epdg/wiki/EPDG_implementation_plan">https://osmocom.org/projects/osmo-epdg/wiki/EPDG_implementation_plan</a></li>
</ul> OsmoPCU - Bug #6191 (Resolved): osmo-pcu from OBS latest feeds transmits Dummy blocks a few more ...https://osmocom.org/issues/61912023-09-26T17:57:14Zpespin
<p>After new release 1.3.0/1.3.1, it was spotted that the following tests pass in ttcn3-pcu-test (nightly) but not in ttcn3-pcu-test-latest (running1.3.1).</p>
<pre>
TC_n3105_max_t3195
TC_pcuif_suspend_active_tbf
TC_pdch_energy_saving
TC_ta_ptcch_idle
TC_ul_tbf_reestablish_with_pkt_resource_req_t3168
</pre>
<p>I can reproduce this locally using the docker setup with TC_n3105_max_t3195. Using default IMAGE_SUFFIX=master, the test passes. However, using IMAGE_SUFFIX=latest, the test fails.</p>
<p>This is strange since current master has no real big changes over latest release 1.3.1, only a commit modifying a bit a log message.<br />In fact, I tried running with IMAGE_SUFFIX=master and OSMO_PCU_BRANCH pointing to commit in 1.3.1, and then it passes too. So that means it has something to do with how osmo-pcu binary in the OBS package was built.</p>
<p>I attach a successful pcap and a failing pcap as reference.</p>
<p>Among other thing, the test expects that after T_3195 times out it should receive an empty dl data block from the PCU because there's no more TBFs active in that TS. This seems to work as expected when running against master or 1.3.1 compiled by the docket container, as seen in the good pcap. After the last DUMMY dl block is sent, one can see how the MS and TBF is freed and hence no more DUMMY dl blocks are sent.</p>
<p>However, when running against the package from OBS ("latest"), one can see that after the TBF and MS is freed, the PCU still submits DUMMY DL DATA blocks for a few (3-4) more FN rounds, which is wrong.</p>
<p>The following patch was submitted in the ttcn3 test to more clearly show the problem: <br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34536">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34536</a> pcu: Fail immediately in TC_n3105_max_t3195</p>
<p>So all in all, it looks like:<br />1- Bug in the compiler used in OBS<br />2- Some bug of ours only appeareing when compiled against specific compile flags or compiler version</p>
<p>The logic on whether to submit a DL Dummy block or an empty one, is done in osmo-pcu at gprs_rlcmac_rcv_rts_block():<br /><pre>
/* Prio 3: send dummy control message if need to poll or USF */
else {
/* If there's no TBF attached to this PDCH, we can submit an empty
* data_req since there's nothing to transmit nor to poll/USF. This
* way we help BTS energy saving (on TRX!=C0) by sending nothing
* instead of a dummy block. The early return is done here and
* not at the start of the function because the condition below
* (num_tbfs==0) may not be enough, because temporary dummy TBFs
* created to send Imm Ass Rej (see handle_tbf_reject()) don't
* have a TFI assigned and hence are not attached to the PDCH
* TS, so they don't show up in the count below.
*/
const unsigned num_tbfs = pdch->num_tbfs(GPRS_RLCMAC_DL_TBF)
+ pdch->num_tbfs(GPRS_RLCMAC_UL_TBF);
bool skip_idle = (num_tbfs == 0);
#ifdef ENABLE_DIRECT_PHY
/* In DIRECT_PHY mode we want to always submit something to L1 in
* TRX0, since BTS is not preparing dummy bursts on idle TS for us */
skip_idle = skip_idle && trx != 0;
#endif
if (!skip_idle && (msg = sched_dummy())) {
/* increase counter */
gsmtap_cat = PCU_GSMTAP_C_DL_DUMMY;
} else {
msg = NULL; /* submit empty frame */
}
}
</pre></p>
<p>In theory ENABLE_DIRECT_PHY should not be enabled in the OBS build, so in summary, the dummy message should only be generated based on:<br /><pre>
const unsigned num_tbfs = pdch->num_tbfs(GPRS_RLCMAC_DL_TBF)
+ pdch->num_tbfs(GPRS_RLCMAC_UL_TBF);
bool skip_idle = (num_tbfs == 0);
if (!skip_idle)
msg = sched_dummy()
</pre></p> OsmoBSC - Bug #6189 (Resolved): SCCPLite: Support mgw pool featurehttps://osmocom.org/issues/61892023-09-22T15:31:40Zpespin
<p>Right now the mgw pool feature (with more than 1 configured/ready MGW) only works with AoIP.</p>
<p>The expalantion can be found in this commit description:<br /><a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-bsc/commit/da4af65a51ee8b8d7b380330c0301de293347563">https://gitea.osmocom.org/cellular-infrastructure/osmo-bsc/commit/da4af65a51ee8b8d7b380330c0301de293347563</a></p>
<p>The failing scenario described there can be found by running TTCN3 test BSC_Tests.TC_mgwpool_all_used in the ttcn3-bsc-test-sccplite testsuite.<br />The first call properly does everything through first MGW (port 2427). The second call starts properly using second MGW (port 2428) to set up the BTS-side connection, but then, when the MSC sends the IPA-encapsulated MGCP to osmo-bsc, it forwards it to the first MGW (port 2427), which is wrong, since it should be forwarded to the second MGW.</p>
So in summary, what happens:
<ol>
<li>BSC <- MSC: AssignmentRequest(CIC=1) // This CIC indicated by the MSC to the BSC the MGW endpoint to use, which means its unique per MSC</li>
<li>(BSC selects an MGW from the pool, sets up the BTS-side conn on MGW endpoint=CIC=1)</li>
<li>BSC -> MSC: ASsignmentCompelte</li>
<li>BSC <-> MSC: <abbr title="MGCP(CRCX 1@mgw">IPA</abbr></li>
<li>BSC should be able to remember CIC=1 from that MSC links to a specific MGW it selected previously, and submit the MGCP to it.</li>
</ol>
<p>I attacha sample run of BSC_Tests.TC_mgwpool_all_used to show the problem.</p> Core testing infrastructure - Feature #6187 (Resolved): Update titan.core to 9.0.0 in osmocom rep...https://osmocom.org/issues/61872023-09-21T15:00:53Zpespin
<p>AFAIK we now ship titan 8.3.0, bit 9.0.0 is already available upstream with several bug fixes.</p>
<p>We may want to update it to 9.0.0.</p> Core testing infrastructure - Bug #6185 (New): Submit titan.ProtocolEmulations.SCCP patch upstreamhttps://osmocom.org/issues/61852023-09-20T11:38:25Zpespin
<p>It was noticed that we currently hold & use in osmo-ttcn3-hacks our own fork of titan.ProtocolEmulations.SCCP.git [1].</p>
<p>We use our own fork because we are using an extra patch on top of master [2]. AFAICT, that patch has never been submitted upstream, but at first glance it looks like it should?</p>
<p>The upstream to submit to is in gitlab [3].</p>
<p>[1] <a class="external" href="https://github.com/osmocom/titan.ProtocolEmulations.SCCP">https://github.com/osmocom/titan.ProtocolEmulations.SCCP</a><br />[2] <a class="external" href="https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc6620a0df11d0d98c897fb66168276b16">https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc6620a0df11d0d98c897fb66168276b16</a><br />[3] <a class="external" href="https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolEmulations.SCCP">https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolEmulations.SCCP</a></p> Osmocom Libraries - Bug #6157 (Resolved): libusrp fails to build on Archlinux masterhttps://osmocom.org/issues/61572023-08-29T10:31:37Zpespin
<p>Since recent Archlinux updates, libusrp is still not building here, even if building with "make -j1". Find output below:<br /><pre>
make[4]: Leaving directory '/build/new/tmpdir/libusrp/doc'
make[3]: Leaving directory '/build/new/tmpdir/libusrp/doc'
make[2]: Leaving directory '/build/new/tmpdir/libusrp/doc'
Making all in firmware
make[2]: Entering directory '/build/new/tmpdir/libusrp/firmware'
Making all in include
make[3]: Entering directory '/build/new/tmpdir/libusrp/firmware/include'
PYTHONPATH=/git/libusrp/usrp/firmware/include /git/libusrp/firmware/include/generate_regs.py /git/libusrp/firmware/include/fpga_regs_common.h fpga_regs_common.v
PYTHONPATH=/git/libusrp/usrp/firmware/include /git/libusrp/firmware/include/generate_regs.py /git/libusrp/firmware/include/fpga_regs_standard.h fpga_regs_standard.v
make[3]: Leaving directory '/build/new/tmpdir/libusrp/firmware/include'
Making all in lib
make[3]: Entering directory '/build/new/tmpdir/libusrp/firmware/lib'
sdcc -mmcs51 --no-xinit-opt -I/git/libusrp/firmware/include -c /git/libusrp/firmware/lib/delay.c -o delay.rel
sdcc -mmcs51 --no-xinit-opt -I/git/libusrp/firmware/include -c /git/libusrp/firmware/lib/fx2utils.c -o fx2utils.rel
/git/libusrp/firmware/include/fx2regs.h:324: syntax error: token -> '+' ; column 26
make[3]: *** [Makefile:534: fx2utils.rel] Error 1
make[3]: Leaving directory '/build/new/tmpdir/libusrp/firmware/lib'
make[2]: *** [Makefile:406: all-recursive] Error 1
make[2]: Leaving directory '/build/new/tmpdir/libusrp/firmware'
make[1]: *** [Makefile:638: all-recursive] Error 1
make[1]: Leaving directory '/build/new/tmpdir/libusrp'
make: *** [Makefile:557: all] Error 2
</pre></p> OsmoDia2GSUP - Bug #6155 (Feedback): osmo_dia2gsup not setting Origin-State-Id Diameter AVP durin...https://osmocom.org/issues/61552023-08-28T17:20:03Zpespin
<p>The AVP is optional but it's nice to have in order to notify peers that the process was restarted.</p>
<p>See rfc6733.</p>