Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T14:00:15ZOpen Source Mobile Communications
Redmine OsmoMGW - Bug #6424 (In Progress): TC_one_crcx_loopback_rtp_implicit consistently failing in mast...https://osmocom.org/issues/64242024-03-26T14:00:15Zlaforge
<p>`TC_one_crcx_loopback_rtp_implicit` appears to be failing consistently in master for 30+ consecutive builds. Meanwhile, the same test is passing just fine in latest. So there seems to be some (long-standing) regression in master?</p> OsmoSGSN - Feature #6294 (New): Support GN/Gp interoperation procedures between SGSN and MMEhttps://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 #6223 (In Progress): TTCN3 unit test[s] for GTPv1U with exte...https://osmocom.org/issues/62232023-10-18T15:03:43Zlaforge
<p>Let's generate GTPv1U trffic with one or even multiple extension headers and see if osmo-ggsn (in both kernel and userspace case) pass the user data as normally expected.</p> OsmoGGSN (former OpenGGSN) - Feature #6096 (In Progress): add support for kernel-GTP IPv6https://osmocom.org/issues/60962023-07-12T20:37:17Zlaforge
<p><a class="user active" href="https://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://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://osmocom.org/users/30187">pespin</a> is currently too busy to look at this, hence assigned to <a class="user active" href="https://osmocom.org/users/301771">osmith</a>, but that's not mandatory. Feel free to pass around as needed.</p> OsmoSGSN - Bug #5880 (In Progress): User Manual sections 11.1.1-2 document non-existing (removed?...https://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://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://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://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://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://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> osmo-remsim - Bug #5527 (Stalled): warn on duplicate client (id) connectionshttps://osmocom.org/issues/55272022-04-12T17:37:27Zlaforge
<p>Every client must have its own unique tuple of (client_id/slot_nr).</p>
<p>If a remsim-server receives a duplicate connection, it should pring a clear warning message to the log.</p>
<p>This might not always be a bug, as in csae of network outages / restarts a new connection might arrive before the old one is closed.</p>
<p>The same should apply to remsim-bankd.</p> Open Source IMS Client - Feature #5481 (New): SIM card interface for doubangohttps://osmocom.org/issues/54812022-03-07T10:53:16Zlaforge
<p>The pre-existing <a class="wiki-page" href="https://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> OsmoBTS - Bug #5257 (New): support random padding in SACCH downlink messageshttps://osmocom.org/issues/52572021-10-12T11:18:54Zlaforge
<p>See GP-110384 and GP-110969</p> gr-osmosdr - Bug #5144 (New): Support multiple Airspy deviceshttps://osmocom.org/issues/51442021-05-08T18:58:56ZAsciiWolf
<p>Please, consider supporting multiple Airspy devices in gr-osmosdr. Currently, this is not possible and only one of my connected Airspy R2 devices is available in GNU Radio companion and Gqrx.</p>
<p>There was a patch adding this support (by being able to specify the device serial number as a value for the "airspy" argument in Airspy Source) already posted in 2016: <a class="external" href="https://lists.osmocom.org/pipermail/osmocom-sdr/2016-April/001446.html">https://lists.osmocom.org/pipermail/osmocom-sdr/2016-April/001446.html</a></p>
<p>The patch still seems to work fine on latest gr-osmosdr and adds exactly the functionality needed to make multiple Airspy devices available. Please, consider adding this patch to upstream gr-osmosdr or implementing a different approach to support multiple Airspy devices in gr-osmosdr. Thanks!</p> OsmoBSC - Feature #5106 (Feedback): Watchdog that would try to un-BORKE BORKen timeslotshttps://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://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> OsmoBSC - Feature #4940 (Stalled): VAMOS support in OsmoBSChttps://osmocom.org/issues/49402021-01-12T13:52:23Zlaforge
<p>This ticket should document what needs to be done in terms of supporting <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/VAMOS">VAMOS</a> from <a class="wiki-page" href="https://osmocom.org/projects/osmobsc/wiki">OsmoBSC</a>, and to track its status via check-lists and possibly sub-issues.</p>
<p>3GPP unfortuantely doesn't provide any specifications for VAMOS beyond the radio interface. Neither A-bis OML nor RSL specs did receive any related updates.</p>
On an abstract level, we (IMHO) have the following problem domains:
<ol>
<li>how to represent the second user for each lchan</li>
<li>how to configure VAMOS via OML</li>
<li>how to represent the VAMOS channels on RSL</li>
<li>how to include VAMOS decisions in the channel allocator for assignment and hand-over</li>
</ol>
<p>as for the "representation" and "RSL" side, my idea would be to use the concept of "shadow TRX", i.e. introduce a second, logical TRX for each real TRX. Then one subscriber is on the "real" TRX and the other subscriber on the "shadow" TRX. Our data structures and RSL currently have at leaset uint8_t for the TRX number, and in reality no more than 12 TRX are ever expected in one BTS. This means we could e.g. use one of the higher-order bits to decide between real / shadow. So e.g.</p>
<ul>
<li>TRX number (and IPA stream ID) 0x00: TRX 0 (real)</li>
<li>TRX number (and IPA stream ID) 0x01: TRX 1 (real)</li>
<li>TRX number (and IPA stream ID) 0x80: TRX 0 (shadow)</li>
<li>TRX number (and IPA stream ID) 0x81: TRX 1 (shadow)</li>
<li>...</li>
</ul> osmo-e1d - Bug #4916 (Stalled): USB unplug / replug renders e1d unusablehttps://osmocom.org/issues/49162020-12-18T10:28:45Zlaforge
right now the behavior on USB unplug (or - god forbid - a firmware crash) is not very user friendly:
<ul>
<li>e1d keeps running</li>
<li>e1d does not re-open the device when it comes back</li>
</ul>
IMHO, we have the following options
<ol>
<li>fail fast - simply exit when the device is lost, assume systemd or some other management instance will keep respawning us until the device is back
<ul>
<li>but what about client programs like osmo-bsc / osmo-mgw ?</li>
</ul>
</li>
<li>implement re-opening of a single icE1usb device, knowing our blocking control transfers would corrupt any other ongoing communication
<ul>
<li>is it worth the effort, assuming this is only an interim solution</li>
</ul>
</li>
<li>go for a full-blown hot-plug capable architecture lined out in <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: consider a one-thread-per-line architecture (New)" href="https://osmocom.org/issues/4915">#4915</a>
<ul>
<li>will probably take significant effort</li>
</ul></li>
</ol>
<p>I think right now we mostly have to worry about situations with a single icE1usb, so I'm tempted to go for the fail-fast approach, assuming osmo-bsc/osmo-mgw recover in some way.</p> OsmocomBB - Bug #4658 (Stalled): Wrong burst order in a multi-trx setuphttps://osmocom.org/issues/46582020-07-08T11:45:30Zfixeria
<p>While running the existing test cases from ttcn3-bts-test on hopping channels (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: baseband frequency hopping support for osmo-bts-trx (Resolved)" href="https://osmocom.org/issues/4546">#4546</a>), I noticed that sometimes trxcon starts to consume a lot of CPU power. As it turned out, this happens because the burst loss detection logic in trxcon somehow detects that the whole TDMA hyper-frame is lost, so it tries to substitute ~2715647 allegedly lost TDMA frames with a dummy burst. Of course it's a bug, because we're not supposed to compensate more than one TDMA multi-frame period. So the problem was a missing 'return' statement:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/19183">https://gerrit.osmocom.org/c/osmocom-bb/+/19183</a> trxcon/scheduler: subst_frame_loss(): print current TDMA fn<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/19184">https://gerrit.osmocom.org/c/osmocom-bb/+/19184</a> trxcon/scheduler: fix subst_frame_loss(): do not compensate too much</p>
<p>However, I was interested to know what exactly tricks the burst detection logic to think that so many frames are lost.</p>
<pre><code class="c syntaxhl"><span class="cm">/*! Return the difference of two specified TDMA frame numbers (subtraction) */</span>
<span class="cp">#define GSM_TDMA_FN_SUB(a, b) \
((a + GSM_TDMA_HYPERFRAME - b) % GSM_TDMA_HYPERFRAME)
</span>
<span class="cm">/* How many frames elapsed since the last one? */</span>
<span class="n">elapsed</span> <span class="o">=</span> <span class="n">GSM_TDMA_FN_SUB</span><span class="p">(</span><span class="n">fn</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">elapsed</span> <span class="o">></span> <span class="n">mf</span><span class="o">-></span><span class="n">period</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DSCHD</span><span class="p">,</span> <span class="n">LOGL_NOTICE</span><span class="p">,</span> <span class="s">"Too many (>%u) contiguous TDMA frames elapsed (%u) "</span>
<span class="s">"since the last processed fn=%u (current %u)</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span>
<span class="n">mf</span><span class="o">-></span><span class="n">period</span><span class="p">,</span> <span class="n">elapsed</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">,</span> <span class="n">fn</span><span class="p">);</span>
<span class="k">return</span> <span class="o">-</span><span class="n">EIO</span><span class="p">;</span>
<span class="p">}</span> <span class="k">else</span> <span class="nf">if</span> <span class="p">(</span><span class="n">elapsed</span> <span class="o">==</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DSCHD</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="s">"No TDMA frames elapsed since the last processed "</span>
<span class="s">"fn=%u, must be a bug?</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">);</span>
<span class="k">return</span> <span class="o">-</span><span class="n">EIO</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>And slightly more informative logging message gives us a hint:</p>
<pre>
sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647) since the last processed fn=633 (current fn=632)
</pre>
<p>so, a burst with TDMA fn=632 is for some reason received <strong>late</strong>, since we already received a burst with TDMA fn=633.</p>
<p>This is definitely unexpected, and of course subtraction would result in a huge number: ((632 + 2715648) - 633) % 2715648 == 2715647.</p> Cellular Network Infrastructure - Bug #4578 (New): Updated slides / presentations / videos on set...https://osmocom.org/issues/45782020-06-03T14:56:52Zlaforge
<p>I just realized that since OsmoCon was discontinued after 2018 didn't result in sufficient turn-out, and only the 2017 incarnation contained some entry-level talks, we actually only have introductory level presentations / videos about a setup that still covers OsmoNITB. (<a class="external" href="https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network">https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network</a>)</p>
<p>This may or may not be a reason why some people still want to set up OsmoNITB in 2020. While our wiki and user manuals all have deprecated OsmoNITB years ago, people who only look for videos might be mislead.</p>
<p>Also, I'm sure that several other presentation (like the one about 3G / osmo-iuh before the CNI split) would similarly benefit from an update.</p>
<p>So I think we should try to create/update some slide decks and record related lectures / tutorials at some point this year. I wouldn't bother setting up a virtual conference or some kind of remote interaction at this point. Recording some talks and/or screencasts allows us to create and release them one-by-one.</p>
<p>Let's use this issue to first collect a list of topics that we think either need an update, or topics that never have been covered so far.</p> Core testing infrastructure - Bug #4576 (Stalled): ttcn3-hlr-tests need to route multicast traffi...https://osmocom.org/issues/45762020-06-02T22:29:38Zneelsnhofmeyr@sysmocom.de
<p>The MSLookup tests in the ttcn3-hlr-test send out multicast-DNS queries,<br />and these should be answered by osmo-hlr running in the osmo-hlr-master container.</p>
<p>Running wireshark on the docker-hosting machine on 'any', the DNS queries are visible:</p>
<pre>
No. Time Arrival Time Source Source Port Destination Destination Port Info
102721 4919.259341 Jun 3, 2020 00:16:05.287612000 CEST 172.18.10.103 4266 239.192.23.42 4266 Standard query 0x5ca3 ANY sip.voice.491618327224.msisdn.mdns.osmocom.org
102722 4919.259341 Jun 3, 2020 00:16:05.287612000 CEST 172.18.10.103 4266 239.192.23.42 4266 Standard query 0x5ca3 ANY sip.voice.491618327224.msisdn.mdns.osmocom.org
</pre>
<p>Running tcpdump in the osmo-hlr-master container shows no such activity.</p>
<p>When running the osmo-mslookup-client commandline tool with the same query, osmo-hlr does receive it and responds in the way that the test expects it:</p>
<pre>
# osmo-mslookup-client sip.voice.262422543586245.imsi
query result last age v4_ip v4_port v6_ip v6_port
sip.voice.262422543586245.imsi result last 257 66.66.66.66 5060
</pre>
<p>But also, the tester does not receive that response<br />(as I found out by "infinitely" looping the MSLookup send and receive in HLR_Tests.ttcn).</p>
<p>I am not sure how <a class="user active" href="https://osmocom.org/users/301771">osmith</a> managed to test the MSLookup tests successfully,<br />there must be some way to get the multicast traffic to pass through the containers.</p> Distributed GSM - Support #4308 (New): thoughts about incorporating credit / billing in D-GSMhttps://osmocom.org/issues/43082019-12-04T14:04:46Zneelsnhofmeyr@sysmocom.de
<p>it is not a priority to really implement a working setup, but we should have a bit of a plan for the future, to not block progress later.</p>
<p>- how could credit management be standardized?<br />- how to handle link loss? keep a set amount of credit on each site to use even if the subscriber's home village is unreachable?<br />- think about credit for: voice, sms, data connections.<br />- Look at DIAMETER accounting specs, CCR / CCA <a class="external" href="https://en.wikipedia.org/wiki/Diameter_Credit-Control_Application">https://en.wikipedia.org/wiki/Diameter_Credit-Control_Application</a></p> Qualcomm Linux Modems by Quectel & Co - Support #4206 (New): Unbrick cpe router without web ui in...https://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://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> gr-osmosdr - Support #3819 (New): OSMO SDR blocks for GNUradiohttps://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> OsmoMSC - Bug #3294 (Stalled): transaction: refactor callref allocationhttps://osmocom.org/issues/32942018-05-26T17:51:04Zfixeria
<p>Each transaction has a field called 'callref', that should contain an unique identifier. This identifier is being assigned either by OsmoMSC itself, either by an external application (e.g. LCR), and is used to distinguish between multiple allocated transactions.</p>
<p>In case of a new callref generation on the MSC side, there are the following sources for that:</p>
<pre>
$ git grep "static uint32_t new_callref"
src/libmsc/gsm_04_08.c:static uint32_t new_callref = 0x80000001;
src/libmsc/gsm_04_11.c:static uint32_t new_callref = 0x40000001;
src/libmsc/mncc_builtin.c:static uint32_t new_callref = 0x00000001;
</pre>
<p>So, we have a few ranges for different types of communication:</p>
<pre><code>- from 0x00000001 to 0x40000000 - Call Control, internal MNCC;<br /> - from 0x40000001 to 0x80000000 - SMS messages;<br /> - from 0x80000001 to 0xffffffff - Call Control, external MNCC;</code></pre>
<p>And this is how a new 'callref' value is generated:</p>
<pre>
new_callref++
</pre>
<p>I see the following problems:</p>
<p>1) Imagine that we have a network, which is running for some long time. What if the amount of calls ever made would reach 0x40000000? The next values will be 0x40000001, 0x40000002, 0x40000003, etc. At some point, this may result into collisions, e.g. two transactions with same 'callref' value.</p>
<p>Possible solution: instead of doing `new_callref++` manually, create a function (e.g. trans_gen_ref), which would prevent overlaps between ranges, and flush the source to initial value.</p>
<p>2) The trans_alloc(), which is used to allocate a new transactions, doesn't check if passed 'callref' value is not used. In other words, it is possible to allocate a few transactions with not unique 'callref'. In this case the trans_find_by_callref() would work incorrectly.</p>
<p>Possible solution: before allocation, check if given 'callref' is already used.</p>
<p>3) The 'callref' as a field name itself looks/sounds like something call related, while this feature will be also used as soon as we implement SMS and SS/USSD over GSUP. It would be better to rename it to something more generic, e.g. just 'ref'.</p>
<p>4) Both sides, i.e. MSC and an external application, are involved in 'callref' generation. There is no master-slave relation... This may result in a situation, when an external application asks to allocate a new transaction with 'callref', which is already used.</p>
<p>Possible solution: inspire by GSM TS 04.07, section 11.2.3 "Transaction identifier" and introduce the direction bit. Probably, this can be a bit simplified, e.g. '0' means allocated by the MSC itself, '1' - by an external application.</p> OsmoPCU - Bug #2400 (Stalled): transmit SI13 on PACCH during long TBFshttps://osmocom.org/issues/24002017-07-25T14:48:22Zlaforge
<pre>
5.5.1.3.3
SI13 reception failure If the mobile station has not received the SI13 or the PSI13 message within the
last 60 s, a SI13 reception failure has occurred. An SI13 reception failure shall result in a cell reselection.
5.5.2.1.3 System information on PACCH (and other logical channels)
The network may broadcast PSI and SI messages on PACCH. In particular, if a mobile station is busy in packet
transfer mode or MAC-Shared state and thus unable to receive the relevant blocks on the broadcast channels
(PBCCH or BCCH) for a period longer than 15 seconds, the following requirements apply: [...]
- If PBCCH is not present in the cell, the network may broadcast the PSI13 message on PACCH such that the
mobile station may receive the PSI13 messages at least every 15 s.
</pre>
<p>So basically this means that on a TBF that has a duration longer than 60s since the last SI13 was received on BCCH, a spec-compliant MS shall start cell re-selection, which will of course interrupt the transmission. We hence must periodically schedule SI13 in PACCH.</p> OP25 - Feature #2171 (New): Use libfftw3 for IFFT/FFT functions.https://osmocom.org/issues/21712017-04-22T16:04:15Z
<p>The software_imbe_decoder is using home-rolled FFT/IFFT functions which are much better left to a proper DFT library. Replace these functions with those of libfftw3 - the library can use SIMD instructions to compute the DFT much more efficiently than this code and it simplifies the decoder.</p> OP25 - Feature #2175 (New): Update code for GNURadio 3.6 and laterhttps://osmocom.org/issues/21752017-04-22T16:04:15Z
<p>GNURadio 3.6 introduces a lot of improved functionality. We are already suffering because not all of this code is backwards compatible nor is it particularly easy to get things working.</p>
1. Using cmake to build the C++ blocks.
<ul>
<li>Integrate all C++ blocks (repeater, decoder, etc.) into single build.</li>
<li>Rename blocks so they comply with new namespace rules.</li>
<li>Add support for message passing and metadata.</li>
<li>Ensure that grc is supported for all blocks.<br />1. Remove IT++ or, at the very minimum, fix the problems with the changes to BCH decoding.</li>
<li>IT++ has changed how it decodes BCH and this breaks packet decoding.<br />1. Refactoring code so we can pass messages and structured data between blocks.<br />1. Update top-level python code to use argparse, update GUI etc..<br />1. Flesh out some top-level C++ code as alternative to Python scripts.</li>
</ul> OsmoPCU - Bug #1759 (Stalled): Wrong calculation of DL window size for DL assignmenthttps://osmocom.org/issues/17592016-06-28T10:27:21Zarvind.sirsikar
<p>Hi,</p>
<p>When we create DOWNLINK TBF without existing UPLINK TBF i.e DL assignment on PCH case, The calculation of window size is found to be incorrect.</p>
<p>Description:<br /> 4 time slots is configured for DL and osmo-pcu.cfg is configured as window-size 64 104.</p>
<pre><code>When we try to do IPERF in DL direction, PCU allocates window-size as 160 but configures 4 time slots<br /> as seen by PCU VTY. Below is the result of VTY output.</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=160 V(A)=12 V(S)=12 nBSN=138</code></pre>
<pre><code>But we see proper calculation of window-size when DL assignement is done on PACCH. as seen by VTY interface below</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=480 V(A)=138 V(S)=139 nBSN=138</code></pre>
<p>Thanks,<br />Aravind Sirsikar</p> Mobile (in)Security - Bug #1483 (New): USSD state is not reset when switching cellshttps://osmocom.org/issues/14832016-02-19T22:51:58Z
<p>USSD support on a phone can be disabled by sending ussdNotify and not sending a releaseComplete. Other USSD commands will not be processed by the phone until the releaseComplete command is send.</p>
<p>The Phone Stack assumes that all USSD operations originate/termate from/at its HLR.</p> SDR (Software Defined Radio) - Bug #1474 (New): USB Claim Interface Errorhttps://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://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> OsmocomDECT - Bug #5393 (New): tipc problems while building on Ubuntu https://osmocom.org/issues/53932010-10-20T00:00:00Z
<p>I have cloned the git repository, and followed this tutorial to get my new kernel built:<br />​https://wiki.ubuntu.com/KernelTeam/GitKernelBuild</p>
<p>I changed all the values in .config to enable DECT functionality, and this is what I get when I try to compile the kernel:<br /><pre>
net/built-in.o: In function `dect_ccp_send_to_cluster':
ccp.c:(.text+0x95e91): undefined reference to `tipc_send_buf'
net/built-in.o: In function `dect_ccp_send_to_cell':
ccp.c:(.text+0x95f31): undefined reference to `tipc_send_buf'
net/built-in.o: In function `dect_ccp_bind_cell':
ccp.c:(.text+0x9656b): undefined reference to `tipc_attach'
ccp.c:(.text+0x965c5): undefined reference to `tipc_createport'
ccp.c:(.text+0x96635): undefined reference to `tipc_send2name'
ccp.c:(.text+0x96657): undefined reference to `tipc_deleteport'
ccp.c:(.text+0x9665f): undefined reference to `tipc_detach'
net/built-in.o: In function `dect_ccp_subscr_rcv':
ccp.c:(.text+0x966fb): undefined reference to `tipc_createport'
ccp.c:(.text+0x96731): undefined reference to `tipc_send2name'
ccp.c:(.text+0x96741): undefined reference to `tipc_deleteport'
net/built-in.o: In function `dect_ccp_cluster_init':
(.text+0x96a3f): undefined reference to `tipc_attach'
net/built-in.o: In function `dect_ccp_cluster_init':
(.text+0x96a96): undefined reference to `tipc_createport'
net/built-in.o: In function `dect_ccp_cluster_init':
(.text+0x96ac5): undefined reference to `tipc_publish'
net/built-in.o: In function `dect_ccp_cluster_init':
(.text+0x96add): undefined reference to `tipc_deleteport'
net/built-in.o: In function `dect_ccp_cluster_init':
(.text+0x96ae5): undefined reference to `tipc_detach'
net/built-in.o: In function `dect_ccp_cl_named_msg':
ccp.c:(.text+0x97235): undefined reference to `tipc_createport'
ccp.c:(.text+0x97245): undefined reference to `tipc_connect2port'
ccp.c:(.text+0x9725a): undefined reference to `tipc_send'
ccp.c:(.text+0x97273): undefined reference to `tipc_disconnect'
ccp.c:(.text+0x9727b): undefined reference to `tipc_deleteport'
net/built-in.o: In function `dect_ccp_unbind_cell':
ccp.c:(.text+0x96524): undefined reference to `tipc_detach'
net/built-in.o: In function `dect_ccp_cluster_shutdown':
(.text+0x96534): undefined reference to `tipc_detach'
make[1]: *** [.tmp_vmlinux1] Error 1
make[1]: Leaving directory `/home/wpld/dect_kernel'
make: *** [debian/stamp-build-kernel] Error 2
</pre></p>
<p>I searched for tipc.h files, and found 3 of them:</p>
<p>./include/config/tipc.h<br />./include/linux/tipc.h<br />./include/net/tipc/tipc.h</p>
<p>I found out that the linux/tipc.h isn't included in the cpp.c program, however the net/tipc/tipc.h includes it anyway. The problematic functions are all correctly defined in the latter two tipc libraries, but somehow it doesn't work for me.</p>
<p>The config/tipc.h is an empty file.</p>