Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-26T14:00:15ZOpen Source Mobile Communications
Redmine OsmoMGW - Bug #6424 (In Progress): TC_one_crcx_loopback_rtp_implicit consistently failing in mast...https://projects.osmocom.org/issues/64242024-03-26T14:00:15Zlaforge
<p>`TC_one_crcx_loopback_rtp_implicit` appears to be failing consistently in master for 30+ consecutive builds. Meanwhile, the same test is passing just fine in latest. So there seems to be some (long-standing) regression in master?</p> OsmocomBB - Bug #6337 (New): bad fr audio with gapk/ms-sdrhttps://projects.osmocom.org/issues/63372024-01-22T21:21:06ZHoernchen
<p>The audio sounds <em>kinda</em> choppy, but not really - one half are apparently decoding issues, the other one.. well.. hard to tell, bad timing doing blocking audio calls?<br />It does not appear to be cpu related.<br />Another problem is is that the (very large!) wq used by l1ctl_client_send keeps filling up, which obviously adds latency, until it overflows. At that point random messages get dropped, which is kinda bad...<br />Sometimes the audio improves after some time - I don't understand why/how.</p>
<p>This might affect phone setups, too.</p> OsmoSGSN - Feature #6294 (New): Support GN/Gp interoperation procedures between SGSN and MMEhttps://projects.osmocom.org/issues/62942023-12-07T14:48:04Zdaniel
<p>In an Inter-RAT setup a UE could perform a RAU coming from a 4G network. In that case the UE/MS is unknown to the SGSN and it should request the SGSN context from the MME.<br />Similarly the MME needs to request the SGSN context from the SGSN if it receives a Tracking Area Update from an unknown UE.</p>
<p>If this succeeds then the PDP context at the pgw needs to be modified. <br />See diagrams TS 23.401 D 3.5-1 and D 3.6-1 for details.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Feature #6290 (In Progress): Organize Os...https://projects.osmocom.org/issues/62902023-12-06T14:17:47Zlaforge
<p>We already wanted to re-start 2023 but somehow I didn't manage to ever find the time and energy to do it. But let's make sure we definitely have an OsmoDevCon in 2024 again.</p>
<p>The date and venue are still TBD, as is pretty much anything else.</p> OsmoGGSN (former OpenGGSN) - Feature #6223 (In Progress): TTCN3 unit test[s] for GTPv1U with exte...https://projects.osmocom.org/issues/62232023-10-18T15:03:43Zlaforge
<p>Let's generate GTPv1U trffic with one or even multiple extension headers and see if osmo-ggsn (in both kernel and userspace case) pass the user data as normally expected.</p> OsmocomBB - Bug #6200 (New): osmo-trx-ms: lots of @Received bad frame (rc=-1, ber=444/444)@https://projects.osmocom.org/issues/62002023-10-03T16:46:40Zfixeria
<p>Hi <a class="user active" href="https://projects.osmocom.org/users/52">Hoernchen</a>,</p>
<p>we had a debugging session with <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> today and we got the mssdr-ms side to work more or less reliably. But we noticed a weird problem:</p>
<pre>
20231003152951965 DL1C NOTICE trxcon(0)[0x5579a42900]{BCCH_CCCH}: L1CTL_DM_EST_REQ indicates single ARFCN GSM900 979 (l1ctl.c:572)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Reset scheduler (sched_trx.c:190)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Delete TDMA timeslot #0 (sched_trx.c:226)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Add a new TDMA timeslot #4 (sched_trx.c:207)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: (Re)configure TDMA timeslot #4 as PDCH (sched_trx.c:276)
20231003152951966 DSCH NOTICE trxcon(0)[0x5579a42900]: TS4-PDTCH activating (sched_trx.c:476)
20231003152951966 DSCH NOTICE trxcon(0)[0x5579a42900]: TS4-PTCCH activating (sched_trx.c:476)
20231003152953364 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=86/456) at fn=513573 (sched_lchan_pdtch.c:94)
20231003152954366 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=87/456) at fn=513790 (sched_lchan_pdtch.c:94)
20231003152954804 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513885 (sched_lchan_pdtch.c:94)
20231003152954827 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513890 (sched_lchan_pdtch.c:94)
20231003152954846 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513894 (sched_lchan_pdtch.c:94)
20231003152954864 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513898 (sched_lchan_pdtch.c:94)
20231003152954887 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513903 (sched_lchan_pdtch.c:94)
20231003152954906 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513907 (sched_lchan_pdtch.c:94)
20231003152954924 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513911 (sched_lchan_pdtch.c:94)
20231003152954947 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513916 (sched_lchan_pdtch.c:94)
20231003152954966 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513920 (sched_lchan_pdtch.c:94)
20231003152954984 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513924 (sched_lchan_pdtch.c:94)
20231003152955007 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513929 (sched_lchan_pdtch.c:94)
20231003152955025 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513933 (sched_lchan_pdtch.c:94)
20231003152955044 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513937 (sched_lchan_pdtch.c:94)
20231003152955067 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513942 (sched_lchan_pdtch.c:94)
20231003152955085 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513946 (sched_lchan_pdtch.c:94)
20231003152955104 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513950 (sched_lchan_pdtch.c:94)
20231003152955127 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513955 (sched_lchan_pdtch.c:94)
20231003152955145 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513959 (sched_lchan_pdtch.c:94)
20231003152955164 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513963 (sched_lchan_pdtch.c:94)
20231003152955188 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513968 (sched_lchan_pdtch.c:94)
20231003152955205 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513972 (sched_lchan_pdtch.c:94)
20231003152955224 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513976 (sched_lchan_pdtch.c:94)
20231003152955248 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513981 (sched_lchan_pdtch.c:94)
20231003152955265 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513985 (sched_lchan_pdtch.c:94)
20231003152955284 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513989 (sched_lchan_pdtch.c:94)
20231003152955308 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513994 (sched_lchan_pdtch.c:94)
20231003152955325 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513998 (sched_lchan_pdtch.c:94)
20231003152955344 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514002 (sched_lchan_pdtch.c:94)
20231003152955368 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514007 (sched_lchan_pdtch.c:94)
20231003152955385 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514011 (sched_lchan_pdtch.c:94)
20231003152955404 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514015 (sched_lchan_pdtch.c:94)
</pre>
<p>It's not seen during the GMM ATTACH and SM PDP CTX ACT procedures, but only when we tried sending some data (ICMP ping) over the tun interface.<br />As can be seen, quite a lot of Downlink PDCH blocks not being decoded. The <code>BER=444/444</code> makes me think that received bursts were all 0 (neither -127 nor 127).<br />This is enlarging the ping delays significantly (from ~600ms to ~5000ms ==> ~10 times):</p>
<pre>
PING 176.16.222.1 (176.16.222.1) 56(84) bytes of data.
64 bytes from 176.16.222.1: icmp_seq=1 ttl=64 time=681 ms
64 bytes from 176.16.222.1: icmp_seq=2 ttl=64 time=803 ms
64 bytes from 176.16.222.1: icmp_seq=3 ttl=64 time=625 ms
64 bytes from 176.16.222.1: icmp_seq=4 ttl=64 time=525 ms
64 bytes from 176.16.222.1: icmp_seq=5 ttl=64 time=5646 ms
64 bytes from 176.16.222.1: icmp_seq=6 ttl=64 time=4678 ms
64 bytes from 176.16.222.1: icmp_seq=7 ttl=64 time=3911 ms
64 bytes from 176.16.222.1: icmp_seq=8 ttl=64 time=2948 ms
64 bytes from 176.16.222.1: icmp_seq=9 ttl=64 time=1984 ms
64 bytes from 176.16.222.1: icmp_seq=10 ttl=64 time=1020 ms
64 bytes from 176.16.222.1: icmp_seq=11 ttl=64 time=602 ms
64 bytes from 176.16.222.1: icmp_seq=12 ttl=64 time=742 ms
64 bytes from 176.16.222.1: icmp_seq=13 ttl=64 time=5741 ms
64 bytes from 176.16.222.1: icmp_seq=14 ttl=64 time=4769 ms
64 bytes from 176.16.222.1: icmp_seq=15 ttl=64 time=3824 ms
64 bytes from 176.16.222.1: icmp_seq=16 ttl=64 time=2860 ms
64 bytes from 176.16.222.1: icmp_seq=17 ttl=64 time=1896 ms
64 bytes from 176.16.222.1: icmp_seq=18 ttl=64 time=932 ms
64 bytes from 176.16.222.1: icmp_seq=19 ttl=64 time=813 ms
64 bytes from 176.16.222.1: icmp_seq=20 ttl=64 time=653 ms
64 bytes from 176.16.222.1: icmp_seq=21 ttl=64 time=5630 ms
64 bytes from 176.16.222.1: icmp_seq=22 ttl=64 time=4658 ms
64 bytes from 176.16.222.1: icmp_seq=23 ttl=64 time=3893 ms
64 bytes from 176.16.222.1: icmp_seq=24 ttl=64 time=2929 ms
64 bytes from 176.16.222.1: icmp_seq=25 ttl=64 time=1969 ms
64 bytes from 176.16.222.1: icmp_seq=26 ttl=64 time=1005 ms
64 bytes from 176.16.222.1: icmp_seq=27 ttl=64 time=546 ms
64 bytes from 176.16.222.1: icmp_seq=28 ttl=64 time=686 ms
</pre>
<p>This looks like a PHY problem to me, so assigning to you.</p> osmo-e1d - Bug #6169 (New): Frame masking against network frame ordering, not frame numbershttps://projects.osmocom.org/issues/61692023-09-06T08:33:34Zmanawyrm
<p>The osmo-e1d code includes functionality to save bandwidth by not transmitting timeslots, which haven't changed since the last frame.</p>
<p><a class="external" href="https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263">https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263</a></p>
<p>Later in development, the frame_rifo was introduced to combat packet reordering in real-world networks (like DOCSIS).<br />The code unpacking the timeslots into full E1 frames is currently unpacking against the last frame in the incoming buffer, not the last frame in the RIFO (random in, first out) buffer.<br />This means that frames will get filled with random data from other frames in the event of a re-ordering.</p>
<p>Unpacking/Unmasking should be done after the RIFO mechanism.</p> OsmoGGSN (former OpenGGSN) - Feature #6096 (In Progress): add support for kernel-GTP IPv6https://projects.osmocom.org/issues/60962023-07-12T20:37:17Zlaforge
<p><a class="user active" href="https://projects.osmocom.org/users/21027">pablo</a> has implemented [inner] IPv6 support in the kernel GTP driver and libgtpnl, see <a class="issue tracker-1 status-2 priority-3 priority-high3" title="Bug: IPv6 support for inner (user) IP layer missing (In Progress)" href="https://projects.osmocom.org/issues/1952">#1952</a></p>
<p>In order to end-to-end test it in our TTCN3 test suite (which already tests ipv6 when used with userspace GTP), we would need to add supprot for it to osmo-ggsn</p>
<p>I think <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> is currently too busy to look at this, hence assigned to <a class="user active" href="https://projects.osmocom.org/users/301771">osmith</a>, but that's not mandatory. Feel free to pass around as needed.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6091 (Feedback): osmo-epdg: Implement CEAI ...https://projects.osmocom.org/issues/60912023-07-10T17:09:19Zlynxis
<p>Write all relevant parts to have a gsup server module which the strongswan can connect to it.</p> libosmo-netif - Bug #5931 (New): heap-use-after-free when osmo_stream_srv_destroy() is called ins...https://projects.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> SIMtrace 2 - Bug #5921 (In Progress): simtrace2 cardem vs. Linux kernel USB autosuspendhttps://projects.osmocom.org/issues/59212023-02-23T17:40:01Zlaforge
<p>(at least) after the following patch was merged, simtrace2-cardem doesn't work with Linux kernels' USB autosuspend anymore:<br /><pre>
commit a5d537973db9359804e82a506057f3dd6d53fab9
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Jul 25 19:59:08 2022 +0200
cardem: reset the uC in case of USB disconnect
</pre></p>
<p>The problem is that the USB kernel notices the simtrace2 device is not in use (no application using it), which in turn means it will power-down the device after 5s. The device then recognizes this as USB disconnect, and we use that to reset the firmware:</p>
<pre>
=============================================================================
SIMtrace2 firmware 0.8.1.58-773d, BOARD=simtrace, APP=cardem
(C) 2010-2019 by Harald Welte, 2018-2019 by Kevin Redon
=============================================================================
-I- Chip ID: 0x299b0a60 (Ext 0x00000000)
-I- Serial Nr. 44203020-48574336-30303931-32323032
-I- Reset Cause: software reset (processor reset required by the software)
-I- USB init...
USBD_Init
SetAddr(22) -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ SetCfg(1) cfgChanged1 -I- calling configure of all configurations...
-I- calling init of config 1...
-I- Modem 0: physical SIM
-I- 0: Use local/physical SIM
-I- entering main loop...
-I- USB is now configured
-I- Resetting uC on USB disconnect
=============================================================================
SIMtrace2 firmware 0.8.1.58-773d, BOARD=simtrace, APP=cardem
(C) 2010-2019 by Harald Welte, 2018-2019 by Kevin Redon
=============================================================================
-I- Chip ID: 0x299b0a60 (Ext 0x00000000)
-I- Serial Nr. 44203020-48574336-30303931-32323032
-I- Reset Cause: software reset (processor reset required by the software)
-I- USB init...
USBD_Init
SetAddr(23) -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ SetCfg(1) cfgChanged1 -I- calling configure of all configurations...
-I- calling init of config 1...
-I- Modem 0: physical SIM
-I- 0: Use local/physical SIM
-I- entering main loop...
-I- USB is now configured
-I- Resetting uC on USB disconnect
</pre>
<p>This in turn will make the device enumerate and re-enumerate in 5s cycles:</p>
<pre>
[585591.174222] usb 1-1: new full-speed USB device number 84 using xhci_hcd
[585591.330180] usb 1-1: New USB device found, idVendor=1d50, idProduct=60e3, bcdDevice= 0.02
[585591.330216] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=11
[585591.330231] usb 1-1: Product: SIMtrace 2
[585591.330242] usb 1-1: Manufacturer: sysmocom - s.f.m.c. GmbH
[585591.330253] usb 1-1: SerialNumber: 44203020485743363030393132323032
[585594.759881] usb 1-1: USB disconnect, device number 84
[585595.530214] usb 1-1: new full-speed USB device number 85 using xhci_hcd
[585595.682690] usb 1-1: New USB device found, idVendor=1d50, idProduct=60e3, bcdDevice= 0.02
[585595.682697] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=11
[585595.682701] usb 1-1: Product: SIMtrace 2
[585595.682704] usb 1-1: Manufacturer: sysmocom - s.f.m.c. GmbH
[585595.682706] usb 1-1: SerialNumber: 44203020485743363030393132323032
[585598.802549] usb 1-1: USB disconnect, device number 85
[585602.158170] usb 1-1: new full-speed USB device number 86 using xhci_hcd
[585602.313720] usb 1-1: New USB device found, idVendor=1d50, idProduct=60e3, bcdDevice= 0.02
[585602.313757] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=11
[585602.313772] usb 1-1: Product: SIMtrace 2
[585602.313784] usb 1-1: Manufacturer: sysmocom - s.f.m.c. GmbH
[585602.313795] usb 1-1: SerialNumber: 44203020485743363030393132323032
[585606.602416] usb 1-1: USB disconnect, device number 86
</pre> OsmoSGSN - Bug #5880 (In Progress): User Manual sections 11.1.1-2 document non-existing (removed?...https://projects.osmocom.org/issues/58802023-01-27T12:08:58Zfixeria
<p>This problem was reported by a user in the IRC:</p>
<pre>
18:55 < PJHarvy> i can't understand: in osmo sgsn manual we use:
18:55 < PJHarvy> encapsulation udp local-ip 127.0.0.1 1
18:55 < PJHarvy> encapsulation udp local-port 23000. but my version doesn't support this commands
</pre>
<p>The current <a class="external" href="https://downloads.osmocom.org/docs/latest/osmosgsn-usermanual.pdf">https://downloads.osmocom.org/docs/latest/osmosgsn-usermanual.pdf</a> indeed lists these commands, which do not exist.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #5861 (In Progress): extend charon with ...https://projects.osmocom.org/issues/58612023-01-17T15:53:09Zlaforge
<p>right now there's a charon plugin for eap-aka. It uses a local CSV file for storage of K/OP values, and it assumes it can synchronously access that and use it to derive AUTN challenges. so basically it includes a mini-hss/hlr.</p>
<p>We need to modify/replace that with a system where we get an asynchronous request for authentication over some external interface (currently called CEAI in my diagram at <a class="wiki-page" href="https://projects.osmocom.org/projects/osmo-epdg/wiki/EPDG_implementation_plan">EPDG_implementation_plan</a>), like a unix domain socket. Charon then needs to wait until whatever external application has obtained auth tuples, and proceed with EAP-AKA only once a tuple has been received.</p>
<p>This can be developed and tested independent of the actual ePDG by implementing a small stub program that for example reas key material from a local CSV file (again), or possibly even by asking osmo-hlr via GSUP (we do have all the related libraries in place for C and python, AFAIR). So the latter might actually be easier than the CSV approach, where again one needs to do key derviation etc.</p> OsmoBSC - Feature #5755 (In Progress): io_uring support in osmo-bschttps://projects.osmocom.org/issues/57552022-11-09T12:56:54Zlaforge
<p>Once libosmocore provides the new API for the upcoming io_uring backend (<a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: io_uring support in libosmocore (Resolved)" href="https://projects.osmocom.org/issues/5751">#5751</a>) we will need to port osmo-bsc over to this new API.</p>
<p>Some I/O is done directly by osmo-bsc, while other I/O is done via libaries such as libosmo-sigtran, libosmo-netif, libosmo-mgcp-client. There are separate tickets for porting over those libraries. Once that has happened, there might also be API changes for osmo-bsc to catch up with.</p>
<p>Currently we're using the following code-paths for I/O</p>
<table>
<tr>
<th>osmo-bsc function</th>
<th>I/O function</th>
<th>provided by</th>
</tr>
<tr>
<td>bsc_sccplite_mgcp_proxy_cb</td>
<td>recv</td>
<td>-</td>
</tr>
<tr>
<td>bsc_sccplite_rx_mgcp</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>cbsp_srv_cb/cbsp_client_read_cb</td>
<td>osmo_cbsp_recv_buffered</td>
<td>libosmocore</td>
</tr>
<tr>
<td>cbsp_tx_decoded</td>
<td>osmo_stream_{cli,srv}_send</td>
<td>libosmo-netif</td>
</tr>
<tr>
<td>Abis interface</td>
<td>-</td>
<td>libosmo-abis</td>
</tr>
<tr>
<td>A+Lb interface</td>
<td>-</td>
<td>libosmo-sigtran</td>
</tr>
<tr>
<td>VTY interface</td>
<td>-</td>
<td>libosmo-vty</td>
</tr>
<tr>
<td>CTRL interface</td>
<td>-</td>
<td>libosmo-ctrl</td>
</tr>
</table>
<p>We need to analyze each of those and migrate, if possible.</p>
<p>There is also some other I/O like meas_feed, pcu_sock rf_ctrl which are not performance critical and hence can stay like they are and are not further discussed here.</p> Osmocom Libraries - Bug #5683 (New): How to install osmocom in Chinahttps://projects.osmocom.org/issues/56832022-09-18T10:18:56Z914068469@qq.com
<p>Is it necessary to <a class="external" href="ftp://sources.redhat.com/pub/newlib">ftp://sources.redhat.com/pub/newlib</a> Download newlib-1.19.0.tar.gz</p> OsmoBSCNAT - Bug #5574 (New): OsmoBSCNAT testsuite running in jenkinshttps://projects.osmocom.org/issues/55742022-06-01T10:38:54Zosmith
<p>As discussed earlier, OsmoBSCNAT ttcn3 tests should be running in jenkins, like for other Osmocom projects.</p> OsmoMSC - Bug #5559 (Stalled): OsmoMSC at 100% CPU and unresponsive for up to several minutes!https://projects.osmocom.org/issues/55592022-05-12T23:22:09Zkeith
<p>Not much more to say than the title I'm afraid.</p>
<p>So far, I've actually only noticed it on a system using the RBS and osmo-e1d. But I do not have conclusive proof that it is exclusively happening here.</p>
<p>I'm assuming a culprit might be the sms queue, but I'm not convinced because I'm not seeing it on other systems with more messages in the queue in the sqlite db - and this can be upwards of 1,000 SMS queued.</p> OsmoTRX - Feature #5516 (In Progress): BladeRF 2.0 Supporthttps://projects.osmocom.org/issues/55162022-04-07T08:12:04Zakibsayyed
<p>Dear OSMOCOM Community</p>
<p>I was looking to purchase LimeSDR/Mini but it's been discontinued and coming up with a newer 2.0 version</p>
<p>Can we put efforts in adding support for bladerf as well.</p>
<p>Link for new LimeSDR Mini Page<br /><a class="external" href="https://www.crowdsupply.com/lime-micro/limesdr-mini-2-0">https://www.crowdsupply.com/lime-micro/limesdr-mini-2-0</a></p> Open Source IMS Client - Feature #5481 (New): SIM card interface for doubangohttps://projects.osmocom.org/issues/54812022-03-07T10:53:16Zlaforge
<p>The pre-existing <a class="wiki-page" href="https://projects.osmocom.org/projects/foss-ims-client/wiki/Doubango">doubango</a> library code assumes that the IMS client has knowledge of the secret key material (K + OP/OPc) in order to perform the authentication and IPsec key establoshment to the P-CSCF.</p>
<p>This may be the case in <em>some</em> testing/lab setups, but in general this key material is stored on the ISIM or USIM application of a SIM card.</p>
<p>If we want to use doubango with such standard cards, we need some kind of interface how doubango can perform authentication via ISIM/USIM.</p>
The interface should be rather generic, as the detailed interface for SIM access will be highly platform specific:
<ul>
<li>For development on a normal Linux laptop, a pcsc-lite based interface to a smart card reader will be used.</li>
<li>For execution inside a specific phone, phone specific interfaces for SIM card access may be used (QMI, AT+CSIM, ...)</li>
</ul> OsmoSGSN - Bug #5349 (In Progress): Message for non-existing SNDCP Entity https://projects.osmocom.org/issues/53492021-12-09T20:57:14Zkeith
<p>It seems pretty easy to get into a state where the TLLI in the MM context is not matching that in the SNDCP.</p>
<pre>
MM Context for IMSI 262423203000396, IMEI 013895003719350, P-TMSI ecc8a829
MSISDN: 57057157010, TLLI: ecc8a829 HLR:
GMM State: Registered.NORMAL, Routeing Area: 334-07-1101-21, Cell ID: 0
MM State: Standby, RAN Type: GPRS/EDGE via Gb
SGSN MM Context Statistics:
Signalling Messages ( In): 45 (0/s 0/m 45/h 0/d)
Signalling Messages (Out): 21 (0/s 0/m 21/h 0/d)
User Data Messages ( In): 369 (0/s 0/m 369/h 0/d)
User Data Messages (Out): 288 (0/s 0/m 288/h 0/d)
User Data Bytes ( In): 37388 (0/s 0/m 37388/h 0/d)
User Data Bytes (Out): 56465 (0/s 0/m 56465/h 0/d)
PDP Context Activations : 1 (0/s 0/m 1/h 0/d)
SUSPEND Count : 0 (0/s 0/m 0/h 0/d)
Paging Packet Switched : 2 (0/s 0/m 2/h 0/d)
Paging Circuit Switched : 0 (0/s 0/m 0/h 0/d)
Routing Area Update : 14 (0/s 0/m 14/h 0/d)
OsmoSGSN# show snd
OsmoSGSN# show sndcp
State of SNDCP Entities
TLLI c6ada2d6 SAPI=3 NSAPI=5:
Defrag: npdu=289 highest_seg=2 seg_have=0x00000007 tot_len=1233
TLLI e9d026da SAPI=3 NSAPI=5:
Defrag: npdu=339 highest_seg=1 seg_have=0x00000003 tot_len=793
</pre>
<p>resulting in:</p>
<pre>
20211209214900128 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900148 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900149 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900170 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900170 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900188 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900210 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900210 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900230 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900231 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900248 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900248 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900267 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
20211209214900267 DSNDCP ERROR Message for non-existing SNDCP Entity (lle=0x55672ad42848, TLLI=ecc8a829, SAPI=3, NSAPI=5) (gprs_sndcp.c:812)
</pre>
<p>My apologies - Over the last year or so I've suffered a memory leak for all the GRPS workings, I'll need to read up again to further debug this myself, but in the meantime, it should be reproducible if anyone wishes to take a look.</p>
<p><del>One way to trigger it seems to be cause a GPRS suspend by making a call</del> . In fact I can't reproduce this so easily. Something else is in the mix.</p>
<p>See the notes I erroneously posted on related issue <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: vty comand "show sndcp" can cause SEGV in vty_dump_sne() (Resolved)" href="https://projects.osmocom.org/issues/4824">#4824</a> , especially <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: vty comand "show sndcp" can cause SEGV in vty_dump_sne() (Resolved)" href="https://projects.osmocom.org/issues/4824#note-13">#4824-13</a></p>
<p>Marking high priority as I am observing this as a show stopper in production. <br />Thanks.</p> gr-osmosdr - Bug #5144 (New): Support multiple Airspy deviceshttps://projects.osmocom.org/issues/51442021-05-08T18:58:56ZAsciiWolf
<p>Please, consider supporting multiple Airspy devices in gr-osmosdr. Currently, this is not possible and only one of my connected Airspy R2 devices is available in GNU Radio companion and Gqrx.</p>
<p>There was a patch adding this support (by being able to specify the device serial number as a value for the "airspy" argument in Airspy Source) already posted in 2016: <a class="external" href="https://lists.osmocom.org/pipermail/osmocom-sdr/2016-April/001446.html">https://lists.osmocom.org/pipermail/osmocom-sdr/2016-April/001446.html</a></p>
<p>The patch still seems to work fine on latest gr-osmosdr and adds exactly the functionality needed to make multiple Airspy devices available. Please, consider adding this patch to upstream gr-osmosdr or implementing a different approach to support multiple Airspy devices in gr-osmosdr. Thanks!</p> OsmoBSC - Feature #5106 (Feedback): Watchdog that would try to un-BORKE BORKen timeslotshttps://projects.osmocom.org/issues/51062021-04-04T20:21:26Zkeith
<p>In <a class="issue tracker-1 status-3 priority-2 priority-default closed behind-schedule" title="Bug: rbs2000 ALL BORKEN Channels (Resolved)" href="https://projects.osmocom.org/issues/5096">#5096</a> that discussed lchans ending up borken on a busy ericsson bts:</p>
<p>"What would probably make sense is some kind of watchdog that would try to un-BORKE BORKen timeslots after a certain time. This can be done by activating a broken sub-slot and releasing it immediately. If the BTS still refuses to activate it, then it's completely BORKen and the second attempt to un-BORKE can be postponed further."</p>
<p>(<a class="external" href="https://osmocom.org/issues/5096#note-12">https://osmocom.org/issues/5096#note-12</a>)</p> osmo-e1d - Bug #4916 (Stalled): USB unplug / replug renders e1d unusablehttps://projects.osmocom.org/issues/49162020-12-18T10:28:45Zlaforge
right now the behavior on USB unplug (or - god forbid - a firmware crash) is not very user friendly:
<ul>
<li>e1d keeps running</li>
<li>e1d does not re-open the device when it comes back</li>
</ul>
IMHO, we have the following options
<ol>
<li>fail fast - simply exit when the device is lost, assume systemd or some other management instance will keep respawning us until the device is back
<ul>
<li>but what about client programs like osmo-bsc / osmo-mgw ?</li>
</ul>
</li>
<li>implement re-opening of a single icE1usb device, knowing our blocking control transfers would corrupt any other ongoing communication
<ul>
<li>is it worth the effort, assuming this is only an interim solution</li>
</ul>
</li>
<li>go for a full-blown hot-plug capable architecture lined out in <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: consider a one-thread-per-line architecture (New)" href="https://projects.osmocom.org/issues/4915">#4915</a>
<ul>
<li>will probably take significant effort</li>
</ul></li>
</ol>
<p>I think right now we mostly have to worry about situations with a single icE1usb, so I'm tempted to go for the fail-fast approach, assuming osmo-bsc/osmo-mgw recover in some way.</p> OsmoPCU - Bug #4879 (Stalled): endless pdch.cpp:809 Got CS-N RLC block: R=0, SI=0, TFI=0, CPS=0, ...https://projects.osmocom.org/issues/48792020-11-29T23:17:31Zfixeria
<p>I just upgraded all osmo-{ran,cni} components to the recent master, and now quite often run into a situation when the MS (at least Sony Ericsson K800i, TEMS) keeps sending the same Uplink block again and again. I am not sure what exactly causes it, but I can reproduce it more or less reliably by starting Opera Mini (<a class="external" href="http://people.osmocom.org/fixeria/j2me/opera_mini.jar">http://people.osmocom.org/fixeria/j2me/opera_mini.jar</a>). When started for the first time, Opera initiates the installation process, and this is where the problem usually shows up.</p>
<pre>
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACMEAS INFO gprs_rlcmac_meas.cpp:108 MS(TLLI=0xc5849e78, IMSI=901990000000021, TA=0, 10/0, UL DL) UL RSSI: -29 dBm
</pre>
<p>Please see the attached capture file. Some highlights:</p>
<pre>
43585 RACH!
43591 IMM ASS (single block)
43731 UL Packet Resource Request
43799 DL Packet Uplink Assignment (TS=6 USF=0)
...
43910 UL DATA (BSN=0 CV=15)
...
43915 UL DATA | TCP FIN,ACK (Opera Mini closes connection to the server)
...
43918 UL DATA (BSN=3 CV=15)
43955 UL DATA (BSN=5 CV=14) <-- 14 RLC blocks left
...
44070 UL DATA (BSN=14 CV=5)
...
44146 UL DATA (BSN=19 CV=0) <-- 0 RLC blocks left
...
44149 UL DATA (BSN=19 CV=0) <-- re-transmission
44152 UL DATA (BSN=19 CV=0) <-- re-transmission
</pre>
<p>starting from frame 44149, the MS keeps transmitting the same RLC/MAC block ('35bdc794cd2b631285b2d43513'O). Interestingly enough, after each re-transmission the PCU logs "GPRS DL CTRL: PACKET_UPLINK_ACK_NACK", but <strong>does not actually send it</strong> (dummy RLC/MAC frames are not recorded). And this goes like that unless I turn off the phone. At the same time, Downlink blocks are received and accepted by the MS on the same timeslot.</p>
<p>OsmoPCU 58cd1d2f8a0474de45112e8d6e460051494eba79<br />OsmoBTS def24f0d9af2463a5ef557d35f23abd5b4d07120</p> Qualcomm Linux Modems by Quectel & Co - Support #4206 (New): Unbrick cpe router without web ui in...https://projects.osmocom.org/issues/42062019-09-16T10:41:38Zjahcultura
<p>I have a router 4G cpe modem with linux embedded without web access and terminal does anyone know how to recover? I checked on the board has the points RX, TX, DLOAD, RESET_N, so I saw here only have SMD components so the only way to rewrite the firmware would be for these communication points. Note: I tried access via serial but stops at bootloader.</p>
<p>SERIAL LOG:<br />Format: Log Type - Time(microsec) - Message - Optional Info<br />Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic<br />S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.1.2-00075<br />S - IMAGE_VARIANT_STRING=LAATANAZA<br />S - OEM_IMAGE_VERSION_STRING=ubuntu<br />S - Boot Config, 0x000002e0<br />B - 1216 - PBL, Start<br />B - 3723 - bootable_media_detect_entry, Start<br />B - 4454 - bootable_media_detect_success, Start<br />B - 4458 - elf_loader_entry, Start<br />B - 6701 - auth_hash_seg_entry, Start<br />B - 6923 - auth_hash_seg_exit, Start<br />B - 59917 - elf_segs_hash_verify_entry, Start<br />B - 107892 - PBL, End<br />B - 97478 - SBL1, Start<br />B - 146003 - pm_device_init, Start<br />B - 163114 - PM_SET_VAL:Skip<br />D - 15890 - pm_device_init, Delta<br />B - 164120 - boot_config_data_table_init, Start<br />D - 174948 - boot_config_data_table_init, Delta - (420 Bytes)<br />B - 342576 - CDT version:3,Platform ID:8,Major ID:1,Minor ID:0,Subtype:0<br />B - 348767 - sbl1_ddr_set_params, Start<br />B - 352580 - Pre_DDR_clock_init, Start<br />D - 244 - Pre_DDR_clock_init, Delta<br />D - 0 - sbl1_ddr_set_params, Delta<br />B - 365237 - pm_driver_init, Start<br />D - 4544 - pm_driver_init, Delta<br />B - 371642 - cpr_init, Start<br />D - 91 - cpr_init, Delta<br />B - 376156 - cpr_cx_mx_apc_vol_update, Start<br />D - 91 - cpr_cx_mx_apc_vol_update, Delta<br />B - 391071 - sbl1_qhsusb_al_do_fast_enum, Start<br />D - 0 - sbl1_qhsusb_al_do_fast_enum, Delta<br />B - 394060 - clock_init, Start<br />D - 152 - clock_init, Delta<br />B - 399855 - boot_flash_init, Start<br />D - 28670 - boot_flash_init, Delta<br />B - 500230 - Image Load, Start<br />D - 78172 - QSEE Image Loaded, Delta - (490820 Bytes)<br />B - 580049 - sbl1_efs_handle_cookies, Start<br />D - 0 - sbl1_efs_handle_cookies, Delta<br />B - 585661 - Devcfg Partition does not exist<br />B - 589839 - Image Load, Start<br />D - 518 - SEC Image Loaded, Delta - (2048 Bytes)<br />B - 597800 - Image Load, Start<br />D - 31994 - RPM Image Loaded, Delta - (152400 Bytes)<br />B - 629825 - Image Load, Start<br />D - 58804 - APPSBL Image Loaded, Delta - (367664 Bytes)<br />B - 688690 - QSEE Execution, Start<br />D - 152 - QSEE Execution, Delta<br />B - 694393 - SBL1, End<br />D - 599203 - SBL1, Delta<br />S - Throughput, 3000 KB/s (1013352 Bytes, 321860 us)<br />S - DDR Frequency, 240 MHz<br />Android Bootloader - UART_DM Initialized!!!<br />[0] welcome to lk<br />-----------------------------------------------------------------------<br />DMESG PART :</p>
<p>[ 0.000000] Booting Linux on physical CPU 0x0<br />[ 0.000000] Initializing cgroup subsys cpu<br />[ 0.000000] Initializing cgroup subsys cpuacct<br />[ 0.000000] Linux version 3.18.20 (wangshihong@ubuntu-238) (gcc version 4.9.2 (GCC) ) <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://projects.osmocom.org/issues/1">#1</a> PREEMPT Mon Oct 22 19:35:14 CST 2018<br />[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d<br />[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache<br />[ 0.000000] Machine model: Qualcomm Technologies, Inc. MDM <br />------------------------------------------------------------------------------------------------<br />Technical Specifications</p>
<p>LTE Support Bands FDD Band 1/3/5/7/8/28<br />WCDMA 850Mhz and 2100MHz<br />CPU frequency 533MHz<br />Flash + Memory 4Gb + 2 Gb DDR2<br />WIFI<br />2T2R 2.4GHz<br />802.11b/g/n, 300Mbps<br />Interface<br />1 x Power DC Port :<br />DC12V/1A<br />1 x RJ11<br />1x RJ45<br />10Mbps/100Mbps/1000<br />Mbps WAN/LAN Port<br />1x Power Button<br />1x Reset Button<br />1x WPS Button<br />1x 2FF Standard SIM card slot<br />1x USB port</p> Cellular Network Infrastructure - Feature #4107 (Stalled): Start systemd services as non-root userhttps://projects.osmocom.org/issues/41072019-07-15T06:56:35Zosmith
<p><a class="user active" href="https://projects.osmocom.org/users/7">laforge</a> wrote in <a href="https://osmocom.org/issues/3369#note-12" class="external">OS#3369</a>:</p>
<blockquote>
<p>Ideally, as far as possible, we should start them as non-root user<br />(which may require changes to our systemd service files, etc. in the<br />individual git repos - but that is fine!). Starting them as non-root<br />will also means that any writes to unintended directories like '/'will<br />be discovered as they then would make the program start fail.</p>
</blockquote> gr-osmosdr - Support #3819 (New): OSMO SDR blocks for GNUradiohttps://projects.osmocom.org/issues/38192019-02-28T18:00:07Zchesir
<p>I installed GNUradio, and its GUI, gnuradio-companion, using pybombs. The use of pybombs for installation requires that one set up a prefix point, or directory, so that all installation files are under that directory. When I use the method outlined in <a class="external" href="https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR">https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR</a>, many files, including the RTL SDR Source block file, are installed, but I do not know which files, aside from (obviously) the block file, should be copied from the default installation locations to a directory under my prefix point for the blocks to actually work. Having copied only the RTL SDR Source block file, and attempting to execute the GRC flowgraph (which contains that one block), I am greeted with the error "Import Error: No module named osmosdr" What do I do?</p> OsmoBSC - Feature #3659 (Stalled): handover during LCLS directly between BTSshttps://projects.osmocom.org/issues/36592018-10-17T09:22:23Zlaforge
<p>So far, we have implemented LCLS on the BSC level, i.e. in case of a local switch, the RTP stream still goes from BTS A to the BSC-colocated MGW and from there to BTS B. This removes the RTP/voice from A, but not from the Abis side.</p>
<p>In deployments where there are e.g. 3 BTS (A,B,C) at one site, back-hauled via Abis to a BSC in a remote data center, we want the voice to go directly between BTS A and BTS B, without going to the MGW at the BSC.</p>
<p>This basically means that we close the loop not inside our osmo-mgw via MGCP, but that we close it between the two involved BTSs.</p>
<p>Even in a single-remote-BTS use case, this helps in cases where both calling and called subscribers are attached to that same BTS.</p> SIMtrace 2 - Bug #3379 (Stalled): documentation on how to use SIMtrace2https://projects.osmocom.org/issues/33792018-07-04T16:10:36Zlaforge
<p>the wiki in the SIMtrace2 redmine project currently only documents flashing, but there should of course be good information on how to use the host tools in order to run the complete system.</p> Linux Kernel GTP-U - Bug #1952 (In Progress): IPv6 support for inner (user) IP layer missinghttps://projects.osmocom.org/issues/19522017-02-18T12:29:29Zlaforge
<p>The 3GPP specs permit for both IPv4 and IPv6, but we only implement IPv4. This is embarrassing and should be changed. Contribution welcome!</p>