Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-11-06T13:48:35ZOpen Source Mobile Communications
Redmine OCTOI - Osmocom Community TDM over IP - Feature #6246 (New): co-locate cisco 2811 for FrameRelay...https://osmocom.org/issues/62462023-11-06T13:48:35Zlaforge
<p>let's put a Cisco 2811 into the co-location, ideally with support for both X.25 as well as FrameRelay.</p>
<p>The idea would be to use it as basis for interop testing any Linux/FOSS work on X.25/framerelay routing/switching that would happen on the OCTOI hub.</p> pySim - Feature #6092 (New): "export" suport for ARA-Mhttps://osmocom.org/issues/60922023-07-10T18:47:34Zlaforge
<p>right now the "export" command is focussed around exporting files present in the file system hierarchy of the MF, as well as the various ADFs.</p>
<p>However, there are applications like ARA-M, which have data stored outside of the filesystem. So we should probably introduce an <code>export(self)</code> method within the <code>CardApplication</code> class. If that method is present, use this to export, and fall back to the filesystem for all others.</p>
<p>This way the ARA-M <code>CardApplication</code> could implement a custom method for doing the equivalent of the <code>aram_get_all</code> vty command. However, that wouldn't by itself be something that can be executed when the "export" text is re-run as a script by pySim-shell. For that to work we'd have to export different aram_* vty commands depending on the data we are reading from aram_get_all.</p> OsmoTRX - Feature #5775 (Resolved): VCGS/VBS support in osmo-trxhttps://osmocom.org/issues/57752022-11-20T16:44:57Zlaforge
<p>In order to support GSM-R ASCI, we'd need VGCS/VBS support.</p>
<p>For the TRX, this maninly means the ability to activate TCH unidirectionally</p>
<p>I'm not certain if there are additional needs in terms of talker/listener detection, too?</p> Open Source IMS Client - Feature #5483 (New): SIM card interface for strongswanhttps://osmocom.org/issues/54832022-03-07T11:11:31Zlaforge
<p>Similar to <a class="issue tracker-2 status-1 priority-4 priority-high2" title="Feature: SIM card interface for doubango (New)" href="https://osmocom.org/issues/5481">#5481</a>, we need an interface for performing UMTS-AKA with an external SIM Card.</p>
<p>The patches of <a class="issue tracker-2 status-1 priority-4 priority-high2" title="Feature: SIM card interface for doubango (New)" href="https://osmocom.org/issues/5481">#5481</a> implement the low-level APDUs for authentication and a pcsc-lite client internally. This is convenient, but for the more general use case (accessing SIM cards via phone-specific APIs like QMI or AT+CSIM comamnds) we need an interface at a higher layer of abstraction.</p>
<p>The interface should ideally be identicalt ot <a class="issue tracker-2 status-1 priority-4 priority-high2" title="Feature: SIM card interface for doubango (New)" href="https://osmocom.org/issues/5481">#5481</a>, so that both strongswan and doubango can be ran side-to-side, both accessing the same "USIM/ISIM card provider". That way, the provider must be implemented only once for each given target platform.</p> SIMtrace 2 - Feature #5422 (In Progress): "cardem" continuous testing setuphttps://osmocom.org/issues/54222022-01-27T12:22:10Zlaforge
<p>We shuold create a test setup where we can continously test the <code>cardem</code> firmware for the various targets, such as at least simtrace2 and qmod.</p>
<p>The idea would be to use the TTCN3 test ports for SIMTRACE USB protocol on the one hand side and CCID USB protocol on the other hand side.</p>
<p>Tests should ideally not just test interop with one specific CCID reader model but with a larger number of different readers to cover reader-specific issues (I'm seeing different issues with different readers in manual testing).</p>
<p>The tests can then be executed with the latest cardem firmware of the day, on different IUT hardware (simtrace2, qmod) against different readers.</p>
For QMOD testing we would have to either
<ul>
<li>insert a modem with CCID capability (they do exist)</li>
<li>use a custom PCB adapter or some solder wire to hook up the SIM traces of the mCPIE sockets with some external reader</li>
</ul>
<p>But let's focus on simtrace2 for the initial setup, and then expand from there.</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> pySim - Feature #5275 (Resolved): "export" and "read_*" should include the SW if reading a file ...https://osmocom.org/issues/52752021-10-20T12:19:05Zlaforge
<p>When dumping files fails, it would be good if the comment would not just state "failed to read" but also the SW (hex and string-decoded) why it failed.</p>
<p>Example:</p>
<pre>
################################################################################
# MF/DF.SYSTEM/EF.CHV1 #
################################################################################
# directory: MF/DF.SYSTEM (3f00/a515)
# file: EF.CHV1 (6f01)
# structure: transparent
select MF
select DF.SYSTEM
select EF.CHV1
# bad file: MF/DF.SYSTEM/EF.CHV1, Failed to read (offset 0)
</pre>
<p>The same actually also applies to the normal case, when "read_binary" or "read_binary_decoded":</p>
<pre>
pySIM-shell (MF/DF.SYSTEM/EF.CHV1)> read_binary
EXCEPTION of type 'ValueError' occurred with message: 'Failed to read (offset 0)'
To enable full traceback, run the following command: 'set debug true'
</pre>
<p>Where the SW is not printed and/or decoded in the exception.</p> pySim - Bug #5274 (Resolved): "export" doesn't save EF in MFhttps://osmocom.org/issues/52742021-10-20T12:15:08Zlaforge
<pre>
################################################################################
# MF/EF.DIR #
################################################################################
# directory: MF (3f00)
# file: EF.DIR (2f00)
# bad file: MF/EF.DIR, string indices must be integers
#
################################################################################
# MF/EF.ICCID #
################################################################################
# directory: MF (3f00)
# file: EF.ICCID (2fe2)
# bad file: MF/EF.ICCID, string indices must be integers
#
################################################################################
# MF/EF.PL #
################################################################################
# directory: MF (3f00)
# file: EF.PL (2f05)
# bad file: MF/EF.PL, string indices must be integers
#
################################################################################
# MF/EF.ARR #
################################################################################
# directory: MF (3f00)
# file: EF.ARR (2f06)
# bad file: MF/EF.ARR, string indices must be integers
#
################################################################################
# MF/EF.UMPC #
################################################################################
# directory: MF (3f00)
# file: EF.UMPC (2f08)
# bad file: MF/EF.UMPC, string indices must be integers
#
</pre>
<p>I suspect this relates to the fact that we currently don't use the FCP decoder of UICC (TS 102 221) until we have selected an application like ISIM/USIM.</p>
<p>So the question boils down to: From which point onwards do we know we deal with an UICC, and hence can use that decoder?</p> OsmoHNBGW - Feature #5153 (In Progress): support hnbgw co-located GTP-U proxy (UPF)https://osmocom.org/issues/51532021-05-13T12:13:07Zlaforge
<p>In the current osmo-hnbgw implementation, we simply configure the hNB GTP-U data to go directly to the GGSN. This requires IP-level routing between the RAN and the CN, which is possible in most lab situations, but not possible in real operator networks.</p>
<p>So we'd need to add support for a GTP-U proxy to control a co-located osmo-mgw. That proxy would translate GTP flows on the RAN side to GTP flows on the CN side (each with their own IPs/TEIDs).</p>
<p>The problem faced here is a 1:1 identical situation to what we're facing in OsmoSGSN in <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: OsmoSGSN doesn't trigger 3G paging if downlink GTP traffic arrives after long break (New)" href="https://osmocom.org/issues/5154">#5154</a>. So both should then be able to use that same GTP-U proxy component.</p>
<p>Further brainstorming about this problem revealed that we're actualy talking about the same as the "SGW-U" network element described in 3GPP TS 23.214, which is what 3GPP invented when they introduced the control/user plane separation into the 4G EPC.</p>
<p>The SGW-U is exactly a GTP-U proxy between the RAN and the CN side, and it even includes functions for buffering GTP-U packets during mobility related GTP-U tunnel modification. It also includes functions for notifying the control plane entity of the first downlink packet received (so it can trigger paging). The SGW-U is controlled by the PFCP protocol. Only very few features of PFCP are required (PFCP is also used for he PGW-U which is much more complex).</p>
So in fact, what we'd have to implement is
<ul>
<li>a minimalistic SGW-U with PFCP suport</li>
<li>functionality in osmo-hnbgw to control that SGW-U via PFCP</li>
</ul> libosmocore - Bug #4997 (Resolved): ns2: ALIVE response time : 180341 mshttps://osmocom.org/issues/49972021-01-30T21:37:47Zlaforge
<p>for some reason the reported Alive response time is unrealistically high. I'm getting readings like this when calliung "show ns nsvc ... stats" repeatedly in VTY:</p>
<pre>
ALIVE response time : 150101 ms
ALIVE response time : 180341 ms
ALIVE response time : 271118 ms
</pre> osmo-gbproxy - Feature #4961 (New): gbproxy support for "network sharing" via MOCNhttps://osmocom.org/issues/49612021-01-20T20:38:43Zlaforge
<p>In MOCN, the PS domain is also affected.</p>
<p>Likely required enhancements to osmo-gbproxy would include</p>
<ul>
<li>not only one pool of SGSNs, but multiple pools (one per CN)</li>
<li>modifications to UL-UNITDATA/DL-UNITDATA processing related to redirect etc.</li>
<li>logic for redirect handling based on redirection indication, redirect attempt flag, redirection completed</li>
</ul> OsmoMSC - Bug #4934 (Rejected): "latest" feed contains osmo-msc 1.6.3 yet no tag is in the git repo?https://osmocom.org/issues/49342021-01-06T15:50:59Zlaforge
<p><a class="external" href="https://build.opensuse.org/package/show/network:osmocom:latest/osmo-msc">https://build.opensuse.org/package/show/network:osmocom:latest/osmo-msc</a> lists a build for 1.6.3, but the latet tag in the git repository is 1.6.2 - something is odd there.</p> osmo-clock-gen - Bug #4857 (Stalled): TLV9001IDBVR no longer in stock ag digikeyhttps://osmocom.org/issues/48572020-11-10T17:06:55Zlaforge
<p>It seems this part is no longer available in digikey (below 3000 units MOQ).</p>
<p>We can source it elsewhere, but that complicates the purchasing process.</p>
<p>Digikey does have a TLV9001UIDBVR in stock. I couldn't find any differences in the TLV9001 datasheet: They both are in SOT-23-5 package, etc. Please investigate.</p> osmo-clock-gen - Bug #4814 (New): alignment of DC barrel with face platehttps://osmocom.org/issues/48142020-10-16T17:30:40Zlaforge
<p>Check if <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: alignment of DC barrel with face plate (New)" href="https://osmocom.org/issues/4809">#4809</a> also applies here.</p> OsmoGGSN (former OpenGGSN) - Bug #4713 (Resolved): TC_pdp6_act_deact_gtpu_access failures since ...https://osmocom.org/issues/47132020-08-14T06:38:03Zlaforge
<p>From build 667 onwards, TC_pdp6_act_deact_gtpu_access is failing both in 'latest' and in 'master': <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-latest/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-latest/test_results_analyzer/</a></p>
<p>We merged <a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/19572">https://gerrit.osmocom.org/c/docker-playground/+/19572</a> the night before. But all that does is enalbe IPv6 on the docker network between containers. Needs investigation.</p> OsmoBSC - Bug #4614 (Stalled): "bogus channel load sample" when using BS-11, Nokia or Ericsson BTShttps://osmocom.org/issues/46142020-06-15T13:47:09Zlaforge
<pre>
Mon Jun 15 15:36:12 2020 DRLL chan_alloc.c:208 (bts=0) bogus channel load sample (used=0 / total=0)
Mon Jun 15 15:36:13 2020 DRLL chan_alloc.c:208 (bts=0) bogus channel load sample (used=0 / total=0)
</pre>
<p>Also, interestingly:<br /><pre>
OsmoBSC> show trx
TRX 0 of BTS 0 is on ARFCN 121
Description: (null)
RF Nominal Power: 24 dBm, reduced by 0 dB, resulting BS power: 24 dBm
NM State: Oper 'NULL', Admin 'Unlocked', Avail 'Power off'
RSL State: connected
Baseband Transceiver NM State: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
E1 Signalling Link:
E1 Line 2, Type dahdi: Timeslot 1, Mode RSL
E1 TEI 1, SAPI 0
</pre></p>
<p>I think the problem is that the Siemens BS-11 MO structure is quite unlike what TS 12.21 describes, so the baseband transceiver object is simply never initialized.</p>
<p>The " OC=<abbr title="a5">SIEMENSHW</abbr> INST=(03,00,00)" might be can idea?</p> libosmo-sccp + libosmo-sigtran - Feature #4608 (New): "action" commands to interactively shutdown...https://osmocom.org/issues/46082020-06-10T13:12:24Zlaforge
<p>would be great to do that, especially for testing/debugging.</p> OsmoBSC - Feature #4549 (Resolved): Emergency Call Priority / Pre-Emptionhttps://osmocom.org/issues/45492020-05-12T13:35:15Zlaforge
This is entrely a BSC feature. The BSC
<ol>
<li>notices there is a pending emergency call (RACH request with CHREQ_T_EMERG_CALL)</li>
<li>notices it cannot allocate a suitable TCH/F or TCH/H channel</li>
<li>must pick any random non-emergency TCH on he same cell and terminate it</li>
<li>assign that TCH to the MS that has send the emrergency related RACH request</li>
</ol>
<p>As OsmoBSC currently performs channel allocation "synchronously" (i.e. within the context of the received RACH request, without any delays), this must be extended. We need to introduce a queue for asynchronous processing of RACH requests, as we hav to wait for the deactivation/re-activation of the logical channel to complete at the BTS before being able to do the IMMEDIATE ASSIGNMENT.</p>
<p>manual testing sidenote: OsmoMSC may not be able to process Emergency Call without SIM (no IMSI, only IMEI). This is a layer3 feature and hence should be suppored by the regular operator MSC. There are no changes / extensions on the RAN side to support this. In some jurisdictions, like Germany, emergency calls without SIM/IMSI must be rejected by the operator anyway. I'm just mentioning this for testing of emergency calls: Make sure you test them with a SIM inserted.</p> OsmoBSC - Feature #4545 (Resolved): Automatic TTCN3 tests for frequency hopping support in BSC https://osmocom.org/issues/45452020-05-12T13:18:50Zlaforge
<p>We currently have no testing at all whether or not the BSC encodes the various "Channel Description IEs" as expected when frequency hopping is in use.</p>
<p>We know it worked once a decade ago when we first implemented it with Siemens BTS, but that's a long time ago.</p>
<p><a class="user active" href="https://osmocom.org/users/12">tnt</a> recently reported he had frequency hopping active on an Ericsson BTS driven by OsmoBSC, but only signalling up to Location Update, no voice channels in use. Also, that is just a single manual test and not an automatic test.</p>
<p>Let's try to cover this part of the BSC codebase with TTCN-3 tests.</p> OsmoBTS - Bug #4475 (Resolved): TC_paging_imsi_80percent + TC_paging_tmsi_80percent fail since 8...https://osmocom.org/issues/44752020-03-30T17:57:45Zlaforge
<p>These two tests started failing from March 28 onwards:</p>
<p>The IMSI test case:<br /><pre>
"BTS_Tests.ttcn:3051 : Expected 271 pagings but have 284"
BTS_Tests.ttcn:6414 BTS_Tests control part
BTS_Tests.ttcn:3051 TC_paging_imsi_80percent testcase
</pre></p>
<p>The TMSI test case:<br /><pre>
"BTS_Tests.ttcn:3075 : Expected 543 pagings but have 553"
BTS_Tests.ttcn:6415 BTS_Tests control part
BTS_Tests.ttcn:3075 TC_paging_tmsi_80percent testcase
</pre></p>
<p>How can the number of expected pagings in a given time period have changed? It's not that we suddenly have more PCH capacity in downlink?</p> OsmoBTS - Bug #4466 (Rejected): " N(S) sequence error" when operating osmo-bts-trxhttps://osmocom.org/issues/44662020-03-20T21:19:54Zlaforge
<p>When operating current osmo-bts-trx master, I get quite a number of log messages about N(S) sequence errors:<br /><pre>
<0000> rsl.c:813 (bts=0,trx=0,ts=1,pchan=TCH/F) (ss=0) TCH_F Tx CHAN ACT ACK
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=0, V(R)=1 (dl=0x7f933b62aca8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=0, V(R)=1 (dl=0x7f933b62aca8 state LAPD_STATE_MF_EST)
<0000> rsl.c:813 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=1) SDCCH Tx CHAN ACT ACK
<0011> lapd_core.c:921 Store content res. (dl=0x7f933b610f70)
<0000> rsl.c:792 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK
<0000> rsl.c:813 (bts=0,trx=0,ts=2,pchan=TCH/F) (ss=0) TCH_F Tx CHAN ACT ACK
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=0, V(R)=1 (dl=0x7f933b648278 state LAPD_STATE_MF_EST)
<0004> measurement.c:645 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (4 vs exp 3)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=0, V(R)=1 (dl=0x7f933b648278 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=1, V(R)=2 (dl=0x7f933b648278 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=1, V(R)=2 (dl=0x7f933b648278 state LAPD_STATE_MF_EST)
<0000> rsl.c:792 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=1) SDCCH Tx CHAN REL ACK
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=2, V(R)=3 (dl=0x7f933b648278 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=1, V(R)=2 (dl=0x7f933b62aca8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=2, V(R)=3 (dl=0x7f933b62aca8 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=3, V(R)=4 (dl=0x7f933b648278 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=3, V(R)=4 (dl=0x7f933b648278 state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1557 N(S) sequence error: N(S)=3, V(R)=4 (dl=0x7f933b62aca8 state LAPD_STATE_MF_EST)[[]]
</pre></p> libosmo-abis - Bug #4464 (In Progress): "osmo_rtp_socket_poll(): ERROR!" messages during normal o...https://osmocom.org/issues/44642020-03-20T21:11:03Zlaforge
<p>When using osmo-bts-trx and establishing voice calls, I get lots of those osmo_rtp_socket_poll() ERROR messages when a TCH/F is established but voice is not yet conncted (i.e. while dialing, until the call is fully established):</p>
<pre>
NOTICE <0000> rsl.c:813 (bts=0,trx=0,ts=1,pchan=TCH/F) (ss=0) TCH_F Tx CHAN ACT ACK
INFO <000e> rsl.c:2122 (bts=0,trx=0,ts=1,ss=0) IPAC set RTP socket parameters: 1
INFO <0015> trau/osmo_ortp.c:0 RtpSession bound to [127.0.0.1] ports [16396] [16397]
INFO <0015> trau/osmo_ortp.c:449 osmo_rtp_socket_connect() refused to set remote 127.0.0.1:0
INFO <0015> trau/osmo_ortp.c:0 RtpSession [0x5607c73cc9d0] sending to rtp 192.168.103.248:4116 rtcp 192.168.103.248:4117
INFO <0015> trau/osmo_ortp.c:0 First estimation
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(0): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(160): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(320): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(480): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(640): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(800): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(960): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1120): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1280): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1440): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1600): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1760): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1920): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2080): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2240): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2400): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2560): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2720): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2880): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3040): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3200): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3360): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3520): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3680): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3840): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4000): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4160): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4320): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4480): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4640): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4800): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4960): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5120): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5280): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5440): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5600): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5760): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5920): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6080): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6240): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6400): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6560): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6720): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6880): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7040): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7200): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7360): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7520): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7680): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7840): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(8000): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(8160): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(8320): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(8480): ERROR!
</pre>
<p>Looking at the code, this is actually not an error as such (it's also LOGL_INFO). It merely tells us that we tried to poll for an incoming RTP packet, and there was none received since our last call.</p>
<p>We should probably either remove it completely, or turn it to 'DEBUG' and remove the 'ERROR' from the messate. Or we simply replace it with a counter?</p> OsmoMGW - Feature #4395 (Resolved): Circuit Switched Data (CSD) Support in osmo-mgwhttps://osmocom.org/issues/43952020-02-13T19:59:09Zlaforge
CSD support in OsmoMGW would be relatively simple:
<ul>
<li>understand the "CLEARMODE/8000" SDP type as per RFC4040 on the MGCP side</li>
<li>transparently pass the 160 byte per packet payload between endpoints</li>
</ul> OsmoMSC - Feature #4394 (Resolved): Circuit Switched Data (CSD) Support in osmo-mschttps://osmocom.org/issues/43942020-02-13T19:57:38Zlaforge
The MSC side support for CSD would entail:
<ul>
<li>parsing of the "data" bearer type from 04.08 call control</li>
<li>passing it correctly to [external] MNCC</li>
<li>handling incoming "data" bearer from MNCC</li>
<li>permitting data bearer types in internal MNCC handler</li>
<li>encoding the related channel types in the 48.008 A (ASSIGNMENT CMD, ...)</li>
<li>instructing the MGW to use RTP PT 120 with "CLEARMODE/8000" SDP</li>
</ul> OsmoBSC - Feature #4393 (Resolved): Circuit Switched Data (CSD) Support in osmo-bschttps://osmocom.org/issues/43932020-02-13T19:55:21Zlaforge
The BSC doesn't have to do much to support CSD:
<ul>
<li>parse the bearer service details from the 48.008 A signaling side (ASSIGNMENT CMD)</li>
<li>encode the bearer service details to the 48.058 Abis RSL signaling side (RSL CHAN ACT)</li>
<li>instruct the MGW to use RTP payload-type 120 as "CLEARMODE/8000"</li>
</ul> libosmocore - Bug #4265 (New): --enable-embedded doesn't work as expectedhttps://osmocom.org/issues/42652019-11-12T11:18:36Zlaforge
<p>--enable-embedded is supposed to automatically set flags like --disable-libsctp. In theory that<br /> is implemented, but in practise it doesn't work, as the actual <strong>check</strong> is still performed, even if later down the configure[.ac] script we set ENABLE_LIBSCTP to "false". So we perform the check (and abort in case it isn't present), but later would discard the result.</p>
<p>Re-ordering the blocks in configure.ac to first have the embedded handling doesn't help. I guess we would need to take the "$embedded" variable into account somehow in each of the enable/disable clauses?</p>
<p>Unless somebody knows a quick fix, it's not worth spending time on right now, but just for the record...</p> libosmo-netif - Bug #4106 (Resolved): 'make check' failures on debian 9 and 10 on x86_64https://osmocom.org/issues/41062019-07-14T06:05:49Zlaforge
<p><a class="external" href="https://build.opensuse.org/build/network:osmocom:nightly/Debian_9.0/i586/libosmo-netif/_log">https://build.opensuse.org/build/network:osmocom:nightly/Debian_9.0/i586/libosmo-netif/_log</a></p> OsmoMGW - Bug #3119 (Resolved): TC_crcx_illegal_double_lco failshttps://osmocom.org/issues/31192018-03-28T10:35:59Zlaforge
<p>Th test case <code>MGCP_Tests.TC_crcx_illegal_double_lco</code> of the osmo-mgw test suite fails. It has always failed, we unfortunately didn't execute it automatically from jenkins until today so this sort-of slipped through the cracks.</p> Cellular Network Infrastructure - Bug #2641 (Closed): "latest" debian packages are rebuilt every ...https://osmocom.org/issues/26412017-11-15T05:52:00Zlaforge
<p>We don't actually want to rebuild the "latest" packages every night. Only if a new version of a given repository has been tagged, this should trigger a rebuild.</p> OsmoBTS - Bug #1979 (Resolved): Priority of SAPI=0/SAPI=3 on SABMhttps://osmocom.org/issues/19792017-03-10T21:07:15Zlaforge
<p>In RT#1205sysmocom got a trace that showed a message flow like the following resulting in a re-transmission by the Mobile Station</p>
<pre>
MS BTS
- SABM SAPI=0, Paging Response ---->
<- SABM SAPI=3 ---------------------
<- SABM ACK (UA?) for SAPI=0 ----
- SABM SAPI=0, Paging Response ---->
</prE>
We need to investigate if we should start sending messages with SAPI=0 first or if there are other priority requirements that we need to consider.</pre>