Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-12-13T11:23:35ZOpen Source Mobile Communications
Redmine libosmo-ranap - Bug #6307 (Resolved): iu_client rejects SCCP CR without datahttps://osmocom.org/issues/63072023-12-13T11:23:35Zdaniel
<p>Since <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Respect size limit of 130 data bytes in SCCP CR (Resolved)" href="https://osmocom.org/issues/5579">#5579</a> the limit of 130 bytes in CR/CC/RLSD messages is enforced.<br />For osmo-hnbgw this means that if a larger InitialUE-Message must be forwarded an empty CR is sent and the Message is send after the CC in a separate DT1 message. Unfortunately in iu_client.c:832 we reject a CR without any userdata.</p> Cellular Network Infrastructure - Bug #6143 (Resolved): liburing-dev is not available in Debian 10https://osmocom.org/issues/61432023-08-23T16:34:23Zdaniel
<p>This currently breaks Gerrit verification here:<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/32536">https://gerrit.osmocom.org/c/libosmocore/+/32536</a></p>
We could:
<ul>
<li>add liburing-dev from buster-backports <a class="external" href="https://packages.debian.org/search?suite=buster-backports&searchon=names&keywords=liburing-dev">https://packages.debian.org/search?suite=buster-backports&searchon=names&keywords=liburing-dev</a></li>
<li>add liburing-dev as a package in our (Debian 10) OBS repo</li>
<li>build libosmocore on Debian 10 with --disable-uring and remove the requirement there</li>
</ul> libosmo-netif - Bug #5931 (New): heap-use-after-free when osmo_stream_srv_destroy() is called ins...https://osmocom.org/issues/59312023-03-02T11:03:22Zdaniel
<p>This can happen in the ipa-stream-server example if the client disconnects unexpectedly (i.e. if there is still data the server wants to send).</p>
<pre>
<0003> stream.c:1542 message received
<0000> ipa-stream-server.c:53 received message from stream
<0003> stream.c:1864 connection closed with client
<0000> ipa-stream-server.c:61 cannot receive message
=================================================================
==2103936==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000000d58 at pc 0x7f2196d84d24 bp 0x7ffe1b9f4330 sp 0x7ffe1b9f4328
READ of size 8 at 0x611000000d58 thread T0
#0 0x7f2196d84d23 in llist_empty /home/daniel/local/osmo-master/include/osmocom/core/linuxlist.h:171
#1 0x7f2196d84d23 in osmo_stream_srv_write /home/daniel/scm/osmo/libosmo-netif/src/stream.c:1563
#2 0x7f2196d859f7 in osmo_stream_srv_cb /home/daniel/scm/osmo/libosmo-netif/src/stream.c:1629
#3 0x7f219658cbfd in poll_disp_fds /home/daniel/scm/osmo/libosmocore/src/core/select.c:361
#4 0x7f219658ccfd in _osmo_select_main /home/daniel/scm/osmo/libosmocore/src/core/select.c:399
#5 0x7f219658cda6 in osmo_select_main /home/daniel/scm/osmo/libosmocore/src/core/select.c:438
#6 0x5584fc1c390c in main /home/daniel/scm/osmo/libosmo-netif/examples/ipa-stream-server.c:130
#7 0x7f2195a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x7f2195a46244 in __libc_start_main_impl ../csu/libc-start.c:381
#9 0x5584fc1c3240 in _start (/home/daniel/scm/osmo/libosmo-netif/examples/.libs/ipa-stream-server+0x2240)
0x611000000d58 is located 152 bytes inside of 200-byte region [0x611000000cc0,0x611000000d88)
freed by thread T0 here:
#0 0x7f2196eb76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7f21974fa5b1 (/lib/x86_64-linux-gnu/libtalloc.so.2+0x45b1)
#2 0x5584fc1c34c7 in read_cb /home/daniel/scm/osmo/libosmo-netif/examples/ipa-stream-server.c:62
#3 0x7f2196d78877 in osmo_stream_srv_read /home/daniel/scm/osmo/libosmo-netif/src/stream.c:1550
#4 0x7f2196d859df in osmo_stream_srv_cb /home/daniel/scm/osmo/libosmo-netif/src/stream.c:1627
#5 0x7f219658cbfd in poll_disp_fds /home/daniel/scm/osmo/libosmocore/src/core/select.c:361
#6 0x7f219658ccfd in _osmo_select_main /home/daniel/scm/osmo/libosmocore/src/core/select.c:399
#7 0x7f219658cda6 in osmo_select_main /home/daniel/scm/osmo/libosmocore/src/core/select.c:438
#8 0x5584fc1c390c in main /home/daniel/scm/osmo/libosmo-netif/examples/ipa-stream-server.c:130
#9 0x7f2195a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
#0 0x7f2196eb89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7f21974fbe3d (/lib/x86_64-linux-gnu/libtalloc.so.2+0x5e3d)
SUMMARY: AddressSanitizer: heap-use-after-free /home/daniel/local/osmo-master/include/osmocom/core/linuxlist.h:171 in llist_empty
</pre>
<p>osmo_stream_srv_destroy() frees the complete conn but osmo_stream_srv_cb() could still call osmo_stream_srv_write(conn) after osmo_stream_srv_read() (and by extension the read_cb()) returns.</p>
<p>We need to guard this and delay actually freeing the conn if we are currently in a callback.</p> Core testing infrastructure - Bug #5928 (Resolved): [ttcn3 docker tests]: Wait for docker contain...https://osmocom.org/issues/59282023-02-28T16:22:34Zdaniel
<p>We had a test failure where<br />docker container kill jenkins-ttcn3-hnbgw-test-latest-245-stp<br />failed to actually stop before the jenkins script tries to execute the container again:</p>
<p>See <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/245/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/245/console</a></p>
<pre>
Tue 28 Feb 2023 04:55:23 PM - osmith: I'd also have expected the kill command to wait until the container is killed
Tue 28 Feb 2023 04:59:27 PM - dwillmann: Well, it lets you do "docker container kill -s HUP name" so I think it's just a fancy frontend for kill
Tue 28 Feb 2023 05:07:03 PM - hwelte: I also thought kill is like stop waiting for the container to terminate, but I guess we all had wrong expectations
Tue 28 Feb 2023 05:07:27 PM - hwelte: we can do 'docker stop -t 1' to avoid waiting 10s
Tue 28 Feb 2023 05:13:04 PM - hwelte: there's also 'docker wait'
Tue 28 Feb 2023 05:13:37 PM - hwelte: I guess that should certainly make sure the container is gone
Tue 28 Feb 2023 05:14:04 PM - hwelte: can even wait for multiple containers in one call
Tue 28 Feb 2023 05:14:54 PM - hwelte: so something like kill+wait (if that differs at all from stop)
Tue 28 Feb 2023 05:15:45 PM - dwillmann: Stop does a graceful shutdown and kill if that times out (without waiting for the kill I assume)
</pre>
<p>So the best solution will probably to add a docker container wait <containers> to wait for all killed containers to actually be gone before starting those again.<br />This probably only applies to the builds that run the same tests multiple times with different configurations, but shouldn't matter to implement it for all.</p> OsmoDia2GSUP - Bug #5657 (Feedback): dia2gsup not (re-)connecting to HLR if osmo-hlr is downhttps://osmocom.org/issues/56572022-08-22T15:42:57Zdaniel
<p>It seems sometimes osmo_dia2gsup doesn't manage to connect to osmo-hlr:</p>
<pre>
root@sysmonitb:~# systemctl status osmo_dia2gsup
● osmo_dia2gsup.service - Osmocom DIAMETER to GSUP translator
Loaded: loaded (/lib/systemd/system/osmo_dia2gsup.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-08-22 14:57:42 UTC; 39min ago
Main PID: 254 (beam.smp)
Tasks: 23 (limit: 4642)
Memory: 55.7M
CPU: 4.710s
CGroup: /system.slice/osmo_dia2gsup.service
├─254 /usr/bin/osmo-dia2gsup -B -- -root /usr/lib/erlang -progname erl -- -home /var/lib/osmo_dia2gsup -- -boot no_dot_erlang -noshell -escript main osmo_dia2gsup -pz osm>
├─271 erl_child_setup 1024
├─454 inet_gethost 4
└─455 inet_gethost 4
Aug 22 14:57:42 sysmonitb systemd[1]: Starting Osmocom DIAMETER to GSUP translator...
Aug 22 14:57:42 sysmonitb systemd[1]: Started Osmocom DIAMETER to GSUP translator.
Aug 22 14:57:47 sysmonitb osmo-dia2gsup[254]: *DBG* ss7_routes got call flush_routes from <0.132.0>
Aug 22 14:57:47 sysmonitb osmo-dia2gsup[254]: *DBG* ss7_routes sent ok to <0.132.0>, new state {sr_state,ss7_routes}
Aug 22 14:57:48 sysmonitb osmo-dia2gsup[254]: 14:57:48.180 [info] Diameter HSS Application started on IP 127.0.0.8, sctp port 3868
Aug 22 14:57:48 sysmonitb osmo-dia2gsup[254]: 14:57:48.239 [info] Connecting to GSUP HLR on IP 127.0.0.1 port 4222
root@sysmonitb:~# systemctl status osmo-hlr
● osmo-hlr.service - Osmocom Home Location Register (OsmoHLR)
Loaded: loaded (/lib/systemd/system/osmo-hlr.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-08-22 15:02:28 UTC; 34min ago
Docs: https://osmocom.org/projects/osmo-hlr/wiki/OsmoHLR
Main PID: 532 (osmo-hlr)
Tasks: 1 (limit: 4642)
Memory: 5.1M
CPU: 176ms
CGroup: /system.slice/osmo-hlr.service
└─532 /usr/bin/osmo-hlr -c /etc/osmocom/osmo-hlr.cfg -l /var/lib/osmocom/hlr.db
Aug 22 15:02:28 sysmonitb systemd[1]: Started Osmocom Home Location Register (OsmoHLR).
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229034 DMAIN NOTICE hlr starting (hlr.c:791)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229034 DDB NOTICE using database: /var/lib/osmocom/hlr.db (db.c:558)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229053 DDB NOTICE Missing database tables detected; Bootstrapping database '/var/lib/osmocom/hlr.db' (db.c:626)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229097 DDB NOTICE Database '/var/lib/osmocom/hlr.db' has HLR DB schema version 6 (db.c:636)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229102 DLGLOBAL NOTICE Available via telnet 127.0.0.1 4258 (telnet_interface.c:100)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229102 DLCTRL NOTICE CTRL at 127.0.0.1 4259 (control_if.c:1013)
</pre>
<p>You can see that the hlr has been started after dia2gsup was already running.</p>
<p>After restarting dia2gsup manually the connection succeeds:<br /><pre>
root@sysmonitb:~# systemctl restart osmo_dia2gsup
root@sysmonitb:~# systemctl status osmo_dia2gsup
● osmo_dia2gsup.service - Osmocom DIAMETER to GSUP translator
Loaded: loaded (/lib/systemd/system/osmo_dia2gsup.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-08-22 15:37:21 UTC; 3s ago
Process: 4301 ExecStartPre=/usr/bin/mkdir -p /var/lib/osmo_dia2gsup (code=exited, status=0/SUCCESS)
Main PID: 4302 (beam.smp)
Tasks: 23 (limit: 4642)
Memory: 36.1M
CPU: 4.608s
CGroup: /system.slice/osmo_dia2gsup.service
├─4302 /usr/bin/osmo-dia2gsup -B -- -root /usr/lib/erlang -progname erl -- -home /var/lib/osmo_dia2gsup -- -boot no_dot_erlang -noshell -escript main osmo_dia2gsup -pz os>
├─4309 erl_child_setup 1024
├─4330 inet_gethost 4
└─4331 inet_gethost 4
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: "00:00:00:00:00:00",
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: "00:00:00:00:00:00",
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: "HSS-00-00-00-00-00-00",false}
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: 15:37:24.947 [info] connected!
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Registering handler {process_id,<0.147.0>} for socket #Port<0.7> Stream {osmo,
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: 5}
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Unblocking socket #Port<0.7>
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Unblocking socket #Port<0.7>:ok
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Stream 254, 17 bytes
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Socket #Port<0.7> Stream 254: ID_GET -> ID_RESP
Aug 22 15:37:50 sysmonitb osmo-dia2gsup[4302]: 15:37:50.392 [info] Peer up <0.146.0> - #diameter_caps{origin_host={"hss.localdomain","mme.localdomain"},origin_realm={"localdomain","lo>
</pre></p> OsmoDia2GSUP - Bug #5651 (Closed): contrib/generate_build_dep.sh does not work if erlang versions...https://osmocom.org/issues/56512022-08-19T16:00:55Zdaniel
<p>I tried uploading a custom osmo-dia2gsup package from my laptop to obs, but when obs uses the beam files from the build_dep.tar.gz it aborts with an error saying the versions don't match.</p>
<p>So while the current solution seems to work with the jenkins obs job maybe we should find some more robust was to download the dependencies.</p> Core testing infrastructure - Bug #5642 (Resolved): (Jenkins) Collect artifacts on master build f...https://osmocom.org/issues/56422022-08-09T13:02:59Zdaniel
<p>Today we had an issue where a master-libosmocore job failed with a segfault:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-libosmocore/2898/a2=default,a3=default,a4=default,arch=amd64,label=osmocom-master-debian9/consoleFull">https://jenkins.osmocom.org/jenkins/view/master/job/master-libosmocore/2898/a2=default,a3=default,a4=default,arch=amd64,label=osmocom-master-debian9/consoleFull</a></p>
<pre>
ERROR: files left in build directory after distclean:
./tests/core
make[1]: Leaving directory '/build/libosmocore-1.7.0.26-862dd/_build/sub'
make[1]: *** [Makefile:1010: distcleancheck] Error 1
make: *** [Makefile:941: distcheck] Error 1
</pre>
<p>It would be nice to archive some artifacts in case of build failures. Especially core files that may exist, but probably also the (auto)test logs.</p> osmo-gbproxy - Bug #5332 (Resolved): Missing BVCI in FLUSH_LL_ACK can cause segfaulthttps://osmocom.org/issues/53322021-11-25T17:13:00Zdaniel
<p>The BVCI IE is listed as conditional and is only included if the flush action indicates that LLC-PDUs are transferred. (3GPP TS 48.018 Ch. 10.4.2).</p>
<p>The code in gbprox_rx_sig_from_bss unconditionally tries to get a BVCI from a FLUSH_LL message which could result in a segfault if no such IE is included.</p> libosmocore - Bug #5277 (New): ns2: Allow SNS-CONFIG PDUs from unknown endpoints during config pr...https://osmocom.org/issues/52772021-10-22T14:28:37Zdaniel
<p>Currently the SNS code expects SNS-CONFIG to happen between the primary EPs configured in the VTY.</p>
<p>NS2 with the following configuration<br /><pre>
ns
bind udp sgsn
listen 10.0.0.2 2157
nse 1
ip-sns-remote 10.0.0.1 2157
ip-sns-bind sgsn
</pre><br />would only handle SNS-CONFIG PDUs from the SGSN that originate from 10.0.0.1:2157</p>
<p>However, 3GPP TS 48.016 Ch. 6.2.5 states:</p>
<blockquote>
<p>After completion on the BSS side of the Size procedure having indicated a reset, the BSS NSE shall send an SNS-CONFIG PDU to the same pre-configured SGSN IP endpoint used in the Size procedure.</p>
<p>NOTE: This does not imply that the SNS-CONFIG PDU has to be sent from the same IP endpoint used in the Size procedure</p>
</blockquote>
<p>This also seems to apply to the SNS-CONFIG PDU sent from the SGSN to the BSS because some SGSNs send the SNS-CONFIG PDU alreads from the EP that is specified in that same PDU.<br />So it seems we need to relax our requirements and accept SNS-CONFIG PDUs from any source address as long as there exists an NSE with the NSEI specified in that PDU (on the bind that received the message).</p> osmo-remsim - Bug #5216 (Resolved): Events request-sim-local / request-card-remove are never senthttps://osmocom.org/issues/52162021-08-24T16:56:18Zdaniel
<p>Using osmo-remsim-{server,bankd} version 0.2.2.112-694e<br />osmo-remsim-client version 0.3.0</p>
<p>If I create a mapping osmo-remsim-client switches to the remote SIM and resets the modem<br /><pre>
$ ./contrib/remsim-apitool.py -m 1 0 1 1
$ ./contrib/remsim-apitool.py -a
/clients: {'clients': [{'peer': 'C1:1', 'state': 'CONNECTED_CLIENT', 'component_id': {'type_': 'remsimClient', 'name': 'client', 'software': 'remsim-client', 'swVersion': '0.3.0'}}]}
/banks: {'banks': [{'peer': 'B1', 'state': 'CONNECTED_BANKD', 'component_id': {'type_': 'remsimBankd', 'name': 'fixme-name', 'software': 'remsim-bankd', 'swVersion': '0.2.2.112-694e'}, 'bankId': 1, 'numberOfSlots': 1}]}
/slotmaps: {'slotmaps': [{'bank': {'bankId': 1, 'slotNr': 0}, 'client': {'clientId': 1, 'slotNr': 1}, 'state': 'ACTIVE'}]}
</pre></p>
<p>Events sent by remsim-client: request-card-insert, request-sim-remote and finally request-modem-reset</p>
<p>AT+CIMI now reports the remote IMSI. If I then remove the mapping again I would expect the reverse events to be sent (card-remove, sim-local) followed by request-modem-reset</p>
<blockquote>
<p>$ ./contrib/remsim-apitool.py -d 1 0</p>
</blockquote>
<p>remsim-client:<br /><pre>
<0000> ../rspro_client_fsm.c:165 RSPRO_CLIENT(server)[0xb6e10ea0]{CONNECTED}: Received RSPRO [L1]> 00 20 ee 07 [L2]> 30 1d 80 01 02 81 01 00 a2 15 b1 13 30 06 02 01 01 02 01 00 30 09 80 04 00 00 00 00 02 01 00
<0000> remsim_client.c:118 CLIENT_MAIN(main)[0xb6e10cc0]{OPERATIONAL}: Received Event MF_E_SRVC_CONFIG_BANK
<0000> main_fsm.c:236 CLIENT_MAIN(main)[0xb6e10cc0]{OPERATIONAL}: state_chg to UNCONFIGURED
<0000> main_fsm.c:158 RSPRO_CLIENT(bankd)[0xb6f9d040]{CONNECTED}: Received Event SRVC_E_DISCONNECT
<0000> ../rspro_client_fsm.c:359 RSPRO_CLIENT(bankd)[0xb6f9d040]{CONNECTED}: Received Event SRVC_E_KA_TERMINATED
<0000> ../rspro_client_fsm.c:359 RSPRO_CLIENT(bankd)[0xb6f9d040]{CONNECTED}: Event SRVC_E_KA_TERMINATED not permitted
<0000> ../rspro_client_fsm.c:363 RSPRO_CLIENT(bankd)[0xb6f9d040]{CONNECTED}: Destroying existing connection to server
<0000> ../rspro_client_fsm.c:279 CLIENT_MAIN(main)[0xb6e10cc0]{UNCONFIGURED}: Received Event MF_E_BANKD_LOST
<0000> ../rspro_client_fsm.c:279 CLIENT_MAIN(main)[0xb6e10cc0]{UNCONFIGURED}: Event MF_E_BANKD_LOST not permitted
<0000> ../rspro_client_fsm.c:368 RSPRO_CLIENT(bankd)[0xb6f9d040]{CONNECTED}: state_chg to INIT
<0000> ../rspro_client_fsm.c:93 RSPRO_CLIENT(server)[0xb6e10ea0]{CONNECTED}: Received Event SRVC_E_RSPRO_TX
<0000> ../rspro_client_fsm.c:82 RSPRO_CLIENT(server)[0xb6e10ea0]{CONNECTED}: Tx RSPRO configClientBankRes
<0000> user_simtrace2.c:114 CLIENT_MAIN(main)[0xb6e10cc0]{UNCONFIGURED}: Received Event MF_E_MDM_TPDU
<0000> user_simtrace2.c:114 CLIENT_MAIN(main)[0xb6e10cc0]{UNCONFIGURED}: Event MF_E_MDM_TPDU not permitted
</pre></p>
<p>Even if my expectation when removing the mapping is incorrect - those events are not even in the code:</p>
<pre>
$ git grep call_script
src/client/main_fsm.c:static int call_script(struct bankd_client *bc, const char *cause)
src/client/main_fsm.c: call_script(bc, "event-server-connect");
src/client/main_fsm.c: call_script(bc, "event-bankd-connect");
src/client/main_fsm.c: call_script(bc, "request-card-insert");
src/client/main_fsm.c: call_script(bc, "request-sim-remote");
src/client/main_fsm.c: call_script(bc, "request-modem-reset");
src/client/main_fsm.c: call_script(bc, "event-config-bankd");
src/client/main_fsm.c: call_script(bc, "event-modem-status");
</pre>
<p>There should be a way to switch a modem back to local sim.</p> osmo-gbproxy - Bug #5200 (Resolved): CTRL command nsvc-state causes memory corruptionhttps://osmocom.org/issues/52002021-07-19T12:06:34Zdaniel
<p>ASan crashes with heap-use-after-free /home/daniel/scm/osmo/libosmocore/src/select.c:294 in poll_fill_fds</p>
<pre>
osmo_ctrl.py -d localhost -p 4263 -g nsvc-state
</pre>
<pre>
Breakpoint 1, __asan::ReportGenericError (pc=140737325940093, bp=bp@entry=140737488346384, sp=sp@entry=140737488346376,
addr=106652627902132, is_write=is_write@entry=false, access_size=access_size@entry=4, exp=0, fatal=true)
at ../../../../src/libsanitizer/asan/asan_report.cpp:458
458 ../../../../src/libsanitizer/asan/asan_report.cpp: No such file or directory.
(gdb) bt
#0 __asan::ReportGenericError (pc=140737325940093, bp=bp@entry=140737488346384, sp=sp@entry=140737488346376, addr=106652627902132,
is_write=is_write@entry=false, access_size=access_size@entry=4, exp=0, fatal=true)
at ../../../../src/libsanitizer/asan/asan_report.cpp:458
#1 0x00007ffff764b8a8 in __asan::__asan_report_load4 (addr=<optimized out>) at ../../../../src/libsanitizer/asan/asan_rtl.cpp:119
#2 0x00007ffff651bd7d in poll_fill_fds () at select.c:294
#3 0x00007ffff651e9b4 in _osmo_select_main (polling=polling@entry=0) at select.c:377
#4 0x00007ffff651ead5 in osmo_select_main (polling=polling@entry=0) at select.c:432
#5 0x00005555555b299e in main (argc=3, argv=0x7fffffffdec8) at gb_proxy_main.c:362
(gdb)
</pre>
<p>So somehow the list of fds gets corrupted</p> osmo-gbproxy - Bug #5040 (Rejected): Block all BSS-NSVC if no SGSNs are availablehttps://osmocom.org/issues/50402021-02-23T11:00:32Zdaniel
<p>When the last SGSN becomes unavailable we should NS-BLOCK all BSS NSVCs.<br />At that point we can also free all BVCs/cells since the BSS needs to BVC-RESET after NS-UNBLOCK.</p>
<p>As soon as an SGSN is available again we need to unblock the BSS-NSVCs</p> libosmocore - Bug #4977 (Resolved): NS2: adding and removing a listen to/from a bind crashes osmo...https://osmocom.org/issues/49772021-01-26T14:35:00Zdaniel
<pre>
$ telnet localhost 4246
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Welcome to the OsmoGbProxy VTY interface
Copyright (C) 2010 Harald Welte and On-Waves
License AGPLv3+: GNU AGPL version 3 or later <http://gnu.org/licenses/agpl-3.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
OsmoGbProxy> enable
OsmoGbProxy# configure terminal
OsmoGbProxy(config)# ns
OsmoGbProxy(config-ns)# bind udp foo
OsmoGbProxy(config-ns-bind)# listen 127.0.0.1 1234
OsmoGbProxy(config-ns-bind)# no listenConnection closed by foreign host.
~ took 28s
</pre>
<pre>
Assert failed bind->ll != GPRS_NS2_LL_UDP gprs_ns2_vty2.c:509
backtrace() returned 18 addresses
/home/daniel/local/osmo-master/lib/libosmocore.so.16(+0x13de6f) [0x7ff9092a2e6f]
/home/daniel/local/osmo-master/lib/libosmocore.so.16(osmo_generate_backtrace+0x18) [0x7ff9092a32e3]
/home/daniel/local/osmo-master/lib/libosmocore.so.16(+0x13dc16) [0x7ff9092a2c16]
/home/daniel/local/osmo-master/lib/libosmocore.so.16(osmo_set_panic_handler+0) [0x7ff9092a2d7b]
/home/daniel/local/osmo-master/lib/libosmogb.so.11(+0x2a7806) [0x7ff909826806]
/home/daniel/local/osmo-master/lib/libosmovty.so.4(+0x93d45) [0x7ff90949cd45]
/home/daniel/local/osmo-master/lib/libosmovty.so.4(cmd_execute_command+0xfd) [0x7ff9094a3486]
/home/daniel/local/osmo-master/lib/libosmovty.so.4(+0xa4157) [0x7ff9094ad157]
/home/daniel/local/osmo-master/lib/libosmovty.so.4(+0xa444e) [0x7ff9094ad44e]
/home/daniel/local/osmo-master/lib/libosmovty.so.4(vty_read+0x1092) [0x7ff9094b2f5a]
/home/daniel/local/osmo-master/lib/libosmovty.so.4(+0xb143a) [0x7ff9094ba43a]
/home/daniel/local/osmo-master/lib/libosmocore.so.16(+0xf8896) [0x7ff90925d896] /home/daniel/local/osmo-master/lib/libosmocore.so.16(+0xf8980) [0x7ff90925d980]
/home/daniel/local/osmo-master/lib/libosmocore.so.16(osmo_select_main+0xc) [0x7ff90925da05]
/home/daniel/scm/osmo/osmo-sgsn/src/gbproxy/osmo-gbproxy(+0x72077) [0x55c27637f077]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7ff90863ad0a]
/home/daniel/scm/osmo/osmo-sgsn/src/gbproxy/osmo-gbproxy(+0x599ba) [0x55c2763669ba]
signal 6 received
</pre> libosmocore - Bug #4974 (Resolved): gbproxy-ttcn3-test over framerelay are unstablehttps://osmocom.org/issues/49742021-01-25T09:31:15Zdaniel
<p>Even though it appears in gbproxy I think this is NS2-related.</p>
<p>Lots of tests started failing randomly around Job #92, see:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-gbproxy-test-fr/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-gbproxy-test-fr/test_results_analyzer/</a></p>
<p>The non-fr tests are quite stable so this has something to do with either NS2 or the ttcn3 implementation of NS over FR.</p>
<p>The failure is usually some timeout waiting for BSSGP on PCU side<br /><pre>
Timeout waiting for BSSGP on PCU side: { pDU_BSSGP_DL_UNITDATA := { bssgpPduType := '00'O, tLLI_current := 'C2180023'O, qoS_Profile := ?, pDU_Lifetime := ?, mS_Radio_Access_Capability := *, priority := *, dRX_Parameters := *, iMSI := { iEI := '0D'O ("\r"), ext := '1'B, lengthIndicator := ?, type_of_Identity := '001'B, oddevenIndicator := ?, digits := '262420000000000'H }, tLLI_old := *, pFI := *, lSA_Information := *, service_UTRAN_CCO := *, service_Class_Indicator := *, subscriber_Profile_ID_For_RAT_Priority := *, redirection_Indication := *, redirection_Completed := *, unconfirmed_Send_State_Variable := *, sCI := *, gGSN_PGW_Location := *, eDRX_Paremeters := *, old_Routing_Area_Identification := *, attach_Indicator := *, alignment_octets := *, lLC_PDU := { iEI := '0E'O, ext := ?, lengthIndicator := ?, lLC_PDU := 'DAA1113E56FAE9C68FA81DA1'O }, initialLLC_PDU := * } }
GBProxy_Tests.ttcn:3297 GBProxy_Tests control part
GBProxy_Tests.ttcn:1141 TC_dl_unitdata testcase
[...]
Timeout waiting for BSSGP on PCU side: { pDU_BSSGP_FLOW_CONTROL_MS_ACK := { bssgpPduType := '29'O (")"), tLLI := { iEI := '1F'O, ext := '1'B, lengthIndicator := { length1 := 4 }, tLLI_Value := 'C220040B'O }, tag := { iEI := '1E'O, ext := '1'B, lengthIndicator := { length1 := 1 }, unstructured_Value := '12'O } } }
GBProxy_Tests.ttcn:3374 GBProxy_Tests control part
GBProxy_Tests.ttcn:2775 TC_fc_ms testcase
</pre></p> osmo-gbproxy - Bug #4968 (Feedback): Multiple TTCN3 tests only expect one SGSNhttps://osmocom.org/issues/49682021-01-21T17:26:17Zdaniel
<p>There are various tests in TTCN3 that are not yet aware of SGSN-pooling. As such they usually just test that a message is forwarded to the first SGSN where we would expect it to be broadcast.</p>
<p>f_reset_ptp_bvc_from_sgsn() is a bit special and I'm not sure what to do here. Right now we expect the reset from one SGSN to be forwarded to the BSS. In that case we also need to reset the connection on the other SGSNs. Or we block the BVC to the other SGSNs and reset those connection as soon as the RESET-ACK from the BSS arrives at the gbproxy.</p>
<p>Couldn't we also locally answer the BVC-RESET?</p> libosmocore - Bug #4920 (Rejected): BSSGP does not wait after BVC Reset timeouthttps://osmocom.org/issues/49202020-12-21T14:00:54Zdaniel
<p>The first time a BVC Reset times out we wait a couple seconds, but after sending the second BVC Reset all other Resets are sent directly after another without waiting.</p> Cellular Network Infrastructure - Feature #4063 (Resolved): Add current version information to th...https://osmocom.org/issues/40632019-06-19T09:51:43Zdaniel
<p>Currently the only version information in the vty reference manuals is the revision history that needs to be updated manually.</p>
<p>This info resides in doc/manuals/*-vty-reference.xml</p>
<p>We now have a script to regenerate the actual vty reference (in doc/manuals/vty/*_vty_reference.xml) so updating the revision information should be automated as well.<br />I don't think using the revision history field in docbook makes sense for this task - at least not adding an entry for every change/commit. Maybe we just want to use one revision entry and update that to the date of the commit and use the git describe string of the commit as the revnumber.</p>
<p>That way it is at least clear which version this documentation belongs to.</p> Core testing infrastructure - Bug #3932 (Resolved): Check in CommonBssmapUnitdataCallback always ...https://osmocom.org/issues/39322019-04-15T15:25:46Zdaniel
<p>isvalue(null) returns true since it just checks for bound values.</p>
<p>From a recent ttcn3-msc-tester run:<br /><pre>
MSC_Test-MNCC(449)@87b5f3d98983: Added conn table entry 0TC_lu_and_mt_call_no_dlcx_resp(454)756985435
MSC_Test_0-M3UA(447)@87b5f3d98983: Message received on association #8
MSC_Test_0-M3UA(447)@87b5f3d98983: MTP3_SP_PORT: Data received -> TRANSFERind sent
MSC_Test_0-BSSMAP(446)@87b5f3d98983: Deleted conn table entry 0TC_lu_and_mt_call_no_dlcx_resp(454)12285786
MSC_Test_0-BSSMAP(446)@87b5f3d98983: CommonBssmapUnitdataCallback: IMSI/TMSI found in table, dispatching to null
MSC_Test_0-BSSMAP(446)@87b5f3d98983: Dynamic test case error: Data cannot be sent on port CLIENT to component 0 because there is no connection towards component 0.
MSC_Test-MNCC(449)@87b5f3d98983: Deleted conn table entry 0TC_lu_and_mt_call_no_dlcx_resp(454)756985435
</pre></p>
<p>Instead we should check if client != null and react on that.</p> OsmoMSC - Bug #3816 (Resolved): MSC ttcn3 test TC_sgsap_reset crashes ttcn3-msc-test-latesthttps://osmocom.org/issues/38162019-02-25T13:36:02Zdaniel
<p>It doesn't seem to happen every time, I just found one occurrence here:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/137/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/137/</a></p>
<p>There is a core file here:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/137/artifact/logs/msc-tester/core">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/137/artifact/logs/msc-tester/core</a></p>
<pre>
MSC_Tests.TC_cipher_complete_with_invalid_cipher pass' was executed successfully (exit status: 0).
MTC@209d54173aa7: Starting external command `../ttcn3-tcpdump-start.sh MSC_Tests.TC_sgsap_reset'.
Waiting for tcpdump to start... 0
MTC@209d54173aa7: External command `../ttcn3-tcpdump-start.sh MSC_Tests.TC_sgsap_reset' was executed successfully (exit status: 0).
MTC@209d54173aa7: Test case TC_sgsap_reset started.
MTC@209d54173aa7: Connecting BSSMAP Emulation to SCCP_SP_PORT and starting emulation
MSC_Test_0-M3UA(677)@209d54173aa7: *************************************************
MSC_Test_0-M3UA(677)@209d54173aa7: M3UA emulation initiated, the test can be started
MSC_Test_0-M3UA(677)@209d54173aa7: *************************************************
MSC_Test_0-SCCP(675)@209d54173aa7: v_sccp_pdu_maxlen:268
MSC_Test-MNCC(679)@209d54173aa7: Ignoring MNCC { msg_type := MNCC_SOCKET_HELLO (1024), u := { hello := { version := 5, mncc_size := 836, data_frame_size := 8, called_offset := 104, signal_offset := 796, emergency_offset := 812, lchan_type_offset := 832 } } }
MSC_Test-GSUP-IPA(681)@209d54173aa7: IPA: Connected
MSC_Test-GSUP-IPA(681)@209d54173aa7: CCM Tx:{ msg_type := IPAC_MSGT_ID_GET (4), u := { get := { { len := 1, tag := IPAC_IDTAG_UNITNAME (1) } } } }
MSC_Test-GSUP-IPA(681)@209d54173aa7: CCM Rx:{ msg_type := IPAC_MSGT_PING (0), u := omit }
MSC_Test-GSUP-IPA(681)@209d54173aa7: CCM Tx:{ msg_type := IPAC_MSGT_PONG (1), u := omit }
MSC_Test-GSUP-IPA(681)@209d54173aa7: CCM Rx:{ msg_type := IPAC_MSGT_ID_RESP (5), u := { resp := { { len := 23, tag := IPAC_IDTAG_UNITNAME (1), data := '4D53432D30302D30302D30302D30302D30302D303000'O } } } }
MSC_Test-GSUP-IPA(681)@209d54173aa7: IPA ID RESP: { { len := 23, tag := IPAC_IDTAG_UNITNAME (1), data := '4D53432D30302D30302D30302D30302D30302D303000'O } }
MSC_Test-GSUP-IPA(681)@209d54173aa7: CCM Tx:{ msg_type := IPAC_MSGT_ID_ACK (6), u := omit }
MSC_Test-GSUP-IPA(681)@209d54173aa7: CCM Rx:{ msg_type := IPAC_MSGT_ID_ACK (6), u := omit }
MC@209d54173aa7: Test Component 684 has requested to stop MTC. Terminating current testcase execution.
MSC_Test_0-M3UA(677)@209d54173aa7: Warning: The maximum number of open file descriptors (1048576) is greater than FD_SETSIZE (1024). Ensure that Test Ports using Install_Handler do not try to wait for events of file descriptors with values greater than FD_SETSIZE (1024). (Current caller of Install_Handler is "SCTP_PORT")
MSC_Test_0-M3UA(677)@209d54173aa7: Dynamic test case error: Fd_And_Timeout_User::remove_all_fds Internal error 4: fdCount: 1
MSC_Test_0-M3UA(677)@209d54173aa7: Dynamic test case error: Fd_And_Timeout_User::remove_all_fds Internal error 4: fdCount: 1
MSC_Test_0-M3UA(677)@209d54173aa7: Dynamic test case error: Fd_And_Timeout_User::remove_all_fds Internal error 4: fdCount: 1
MC@209d54173aa7: Unexpected message KILLED was received from PTC 677.
MC@209d54173aa7: Unexpected end of PTC connection (677) from 209d54173aa7 [172.18.1.103].
MTC@209d54173aa7: Test case TC_sgsap_reset finished. Verdict: error
MTC@209d54173aa7: Starting external command `../ttcn3-tcpdump-stop.sh MSC_Tests.TC_sgsap_reset error'.
[1;31m------ MSC_Tests.TC_sgsap_reset error ------[0m
terminate called after throwing an instance of 'TC_Error'
/osmo-ttcn3-hacks/msc/MSC_Tests: Abort was called
Waiting for tcpdump to finish... 0 (prev_count=-1, count=9056)
/usr/lib/titan/libttcn3-parallel-dynamic.so(_Z14signal_handleri+0xa3)[0x7ff5d14972d3]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060)[0x7ff5cfaf4060]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7ff5cfaf3fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7ff5cfaf542a]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x15d)[0x7ff5d040c0ad]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x8f066)[0x7ff5d040a066]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x8e089)[0x7ff5d0409089]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(__gxx_personality_v0+0x2cd)[0x7ff5d04099dd]
/lib/x86_64-linux-gnu/libgcc_s.so.1(+0xff33)[0x7ff5cfe6ff33]
/lib/x86_64-linux-gnu/libgcc_s.so.1(_Unwind_RaiseException+0xfb)[0x7ff5cfe7029b]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(__cxa_throw+0x5c)[0x7ff5d040a2bc]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_Z10TTCN_errorPKcz+0x1af)[0x7ff5d142006f]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN19Fd_And_Timeout_User14remove_all_fdsEP28Fd_And_Timeout_Event_Handler+0x3af)[0x7ff5d145a0bf]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN4PORT15deactivate_portEb+0x144)[0x7ff5d1451524]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN4PORTD1Ev+0x1f)[0x7ff5d14515ff]
/osmo-ttcn3-hacks/msc/SCTPasp_PT.so(_ZN17SCTPasp__PortType20SCTPasp__PT_PROVIDERD1Ev+0xbc)[0x7ff5d4450d3c]
/osmo-ttcn3-hacks/msc/SCTPasp_PortType.so(_ZN17SCTPasp__PortType11SCTPasp__PTD1Ev+0x36)[0x7ff5dedcccce]
/lib/x86_64-linux-gnu/libc.so.6(__cxa_finalize+0x8f)[0x7ff5cfaf6caf]
/osmo-ttcn3-hacks/msc/M3UA_Emulation.so(+0x243b3)[0x7ff5e61453b3]
Waiting for tcpdump to finish... 1 (prev_count=9056, count=10216)
MTC@209d54173aa7: External command `../ttcn3-tcpdump-stop.sh MSC_Tests.TC_sgsap_reset error' was executed successfully (exit status: 0).
MTC@209d54173aa7: Starting external command `../ttcn3-tcpdump-start.sh MSC_Tests.TC_sgsap_lu'.
Waiting for tcpdump to start... 0
MTC@209d54173aa7: External command `../ttcn3-tcpdump-start.sh MSC_Tests.TC_sgsap_lu' was executed successfully (exit status: 0).
MTC@209d54173aa7: Test case TC_sgsap_lu started.
MTC@209d54173aa7: Connecting BSSMAP Emulation to SCCP_SP_PORT and starting emulation
MSC_Test_0-M3UA(687)@209d54173aa7: *************************************************
MSC_Test_0-M3UA(687)@209d54173aa7: M3UA emulation initiated, the test can be started
MSC_Test_0-M3UA(687)@209d54173aa7: *************************************************
MSC_Test_0-SCCP(685)@209d54173aa7: v_sccp_pdu_maxlen:268
MSC_Test-MNCC(689)@209d54173aa7: Ignoring MNCC { msg_type := MNCC_SOCKET_HELLO (1024), u := { hello := { version := 5, mncc_size := 836, data_frame_size := 8, called_offset := 104, signal_offset := 796, emergency_offset := 812, lchan_type_offset := 832 } } }
</pre> Core testing infrastructure - Bug #3800 (Resolved): Core file breaks jenkins ttcn3 buildshttps://osmocom.org/issues/38002019-02-13T15:33:06Zdaniel
<p>ttcn3 jenkins jobs fail if the tested component crashes with a core dump.</p>
<p>The issue is that docker runs (for example) osmo-msc as root and if it crashes the core dump generated is also owned by root - but without read permissions for others. Then the jenkins task that collects the artifacts runs as user and fails to read the core file. The log file is also owned by root, but since it is readable by all it can be archived.</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/438/consoleFull">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/438/consoleFull</a></p>
<p>The workspace of osmo-msc-test shows the core file and also shows that it can't be read by jenkins.</p>
<p>One possibility would be to run osmo-msc inside docker as user instead of root, but then you need to ensure that uid inside and outside of docker match. Fixuid seems to do exactly that: <a class="external" href="https://github.com/boxboat/fixuid">https://github.com/boxboat/fixuid</a></p>
<p>We could just sudo chown -R $USER $VOL_BASE_DIR in jenkins.sh or in the jenkins job after running jenkins.sh if we don't want to have it in the script.</p> OsmoBTS - Bug #3745 (Resolved): Build osmo-bts-oc2g in master-osmo-bts jenkins jobhttps://osmocom.org/issues/37452019-01-03T16:42:24Zdaniel
<p>We don't yet build osmo-bts-oc2g in our nightly builds.</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-bts/">https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-bts/</a></p>
<p>./configure --enable-oc2g needs oc2g.h which we will need to get from nuran somewhere before we can build these.</p> OsmoBSC - Bug #3646 (Resolved): debian package does not include meas-vis toolhttps://osmocom.org/issues/36462018-10-11T22:41:45Zdaniel
<p>meas-json is built and packaged into osmo-bsc-meas-utils, but the curses visualization is not built and not packaged because of a missing dependency to libcdk. Add libcdk as a build-dependency</p>
<p>Patch is in Gerrit:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/11324">https://gerrit.osmocom.org/#/c/osmo-bsc/+/11324</a></p> OsmoBSC - Bug #3642 (New): logging filter imsi leaks bsc_subscr referenceshttps://osmocom.org/issues/36422018-10-09T22:04:16Zdaniel
<p>The function log_set_filter_bsc_subscr is called by vty command "logging filter imsi <imsi>". This function calls bsc_subscr_get which is necessary so we don't loose/free the subscriber and forget the filter state.</p>
<p>However, it seems that the subscriber is never put() again:</p>
<pre>
OsmoBSC# show subscriber all
IMSI TMSI LAC Use
901700000023361 0122b2d3 1 8
OsmoBSC# logging filter imsi 901700000023361
OsmoBSC# logging filter imsi 901700000023361
OsmoBSC# logging filter imsi 901700000023361
OsmoBSC# logging filter imsi 901700000023361
OsmoBSC# show subscriber all
IMSI TMSI LAC Use
901700000023361 0122b2d3 1 12
OsmoBSC# logging disable
OsmoBSC# show subscriber all
IMSI TMSI LAC Use
901700000023361 0122b2d3 1 12
</pre> OsmoBSC - Feature #3641 (Resolved): Make "logging filter imsi " work for (currently) unknown subs...https://osmocom.org/issues/36412018-10-09T21:58:12Zdaniel
<p>osmo-bsc only allows filtered logging base on IMSI it already knows. We should change this so a log filter can also be created for a subscriber that is currently unknown to osmo-bsc.</p>
<p>The attached untested patch should work as intended. It will create the subscriber in the logging filter imsi statement if it doesn't exist. Once we get an CompleteL3 message with the IMSI the code should reuse this subscriber and the logging filter should work.</p> libosmocore - Bug #3640 (Resolved): Logging broken in network:osmocom:latest buildshttps://osmocom.org/issues/36402018-10-09T21:42:10Zdaniel
<p>Filtering by log level is broken in the current libosmocore latest packages (Tried with Debian 9)</p>
<p>As soon as you set logging level all <something> there is no way to go back to category-based log levels.</p>
<p>But since "logging level all everything" is deprecated the only way to set tar->loglevel back to 0 is to destroy the log context and recreate it. This is unintuitive and the logging set-all patches from master should be included in a new release soon.</p> osmo-gbproxy - Bug #3281 (Resolved): Add ctrl interface to osmo-gbproxyhttps://osmocom.org/issues/32812018-05-22T08:07:23Zdaniel
<p>We want to be able to query the NS status from osmo-gbproxy. Basically have the information from show ns exported:</p>
<pre>
OsmoGbProxy> show ns
Encapsulation NS-UDP-IP Local IP: 0.0.0.0, UDP Port: 23000
Encapsulation NS-FR-GRE-IP Local IP: 0.0.0.0
NSEI 110, NS-VC 110, Remote: BSS , ALIVE UNBLOCKED, UDP 127.0.0.1:23001
NSEI 18025, NS-VC 18025, Remote: SGSN, ALIVE UNBLOCKED, UDP 151.80.237.229:23000
</pre>
<p>Especially whether NSEI/NS-VS is dead/alive and (un)blocked</p> OsmoMSC - Bug #2943 (New): Errors in MGCP do not propagate back to MNCC gsm_subscriber_conn state...https://osmocom.org/issues/29432018-02-13T20:08:12Zdaniel
<p>TC_mo_crcx_ran_reject shows that if the CRCX during call setup fails the call control state machine just stalls. The MGCP code handles that case and clears all connections on the endpoint.<br />The call control side is never notified of the failure and so the connection just hangs half open at that stage.<br />See handle_error() and the caller mgw_crcx_ran_resp_cb() in libmsc/msc_mgcp.c</p>
<p>In case of an error the MGCP code should make sure the call is released to the phone side and also notify the (external) mncc.</p> OsmoMGW - Bug #2837 (Resolved): Missing sdp fields in libosmo-mgcp-clienthttps://osmocom.org/issues/28372018-01-18T16:47:38Zdaniel
<p>When generating an MDCX the code in mgcp_msg_gen doesn't include the following mandatory SDP fields:<br />(v)ersion,(o)rigin,(s)ession,(t)ime</p>
<p>Version, session and time can probably be static. Only origin needs our IP address and a unique ID.<br />See <a class="external" href="https://www.ietf.org/rfc/rfc2327.txt">https://www.ietf.org/rfc/rfc2327.txt</a> chapter 6 for more info.</p> OsmoMGW - Bug #2835 (Resolved): Newline handling of libosmo-mgcp-client needs to be more lenienthttps://osmocom.org/issues/28352018-01-17T17:04:28Zdaniel
<p>The code in mgcp-client assumes certain different line endings on MGCP reponses.</p>
<p>e.g. These don't parse (there's more options):<br /><pre>
"200 5 OK\r\nI: 10A96B45\r\n\nv=0\r\no=- foo 21 IN IP4 127.0.0.1\r\ns=-\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\nm=audio 1000 RTP/AVP 98\r\na=rtpmap:98 AMR/8000\r\na=ptime:20\r\n"
^^^^^^
"200 5 OK\r\nI: 10A96B45\r\n\r\nv=0\r\no=- foo 21 IN IP4 127.0.0.1\r\ns=-\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\nm=audio 1000 RTP/AVP 98\r\na=rtpmap:98 AMR/8000\r\na=ptime:20\r\n"
^^^^^^^^
</pre></p>
<p>Only the following is correctly parsed:<br /><pre>
"200 5 OK\r\nI: 10A96B45\n\nv=0\r\no=- foo 21 IN IP4 127.0.0.1\r\ns=-\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\nm=audio 1000 RTP/AVP 98\r\na=rtpmap:98 AMR/8000\r\na=ptime:20\r\n"
</pre></p>
<p>This has to do with the way different parts of the parser search for newlines or double newlines and how they replace parts of the string with NULL.<br />See parse_head_params(), for_each_non_empty_line and mgcp_response_parse_params() in mgcp_client.c</p> libosmocore - Bug #1913 (Closed): Document log alarms targethttps://osmocom.org/issues/19132017-01-12T16:49:43Zdaniel
<p>log alarms is used to save log messages inside a ringbuffer. This way past messages can be printed on the vty interface with show alarms. Our vty documentation should include this option.</p>
<p>alarms is a log target like any other (logging filter/level/... works).</p>