Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-01T07:19:47ZOpen Source Mobile Communications
Redmine Core testing infrastructure - Bug #6381 (Feedback): libosmocore changes take too long until they ...https://projects.osmocom.org/issues/63812024-03-01T07:19:47Zlaforge
<p>(05:23:15 PM) hwelte: I don't understand why <a class="external" href="https://gerrit.osmocom.org/c/libosmo-netif/+/35069">https://gerrit.osmocom.org/c/libosmo-netif/+/35069</a> keeps failing even hours after the libosmocore patch has been merged. I even checked that the OBS package for libosmocore had been rebuilt meanwhile<br />(05:29:17 PM) hwelte: the debian10/debian12 builds fail despite the libosmocore on which the changes depend has long been built on obs.<br />(05:54:43 PM) osmith: hwelte, it says here: build jobs exist (gear icon): <a class="external" href="https://obs.osmocom.org/package/show/osmocom:master/libosmocore">https://obs.osmocom.org/package/show/osmocom:master/libosmocore</a><br />(05:55:04 PM) hwelte: osmith: yes, but that's for much more recent libosmocore commits<br />(05:55:04 PM) osmith: the builders just seem to be busy building everything, I guess because of multiple libosmocore merges in a row, each triggering a rebuild of everything<br />(05:55:12 PM) osmith: <a class="external" href="https://obs.osmocom.org/monitor">https://obs.osmocom.org/monitor</a> <- builders being busy<br />(05:55:34 PM) osmith: it might be that OBS doesn't publish a repository before all packages for a distribution are built<br />(05:58:26 PM) osmith: hwelte, so in summary: libosmocore changes cause a lot of packages to be built, and the repo (probably) only gets published once all packages are built. unfortunately it seems that the builders were not able to build everything within the last hours since the merge, or that it started building additional packages because of more merges.</p>
<p>So it somehow seems that if a longer series of patches is committed to libosmocore, each of them gets built as OBS packge for each arch/distibution, and that's what takes so long? Can we somehow get it to only build the most recent commit at a time, and first build that all the way to the end and make sure those packages are published/available for further downstream builds?</p>
It's not exactly a rare situation that we add something to one library, and then there are also patches that use those additions elsewhere. So either
<ul>
<li>we can achieve the above, or </li>
<li>we can make sure that repos/feeds are updated after building [only] the debian10/debian12 on amd64 which we use for gerrit build verification [and even prioritize those]?</li>
<li>we can make find some other way to make sure the (in this case) libosmocore package is somehow available for gerrit build verification after it has been built, and not only after the entire universe has been re-built?</li>
</ul> pySim - Bug #6340 (New): exception when using osmo-smdpp with python 3.9https://projects.osmocom.org/issues/63402024-01-24T09:43:35Zdexter
<p>There is an exception when starting osmo-smdpp with python 3.9. This exception does not occur with python 3.10.</p>
<pre>
owner@osmotest:~/git_master/pysim$ python3.9 ./osmo-smdpp.py
Traceback (most recent call last):
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 100, in <module>
class SmDppHttpServer:
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 196, in SmDppHttpServer
def initiateAutentication(self, request: IRequest, content: dict) -> dict:
TypeError: 'staticmethod' object is not callable
</pre>
<p>Commit hash: af87cd544f784e51a41cea303cb57001d9954d9c</p> pySim - Bug #6317 (Stalled): data driven tests for TLV decodershttps://projects.osmocom.org/issues/63172023-12-23T15:12:32Zlaforge
<p>While we do have the <code>_test_de_encode</code> data driven tests for file definitions, we don't yet have something similar for derived classes of BER_TLV_IE. This means that TLVs used outside of the filesystem context (for example, decoding the SELECT/STATUS response, but also eUICC and other stuff) do not yet have test coverage.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Bug #6291 (New): 2024 event bringing tog...https://projects.osmocom.org/issues/62912023-12-06T14:31:01Zlaforge
<p>I've been considering this for a number of years, but never actually got aroun to acting on it:</p>
<p>Have an event where the various FOSS mobile communications projects meet, get to know each other and exchange status, plans and ideas.</p>
<p>Matthias Kirschner of the FSFE suggested to <em>attach</em> that event to sfscon (<a class="external" href="https://www.sfscon.it/">https://www.sfscon.it/</a>) and do it a few days ahead (or after) the 2024 incarnation, which is likely happning again in November 2024. The FSFE could help with funding of the related expenses from a donation made by sysmocom to FSFE earmarked to help FOSS in mobile communications.</p>
<p>Let's use this issue to collect a list of projects we'd want to invite, and to generally keep track on status.</p>
<p>For now, I am thinking of the following potential projects:</p>
<a name="cellular-infrastructureprotocol-stacks"></a>
<h2 >cellular infrastructure/protocol stacks<a href="#cellular-infrastructureprotocol-stacks" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://osmocom.org/" class="external">Osmocom</a></li>
<li><a href="https://open5gs.org/" class="external">open5gs</a></li>
<li><a href="https://www.srslte.com/" class="external">srsRAN/srsUE</a></li>
<li><a href="https://free5gc.org/" class="external">free5gc</a></li>
<li><a href="https://github.com/edgecomllc/eupf" class="external">eupf</a></li>
<li><a href="https://github.com/travelping/ergw" class="external">ergw</a></li>
<li><a href="https://magmacore.org/" class="external">Magma</a> + <a href="https://github.com/magma/S1APTester" class="external">S1APTester</a></li>
<li><a href="https://github.com/omec-project" class="external">OMEC</a></li>
<li><a href="https://github.com/wmnsk" class="external">wmnsk</a> and his various go-{gtp,pfcp,m3ua,sccp,tcap} projects</li>
</ul>
<a name="SIM-card-related-projects"></a>
<h2 >SIM card related projects<a href="#SIM-card-related-projects" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/tomasz-lisowski/swsim" class="external">swsim</a> + <a href="https://github.com/tomasz-lisowski/swicc" class="external">swicc</a></li>
</ul>
<a name="Development-Debugging"></a>
<h2 >Development + Debugging<a href="#Development-Debugging" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/fgsect/scat" class="external">SCAT</a></li>
<li><a href="https://github.com/P1sec/QCSuper" class="external">QCsuper</a></li>
<li><a href="https://github.com/PentHertz/Modmobmap" class="external">Modmobmap</a></li>
<li><a href="https://github.com/SysSec-KAIST/LTESniffer" class="external">LTESniffer</a></li>
<li><a href="https://github.com/falkenber9/falcon" class="external">FALCON</a></li>
<li><a href="https://github.com/aligungr/UERANSIM" class="external">UERANSIM</a></li>
<li><a href="https://github.com/HewlettPackard/PacketRusher" class="external">PacketRusher</a></li>
<li>the various projects by <a href="https://github.com/fasferraz" class="external">fasferraz</a> (Swu-IKEv2, ...)</li>
<li><a href="https://github.com/P1sec/pycrate" class="external">pycrate</a></li>
</ul>
<a name="FOSS-software-stacks-on-mobile-devices"></a>
<h2 >FOSS software stacks on mobile devices<a href="#FOSS-software-stacks-on-mobile-devices" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://postmarketos.org/" class="external">postmarketos</a></li>
<li><a href="https://replicant.us/" class="external">replicant</a></li>
<li><a href="https://ubuntu-touch.io/" class="external">Ubuntu touch</a></li>
</ul>
<p>I'm very happy to accept further suggestions for projects/people to add to the invite list.</p> osmo-e1d - Bug #6169 (New): Frame masking against network frame ordering, not frame numbershttps://projects.osmocom.org/issues/61692023-09-06T08:33:34Zmanawyrm
<p>The osmo-e1d code includes functionality to save bandwidth by not transmitting timeslots, which haven't changed since the last frame.</p>
<p><a class="external" href="https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263">https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263</a></p>
<p>Later in development, the frame_rifo was introduced to combat packet reordering in real-world networks (like DOCSIS).<br />The code unpacking the timeslots into full E1 frames is currently unpacking against the last frame in the incoming buffer, not the last frame in the RIFO (random in, first out) buffer.<br />This means that frames will get filled with random data from other frames in the event of a re-ordering.</p>
<p>Unpacking/Unmasking should be done after the RIFO mechanism.</p> pySim - Bug #6119 (In Progress): aram_get_config runs into an exception on a sysmocomSJA2https://projects.osmocom.org/issues/61192023-07-28T22:48:14Zlynxis
<ul>
<li>Use a SysmocomSJA2</li>
<li>pysim master / 791f80a44f8110f478a632cd2bcde5944ad4bd96</li>
</ul>
<pre>
pySIM-shell (MF)> select ADF.ARA-M
pySIM-shell (MF/ADF.ARA-M)> aram_get_config
EXCEPTION of type 'ValueError' occurred with message: auto_collection_DeviceConfigDO(<class 'pySim.ara_m.DeviceInterfaceVersionDO'>): Unknown TLV Class DeviceInterfaceVersionDO in [{'DeviceInterfaceVersionDO': {'major': 0, 'minor': 0, 'patch': 1}}]; expected dict_keys(['device_interface_version_do'])
To enable full traceback, run the following command: 'set debug true'
pySIM-shell (MF/ADF.ARA-M)>
pySIM-shell (MF/ADF.ARA-M)> set debug true
debug - was: False
now: True
pySIM-shell (MF/ADF.ARA-M)> aram_get_config
Traceback (most recent call last):
File "/home/lynxis/.local/share/virtualenvs/pysim-C216Z-pe/lib/python3.11/site-packages/cmd2/cmd2.py", line 2399, in onecmd_plus_hooks
stop = self.onecmd(statement, add_to_history=add_to_history)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/.local/share/virtualenvs/pysim-C216Z-pe/lib/python3.11/site-packages/cmd2/cmd2.py", line 2852, in onecmd
stop = func(statement)
^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/ara_m.py", line 315, in do_aram_get_config
res_do = ADF_ARAM.get_config(self._cmd.card._scc._tp)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/ara_m.py", line 298, in get_config
cmd_do.from_dict([{'DeviceInterfaceVersionDO': {
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/tlv.py", line 161, in from_dict
self.children = self.nested_collection.from_dict(decoded)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/tlv.py", line 406, in from_dict
raise ValueError('%s: Unknown TLV Class %s in %s; expected %s' %
ValueError: auto_collection_DeviceConfigDO(<class 'pySim.ara_m.DeviceInterfaceVersionDO'>): Unknown TLV Class DeviceInterfaceVersionDO in [{'DeviceInterfaceVersionDO': {'major': 0, 'minor': 0, 'patch': 1}}]; expected dict_keys(['device_interface_version_do'])
EXCEPTION of type 'ValueError' occurred with message: auto_collection_DeviceConfigDO(<class 'pySim.ara_m.DeviceInterfaceVersionDO'>): Unknown TLV Class DeviceInterfaceVersionDO in [{'DeviceInterfaceVersionDO': {'major': 0, 'minor': 0, 'patch': 1}}]; expected dict_keys(['device_interface_version_do'])
pySIM-shell (MF/ADF.ARA-M)>
pySIM-shell (MF/ADF.ARA-M)> aram_get_all
[
{
"response_all_ref_ar_do": [
{
"ref_ar_do": [
{
"ref_do": [
{
"aid_ref_do": "ffffffffffff"
},
{
"dev_app_id_ref_do": "550f1a164ccd48d27a5ea3b765957493cd830171"
}
]
},
{
"ar_do": [
{
"perm_ar_do": {
"permissions": "0000000000000001"
}
}
]
}
]
}
]
}
]
</pre> Retrocomputing - Bug #5939 (In Progress): Assemble GraphicGremlin / isavideohttps://projects.osmocom.org/issues/59392023-03-06T16:39:24Zlaforge
<p><a class="external" href="https://github.com/schlae/graphics-gremlin">https://github.com/schlae/graphics-gremlin</a></p> libosmo-abis - Bug #5896 (Feedback): libosmo-abis built withtout --enable-e1d in deb and rpm pack...https://projects.osmocom.org/issues/58962023-02-07T11:06:06Zpespin
<p>I see there's a "--enable-e1d" which then makes libosmo-abis depend on osmo-e1d.git, but I see that not being enabled for deb nor rpm builds, the dependencies are missing there. (debian/* and contrib/*.spec.in)</p>
<p>First we need to find out whether we want to have that enabled in package repositories. Then pass --enable-e1d and update the dependencies.</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://projects.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> osmo-remsim - Bug #5891 (New): bankd: potential pthread deadlock reported by coverityhttps://projects.osmocom.org/issues/58912023-02-03T19:35:22Zlaforge
<pre>
*** CID 307529: Program hangs (ORDER_REVERSAL)
/source-Osmocom/osmo-remsim/src/server/rspro_server.c: 782 in event_fd_cb()
776 }
777
778 LOGP(DMAIN, LOGL_INFO, "Event FD arrived, checking for any pending work\n");
779
780 pthread_rwlock_rdlock(&srv->rwlock);
781 llist_for_each_entry(conn, &srv->banks, list) {
>>> CID 307529: Program hangs (ORDER_REVERSAL)
>>> Calling "pthread_rwlock_rdlock" acquires lock "slotmaps.rwlock" while holding lock
"rspro_server.rwlock" (count: 2 / 5).
782 slotmaps_rdlock(srv->slotmaps);
783 non_empty_new = llist_empty(&conn->bank.maps_new);
784 non_empty_del = llist_empty(&conn->bank.maps_delreq);
785 slotmaps_unlock(srv->slotmaps);
786
787 /* trigger FSM to send any pending new/deleted maps */
</pre> osmo-e1d - Bug #5824 (Feedback): Line dead message in the log after starthttps://projects.osmocom.org/issues/58242022-12-12T20:57:41Zperformer
<p>In half cases I have next message in the log:<br /><0000> intf_line.c:95 (I0:L0) Received Only 0 bytes/s (expected: 262144): Line dead?</p>
<p>Also no traffic on client socket. Restart of e1d helps.</p> OCTOI - Osmocom Community TDM over IP - Bug #5694 (Stalled): BERT testinghttps://projects.osmocom.org/issues/56942022-10-01T06:59:48Zlaforge
<p>Soem initial tests with a PrTel93i doing BERT testing on a single B-channel indicates we have some problems to investigate.</p>
<p>This ticket serves as log of the various tests/attempts so far</p>
<ul>
<li>PrTel93i against same PrTel93i doing internal call through Auerswald COMmander2 PBX
<ul>
<li>0 errors in several 1min and 15min calls. So the PrTel and the wiring are good.</li>
</ul></li>
</ul>
<ul>
<li>PrTel93i against same PrTel93i doing external call through same PBX but going out via icE1usb to OCTOI hub and calling back through the same path:
<ul>
<li>first 1min call was with 0 errors</li>
<li>first 15min call was with 6.62 E-2 BER</li>
<li>second 15min call was with 5.92 E-2 BER</li>
<li>no lost / reordered OCTOI frames observed during that time</li>
</ul></li>
</ul>
<ul>
<li>PrTel93i against bchan_loop from capi-hacks (hfc-usb, mISDN, CAPI20) doing internal call through Auerswald COMmander2 PBX
<ul>
<li>1min call with 4.25 E-1 BER</li>
<li>so clearly there are some problems in the misdn/capi integration</li>
</ul></li>
</ul> Retronetworking - Bug #5681 (New): Figure out suitable connectors for EKSOShttps://projects.osmocom.org/issues/56812022-09-15T15:47:06Zlaforge
<p>While we did receive a few cables for EKSOS, many of them are missing, so I am looking for suitable alternative cables.</p>
<ul>
<li>EKSOS shelf DC power connector is confirmed to be a TE 350766-1 (contacts for 2.5mm2 wire: 640310-3)</li>
<li>EKSOS NCU E1 connector is <em>almost</em> a Harting 09232326824. Almost in that the clip-on frame has some notches, so the clip-on guide would have to be removed.</li>
<li>EKSOS POTS/ISDN line card subscriber line conncetor is <strong>not</strong> a typical 32pin 3-row DIN "C" connector. While both the EKSOS and this connector have pins every second position in the outer two rows, the order is exactly reversed: The standard DIN Connector has pins where EKSOS has none, and vice versa. A 64pos DIN C connector should work, assuming one then simply doesn't use every second pin present.</li>
</ul>
<p>The original manfacturer of those connectors (Perlos corporation of Joensuu, Finland) <a href="https://www.thefreelibrary.com/Finland%27s+Perlos+Corporation+sells+Special+Products+and+Connectors...-a0163748830" class="external">sold the connector business to Valuukumpu/M2 LTD in 2007</a></p>
<p><a href="https://www.cambridgeelectronics.com/DIN-41612-connectors" class="external">Cambridge Electronics</a> seems to be selling compatible connectors for at least some configurations, using seemingly the same retention lock / frame construction as featured on the EKSOS units.</p> OsmoMSC - Bug #5564 (Stalled): blocking database I/O by SMS databasehttps://projects.osmocom.org/issues/55642022-05-15T14:18:42Zlaforge
<p>when OsmoMSC was split from OsmoNITB, we externalized the HLR database and removed the database-stored counters. This leaves the internal SMS queue / database code as the only remaining part of code which performs potentailly blocking disk I/O.</p>
<p>As seen in <a class="issue tracker-1 status-7 priority-3 priority-high3" title="Bug: OsmoMSC sometimes stalls for dozens of seconds in a production deployment (Stalled)" href="https://projects.osmocom.org/issues/5563">#5563</a> this is a real issue.</p>
I spent half a day on reviewing the code in detail and playing with different ideas, including
<ol>
<li>ripping out the sms_queue.c / db.c code completely into an external osmo-smsc which then uses GSUP</li>
<li>just moving db.c into a separate thread; make DB operations asynchronous</li>
<li>move sms_queue + db.c into a separate thread</li>
</ol>
<a name="moving-sms_queue-DB-code-to-new-osmo-smsc-intrfaced-via-GSUP"></a>
<h2 >moving sms_queue + DB code to new osmo-smsc, intrfaced via GSUP<a href="#moving-sms_queue-DB-code-to-new-osmo-smsc-intrfaced-via-GSUP" class="wiki-anchor">¶</a></h2>
<p>osmo-msc already contains code to do SMS via GSUP, so there's no mandatory modification to osm-msc expected in this approach.</p>
the major disadvantages of this appraoch are:
<ul>
<li>SMPP code would have to move to SMSC, and it is more tied into the MSC/VLR codebase -> extra effort</li>
<li>GSUP SMS interface is at a lower level than current sms_queue intrface -> extra effort of migrating/reimplementing that stuff in SMSC</li>
</ul>
<a name="SMS-related-VTY-commands-not-an-issue-SMSC-would-have-its-own-VTY"></a>
<h3 >SMS related VTY commands (not an issue, SMSC would have its own VTY)<a href="#SMS-related-VTY-commands-not-an-issue-SMSC-would-have-its-own-VTY" class="wiki-anchor">¶</a></h3>
<p>this would cover the following API parts</p>
<ul>
<li>sms_queue_clear</li>
<li>sms_queue_set_max_failure</li>
<li>sms_queue_set_max_pending</li>
<li>sms_queue_stats</li>
<li>sms_queue_sms_is_pending</li>
<li>sms_queue_trigger</li>
<li>vty_out</li>
</ul>
<a name="incoming-signals-into-sms_queue"></a>
<h3 >incoming signals into sms_queue<a href="#incoming-signals-into-sms_queue" class="wiki-anchor">¶</a></h3>
<ul>
<li>SS_SUBSCR / S_SUBSCR_ATTACHED
<ul>
<li>FIXME: unclear how this is handled in the GSUP case?</li>
</ul>
</li>
<li>SS_SMS / S_SMS_DELIVERED
<ul>
<li>-> gsm411_gsup_mt_fwd_sm_res()</li>
</ul>
</li>
<li>SS_SMS / S_SMS_MEM_EXCEEDED
<ul>
<li>-> gsm411_gsup_mt_fwd_sm_err()</li>
</ul>
</li>
<li>SS_SMS / S_SMS_UNKNOWN_ERROR
<ul>
<li>-> gsm411_gsup_mt_fwd_sm_err()</li>
</ul>
</li>
<li>SS_SMS / S_SMS_SUBMITTED
<ul>
<li>-> gsm411_gsup_mo_fwd_sm_req()</li>
</ul>
</li>
<li>SS_SMS / S_SMS_SMMA
<ul>
<li>-> gsm411_gsup_mo_ready_for_sm_req()</li>
</ul></li>
</ul>
<a name="DB-not-an-issue-DB-code-would-then-run-in-SMSC"></a>
<h3 >DB (not an issue, DB code would then run in SMSC)<a href="#DB-not-an-issue-DB-code-would-then-run-in-SMSC" class="wiki-anchor">¶</a></h3>
<ul>
<li>db_sms_delete_oldest_expired_message</li>
<li>db_sms_delete_sent_message_by_id</li>
<li>db_sms_get</li>
<li>db_sms_get_next_unsent_rr_msisdn</li>
<li>db_sms_get_unsent_for_subscr</li>
<li>db_sms_inc_deliver_attempts</li>
</ul>
<a name="SMS-transmission"></a>
<h3 >SMS transmission<a href="#SMS-transmission" class="wiki-anchor">¶</a></h3>
<ul>
<li>gsm411_send_sms calls by sms_queue
<ul>
<li>would have to be mapped to OSMO_GSUP_MSGT_MT_FORWARD_SM_REQUEST</li>
</ul>
</li>
<li>sms_free
<ul>
<li>FIXME: what about vsub pointer/references?</li>
</ul>
</li>
<li>vlr_subscr_msisdn_or_name
<ul>
<li>just for logging, can be avoided</li>
</ul></li>
</ul>
<a name="making-just-the-DB-code-async-run-in-separate-thread"></a>
<h2 > making just the DB code async / run in separate thread<a href="#making-just-the-DB-code-async-run-in-separate-thread" class="wiki-anchor">¶</a></h2>
Is not easy as all of the call sites are assuming synchronous return/results<br />db_sms_get
<ul>
<li>sms_resend_pending
<ul>
<li>resend_pending timer
<ul>
<li>sms_queue_start
<ul>
<li>=> can be executed from separate thread</li>
</ul></li>
</ul></li>
</ul></li>
</ul>
db_sms_get_next_unsent_rr_msisdn
<ul>
<li>smsq_take_next_sms
<ul>
<li>sms_submit_pending
<ul>
<li>sms_send_next
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED
<ul>
<li>=> happens from the send_next it_Q completion handler</li>
</ul>
</li>
</ul>
</li>
<li>push_queue_timer
<ul>
<li>sms_queue_start
<ul>
<li>=> can be executed from separate thread</li>
</ul></li>
</ul></li>
</ul></li>
</ul></li>
</ul>
db_sms_get_unsent_for_subscr
<ul>
<li>sms_send_next
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED
<ul>
<li>=> request to it_Q; completion then might add SMS to pending + gsm411_send_sms</li>
</ul>
</li>
</ul>
</li>
<li>sub_ready_for_sm
<ul>
<li>sms_subscr_cb / S_SUBSCR_ATTACHED
<ul>
<li>=> request to it_Q; completion then might add SMS to pending + gsm411_send_sms</li>
</ul></li>
</ul></li>
</ul>
db_sms_delete_sent_message_by_id
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED
<ul>
<li>=> no return value, no success check: async it_Q</li>
</ul></li>
</ul>
db_sms_inc_deliver_attempts
<ul>
<li>sms_sms_cb / S_SMS_UNKNOWN_ERROR
<ul>
<li>=> no return value, no success check: async it_Q</li>
</ul></li>
</ul>
db_sms_delete_oldest_expired_message
<ul>
<li>sms_sms_cb / any signal
<ul>
<li>=> no return value, no success check: async it_Q</li>
</ul></li>
</ul>
<a name="moving-sms_queue-DB-code-to-separate-thread"></a>
<h2 >moving sms_queue + DB code to separate thread<a href="#moving-sms_queue-DB-code-to-separate-thread" class="wiki-anchor">¶</a></h2>
<a name="access-to-pending_sms-linked-list"></a>
<h3 >access to pending_sms linked list<a href="#access-to-pending_sms-linked-list" class="wiki-anchor">¶</a></h3>
<p>There are quite a number of accesses to the pending_sms linked list. Given most ar read, and only some are write, we might use a rwlock?</p>
<ul>
<li>sms_find_pending [R]
<ul>
<li>sms_sms_cb</li>
<li>sms_queue_sms_is_pending</li>
</ul></li>
</ul>
<ul>
<li>sms_queue_sms_is_pending [R]
<ul>
<li>sms_submit_pending
<ul>
<li>timer</li>
</ul>
</li>
<li>vty</li>
</ul></li>
</ul>
<ul>
<li>sms_subscriber_find_pending [R]
<ul>
<li>sub_ready_for_sm
<ul>
<li>SS_SUBSCR / S_SUBSCR_ATTACHED</li>
</ul>
</li>
<li>sms_subscriber_is_pending
<ul>
<li>sms_submit_pending
<ul>
<li>timer</li>
</ul>
</li>
<li>sms_send_next
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED</li>
</ul></li>
</ul></li>
</ul></li>
</ul>
<ul>
<li>sms_pending_from [R]
<ul>
<li>sms_submit_pending
<ul>
<li>timer</li>
</ul>
</li>
<li>sms_send_next
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li>sms_pending_free [W]
<ul>
<li>sms_pending_failed
<ul>
<li>sms_sms_cb / S_SMS_UNKNOWN_ERROR</li>
</ul>
</li>
<li>sms_resend_pending
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED</li>
<li>sms_sms_cb / S_SMS_MEM_EXCEEDED</li>
</ul>
</li>
<li>sms_queue_clear
<ul>
<li>vty</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li>sms_resend_pending [R]
<ul>
<li>timer</li>
</ul></li>
</ul>
<ul>
<li>sms_queue_stats [R]
<ul>
<li>vty</li>
</ul></li>
</ul>
<ul>
<li>sms_queue_clear [W]
<ul>
<li>vty</li>
</ul></li>
</ul>
<a name="Conclusion"></a>
<h2 >Conclusion<a href="#Conclusion" class="wiki-anchor">¶</a></h2>
I think the following approach is best:
<ul>
<li>have a separate "SMS" thread</li>
<li>all database access happens <strong>from that thread only</strong></li>
<li>inter-thread message queues (libosmocore it_q) between main thread and SMS thread</li>
<li>sms_queue timers (push_queue_timer, resend_pending_timer) run in that thread</li>
<li>other input (mainly signals today) are serialized via it_q in main -> SMS direction</li>
<li>other output (mainly gsm411_send_sms) are serialized via it_q in SMS -> main direction</li>
</ul>
<a name="Serialize-SS_SMS-signals"></a>
<h3 >Serialize SS_SMS signals<a href="#Serialize-SS_SMS-signals" class="wiki-anchor">¶</a></h3>
<ul>
<li>we really only need to serialize paging_result and sms->id</li>
<li>submit them into it_q to SMS thread</li>
</ul>
<a name="serialize-SS_SUBSCR-signal"></a>
<h3 >serialize SS_SUBSCR signal<a href="#serialize-SS_SUBSCR-signal" class="wiki-anchor">¶</a></h3>
<ul>
<li>sms_subscriber_find_pending() can be done in main thread before serialization</li>
<li>check for vsub->lu_complete and zero MSISDN before serialization</li>
<li>we really only need to serialize the MSISDN</li>
<li>db_sms_get_unsent_for_subscr() then happens from SMS thread</li>
</ul>
<a name="move-push_queue_timer-resend_pending_timer-to-SMS-thread"></a>
<h3 >move push_queue_timer + resend_pending_timer to SMS thread<a href="#move-push_queue_timer-resend_pending_timer-to-SMS-thread" class="wiki-anchor">¶</a></h3>
<a name="serialize-db_sms_store-MO-SMS-SMPP"></a>
<h3 >serialize db_sms_store() (MO-SMS, SMPP)<a href="#serialize-db_sms_store-MO-SMS-SMPP" class="wiki-anchor">¶</a></h3>
<ul>
<li>failure to store in database would only be known asynchronously!</li>
<li>we can probably just ignore that.</li>
</ul>
<a name="serialize-db_sms_mark_delivered"></a>
<h3 >serialize db_sms_mark_delivered()<a href="#serialize-db_sms_mark_delivered" class="wiki-anchor">¶</a></h3>
<ul>
<li>we don't care about success right now anyway, so async is no problem</li>
</ul>
<a name="VTY"></a>
<h3 >VTY<a href="#VTY" class="wiki-anchor">¶</a></h3>
<ul>
<li>remove 'sms send pending' or implement different command via it_Q</li>
<li>remove 'sms delete expired' or implement different command via it_Q</li>
<li>serialize 'subscriber ... sms ...' via it_Q</li>
</ul> SIMtrace 2 - Bug #5464 (In Progress): cardem firmware unable to attach to cardhttps://projects.osmocom.org/issues/54642022-02-21T19:07:57Zk_o_
<p>I'm using a Nexus 5 phone. I have a permanent problem that the remote SIM cannot be attached. I always see several RESETs after the phone is restarted. The trace firmware together with the command line works. The adapter cable is in a prepared SIM tray and works. What could be the issue?</p>
<pre>
simtrace2-cardem-pcsc --usb-vendor 1d50 --usb-product 60e3 --usb-path 2-1.4 --usb-config 1 -n 2
simtrace2-cardem-pcsc - Using PC/SC reader as SIM
(C) 2010-2020, Harald Welte <laforge@gnumonks.org>
(C) 2018, sysmocom -s.f.m.c. GmbH, Author: Kevin Redon <kredon@sysmocom.de>
<0002> simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
<0002> simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
<0002> simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
<0002> simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f c7 80 31 e0 73 f6 21 13 67 56 03 27 00 89 01 02 28 )
<0002> simtrace2_api.c:284 [0] <= _modem_reset(asserted=2, pulse_ms=300)
Entering main loop
-> 01 08 00 00 00 00 0d 00 01 00 00 00 00
SIMtrace IRQ 01 04 00 00 00 00 15 00 00 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x0, fi=1, di=1, wi=10 wtime=9600 ()
SIMtrace IRQ 01 04 00 00 00 00 15 00 10 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x10, fi=1, di=1, wi=10 wtime=9600 (RESET )
SIMtrace IRQ 01 04 00 00 00 00 15 00 00 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x0, fi=1, di=1, wi=10 wtime=9600 ()
SIMtrace IRQ 01 04 00 00 00 00 15 00 10 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x10, fi=1, di=1, wi=10 wtime=9600 (RESET )
</pre> SIMtrace 2 - Bug #5419 (Stalled): cardem errors with higher baud ratehttps://projects.osmocom.org/issues/54192022-01-25T18:27:00Zlaforge
Setup is as follows:
<ul>
<li>sysmoISIM-SJA2 in built-in CCID reader of my Thinkpad x260</li>
<li>SIMtrace2 with cardem firmware 'master' (0.8.1.7-ea9a) hooked up via FPC to</li>
<li>CCID reader "Identive CLOUD 2700 F" </li>
<li><code>simtrace2-cardem-pcsc</code> to forward request from IdentiveCCID -> SIMtrace -> st2-cardem-pcsc -> builtin-CCID</li>
</ul>
<p>This works fine with F/D ratio 372, and also works fine in most cases with F/D ratio 16.</p>
<p>However, sometimes with ratio 16, things break down at some point.</p>
<a name="log-output-of-cardem-firmware"></a>
<h2 >log output of cardem firmware<a href="#log-output-of-cardem-firmware" class="wiki-anchor">¶</a></h2>
<pre>
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9d 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9e 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9f 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 a0 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
N-I- 0: send_tpdu_header: 00 b2 a1 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
N-I- 0: send_tpdu_header: 00 c0 00 00 60
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 02 00 a4 00 04
-I- 0: flush_rx_buffer (5)
</pre>
two things noticable:
<ul>
<li>the 'N' being printed by card_emu as waiting time extension</li>
<li>the last TPDU header <code>02 00 a4 00 04</code> doesn't look like a TPDU header: The 02 seems wrong, the TPDU likely starts with <code>00 a4</code>.</li>
</ul>
<a name="situation-on-Identive-CCID-reader-side"></a>
<h2 >situation on "Identive CCID reader" side<a href="#situation-on-Identive-CCID-reader-side" class="wiki-anchor">¶</a></h2>
<p>pySim-shell "export" shows:<br /><pre>
update_record 159 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
update_record 160 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
update_record 161 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
# bad file: MF/DF.TELECOM/EF.ADN, Failed to transmit with protocol T0. Transaction failed.
EXCEPTION of type 'RuntimeError' occurred with message: '6881: Functions in CLA not supported - Logical channel not supported'
To enable full traceback, run the following command: 'set debug true'
</pre></p>
<a name="simtrace2-cardem-pcsc"></a>
<h2 >simtrace2-cardem-pcsc<a href="#simtrace2-cardem-pcsc" class="wiki-anchor">¶</a></h2>
<pre>
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9d 04 22
=> DATA: flags=1, 00 b2 9d 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9e 04 22
=> DATA: flags=1, 00 b2 9e 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9f 04 22
=> DATA: flags=1, 00 b2 9f 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 a0 04 22
=> DATA: flags=1, 00 b2 a0 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 a1 04 22
=> DATA: flags=1, 00 b2 a1 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 60
=> DATA: flags=1, 00 c0 00 00 60 : SW=0x6c23, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 02 00 a4 00 04
<0000> apdu_dispatch.c:112 Unknown APDU case 0
=> DATA: flags=1, 02 00 a4 00 04 : SW=0x6881, len_rx=0
</pre>
<p>it also agrees that this last APDU is somehow wrong and cannot determine the APDU case.</p>
<a name="USB-communication"></a>
<h2 >USB communication<a href="#USB-communication" class="wiki-anchor">¶</a></h2>
<p>last message from SIMtrace to host is "RX DATA" with header flag set and 0200a40004. The card still responds with SW 6881 to that, as obviously the APDU header is invalid.</p>
<p><img src="https://projects.osmocom.org/attachments/download/4852/wireshark.png" alt="" /></p> E1/T1 Hardware Interface (including icE1usb) - Bug #5381 (New): icE1usb DAHDI driver: generate YE...https://projects.osmocom.org/issues/53812022-01-02T12:16:29Zlaforge
<p>Right now we are displaying YELLOW alarms received from the peer, but we don't yet report a RED alarm using RAI bits to the peer.</p> erlang/osmo_ss7 - Bug #5378 (New): ipa: add support for client applicationhttps://projects.osmocom.org/issues/53782021-12-30T19:23:19Zlynxis
<p>The osmo_dia2gsup is using the ipa module.<br />The ipa module is sending an "Identity Request" after the connection is established. The osmo-hlr will treat this early identity request as invalid and will never answer to it.</p>
<pre>
diff --git a/src/ipa_proto.erl b/src/ipa_proto.erl
index ceb024a..1a6ca4f 100644
--- a/src/ipa_proto.erl
+++ b/src/ipa_proto.erl
@@ -120,10 +120,6 @@ request({ipa_set_ccm_options, Socket, CcmOptions}, _) ->
{ccm_options, CcmOptions};
% server-side handler for unblock()
request({ipa_unblock, Socket}, CcmOptions) ->
- if
- CcmOptions#ipa_ccm_options.initiate_ack -> send_ccm_id_ack(Socket);
- true -> send_ccm_id_get(Socket)
- end,
io:format("Unblocking socket ~p~n", [Socket]),
%[IpaSock] = ets:lookup(ipa_sockets, Socket),
Ret = inet:setopts(Socket, [{active, once}]),
</pre> OsmoBSC - Bug #4614 (Stalled): "bogus channel load sample" when using BS-11, Nokia or Ericsson BTShttps://projects.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> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://projects.osmocom.org/issues/45992020-06-08T18:05:33Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:</p>
<pre>
<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.
</pre>
<p>I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.</p>
<p>The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.</p>
<p><a class="user active" href="https://projects.osmocom.org/users/1741">lynxis</a> any ideas?</p> libosmo-abis - Bug #4464 (In Progress): "osmo_rtp_socket_poll(): ERROR!" messages during normal o...https://projects.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> SIMtrace 2 - Bug #4430 (New): firmware can get in endless out-of-memory loop on OUT EP floodhttps://projects.osmocom.org/issues/44302020-03-01T15:06:25Zlaforge
<p>When flooding the OUT EP with too many messages, the firmware can get into an OOM situation from which it doesn't recover anymore. All it will do is print the below messages:</p>
<pre>
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
</pre>
<p>I'm currently reproducing this with a test case that sends 1000 bogus OUT EP transfers to the device.</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://projects.osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> SIMtrace 2 - Bug #4041 (New): implement SIMTRACE_CMD_BD_BOARD_INFOhttps://projects.osmocom.org/issues/40412019-06-04T15:57:19Zlaforge
<p>this command is supposed to return the hardware manufacturer, hardware version as well as software version information. It would be very useful to obtain the currently running firmware versin as well as other details.</p> OsmoBTS - Bug #3568 (Stalled): CBCH on SDCCH/8 not working for osmo-bts-sysmohttps://projects.osmocom.org/issues/35682018-09-18T20:54:03Zlaforge
<p>During manual testing I observed that while sms arrived on my test phone when using CBCH on SDCCH/4, they were not arriving when using CBCH on SDCCH/8.</p>
<p>SI4 CBCH location was updated properly, so that was not the cause...</p> SIMtrace 2 - Bug #3379 (Stalled): documentation on how to use SIMtrace2https://projects.osmocom.org/issues/33792018-07-04T16:10:36Zlaforge
<p>the wiki in the SIMtrace2 redmine project currently only documents flashing, but there should of course be good information on how to use the host tools in order to run the complete system.</p> Cellular Network Infrastructure - Bug #3192 (New): meas_vis: use the lchan identity as primary ke...https://projects.osmocom.org/issues/31922018-04-21T19:21:40Zneelsnhofmeyr@sysmocom.de
<p>While re-adding meas_feed to osmo-bsc.git, I noticed that the meas_vis and meas_web tools appear to use the lchan's IMSI as primary key to visualizing active lchans. They should use the bts,trx,ts,ss number instead.</p>
<p>See also: <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: resurrect meas_feed (Resolved)" href="https://projects.osmocom.org/issues/2968">#2968</a> <a class="issue tracker-2 status-3 priority-1 priority-lowest closed" title="Feature: obtain and store subscriber identity (Resolved)" href="https://projects.osmocom.org/issues/2969">#2969</a></p>
<p>meas_vis is currently still in openbsc.git, it should probably move over to osmo-bsc <a class="issue tracker-2 status-6 priority-2 priority-default closed" title="Feature: move meas_vis and meas_json over to osmo-bsc.git (Rejected)" href="https://projects.osmocom.org/issues/3191">#3191</a>.<br />meas_web is external, but it could make sense to send a pull request.</p> OsmoMSC - Bug #2933 (New): change of trans->bearer_cap (e.g. via MNCC) will not trigger BSSMAP AS...https://projects.osmocom.org/issues/29332018-02-12T11:36:39Zlaforge
<p>Whenever the trans->bearer_cap change (e.g.due to a CC MODIFY or MNCC MODIFY), the MSC must chck if the new bearer capabilities are different from the old bearer capabilities, and subsequently trigger a BSSMAP ASSIGNMENT towards the BSS.</p>
<p>Currently, the handling of bearer_cap will in only work if the related CC/MNCC message with <br />besrer_cap IE happens before the pint in time at which the MSC performs the BSSMAP ASSIGNMENT<br />procedure. Our logic still needs to change in a way that the CC/MNCC <br />code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and<br />in that case triggers a new follow-up BSSMAP ASSIGNMENT.</p> OsmoPCU - Bug #2383 (New): incompatibility with some SGSNs during P-TMSI allocationhttps://projects.osmocom.org/issues/23832017-07-20T15:23:17Zlaforge
When OsmoSGSN talks to OsmoPCU during a P-TMSI allocation (e.g. as part of GMM ATTACH ACCEPT), it sends that GMM ATTACH ACCEPT in a BSSGP DL-UNITDATA BSSGP PDU structured as follows:
<ul>
<li>include the IMSI IE (after authentication the SGSN knows the IMSI and shall include it as per TS 08.18)</li>
<li>include the TLLI IE, stating the previous TLLI derived from the old P-TMSI. This makes sense, given the fact that the MS cannot yet know the new P-TMSI which is about to be allocated now</li>
<li>include the MS Radio Access Capability IE filled in with information from the GMM ATTACH REQUEST</li>
<li>does not include any "OLD TLLI" IE</li>
</ul>
When talking to an unknown version of a Quortus SGSN, the behavior is different. The GMM ATTACH ACCEPT in BSSGP DL-UNITDATA
<ul>
<li>does not include the IMSI IE (despite the SGSN knowing the IMSI, i.e. it is a violation of TS 08.18)</li>
<li>includes the TLLI IE with a TLLI derived from the new to-be-communicated P-TMSI</li>
<li>includes no MS Radio Access Capability IE, despite the MS having sent them in the GMM ATTACH REQUEST</li>
<li>includes an OLD TLLI IE with the TLLI derived from the P-TMSI that was in use until now.</li>
</ul>
<p>This results in OsmoPCU not being able to deliver the GMM ATTACH ACCEPT to the MS, and subsequently the ATTACH operation timing out at the SGSN, folowed by several (re-)transmissions of a SGSN-initiated GMM DETACH REQUEST (which is equally not delieverd by OsmoPCU).</p>
We need to investigate
<ul>
<li>which parts of the Quortus behavior are within spec and which are out of spec</li>
<li>whether OsmoSGSN behaves within spec</li>
<li>whether OsmoPCU can be easily extended to comply with both approaches</li>
</ul> Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://projects.osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p>