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> OsmoMGW - Feature #6387 (In Progress): osmo_io / io_uring support for RTP/RTCPhttps://osmocom.org/issues/63872024-03-02T16:22:02Zlaforge
<p>The RTP/RTCP sockets of osmo-mgw should be prime candidates for migration to osmo_io and hence benefit from the optional io_uring backend.</p>
<p>Given the many small recvfrom/sendto syscalls on those sockets, performance should be enhanced in a significant way.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Feature #6290 (In Progress): Organize Os...https://osmocom.org/issues/62902023-12-06T14:17:47Zlaforge
<p>We already wanted to re-start 2023 but somehow I didn't manage to ever find the time and energy to do it. But let's make sure we definitely have an OsmoDevCon in 2024 again.</p>
<p>The date and venue are still TBD, as is pretty much anything else.</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> Retronetworking - Support #6193 (New): Replace "event rack" PM3 power supplyhttps://osmocom.org/issues/61932023-09-27T12:14:08Zlaforge
<p>Today I wanted to test the <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Event_Setup">Event_Setup</a> ahead of CC2023 and noticed that the PM3 won't power up :(</p>
<p>Luckily I have a few spare PM3 around so I could replace the broken PSU with one from another unit.</p>
<p>As I've now already seen two PM3 with broken PSU, let's make sure to replace them in all of them according to the procedure I documented in <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Livingston_Portmaster_3">Livingston_Portmaster_3</a></p> pySim - Feature #6089 (Feedback): log the current file / operation during execeution of a scripthttps://osmocom.org/issues/60892023-07-10T07:42:17Zlaforge
<p>When we execute a script (e.g. one generated by <code>export</code>), there is no output that helps us understand where in the script we currently are. This is particularly problematic in case something goes wrong (error/exception), where the backtrace might not give us an indication of the EF that was currently selected.</p>
<p>One can enable <code>set apdu_trace true</code> and then check back from the FID of the last SELECT (A4) to the filename manually, but that's cumbersome and just a hack.</p>
<p>I think when executing a script, we should give a brief log of what we're doing, such as simply echoing the script line to stdout.</p>
<p>Generating the <code>export</code> with explicit <code>echo</code> statements not a solution, as that wouldn't work for other scripts (not generated by <code>export</code>)</p> Core testing infrastructure - Feature #6023 (Stalled): test rack/lab power management software wi...https://osmocom.org/issues/60232023-05-04T06:38:46Zlaforge
<a name="Problem-Statement"></a>
<h2 >Problem Statement<a href="#Problem-Statement" class="wiki-anchor">¶</a></h2>
<p>In our test/lab setups, we do have a number of systems that run 24/7 but which are really used only very few hours per day. This has become very visible after we started (a few months ago) to deploy tasmota/influxdb/grafana for plotting many different power rails.</p>
<p>Direct on/off switching from within a given test job only works if that test job is the only user of the given resource (such as e.g. a BTS in osmo-gsm-tester).</p>
<p>For jenkins builders, OBS workers and similar machines, there could be any number of concurrent users. So there's no single job that can power on the resourec before using it, and power it off after it terminates.</p>
<p>What we need is a system that maintains a usage count, similar to how we do usage/reference counting in data structures in software development.</p>
<p>I've started to prototype a modular python daemon which offers a REST API over which users can obtain <em>usage tokens</em> for named resources. The daemon then keeps track of the current use count and switches resources on/off as needed.</p>
<p>Jenkins jobs would then (e.g. in a pipeline) first obtain a usage token (which would implicitly power up the resource if it is not aleady powwered), and release the usage token after they're gone. This way we can power up build machines only when needed, saving significant electrical power, reducing noise and minimizing heat dissipation.</p>
<a name="Architecture-Class-model"></a>
<h2 >Architecture / Class model<a href="#Architecture-Class-model" class="wiki-anchor">¶</a></h2>
<a name="Resource"></a>
<h3 >Resource<a href="#Resource" class="wiki-anchor">¶</a></h3>
<p>A <em>Resource</em> is typically some kind of physical equipment (server, build host, network equipment, ...) which one or multiple users may be using concurrently.</p>
<p>The Resource has a state, such as</p>
<table>
<tr>
<th>State</th>
<th>Description</th>
</tr>
<tr>
<td>off</td>
<td>Powered down</td>
</tr>
<tr>
<td>powered</td>
<td>Powered up, but not reachable yet</td>
</tr>
<tr>
<td>available</td>
<td>Powered up and reachable (typically via network)</td>
</tr>
</table>
<p>A Resource refers to a <em>Switcher</em> and an <em>AvailabilityChecker</em></p>
<p>A Resource keeps a list of <em>UsageToken</em>; one for each concurrent user.</p>
<a name="Switcher"></a>
<h3 >Switcher<a href="#Switcher" class="wiki-anchor">¶</a></h3>
A <em>Switcher</em> is something that can switch power. Possible implementations include
<ul>
<li>sispm compatible USB-switchable power sockets</li>
<li>Intellinet rackmount PDUs with IP/HTTP interface</li>
<li>Tasmota switchable power sockets</li>
<li>ethernet wake-on-lan (on) + ssh-based shutdown (off)</li>
</ul>
A <em>Switcher</em> implementation (inheriting from the abstract Switcher base class) provides methods for
<ul>
<li>changing the power state (on/off)</li>
<li>determining the current actual power state (if supported by hardware). This is important to get the state right at start-up time.</li>
</ul>
<a name="SwitcherGroup"></a>
<h3 >SwitcherGroup<a href="#SwitcherGroup" class="wiki-anchor">¶</a></h3>
<p>A <em>SwitcherGroup</em> is a logical group of multiple <em>Switcher</em>, for example the set of four switchable sispm sockets in one power strip, or the set of 8 switchable power ports in an Intellinet PDU.</p>
<a name="AvailabilityChecker"></a>
<h3 >AvailabilityChecker<a href="#AvailabilityChecker" class="wiki-anchor">¶</a></h3>
<p>An <em>AvailabilityChecker</em> is something that can check the logical availability of a (powered-up) resource. One common example for an IP-attached resources is an ICMP echo request/response based check.</p>
<a name="UsageToken"></a>
<h3 >UsageToken<a href="#UsageToken" class="wiki-anchor">¶</a></h3>
<p>An <em>UsageToken</em> for a <em>Resource</em> must be obtained by any user intending to use the Resource. The UsageToken has a validity time (in seconds), after which it automatically expires.</p>
<p>Release of the UsageToken can hence be either explicit (via REST API after the user is done) or implicit (timeout of the validity period).</p> Retrocomputing - Feature #5938 (In Progress): assemble "fake parallel printer"https://osmocom.org/issues/59382023-03-06T16:33:11Zlaforge
<p>This will be useful for generating digital captures of e.g. the traces generated by <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Wandel_Goltermann_DTX-1">Wandel_Goltermann_DTX-1</a>.</p>
<p><a class="external" href="https://github.com/tomverbeure/fake_parallel_printer">https://github.com/tomverbeure/fake_parallel_printer</a></p> Cellular Network Infrastructure - Feature #5929 (In Progress): document current (milestones of) n...https://osmocom.org/issues/59292023-02-28T19:37:26Zlaforge
We have been doing a number of NLnet funded projects, and should
<ol>
<li>publish some news item / blog post / release announcement (whatever applicable) on each of them</li>
<li>give credit to NLnet funding received for the respective project.</li>
</ol> 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> SIMtrace 2 - Feature #5826 (Stalled): SAM4S4BA support in firmwarehttps://osmocom.org/issues/58262022-12-13T16:27:45Zlaforge
<p>This ticket is about supporting the SAM4S4BA from our firmware, in addition to the SAM3S4BA, SAM3S8BA and SAM4SD8BA we've been using so far for simtrace2 devices.</p>
<p>This is a spin-off of <a class="issue tracker-2 status-2 priority-1 priority-lowest parent" title="Feature: Hardware / Circuit board update for SAM3S based SIMtrace2 with 1.8V/5V support (In Progress)" href="https://osmocom.org/issues/1706">#1706</a></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> libosmo-abis - Feature #5691 (Stalled): Expose DAHDI statistics to prometheushttps://osmocom.org/issues/56912022-09-27T15:32:46Zlaforge
<p>The DAHDI_SPANSTAT ioctl can be used to obtain a number of statistics for a given span (E1/T1 line).</p>
<p>It would be a good idea to implement some library code which would start a timer to periodically poll the DAHDI_SPANSTAT on each of the relevant spans. This could be used by osmo-bsc, osmo-gbproxy or even a stand-alone application to pull all those counters into osmocom rate_ctr infrastructure.</p>
<p>That in turn would allow the counters to be exported alongside all our other counters/stats via the statsd exporter.</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> Open Source IMS Client - Feature #5480 (In Progress): Linux kernel IPsec plugin for doubangohttps://osmocom.org/issues/54802022-03-07T10:49:03Zlaforge
<p>This task is about creating an IPsec plugin for the <a class="wiki-page" href="https://osmocom.org/projects/foss-ims-client/wiki/Doubango">doubango</a> library, allowing doubango to control IPsec policies and security associations in the kernel IPsec stack.</p>
<p>Doubango already has a related plugin architecture and a sample plugin for Windows 10</p> 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> SIMtrace 2 - Feature #5422 (In Progress): "cardem" continuous testing setuphttps://osmocom.org/issues/54222022-01-27T12:22:10Zlaforge
<p>We shuold create a test setup where we can continously test the <code>cardem</code> firmware for the various targets, such as at least simtrace2 and qmod.</p>
<p>The idea would be to use the TTCN3 test ports for SIMTRACE USB protocol on the one hand side and CCID USB protocol on the other hand side.</p>
<p>Tests should ideally not just test interop with one specific CCID reader model but with a larger number of different readers to cover reader-specific issues (I'm seeing different issues with different readers in manual testing).</p>
<p>The tests can then be executed with the latest cardem firmware of the day, on different IUT hardware (simtrace2, qmod) against different readers.</p>
For QMOD testing we would have to either
<ul>
<li>insert a modem with CCID capability (they do exist)</li>
<li>use a custom PCB adapter or some solder wire to hook up the SIM traces of the mCPIE sockets with some external reader</li>
</ul>
<p>But let's focus on simtrace2 for the initial setup, and then expand from there.</p> 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> Cellular Network Infrastructure - Feature #5124 (Feedback): network:osmocom:nightly feed with "-O...https://osmocom.org/issues/51242021-04-20T21:00:00Zlaforge
<p>when debugging issues, it's always annoying to run into "... optimized out" in gdb.</p>
<p>It might make sense to have an OBS feed that basically is a copy of 'nightly' but has all binaries built with -O0</p>
<p>Hopefully that's not all that much effort? Can we somehow inject the compiler flag without having to maintain a package-specific patch against debian/rules?</p> osmo-e1d - Feature #4917 (Stalled): reporting of alarms/errors known to the icE1usbhttps://osmocom.org/issues/49172020-12-18T10:33:35Zlaforge
<p>Now that the device firmware is exposing error situations / counters via a dedicated interrupt endpoint, we should make use of this in osmo-e1d.</p>
<p>See <a class="external" href="https://gerrit.osmocom.org/c/osmo-e1d/+/21782">https://gerrit.osmocom.org/c/osmo-e1d/+/21782</a> and <a class="external" href="https://gerrit.osmocom.org/c/osmo-e1d/+/21783">https://gerrit.osmocom.org/c/osmo-e1d/+/21783</a> for a start.</p>
<p>We should also consider if and how to report such errors to the clients (libosmo-e1d users).</p>
Furthermore, there is also important knowledge to be gained from parsing the TS0, such as
<ul>
<li>does the remote end indicate alarm via A bit</li>
<li>does the remote end report CRC errors via E bits</li>
</ul> libosmocore - Feature #4727 (Feedback): Add more distro/platform/archs to jenkins CIhttps://osmocom.org/issues/47272020-08-25T14:18:29Zpespin
<p>Currently we rely on OBS to run unit test software on several architectures/distributions/versions. However, OBS hosts lack some features which means we need to disable them when we run there (such as socket_sctp_test), and hence only get tested mostly only in x86_64 on one debian version.</p>
<p>That means we don't test such features in ARM, or in Ubuntu or CentOS, or debian unstable.</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> 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> Misc Hardware Projects - Feature #3566 (Stalled): power supply / battery / charge for our GSM-R O...https://osmocom.org/issues/35662018-09-18T13:54:06Zroh
figure out a pinout/spec for these 2 kinds of devices:
<ul>
<li>sagem NNG OPS 940
<ul>
<li>pogopins from device to battery</li>
<li>ericcson style flat connector row on bottom end</li>
<li>3.6V 2.3Ah li-ion battery</li>
</ul></li>
</ul>
<ul>
<li>timba tec pocket pc
<ul>
<li>5V DC 2.4A label</li>
<li>3.7V 4Ah li-ion battery</li>
</ul></li>
</ul> Cellular Network Infrastructure - Feature #2604 (Stalled): GSUP-to-DIAMETER converter / IWFhttps://osmocom.org/issues/26042017-10-29T23:01:06Zlaforge
<p>In order to support a single subscriber database for 2G/3G and LTE, operators normally use a single HSS. HSS is the EPC successor of the LTE.</p>
<p>Instead of MAP over SS7, HSS's speak DIAMETER over SCTP or TCP (with optional TLS). The types of procedures / transactions are pretty much the same as before, but the encoding and the protocol changed completely.</p>
<p>There are a couple of (at least minimal) HSS implementations out there, from freeDiameter to nextepc, to name some examples.</p>
<p>If we were to implement a converter between GSUP and DIAMETER, then the OsmoMSC and OsmoSGSN could access an external HSS - and that same HSS could be accessed from nextepc or even openair-cn for LTE access.</p>
<p>3GPP TS 29.305 specifies the MAP-to-DIAMETeR InterWorkingFunction (IWF), which is pretty much the same device, with the exception that we'd use GSUP instead of MAP.</p>