Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T11:40:28ZOpen Source Mobile Communications
Redmine OsmoGGSN (former OpenGGSN) - Bug #6420 (New): osmo-ggsn + pre-configured tun device seems to be b...https://osmocom.org/issues/64202024-03-26T11:40:28Zosmith
<p>When using a pre-configured tun device with OsmoGGSN as described in the user manual, in combination with <code>gtpu-mode kernel-gtp</code>, osmo-ggsn fails to configure the kernel GTP device:</p>
<pre>
<0002> ggsn.c:210 APN(internet): Skipping APN start
<000d> gsn.c:465 GTP: gtp_newgsn() started at 10.23.24.2
<000d> gsn.c:386 State information file (/tmp/gsn_restart) not found. Creating new file.
<0002> ggsn.c:854 GGSN(ggsn0): Successfully started
<0002> gtp-kernel.c:79 Initialized GTP kernel mode (genl ID is 34)
<0001> tun.c:213 cannot create GTP tunnel device: File exists
<0002> ggsn.c:215 APN(internet): Failed to configure Kernel GTP device
</pre> OsmoGGSN (former OpenGGSN) - Bug #6419 (New): osmo-ggsn removes tun devices it did not createhttps://osmocom.org/issues/64192024-03-26T11:26:04Zosmith
<p>From the <a href="https://ftp.osmocom.org/docs/osmo-ggsn/master/osmoggsn-usermanual.pdf" class="external">user manual</a>:</p>
<blockquote>
<p>It’s possible to run OsmoGGSN without root privileges if the tun devices are already configured.<br />The interface creation + configuration must then happen before osmo-ggsn starting up.<br />[...]<br />With the tun device pre-configured in one of the ways outlined above, the main changes in your osmo-ggsn.cfg file are:<br />• remove ip ifconfig directive,<br />• make sure that no shutdown is present in the apn section as well as no shutdown ggsn in the ggsn section.</p>
</blockquote>
<p>With this configuration, a tun device created by <code>/etc/network/interfaces</code> will be removed when osmo-ggsn shuts down and <code>ifup -f apn0</code> must be used to recreate it, before starting osmo-ggsn again.</p> pySim - Bug #6322 (New): ATR type annotationhttps://osmocom.org/issues/63222024-01-03T21:55:30Zmerlinchlosta
<p>There's a small mixup in the ATR type annotations (<code>Hexstr</code> vs. <code>List[int]</code>) in <code>PcscSimLink</code>:</p>
<pre>
def get_atr(self) -> Hexstr:
return self._con.getATR()
</pre>
<p><code>pyscard</code> actually returns <code>List[int]</code> for an ATR. Depending code seems to convert using <code>i2h</code>.<br /><code>SerialSimLink</code> mimics the behavior (writing <code>self._atr</code> as <code>List[int]</code> in <code>_reset_card</code>).</p> OsmoMSC - Bug #6321 (New): SMS not delivered from corrupted SMS databasehttps://osmocom.org/issues/63212024-01-02T13:07:31Zjolly
<p>When osmo-msc is started with corrupted "sms.db", no SMS is delivered.</p>
<p>Only the earliest SMS is delivered on a location update. All other SMS are not delivered until the next location update triggers the next earliest SMS delivery.</p>
<p>The problem was solved by removing the "sms.db" file and restarting osmo-msc. All queued SMS were delivered instantly. A newly queued SMS was delivered instantly.</p>
<p>To reproduce and debug the problem, I keept the corrupt database file. It is not included with this issue, because it may contain private information. Ask me for it. (/files/auftraege/sysmocom-MSC_SMS_BUG/sms.db_buggy)</p> pySim - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://osmocom.org/issues/63142023-12-23T09:31:02Zlaforge
<p>during execution of our pySim-shell test, even with the included pcap we're getting:</p>
<pre>
WARNING pySim.apdu.ts_102_221: SELECT UNKNOWN AID a00000015141434c00
</pre>
<p>the AID is that of the ARA-M applet. We do support ARA-M in pySim-shell. However, we do not appear to use that code from pySim-shell, probably related to the AID auto-detection missing.</p> OsmoSGSN - Bug #6176 (New): build failure (dependency / concurrency issue)https://osmocom.org/issues/61762023-09-13T15:02:17Zlaforge
<p>when trying <code>make -j8 check</code> in current master (which is also 1.11.0):</p>
<pre>
...
Making check in src
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[5]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
Making check in gprs
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
Making install in src
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC crc24.lo
CC gprs_llc_parse.lo
CC gprs_utils.lo
Making install in gprs
CC sgsn_ares.lo
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC gprs_llc_parse.lo
CC crc24.lo
CC gprs_utils.lo
CC sgsn_ares.lo
mv: cannot stat '.deps/crc24.Tpo': No such file or directory
make[3]: *** [Makefile:454: crc24.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
mv: cannot stat 'gprs_utils.loT': No such file or directory
mv: cannot stat '.deps/gprs_utils.Tpo': No such file or directory
make[3]: *** [Makefile:454: gprs_utils.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: install-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: install-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:765: install] Error 2
make: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: check-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: check-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:760: check] Error 2
</pre>
<p>doing that with <code>-j1</code> works, though.</p> OsmoBTS - Bug #5995 (New): osmo-bts printing log line 'OC=GPRS-NSE(f0) INST=(00,ff,ff): Tx unkno...https://osmocom.org/issues/59952023-04-04T18:16:58Zpespin
<p>osmo-bts fails to log properly name string of NM_MT_IPACC_SET_ATTR_ACK in oml_mo_send_msg():</p>
<pre>
DEBUGPFOH(DOML, foh, "Tx %s\n", get_value_string(abis_nm_msgtype_names, foh->msg_type));
</pre>
<p>This is because IPACCESS specific messages (enum abis_nm_msgtype_ipacc) are not included in "abis_nm_msgtype_names".</p>
<p>We need to discuss whether we want them added to "abis_nm_msgtype_names" or have some way to also translate those.<br />The problem is that there can be other vendors providing other extensions which may reuse same enum values, such as enum abis_nm_msgtype_bs11.<br />So ideally we should add a function to first check abis_nm_msgtype_names() and if it fails (or within expected range for vendor-implementation) then translte from "enum abis_nm_msgtype_ipacc".</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> Cellular Network Infrastructure - Bug #5819 (New): Gerrit/gitiles: Parent links don't workhttps://osmocom.org/issues/58192022-12-08T13:28:35Zarehbein
<p>When clicking the parent link in a Gitiles commit view, I get an error message</p>
<pre><code>Secure Connection Failed<br />An error occurred during a connection to gerrit.osmocom.org:80. SSL received a record that exceeded the maximum permissible length.<br />Error code: SSL_ERROR_RX_RECORD_TOO_LONG</code></pre>
<p>I have encountered this before and now again, for example here<br /><a class="external" href="https://gerrit.osmocom.org/plugins/gitiles/osmo-upf/+/2430533206004a8d9c29dc837cd08efe0d264dfb">https://gerrit.osmocom.org/plugins/gitiles/osmo-upf/+/2430533206004a8d9c29dc837cd08efe0d264dfb</a></p> osmo-remsim - Bug #5628 (New): client-st2: error mesasges when mapping is removedhttps://osmocom.org/issues/56282022-07-24T07:14:57Zlaforge
<pre>
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=0)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=0)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DRSPRO ERROR ../rspro_client_fsm.c:359 RSPRO_CLIENT(bankd){CONNECTED}: Event SRVC_E_KA_TERMINATED not permitted
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DRSPRO INFO ../rspro_client_fsm.c:363 RSPRO_CLIENT(bankd){CONNECTED}: Destroying existing connection to server
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DMAIN ERROR ../rspro_client_fsm.c:279 CLIENT_MAIN(main){UNCONFIGURED}: Event MF_E_BANKD_LOST not permitted
</pre>
<p>not a big deal, but removing a mapping is normal business, it shoulnd't result in error messages.</p> OsmoCBC - Bug #5585 (New): CBC should not send WRITE-REPLACE to cells that had sent FAILUREhttps://osmocom.org/issues/55852022-06-21T09:41:51Zlaforge
<p>TS 48.049 states about the CBC behaviour :</p>
<blockquote>
<p>Upon receipt of the FAILURE message, the CBC shall not initiate further WRITE-REPLACE messages for concerned cell(s) until the CBC is informed, by the RESTART message, that the cell(s) have resumed CBS message operational state or emergency message operational state again.</p>
</blockquote>
<p>However, osmo-cbc is currently still sending WRITE-REPLACE in such situations.</p> libosmo-sccp + libosmo-sigtran - Bug #5561 (New): pc=0=0.0.0 / RCOC-ERROR.ind not permittedhttps://osmocom.org/issues/55612022-05-13T18:03:28Zlaforge
<p>On a rhizomatica deployment of osmo-msc + osmo-bsc I saw a series of bursts of these after some hours of operation:</p>
<pre>
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3456)[0x555555e9f740]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3455)[0x555555e9f9a0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3463)[0x555555d2d450]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3462)[0x555555d1d860]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3461)[0x555555a5d200]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3460)[0x555555836d20]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3459)[0x555555a1c7b0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3466)[0x555555ba5830]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3465)[0x555555a2c140]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3464)[0x555555d91620]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3454)[0x555555c235d0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3453)[0x555555d42630]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
</pre>
<p>The BSC side for this is:</p>
<pre>
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
</pre>
<p>Unfortunately I have no pcap file.</p>
<p>The error disappeared automatically just as it appeared...</p> osmo-e1d - Bug #5521 (New): don't attempt OCTOI connection of no TDM data from driver (icE1usb)https://osmocom.org/issues/55212022-04-10T10:40:32Zlaforge
<p>If there is no TDM data from the icE1usb device (loss of signal, ...) the octoi client should not attempt to connect. Basically it gets stuck in an indefinite loop of connect, timeout (due to no TDM frames), connect, timeout, ...</p> Retronetworking - Bug #5512 (New): Idea: L1OIP driver for DAHDIhttps://osmocom.org/issues/55122022-04-03T11:46:45Zlaforge
<p>mISDN has <code>l1oip</code> as a protocol to use to establish virtual PRI or BRI trunks between different machines using mISDN.</p>
<p>Implementing L1OIP support in DAHDI would allow a virtual PRI/BRI line between a DAHDI machine and a mISDN machine, making it easier to user mISDN applications without the related hardware.</p> osmo-e1d - Bug #5499 (New): octoi client binds to specific IP even if 0.0.0.0 is specifiedhttps://osmocom.org/issues/54992022-03-28T10:38:46Zlaforge
<p>Even if the config file specifies 0.0.0.0 as the local address for the client, the socket apparently still gets bound to a specifid address at the time of the bind/connect.</p>
<pre>
udp 0 0 192.168.2.6:3333 90.187.70.153:10010 VERBUNDEN
</pre>
<p>This means that the OCTOI connection breaks as soon as the client gets a different IP address (e.g. by DHCP).</p>
<p>The odd part is that this doesn't happen on the server side. My socket looks like this:<br /><pre>
udp 0 0 0.0.0.0:10010 0.0.0.0:*
</pre></p> OsmoGGSN (former OpenGGSN) - Bug #5449 (New): osmo-ggsn: Accept IPv4v6 EUA pdp creation in APv4/v...https://osmocom.org/issues/54492022-02-09T13:37:44Zpespin
<p>Scenario: We configure an "internet" APN to be of type IPv4, so it only serves IPv4 addresses. MS sends Create PDP Context Request using EUA with PDP Type IPv4v6.</p>
Related specs:
<ul>
<li>3GPP TS 24.008 version 15.8.0 Release 15, section 6.1.3.1(.1)</li>
<li>ETSI TS 129 060 V16.0.0 (GTPv1C), section 7.3.2 ("New PDP type due to network preference")</li>
<li>3GPP TS 23.060 version 16.0.0 Release 16, section 9.2.1</li>
</ul>
<p>In current osmo-ggsn master, we seem to implement the pre-release 8 behavior:<br /><pre>
The MS, in a pre release 8 network not supporting IPv4/v6, could encounter other network reactions
[...]
NOTE: Some networks can respond with ACTIVATE PDP CONTEXT REJECT with SM cause #28 "unknown
PDP address or PDP type". In that instance, the MS can attempt to establish dual-stack connectivity by
performing two PDP context activation request procedures to activate an IPv4 PDP context and an IPv6
PDP context, both to the same APN.
</pre><br />This can be seen/reproduced in TTCN3 GGSN_Tests.TC_pdp46_act_deact_apn4</p>
<p>That means we reject it, and the MS then tries again trying to create separate pdp contexts, sending one Create PDP Context Request with PDPType=IPv4 and another one with PDPType=IPv6.<br />That means each MS may end up doing 3 CreatePDPContextRequest+Response ping pongs before properly establishing the PDP context.</p>
<p>The specs mentioned above seems to document a better way to do so, where the first Create PDP Context Request with PDPType=IPv4v6 is answered accepting the request by changing the PDPType to "IPv4" or "IPv6" (based on the APN type configured), and setting cause to "New PDP type due to network preference".</p> gr-osmosdr - Bug #5448 (New): a bug related to gqrx using gr-osmosdr for sdrplay rsp1 through soa...https://osmocom.org/issues/54482022-02-09T02:56:35Zagerasageras@tutanota.com
<p>There is a bug in gqrx with sdrplay rsp1 that it probably has to do with gr-osmosdr.<br />i have posted the issue on gqrx github <a class="external" href="https://github.com/gqrx-sdr/gqrx/issues/970">https://github.com/gqrx-sdr/gqrx/issues/970</a><br />and came in to the conclusion the it is probably on gr-osmosdr.</p>
<p>I use arch linux and the same problem consists for a year or more.<br />I am using gqrx v2.15.2-20-gdadc20b and gr-osmosdr 0.2.3-8.</p>
<p>In gqrx the input rate is only 0.2 MHz available in the 5, 6, 8 MHz, or whatever rate i choose.<br />It renders all the 8 MHz as an example but all of it is noise only for a 0.2 MHz hump in the middle.<br />Everything out of the hump is muted, you can only receive signal in the middle of the hump.</p>
<p>Every other software that i use through soapy has no problem but it is not through gr-osmosdr.</p> SIMtrace 2 - Bug #5423 (New): "trace" firmware continuous test setuphttps://osmocom.org/issues/54232022-01-27T12:24:54Zlaforge
<p>Similar to <code>cardem</code> in <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: "cardem" continuous testing setup (In Progress)" href="https://osmocom.org/issues/5422">#5422</a>, we should also create a continuous test setup for passing SIM protocol tracing. The IUT is the simtrace2 firmware.</p>
<p>We can use diffeent modems / CCID readers accessing a SIM card via a SIMtrace2 device while tracing the communication.</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5382 (New): icE1usb: detect all-1 pattern an...https://osmocom.org/issues/53822022-01-02T12:17:29Zlaforge
<p>This applies to both DAHDI and e1d.</p> libosmo-netif - Bug #5368 (Feedback): consider using SCTP_EVENT instead of SCTP_EVENTShttps://osmocom.org/issues/53682021-12-22T15:45:22Zlaforge
<p>The infamous SCTP_EVENTS and its ABI breakage (<a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: [centos] ttcn3-msc-test: 177 failures! (Resolved)" href="https://osmocom.org/issues/4573">#4573</a>) have been deprecated by IETF in 2011 already, and a new SCTP_EVENT option has been introduced. See <a class="external" href="https://datatracker.ietf.org/doc/html/rfc6458">https://datatracker.ietf.org/doc/html/rfc6458</a> Section 6.2.2.</p>
<p>We could switch libosmo-netif over to the new socket option.</p>
<p>However, Linux only introduced support for SCTP_EVENT in 2018 in<br /><pre>
commit 480ba9c18a27ff77b02a2012e50dfd3e20ee9f7a
Author: Xin Long <lucien.xin@gmail.com>
Date: Sun Nov 18 16:08:54 2018 +0800
sctp: add sockopt SCTP_EVENT
This patch adds sockopt SCTP_EVENT described in rfc6525#section-6.2.
With this sockopt users can subscribe to an event from a specified
asoc.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
</pre></p>
<p>The related code is hence only present in kernels >= 5.0</p>
<p>So it seems like a better choice to stay with SCTP_EVENTS for now as we need it to support older kernels anyway.</p> OsmoHNBGW - Bug #5304 (New): Verizon CDMA femtocellhttps://osmocom.org/issues/53042021-11-10T15:32:33Zcopslock
<p>Verizon Samsung SCS-2U01 is a very famous target for many hackers,while as Harald said in 32C3,none of them even thought about running a local network upon it.Verizon is phasing out its CDMA network,it's time to play with these valuable blackbox<br /><img src="https://scache.vzw.com/content/dam/support/images/network_extender.png" alt="" /><br />It looks like the IS95 core network is a bit simpler than 3GPP network,however,there is no project about IS95 at all,Neither the data PDSN nor the IS95 MSC.</p> OsmoBSC - Bug #5190 (New): segfault with osmo-e1dhttps://osmocom.org/issues/51902021-07-01T20:14:59Zkeith
<ul>
<li>The e1 hardware becomes unresponsive.. (why?) [soft reboot does not help]</li>
<li>osmo-e1d starts but has no interface</li>
<li>osmo-bsc crashes.</li>
</ul>
<pre>
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e8abf0 in e1d_line_update (line=0x555555948af0) at input/e1d.c:370
370 input/e1d.c: No such file or directory.
(gdb) bt
#0 0x00007ffff7e8abf0 in e1d_line_update (line=0x555555948af0) at input/e1d.c:370
#1 0x00007ffff7e84e7c in e1inp_line_update (line=0x555555948af0) at e1_input.c:929
#2 0x00005555555bc3d8 in ?? ()
#3 0x00005555555737ea in ?? ()
#4 0x00007ffff7c6409b in __libc_start_main (main=0x555555573050, argc=1, argv=0x7fffffffe5f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffe5e8) at ../csu/libc-start.c:308
#5 0x000055555557408a in ?? ()
(gdb) quit
A debugging session is active.
Inferior 1 [process 2230] will be killed.
Quit anyway? (y or n) y
root@tosepan:/etc/osmocom# lsusb
Bus 001 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
</pre> libosmocore - Bug #5035 (New): ns2: add a vty to drop a sns connectionhttps://osmocom.org/issues/50352021-02-19T12:20:49Zlynxislibosmocore - Bug #5015 (New): ns2: add consistency check for ns configuration as callbackhttps://osmocom.org/issues/50152021-02-09T14:38:20Zlynxis
<p>There should be a consistency check which checks the NS configuration as go-parent callback.<br />E.g. a ip-sns configuration without a specific bind and without using all binds.</p> OsmoHNBGW - Bug #4933 (New): Femtocell choice in U.K 2021/01https://osmocom.org/issues/49332021-01-03T13:55:43ZcopslockOsmoMSC - Bug #4863 (New): T3212 is unclear in config/vtyhttps://osmocom.org/issues/48632020-11-19T00:37:08Zkeith
<p>In the config file or vty the command timer vlr T3212 accepts a value in minutes.</p>
<p>Inline help suggest that this is a "3GPP compliant timer number", However timer 3212 is expressed in units of 6 minutes.</p> osmo-ccid-firmware - Bug #4822 (Stalled): sysmoOCTSIM with osmo-ccid-firmware sometimes fails to ...https://osmocom.org/issues/48222020-10-20T19:48:41Zlaforge
<p>I've never had this before, for many months. However, with recent firmware (0.2.48) I've observed this:<br /><pre>
[179007.559048] usb 1-4.4.3: new full-speed USB device number 32 using xhci_hcd
[179007.639242] usb 1-4.4.3: device descriptor read/64, error -32
[179007.827237] usb 1-4.4.3: device descriptor read/64, error -32
[179008.015187] usb 1-4.4.3: new full-speed USB device number 33 using xhci_hcd
[179008.095235] usb 1-4.4.3: device descriptor read/64, error -32
[179008.283233] usb 1-4.4.3: device descriptor read/64, error -32
[179008.391179] usb 1-4.4-port3: attempt power cycle
[179008.995200] usb 1-4.4.3: new full-speed USB device number 34 using xhci_hcd
[179008.995416] usb 1-4.4.3: Device not responding to setup address.
[179009.203351] usb 1-4.4.3: Device not responding to setup address.
[179009.411047] usb 1-4.4.3: device not accepting address 34, error -71
[179009.491114] usb 1-4.4.3: new full-speed USB device number 35 using xhci_hcd
[179009.491311] usb 1-4.4.3: Device not responding to setup address.
[179009.699411] usb 1-4.4.3: Device not responding to setup address.
[179009.907037] usb 1-4.4.3: device not accepting address 35, error -71
[179009.907219] usb 1-4.4-port3: unable to enumerate USB device
[179039.515037] usb 1-4.4.3: new full-speed USB device number 36 using xhci_hcd
[179039.595097] usb 1-4.4.3: device descriptor read/64, error -32
[179039.782880] usb 1-4.4.3: device descriptor read/64, error -32
[179039.971039] usb 1-4.4.3: new full-speed USB device number 37 using xhci_hcd
[179040.051067] usb 1-4.4.3: device descriptor read/64, error -32
[179040.239072] usb 1-4.4.3: device descriptor read/64, error -32
[179040.347191] usb 1-4.4-port3: attempt power cycle
[179040.954828] usb 1-4.4.3: new full-speed USB device number 38 using xhci_hcd
[179040.954974] usb 1-4.4.3: Device not responding to setup address.
[179041.167074] usb 1-4.4.3: Device not responding to setup address.
[179041.374849] usb 1-4.4.3: device not accepting address 38, error -71
[179041.454915] usb 1-4.4.3: new full-speed USB device number 39 using xhci_hcd
[179041.455125] usb 1-4.4.3: Device not responding to setup address.
[179041.667065] usb 1-4.4.3: Device not responding to setup address.
[179041.879032] usb 1-4.4.3: device not accepting address 39, error -71
[179041.879256] usb 1-4.4-port3: unable to enumerate USB device
</pre></p>
<p>twice in a row while attaching the same sysmoOCTSIM using the same cable attached to the same USB hub, ... that has litrally worked hundreds of times before.</p>
<p>As sysmocom also received a similar report on raspi a few days ago, there may be something wrong.</p>
<p>I removed one SIM card and re-plugged it, and it worked. Unforunately it currently also works with that SIM card re-inserted. Weird.</p> libosmocore - Bug #4783 (New): doxygen: duplicate 'ports.h' warninghttps://osmocom.org/issues/47832020-10-07T13:29:38Zneelsnhofmeyr@sysmocom.de
<pre>
/build/include/osmocom/vty/ports.h:1: warning: the name `ports.h' supplied as the second argument in the \file statement matches the following input files:
/build/include/osmocom/vty/ports.h
/build/builddir/doc/libosmoctrl.tag:/build/include/osmocom/ctrl/ports.h
Please use a more specific name by including a (larger) part of the path!
</pre> OsmocomDECT - Bug #5389 (New): Namespace clashes between kernel and userspace https://osmocom.org/issues/53892010-10-06T00:00:00Z
<p>There are two namespace clashes between userspace and kernel:</p>
<ul>
<li>kernel: include/linux/dect_netlink.h enum dect_ari_classes</li>
<li>libdect: include/dect/identities.h enum dect_ari_classes</li>
</ul>
<p>This one should probably be resolved by removing parsing of the inner ARI structure from the kernel completely since it doesn't need this knowledge.</p>
<ul>
<li>kernel: include/linux/dect_netlink enum dect_llme_ops</li>
<li>libdect: include/dect/llme.h struct dect_llme_ops</li>
</ul>
<p>In this case one of both needs to be renamed.</p> OsmocomDECT - Bug #5388 (New): {MM-INFO-SUGGEST} message not sent with ext bit set to 0https://osmocom.org/issues/53882010-10-05T00:00:00Z
<p>GAP (ETSI EN 300 444) section 8.29 (Location update) requires two consecutive {MM-INFO-SUGGEST} messages to be sent, one with the ext bit set to one, one with the ext bit set to zero, presumably for compatibility with old equipment. libdect always sets the ext bit to one on the final octet.</p>