Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092023-12-07T14:48:04ZOpen Source Mobile Communications
Redmine 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> 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> 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> 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> SIMtrace 2 - Bug #5419 (Stalled): cardem errors with higher baud ratehttps://projects.osmocom.org/issues/54192022-01-25T18:27:00Zlaforge
Setup is as follows:
<ul>
<li>sysmoISIM-SJA2 in built-in CCID reader of my Thinkpad x260</li>
<li>SIMtrace2 with cardem firmware 'master' (0.8.1.7-ea9a) hooked up via FPC to</li>
<li>CCID reader "Identive CLOUD 2700 F" </li>
<li><code>simtrace2-cardem-pcsc</code> to forward request from IdentiveCCID -> SIMtrace -> st2-cardem-pcsc -> builtin-CCID</li>
</ul>
<p>This works fine with F/D ratio 372, and also works fine in most cases with F/D ratio 16.</p>
<p>However, sometimes with ratio 16, things break down at some point.</p>
<a name="log-output-of-cardem-firmware"></a>
<h2 >log output of cardem firmware<a href="#log-output-of-cardem-firmware" class="wiki-anchor">¶</a></h2>
<pre>
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9d 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9e 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9f 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 a0 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
N-I- 0: send_tpdu_header: 00 b2 a1 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
N-I- 0: send_tpdu_header: 00 c0 00 00 60
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 02 00 a4 00 04
-I- 0: flush_rx_buffer (5)
</pre>
two things noticable:
<ul>
<li>the 'N' being printed by card_emu as waiting time extension</li>
<li>the last TPDU header <code>02 00 a4 00 04</code> doesn't look like a TPDU header: The 02 seems wrong, the TPDU likely starts with <code>00 a4</code>.</li>
</ul>
<a name="situation-on-Identive-CCID-reader-side"></a>
<h2 >situation on "Identive CCID reader" side<a href="#situation-on-Identive-CCID-reader-side" class="wiki-anchor">¶</a></h2>
<p>pySim-shell "export" shows:<br /><pre>
update_record 159 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
update_record 160 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
update_record 161 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
# bad file: MF/DF.TELECOM/EF.ADN, Failed to transmit with protocol T0. Transaction failed.
EXCEPTION of type 'RuntimeError' occurred with message: '6881: Functions in CLA not supported - Logical channel not supported'
To enable full traceback, run the following command: 'set debug true'
</pre></p>
<a name="simtrace2-cardem-pcsc"></a>
<h2 >simtrace2-cardem-pcsc<a href="#simtrace2-cardem-pcsc" class="wiki-anchor">¶</a></h2>
<pre>
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9d 04 22
=> DATA: flags=1, 00 b2 9d 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9e 04 22
=> DATA: flags=1, 00 b2 9e 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9f 04 22
=> DATA: flags=1, 00 b2 9f 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 a0 04 22
=> DATA: flags=1, 00 b2 a0 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 a1 04 22
=> DATA: flags=1, 00 b2 a1 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 60
=> DATA: flags=1, 00 c0 00 00 60 : SW=0x6c23, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 02 00 a4 00 04
<0000> apdu_dispatch.c:112 Unknown APDU case 0
=> DATA: flags=1, 02 00 a4 00 04 : SW=0x6881, len_rx=0
</pre>
<p>it also agrees that this last APDU is somehow wrong and cannot determine the APDU case.</p>
<a name="USB-communication"></a>
<h2 >USB communication<a href="#USB-communication" class="wiki-anchor">¶</a></h2>
<p>last message from SIMtrace to host is "RX DATA" with header flag set and 0200a40004. The card still responds with SW 6881 to that, as obviously the APDU header is invalid.</p>
<p><img src="https://projects.osmocom.org/attachments/download/4852/wireshark.png" alt="" /></p> 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> 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> 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> OsmoTRX - Bug #4622 (New): Lots of "dumping STALE burst in TRX->SDR interface" messages in osmo-t...https://projects.osmocom.org/issues/46222020-06-18T17:01:52Zpespin
<p>Running osmo-bts-trx with osmo-trx-uhd using a B200 with multi-arfcn enabled and 2 TRX.<br />Then osmo-bts-trx enters a "graceful exit" due to Abis signal lost (eg: kill BSC process). As part of "graceful exit", BTS will ramp down power, and finally send CMD POWEROFF and wait for RSP POWEROFF before exiting the process.<br />At this point in time, osmo-trx is still running waiting for next osmo-bts-trx to connect to it and do a "POWERON".<br />When osmo-bts-trx is restarted and connects to it after a few seconds, and does the "POWERON", then LOTS of messages like this show up in the log during a few seconds/minutes</p>
<p>Remark: I'm using my WIP branch to have all those graceful shutdown features I'm mentioning, but they will be merged soon and they are not the "cause" of the issue.</p>
<p>So clearly there's something wrong during 2nd POWERON (POWERON->POWEROFF->wait some time->POWERON). Probably some state is kept regarding reading timestamps and then upon 2nd POWERON osmo-trx somehow tries to catch up.<br /><pre>
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967881 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967881 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967881 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967881 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967883 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967881 vs 6:967952), retrans=0
20200618185527596 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967882 vs 4:967953), retrans=0
20200618185527596 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967882 vs 4:967953), retrans=0
20200618185527596 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967884 vs 4:967953), retrans=0
20200618185527596 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967882 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967882 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967882 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967882 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967884 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967882 vs 6:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967882 vs 6:967953), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967883 vs 4:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967885 vs 4:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967885 vs 5:967954), retrans=0
20200618185527602 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967883 vs 6:967954), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967886 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967886 vs 5:967955), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967885 vs 5:967956), retrans=0
20200618185527611 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967885 vs 5:967956), retrans=0
20200618185527611 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967885 vs 5:967956), retrans=0
20200618185527611 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967887 vs 5:967956), retrans=0
20200618185527611 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967887 vs 5:967956), retrans=0
20200618185527614 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967886 vs 4:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967888 vs 4:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967888 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967886 vs 6:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967886 vs 6:967957), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967887 vs 5:967958), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967887 vs 5:967958), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967887 vs 5:967958), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967887 vs 5:967958), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967887 vs 5:967958), retrans=0
</pre></p> OsmoSGSN - Bug #4605 (New): GMM_ATTACH_REQ_FSM: Event E_AUTH_RESP_RECV_SUCCESS not permittedhttps://projects.osmocom.org/issues/46052020-06-08T19:05:08Zlaforge
<p>I'm seeing quite a bit of these and don't think that's right.</p>
<pre>
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x56242275e5e0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x56242275e5e0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x5624227600a0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x5624227600a0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x562422762bc0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x562422762bc0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
</pre>
<p>any idas?</p> pySim - Bug #4383 (Stalled): Jenkins build verification is non-deterministichttps://projects.osmocom.org/issues/43832020-01-29T08:42:58Zfixeria
<p>Recently I submitted a patch that is not supposed to change the unit test output:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/pysim/+/16982/">https://gerrit.osmocom.org/c/pysim/+/16982/</a></p>
<p>and it actually does not, but Jenkins verification fails:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/job/gerrit-pysim/261/">https://jenkins.osmocom.org/jenkins/job/gerrit-pysim/261/</a></p>
<pre>
Verifying card ...
Card contents do not match the test data:
Expected: sysmoUSIM-SJS1.ok
------------8<------------
Using PC/SC reader (dev=1) interface
Reading ...
ICCID: 1122334455667788990
IMSI: 001010000000102
SMSP: ffffffffffffffffffffffffffffffffffffffffffffffffe1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
SPN:
Display HPLMN: False
Display OPLMN: False
PLMNsel: fff11fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
PLMNwAcT:
fff11fffff # MCC: 1651 MNC: 151 AcT: UTRAN, E-UTRAN, GSM, GSM COMPACT, cdma2000 HRPD, cdma2000 1xRTT
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
OPLMNwAcT:
fff11fffff # MCC: 1651 MNC: 151 AcT: UTRAN, E-UTRAN, GSM, GSM COMPACT, cdma2000 HRPD, cdma2000 1xRTT
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
HPLMNAcT:
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ffffffffff # unused
ACC: 0008
MSISDN: Not available
AD: 00000002
Done !
------------8<------------
Got:
------------8<------------
Using PC/SC reader (dev=2) interface
Reading ...
ICCID: 1122334455667788990
IMSI: 001010000000102
SMSP: ffffffffffffffffffffffffffffffffffffffffffffffffe1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
SPN: Magic <-- The contents of this file do not match the expectations
Display HPLMN: True
Display OPLMN: True
PLMNsel: fff11fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
PLMNwAcT:
fff11fffff # MCC: 1651 MNC: 151 AcT: UTRAN, E-UTRAN, GSM, GSM COMPACT, cdma2000 HRPD, cdma2000 1xRTT
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
OPLMNwAcT:
fff11fffff # MCC: 1651 MNC: 151 AcT: UTRAN, E-UTRAN, GSM, GSM COMPACT, cdma2000 HRPD, cdma2000 1xRTT
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
HPLMNAcT: <-- The contents of this file do not match the expectations
fff11fffff # MCC: 1651 MNC: 151 AcT: UTRAN, E-UTRAN, GSM, GSM COMPACT, cdma2000 HRPD, cdma2000 1xRTT
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ffffff0000 # unused
ACC: 0008
MSISDN: Not available
AD: 00000002
Done !
------------8<------------
Build step 'Execute shell' marked build as failure
[WARNINGS]Skipping publisher since build result is FAILURE
Finished: FAILURE
</pre>
<p>As I figured out, this is a side effect of the other changes previously submitted to Gerrit:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/pysim/+/16941">https://gerrit.osmocom.org/c/pysim/+/16941</a><br /><a class="external" href="https://gerrit.osmocom.org/c/pysim/+/16972">https://gerrit.osmocom.org/c/pysim/+/16972</a></p>
<p>The problem is that a patch submitted to Gerrit may change the contents of SIM card's file system, so after that Jenkins fails to verify any other changes because the unit test output has changed. In this case both SPN and HPLMNAcT have been changed. Perhaps we need a 'smarter' way (than just comparing stdout and a file) to do build verification, e.g. we could match only those files which we're programming in the unit test. Python has a nice framework for unit tests - <a class="external" href="https://docs.python.org/3/library/unittest.html">https://docs.python.org/3/library/unittest.html</a>, so we could have one unit test per file.</p> OsmoSGSN - Bug #4222 (New): Implement PS Paging for the Routing Areashttps://projects.osmocom.org/issues/42222019-10-08T16:30:57Zlynxis
<p>So far the SGSN only supports paging a single cell, but no Routing Area, as it doesn't tracks PCU's.<br />Implement PS paging by having a PCU object (and even further another FSM).</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> OsmoPCU - Bug #3928 (Stalled): Missing PCU_Tests.ttcn for various timers / time-outshttps://projects.osmocom.org/issues/39282019-04-15T07:57:37Zlaforge
<p>We should have automatically-executed tests that test the various RLC/MAC related timers and timeouts</p> 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> 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> OsmoTRX - Bug #3341 (Stalled): osmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-minihttps://projects.osmocom.org/issues/33412018-06-13T13:46:18Zlaforge
<p>I'm observing a strange behavior when comparing the RF envelope of osmo-trx-lms on a LimeSDR and a LimeSDR-mini.</p>
<p>The LimeSDR-mini envelope is within spec. Specifically, the transmit power level is at full strength before the start of the next burst.</p>
<p><img src="https://projects.osmocom.org/attachments/download/3215/SCREEN1.BMP" title="RF envelope on LimeSDR-mini" alt="RF envelope on LimeSDR-mini" /> <img src="https://projects.osmocom.org/attachments/download/3216/SCREEN2.BMP" title="RF envelope on LimeSDR-mini (zoom)" alt="RF envelope on LimeSDR-mini (zoom)" /></p>
<p>On the LimeSDR however, the next burst/timeslot starts too late, (or the slew rate is too low?):</p>
<p><img src="https://projects.osmocom.org/attachments/download/3217/SCREEN3.BMP" title="RF envelope on LimeSDR" alt="RF envelope on LimeSDR" /> <img src="https://projects.osmocom.org/attachments/download/3218/SCREEN4.BMP" title="RF envelope on LimeSDR (zoom)" alt="RF envelope on LimeSDR (zoom)" /></p>
<p>This is using the exact same versions of LimeSuite (f1e5444496923890ad7d030abef9c224c37c46cf) and osmo-trx (70621b74844a6ea08d6da5f5b1e1835b9af91771). All I'm doing is swapping the hardware and re-starting osmo-trx-lms and osmo-bts.</p>
<p>It's very odd, and I currently have no clue of what might be going on here.</p> OsmoSGSN - Bug #2955 (New): No GMM ATTACH REJECT on GSUP UpdateLocation Errorhttps://projects.osmocom.org/issues/29552018-02-17T08:30:59Zlaforge
<p>When the HLR responds with a UpdateLocation Error during AttachRequest processing, OsmoSGSN doesn't send the expected GMM ATTACH REJECT to the MS:</p>
<pre>
Sat Feb 17 09:28:05 2018 DLLC <0012> gprs_llc.c:526 LLC RX: unknown TLLI 0xd5390b4c, creating LLME on the fly
Sat Feb 17 09:28:05 2018 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x24bf94 CMD=UI DATA
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:1271 MM(---/ffffffff) -> GMM ATTACH REQUEST MI(262420000000006) type="GPRS attach"
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_sgsn.c:237 MM(/00000000) Allocated with GEA0 cipher.
Sat Feb 17 09:28:05 2018 DLGLOBAL <001d> rate_ctr.c:218 counter group 'sgsn:mmctx' already exists for index 0, instead using index 2. This is a software bug that needs fixing.
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:556 MM(262420000000006/d724f6f6) <- GPRS IDENTITY REQUEST: mi_type=IMEI
Sat Feb 17 09:28:05 2018 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x612fca CMD=UI DATA
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:1194 MM(262420000000006/d724f6f6) -> GMM IDENTITY RESPONSE: MI(IMEI)=499990000000006
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:160 MM(262420000000006/d724f6f6) Requesting authorization
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:185 MM(262420000000006/d724f6f6) Requesting authentication tuples
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_subscriber.c:894 MM(262420000000006/d724f6f6) Requesting subscriber authentication info
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_sgsn.c:726 MM(262420000000006/d724f6f6) Subscriber data update
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:219 MM(262420000000006/d724f6f6) Updating authorization (unknown -> authenticate)
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:248 MM(262420000000006/d724f6f6) Got authorization update: state unknown -> authenticate
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:591 MM(262420000000006/d724f6f6) <- GPRS AUTH AND CIPHERING REQ (rand = ba fd 0b 20 23 9b 1b c5 be 69 09 8c 8e d2 c6 e8 )
Sat Feb 17 09:28:05 2018 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xeb6e08 CMD=UI DATA
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:731 MM(262420000000006/d724f6f6) -> GPRS AUTH AND CIPH RESPONSE
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:778 MM(262420000000006/d724f6f6) checking auth: received GSM SRES = 4f 30 2f 17
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:160 MM(262420000000006/d724f6f6) Requesting authorization
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:196 MM(262420000000006/d724f6f6) Missing information, requesting subscriber data
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_subscriber.c:869 MM(262420000000006/d724f6f6) Requesting subscriber data update
Sat Feb 17 09:28:05 2018 DGPRS <000f> gprs_subscriber.c:539 SUBSCR(262420000000006) GPRS update location failed, GMM cause = 'Network failure' (17)
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_sgsn.c:726 MM(262420000000006/d724f6f6) Subscriber data update
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:219 MM(262420000000006/d724f6f6) Updating authorization (authenticate -> authenticate)
Sat Feb 17 09:28:35 2018 DLINP <001f> input/ipa.c:67 connection closed with server
Sat Feb 17 09:28:45 2018 DLGSUP <0027> gsup_client.c:76 GSUP connecting to 127.0.0.1:4222
</pre>
<p>I've created <code>SGSN_Tests.TC_attach_gsup_lu_reject</code> for this.</p> SIMtrace 2 - Bug #1705 (Stalled): re-integrate tracing + card reader modes into SIMtrace2 firmwar...https://projects.osmocom.org/issues/17052016-05-09T19:46:30Zlaforge
<p>the current laforge/cardemu branch breaks sim card tracing + card reader modes. Re-integrate and test those to have one firmware image working in all modes</p> UmTRX - Feature #1510 (New): Complete UHD integrationhttps://projects.osmocom.org/issues/15102016-02-19T22:52:48Z
<p>Complete UHD integration.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1508 (New): Implement UmSEL diversity switch controlhttps://projects.osmocom.org/issues/15082016-02-19T22:52:48Z
<p>Implement <a class="wiki-page new" href="https://projects.osmocom.org/projects/umtrx/wiki/UmSEL">UmSEL</a> diversity switch control.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1507 (New): Implement UmSEL tuner controlhttps://projects.osmocom.org/issues/15072016-02-19T22:52:48Z
<p>Implement <a class="wiki-page new" href="https://projects.osmocom.org/projects/umtrx/wiki/UmSEL">UmSEL</a> tuner control.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Bug #1505 (New): OHM4 footprint incorrecthttps://projects.osmocom.org/issues/15052016-02-19T22:52:48Z
<p>OHM4 footprint incorrect.</p>
<p>[Migrated from old Google Code tracker]</p> SDR (Software Defined Radio) - Bug #1474 (New): USB Claim Interface Errorhttps://projects.osmocom.org/issues/14742016-02-19T22:50:52Z
<p>Hello,</p>
<p>I have heard lots of good things about this code. I have currently tried it on Win7HP and <a class="wiki-page new" href="https://projects.osmocom.org/projects/sdr/wiki/WinXPH">WinXPH</a> but in both cases I see the error below.</p>
<p>C:\SpectrumAnalyser>rtl_sdr /tmp/capture.bin -s 1.8e6 -f 392e6<br />Found 1 device(s):<br /> 0: ezcap USB 2.0 DVB-T/DAB/FM dongle</p>
<p>Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle<br />usb_claim_interface error -12<br />Failed to open rtlsdr device #0.</p>
<p>C:\SpectrumAnalyser></p>
<p>----<br />Best regards, John.</p>