Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-06T12:08:24ZOpen Source Mobile Communications
Redmine Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Feature #6392 (New): video recording / c...https://osmocom.org/issues/63922024-03-06T12:08:24Zlaforge
<p>We need to check how we can get c3voc video recording equipment on-site and who will operate it.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Bug #6291 (New): 2024 event bringing tog...https://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> Retronetworking - Feature #6219 (New): Publish pics/videos for EWSD rescue/movehttps://osmocom.org/issues/62192023-10-17T14:10:34Zlaforge
<p>Before publishing more pictures and/or videos, have to clarify</p>
<ul>
<li>individual permission (rights to one's own picture) or in the worst case pixelize some individuals</li>
<li>corporate permission (other equipment which might be visible around the EWSD)</li>
<li>find a good way to publish an entire gallery of pictures + videos, possibly with captions</li>
<li>cut out the lunch breaks from the timelapse videos</li>
<li>provide down-scaled (HD?) versions of the videos for people who don't want to download or stream gigabytes...</li>
<li>some kind of intro / title slide for the videos (just to give context)</li>
</ul> Retronetworking - Feature #6218 (New): write article/report on EWSD rescue for IGHFT / Fernmeldem...https://osmocom.org/issues/62182023-10-17T14:05:27Zlaforge
<p>I'm a member there and it would be nice to get a report into their member magazine "Tele-Kurier" (not publicly available). Still it might be there are some people with interest not only for electromechanical switching.</p>
<p><a class="external" href="https://fernmeldemuseum-dresden.de/">https://fernmeldemuseum-dresden.de/</a></p> osmo-e1d - Bug #6169 (New): Frame masking against network frame ordering, not frame numbershttps://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> osmo-remsim - Bug #5891 (New): bankd: potential pthread deadlock reported by coverityhttps://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> Retronetworking - Feature #5855 (New): Establishing a German non-profit for retronetworkinghttps://osmocom.org/issues/58552023-01-13T11:43:49Zlaforge
<p>While we all have a lot of fun researching and implementing various bits of ancient communication systems, I think there are aspects of our work that deserve to be done under a formal/legal entity that should hopefully outlive the current protagonists, and also protect us against "loss" of individuals (changes in personal life, health issues, ...)</p>
<p>I'm particularly thinking of the <em>archieval and documentation</em> aspects, such as digitizing old specs and books, documenting the cirucit boards, data sheets, etc.</p>
<p>I'll continue this ticket and related information in German, as I expect a lot of the legal/organization aspects are in German, and [almost?] all initial founding members would be German.</p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> Retronetworking - Bug #5681 (New): Figure out suitable connectors for EKSOShttps://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> osmo-clock-gen - Feature #5633 (New): towards a first osmo-clock-gen production batchhttps://osmocom.org/issues/56332022-07-26T12:39:18Zlaforge
<p>A batch of 100 unit Si5351C that I ordered a long time ago has finally arrived. This means we have the most critical part in stock now for a first batch.</p>
<p>The main problem now is the uC situation. We originally chose the SAMD1x and later SAMD2x as they are lower cost and lower complexity compared to the SAM3S or other uC we use in other designs. However, SAMD21 are not available on the market today. One variant might be available in November 2022, while others have lead times to July 2023.</p>
<p>So what uC to use? For example, RP2040 would be available in quantity at ultra low cost. Disadvantage: no internal Flash, so we'd need a SPI flash. Alternatively use something like "RP2040-Zero":<br /><a class="external" href="https://www.waveshare.com/rp2040-zero.htm?sku=20187">https://www.waveshare.com/rp2040-zero.htm?sku=20187</a> which is a small daughterboard with RP2040 + SPI flash + USB-C...</p> osmo-remsim - Feature #5614 (New): log also application-level errorshttps://osmocom.org/issues/56142022-07-11T20:09:58Zlaforge
<p>Right now all the logging just relates to the remsim transport layer. However, it would be rather useful to also check the SW of the SIM communication and log errors whenever non-successful SW are observed. Or at least warnings. This could help us to identify where/when communicatiaon between modem and SIM goes wrong. The best location for this is probably the client, as this is also where (if at all) we are accidentially breaking the communication on the UART.</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> OsmocomBB - Feature #5466 (New): CP2102N evaluation for burst_ind baudratehttps://osmocom.org/issues/54662022-02-22T13:11:29Zlaforge
<p>CP2102N EVB has arrived:</p>
<pre>
Bus 001 Device 022: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x10c4 Silicon Labs
idProduct 0xea60 CP210x UART Bridge
bcdDevice 1.00
iManufacturer 1 Silicon Labs
iProduct 2 CP2102N USB to UART Bridge Controller
iSerial 3 48022d00e29feb11989dd1acdf749906
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
</pre> OCTOI - Osmocom Community TDM over IP - Feature #5442 (New): ensure sequence number covers longer...https://osmocom.org/issues/54422022-02-06T08:09:12Zlaforge
<pre>
08:40 < W|MPy> LaF0rge: IIRC with default timers calls in a PRI are supposed to survive a LOS of up to
10s, so I suggest you find at least a 17th bit for the frame sequence number.
09:04 < LaF0rge> W|MPy: we could mandate at least N frames in each packet (E.g. N=2) and then tranmit
only the upper bits
09:04 < LaF0rge> so if N=2 we already cover more than 10s
</pre> OCTOI - Osmocom Community TDM over IP - Feature #5429 (New): authentication in TDMoIP protocolhttps://osmocom.org/issues/54292022-01-30T10:42:43Zlaforge
<p>We need at least some minimalistic form of authentication to identify users/peers. Authentication must be challenge-response based, so that related credentials are never transmitted over the network.</p>
<p>Authentication should also be mutual. However, without integrity protection or encryption, this will of course not prevent against any type of MITM.</p> OsmoMSC - Feature #5403 (New): Can't connect Call from 2G to 4G networkhttps://osmocom.org/issues/54032022-01-14T22:41:37Zjavi-tic
<p>Hi, I've been testing GSM and LTE Networks from some months ago with Open5gs and Osmo core. <br />I'm using freeswitch and calls from 4G to 2G and just 2G network it works, I attach config files and pcap files when I make calls, on captured packets on 2G to 4G call I can't see SGsAP.<br />I've installed osmo binaries: <br /><pre><code>libosmo-gsup-client0 1.4.0 amd64
libosmo-mgcp-client9/unknown,now 1.9.0 amd64
libosmo-mslookup0/unknown,now 1.4.0 amd64
libosmo-ranap5/unknown,now 1.2.0 amd64
libosmo-sigtran7/unknown,now 1.5.0 amd64
libosmoabis10/unknown,now 1.2.0 amd64
libosmocodec0/unknown,now 1.6.0 amd64
libosmocoding0/unknown,now 1.6.0 amd64
libosmocore-utils/unknown,now 1.6.0 amd64
libosmocore18/unknown,now 1.6.0 amd64
libosmocore/unknown,now 1.6.0 amd64
libosmoctrl0/unknown,now 1.6.0 amd64
libosmogb12/unknown,now 1.6.0 amd64
libosmogsm17/unknown,now 1.6.0 amd64
libosmonetif8/unknown,now 1.1.0 amd64
libosmosim2/unknown,now 1.6.0 amd64
libosmotrau2/unknown,now 1.2.0 amd64
libosmousb0/unknown,now 1.6.0 amd64
libosmovty9/unknown,now 1.6.0 amd64
osmo-bsc-meas-utils/unknown,now 1.8.1 amd64
osmo-bsc/unknown,now 1.8.1 amd64
osmo-hlr/unknown,now 1.4.0 amd64
osmo-mgw/unknown,now 1.9.0 amd64
osmo-msc/unknown,now 1.8.0 amd64
osmo-sgsn/unknown,now 1.8.0 amd64
osmo-sip-connector/unknown,now 1.6.0 amd64
osmo-stp/unknown,now 1.5.0 amd64
osmocom-latest/unknown,now 1.0.0 amd64
</code></pre></p>
<p>and open5gs binaries: <br /><pre><code>
open5gs-common/unknown,now 2.4.1 amd64
open5gs-hss/unknown,now 2.4.1 amd64
open5gs-mme/unknown,now 2.4.1 amd64
open5gs-pcrf/unknown,now 2.4.1 amd64
open5gs-sgwc/unknown,now 2.4.1 amd64
open5gs-sgwu/unknown,now 2.4.1 amd64
open5gs-smf/unknown,now 2.4.1 amd64
open5gs-upf/unknown,now 2.4.1 amd64
</code></pre></p>
<pre><code>
Freswitch version: 1.10.6</code></pre><br /><pre><code>
Devices:
BTS: SysmoBTS 1020
eNB: BaiCell Nova 249
Computer with OsmoCore + Open5gs:
Distro: Debian 10
</code></pre> erlang/osmo_ss7 - Bug #5378 (New): ipa: add support for client applicationhttps://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> pySim - Feature #5268 (New): pySim-shell: GlobalPlatform SCP02 supporthttps://osmocom.org/issues/52682021-10-14T19:12:12Zlaforge
<p>It would be nice to have SCP02 support in pySim-shell so that at least gradually we can have some GP related shell commands available (installation/removal/locking/unlocking of cardlets, key updates).</p>
<p>There is an old python2 code base on github implementing (among other things) SCP02: <a class="external" href="https://github.com/suma12/asterix">https://github.com/suma12/asterix</a></p>
<p>It looks fairly unmaintained. Let's have a look if we can bring it to python3 and test it.</p> pySim - Feature #5127 (New): tool for "re-formatting" [sysmocom] cards in testerhttps://osmocom.org/issues/51272021-04-23T08:07:23Zlaforge
<p>In our automatic testing of pySim, we (every so often) run into the problem of some prior test case execution (e.g. as part of gerrit build verification) leaving the card in a different state than expected by the next test case execution.</p>
<p>We would need a tool that would "re-format" the card, to ensure it always is in 100% the expected state. At least for sysmoISIM-SJA2, sysmoTSIM-SJA1, sysmoUSIM-SJA2 and other "recent" card models this is very much possible.</p>
The tool should ideally be "generic" so it can be parametrized with
<ul>
<li>the specific card profile and profile version to load</li>
<li>the personalization script to use (to set keys/PINs/...)</li>
</ul>
<p>That way the tool can be used for all current and future card models.</p>
<p>We will be installing it on the build slave in a way that only 'root' has access to the tool and related files, and the jenkins-build user will get sudo privilege only to execute the tool but not to read or modify the card profiles etc.</p> OsmoBSC - Bug #4683 (New): properly report OM2000 bring-up problemshttps://osmocom.org/issues/46832020-07-30T06:50:59Zlaforge
<p>If there is a mismatch between hardware or IDB configuration and the osmo-bsc configuration, the OM2000 bring-up will fail in various ways. This is not clearly visible at the moment, and in many situations the user will not be aware that anything has been going wrong. In some situations RSL will simply never be initialized successfully - in some other situations even RSL comes up without errors, but the RBS simpyl doesn't transmit.</p>
The most important indications we get from the RBS:
<ul>
<li>some Enable Result, particularly on the TX or TRXC, <em>not according to request</em>, optionally with information which IE is causing the problem</li>
<li>Failure Maps</li>
</ul>
Let's make sure that
<ul>
<li>the related errors are logged at ERROR level (in human-readable form)</li>
<li>the state of the MO is easily available via introspection/VTY</li>
<li>we document how to deal with this in the user manual or wiki</li>
</ul> OsmoBSC - Feature #4650 (New): Add BIG FAT error message in case OM2000 BTS fail to start uphttps://osmocom.org/issues/46502020-07-04T19:30:38Zlaforge
<p>I was using the internal XO of a Digium DAHDI E1 card while tryign to bring up my RBS2308, and failed for multiple days to do so.</p>
Intrestingly, the TF ca nbe fully broguht up (enabled / operational), but the failure shows in a very weird way:
<ul>
<li>The TX ENABLE RESULT shows <em>MO State: DISABLED</em> and points to the <em>Attribute Idnetifier: ARFCN TX</em></li>
</ul>
<p>This is completely misleading, as the ARFCN number is fully acceptable - it's just that the TRX refuses to come up while timing is not precise.</p>
<p>The only other thing that shows up in a trace is a <em>TF Fault Report</em> with <em>External Condition Map Class 1: 0300</em>.</p>
<p>We should print very descriptive error messags on either of those two events to make sure other people realize that all they have is a bad E1 clock.</p>
<p>(the way how I fixed it is to use a SIU slaved to GPS 1PPS which feeds the clock into one of the 4ports of a Digium Quad-E1, which then uses that port as clock source)</p> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://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://osmocom.org/users/1741">lynxis</a> any ideas?</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> osmo-gbproxy - Feature #4521 (New): gbproxy: Redundancy between NS-VCs (SGSN Side)https://osmocom.org/issues/45212020-05-01T13:39:26Zlaforge
<p>Each Server running osmo-gbproxy features multiple Ethernet Interfaces which can be connected to redundant Switches of a highly-available IP interconnect to the SGSN. The normal Gb/IP interface procedures of the IP-SNS ensure redundant NS-VCs are established via all of the Gb-Proxy side IP addresses.</p>
<p>We need to ensure that we continue to operate without interruption even when some of the NS-VCs to the SGSN are becoming unavailable.</p> SIMtrace 2 - Bug #4430 (New): firmware can get in endless out-of-memory loop on OUT EP floodhttps://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> BBS-Revival - Feature #4341 (New): setup for telnet access to legacy BBS software which doesn't h...https://osmocom.org/issues/43412020-01-01T14:06:50Zlaforge
There are plenty of legacy BBS software packages out there, made for DOS. They either directly interface the serial ports (COM1..COM4) or they use a FOSSIL driver to do so. Attaching those to<br />real serial ports with modems is possible, but not particularly attractive:
<ul>
<li>it requires one physical modem per node (and likely one USB/serial adapter)</li>
<li>it cannot provide direct IP (telnet/ssh) access</li>
<li>it cannot be combined with using a RAS server like our <a class="wiki-page" href="https://osmocom.org/projects/retro-bbs/wiki/Livingston_Portmaster_3">Livingston_Portmaster_3</a></li>
</ul>
<p>For some other OSs (Windows, OS/2) there are solutions like NetFoss to work around this. I've also found references to a DOS based telnet FOSS driver baesed on Ethernet cards with packet driver. No proper solution for a Linux based setup with qemu-kvm seems to be out there.</p>
Using the built-in serial port telnet server of qemu is one idea, but
<ul>
<li>it would mean each line (COM port) has a different telnet port</li>
<li>there doesn't seem to be any escaping for binary (0xFF, ...)</li>
</ul>
<p>One could build something based on <a class="external" href="https://github.com/freemed/tty0tty">https://github.com/freemed/tty0tty</a> (a virtual nullmodem device), so one side could be passed though qemu, and the other end could be served by some kind of custom telnet daemon. tty0tty has the advantage of at least handling the modem status/control lines properly - very uch opposed to any pty based approach.</p>
<p>The cleanest solution would probably be to implement something based on <a href="https://www.ietf.org/rfc/rfc2217.txt" class="external">RFC2217</a> (Telnet Com Port Control Option). This has the advantage that it fully supports modem control lines, and that it can also be used to interface any actual serial/terminal server hardware, if ever needed.</p>
<p>So either qemu would have to run a RFC2217 telnet server which would then accept e.g. up to 4 or 8 connections, and dispatching any of those to a virtual 8250 serial UART, or it would have to run one RFC2217 telnet client for each virtual 8250 UART.</p>
<p>In case of a <em>telnet server</em>, that server then would also have to implement something like AT command emulation, so the DOS applications think they're talking to a modem with RING/ATA/CONNECT/...</p>
In case of a qemu built-in <em>telnet client</em>, we would provide some kind of external program that provides two telnet servers:
<ol>
<li>one for the qemu side to connect to, and where we emulate a basic AT command interface</li>
<li>one for the actual users to connect to, either directly via IP or indirectly from dialup via the Portmaster</li>
</ol>
<p>I think the approach with qemu built-in telnet client with the external server makes most sense, as it offers greatest flexibility in terms of supported configurations. It also keeps things like AT command emulation out of qemu.</p>
<p><code>tnt</code> has implemented the qemu side in <a class="external" href="https://patchwork.kernel.org/patch/11149529/">https://patchwork.kernel.org/patch/11149529/</a> - but that patch unfortunately is still not yet merged, presumably due to a lack of tests and some other feedback raised by qemu developers. But with a custom qemu build, we could already use it here...</p> osmo-remsim - Feature #4249 (New): ability to explicitly provision an "empty SIM card slot" to a ...https://osmocom.org/issues/42492019-11-07T14:21:12Zlaforgelibosmocore - Bug #4149 (New): osmo_fsm allows event names to have spaces in themhttps://osmocom.org/issues/41492019-08-13T10:58:36Zlaforge
<p>See <a class="external" href="https://gerrit.osmocom.org/#/c/libosmocore/+/15154/">https://gerrit.osmocom.org/#/c/libosmocore/+/15154/</a></p>
<p>event names, like state names, should be one word <strong>only</strong>.</p> OsmoCBC - Feature #3977 (New): SABP stream delineation routineshttps://osmocom.org/issues/39772019-05-06T13:52:08Zlaforge
<p>SABP is not only specified as ASN.1 with APER encoding, but 3GPP in their infinite wisdom specified that it will run directly inside a TCP stream.</p>
<p>As TCP, like any stream, doesn't preserve message boudaries, there's no length field or other framing that would tell us once a given SABP PDU is fully received. Instead, we have to implement something like an "incremental APER length determinant parser" which will parse the outer length of the APER encoded data, and then use the result of that to determine the length of one binary/encoded SABP PDU.</p>
<p>See <code>dissect_per_length_determinant()</code> from wireshark <code>packet-per.c</code> which is actually used by the wireshark SABP dissector, facing the same problem.</p> libosmocore - Bug #1762 (New): Review LAPD code for race conditions regarding state, particularly...https://osmocom.org/issues/17622016-07-03T20:20:39Zlaforge
<p>See <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: LAPD: segfault in T200 call-back (Closed)" href="https://osmocom.org/issues/1760">#1760</a> and <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: LAPD: segfault when bootstrapping Nokia InSite (Resolved)" href="https://osmocom.org/issues/1761">#1761</a>, there are quite some problems that apparently need a more thorough review and/or testing.</p>
<p>Maybe implementing (part of?) the Q.921bis LAPD conformance tests might be an option to catch all of those kind of bugs?</p>
<p>See <a class="external" href="https://www.itu.int/rec/T-REC-Q.921bis-199303-I/en">https://www.itu.int/rec/T-REC-Q.921bis-199303-I/en</a></p>