Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-26T11:40:28ZOpen Source Mobile Communications
Redmine OsmoGGSN (former OpenGGSN) - Bug #6420 (New): osmo-ggsn + pre-configured tun device seems to be b...https://projects.osmocom.org/issues/64202024-03-26T11:40:28Zosmith
<p>When using a pre-configured tun device with OsmoGGSN as described in the user manual, in combination with <code>gtpu-mode kernel-gtp</code>, osmo-ggsn fails to configure the kernel GTP device:</p>
<pre>
<0002> ggsn.c:210 APN(internet): Skipping APN start
<000d> gsn.c:465 GTP: gtp_newgsn() started at 10.23.24.2
<000d> gsn.c:386 State information file (/tmp/gsn_restart) not found. Creating new file.
<0002> ggsn.c:854 GGSN(ggsn0): Successfully started
<0002> gtp-kernel.c:79 Initialized GTP kernel mode (genl ID is 34)
<0001> tun.c:213 cannot create GTP tunnel device: File exists
<0002> ggsn.c:215 APN(internet): Failed to configure Kernel GTP device
</pre> OsmoGGSN (former OpenGGSN) - Bug #6419 (New): osmo-ggsn removes tun devices it did not createhttps://projects.osmocom.org/issues/64192024-03-26T11:26:04Zosmith
<p>From the <a href="https://ftp.osmocom.org/docs/osmo-ggsn/master/osmoggsn-usermanual.pdf" class="external">user manual</a>:</p>
<blockquote>
<p>It’s possible to run OsmoGGSN without root privileges if the tun devices are already configured.<br />The interface creation + configuration must then happen before osmo-ggsn starting up.<br />[...]<br />With the tun device pre-configured in one of the ways outlined above, the main changes in your osmo-ggsn.cfg file are:<br />• remove ip ifconfig directive,<br />• make sure that no shutdown is present in the apn section as well as no shutdown ggsn in the ggsn section.</p>
</blockquote>
<p>With this configuration, a tun device created by <code>/etc/network/interfaces</code> will be removed when osmo-ggsn shuts down and <code>ifup -f apn0</code> must be used to recreate it, before starting osmo-ggsn again.</p> pySim - Bug #6418 (New): osmo-smdpp docshttps://projects.osmocom.org/issues/64182024-03-25T17:54:30Zlavy
<p>In these docs: <a class="external" href="https://ftp.osmocom.org/docs/pysim/master/html/osmo-smdpp.html">https://ftp.osmocom.org/docs/pysim/master/html/osmo-smdpp.html</a></p>
<p><img src="https://projects.osmocom.org/attachments/download/8141/clipboard-202403251046-awlff.png" alt="" /></p>
<p>It says osmo-smdpp is absolutely insecure as it does not perform any certificate verification, does not consider matching ID or Confirmation Code, ...</p>
<p>I'm slightly confused by this. By no certificate verification, does it mean that it doesn't check if the root certificate of the eUICC is the same as the SM-DP+ server? Also for not considering matching ID, I had to make it the name of a profile package in the upp folder for it to work. If I did something like 1234 (like you did in the osmodevcall), it doesn't work. I debugged and found it was throwing an error if the matching ID was not a file in the upp folder. Do these docs need an update? I'd be happy to do that if that's the case.</p> E1/T1 Hardware Interface (including icE1usb) - Feature #6417 (New): CRC4 configurationhttps://projects.osmocom.org/issues/64172024-03-22T18:01:37Zpfassberg
<p>Even if the icE1usb support CRC4 enabled or disabled the osmo-e1d process need CRC4 on Rx to align.</p>
<p>I suggest that we do CRC4 check configurable.</p>
<p>On a Cisco modem pool you can disable CRC4 in the E1 controller section:<br /><pre>
controller E1 2/1
framing NO-CRC4
pri-group timeslots 1-31
description Towards Kanin-Q921_4
</pre></p>
<p>Maybe we can do the same in the line section in the config file, something like this:<br /><pre>
e1d
interface 0 icE1usb
usb-serial xxxxxxxxxxxx
line 0
framing no-crc4
mode e1oip
</pre></p>
<p>// Peter</p> Cellular Network Infrastructure - Bug #6411 (New): ttcn3: execute testsuites with a more realisti...https://projects.osmocom.org/issues/64112024-03-20T14:24:47Zfixeria
<p>This idea by <a class="user active" href="https://projects.osmocom.org/users/7">laforge</a> originates from <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://projects.osmocom.org/issues/6375">#6375</a>: we should try running at least some of our BTS / BSC tests over an Abis link with simulated latency and non-zero packet loss. I did some experiments using tc-netem, running the whole ttcn3-bts-test with a simulated delay: <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://projects.osmocom.org/issues/6375#note-14">#6375#note-14</a>. Let's continue discussing this here.</p> libosmocore - Bug #6410 (New): osmo_io poll backend doesn't work on file descriptors that are not...https://projects.osmocom.org/issues/64102024-03-19T19:33:49Zlaforge
<p>I just wanted to use osmo_io on a file descriptor pointing to an actual file, not a socket.</p>
<p>The poll backend fails as it unconditionally tries to use sendmsg, even if the mode is READ_WRITE.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6408 (New): osmo-epdg: Support check IMEIhttps://projects.osmocom.org/issues/64082024-03-15T18:45:50Zpespin
<p>We didn't implement anything IMEI related yet, grep for "IMEI" in TS 29.273.</p>
<p>For instance:<br /><pre>
Specific operator policies may be configured for emergency services, regarding whether to check the IMEI and, if the
IMEI needs to be checked, whether to continue or stop the authentication and authorization procedure upon getting the
IMEI check result or when the IMEI(SV) is not available.
</pre></p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6407 (New): osmo-epdg: Support Emergenc...https://projects.osmocom.org/issues/64072024-03-15T18:43:20Zpespin
<p>Grep for "Emergency" in TS 29.273. We didn't implement any of those yet. We expect an IMSI everywhere.</p> libosmocore - Feature #6402 (New): consider using IORING_RECVSEND_POLL_FIRST for our socket-readshttps://projects.osmocom.org/issues/64022024-03-14T08:21:57Zlaforge
<p>io_uring has an IORING_RECVSEND_POLL_FIRST which will increase the performance of read/recv/recvmsg/recvfrom calls if no data is present in the socket at the time we submit a read.</p>
<p>This works by going directly into poll, bypassing the initial attempt to recv/recvmsg.</p>
<p>Given that our sockets are often very low traffic and work in a request/response fashion, this might be worth a shot.</p> libosmocore - Feature #6401 (New): benchmark batching io_uring operationshttps://projects.osmocom.org/issues/64012024-03-14T08:10:59Zlaforge
<p>right now we <code>io_uring_submit()</code> reads/writes right when they are added. This triggers the kernel processing on those without the benefit of batching multiple operations.</p>
<p>We might want to try to benefit from batching by waiting until we enter osmo_select_main().</p> pySim - Bug #6398 (New): Add helper for SwMatchErrorhttps://projects.osmocom.org/issues/63982024-03-09T21:34:47Zn4n5
<p>Hello</p>
<p>Here is a tiny patch to add the error interpreter to SwMatchError()</p>
<p>Btw I have another question :<br />What can we do when we have "Expected 9000 and got 6983: Command not allowed - Authentication/PIN method blocked" ?</p>
<p>Thanks</p> OsmoHNBGW - Feature #6395 (New): PFCP URR support in osmo-hnbgwhttps://projects.osmocom.org/issues/63952024-03-08T13:38:17Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to use PFCP URR to instruct the UPF to:
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p>The osmo-hnbgw side then will have to report those packet/byte counters [at the very least] as per-hnb aggregate figures.</p>
<p>Until osmo-upf has the related features (<a class="issue tracker-2 status-7 priority-1 priority-lowest" title="Feature: Basic URR (Usage Reporting Rule) support for tunnel mapping (Stalled)" href="https://projects.osmocom.org/issues/6394">#6394</a>), testing of the osmo-hnbgw side can be done against open5gs-upf, which should already suport it since <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> taught it URR support in April 2022.</p> libosmocore - Feature #6390 (New): port CTRL over to osmo_io / io_uringhttps://projects.osmocom.org/issues/63902024-03-02T18:45:00Zlaforge
<p>In theory this should be fairly trivial to mogirate over. It uses a tx_queue anyway for writes today, so handing those msgb's over to osmo_io should be easy.</p>
<p>However, the user API of ctrl is a nightmare and it exposes a lot of internal details - among them are the use of ctrl_connection by a ctrl <strong>CLIENT</strong> from sysmobts_mgr.</p>
<p>Let's not do this now, the performance of CTRL is not that significant.</p> libosmocore - Feature #6389 (New): port VTY over to osmo_io / io_uringhttps://projects.osmocom.org/issues/63892024-03-02T16:55:56Zlaforge
<p>The VTY uses its 'buffer' layer between writes by the software and writing to the acutal socket file descriptor. buffer_flush_all is currently used whenever the socket is write-able. So it's a pull model.</p>
<p>We'd probably have to change that logic to work the other way around: Once a buffer has a certain fill-level (or age?), proactively push it via osmo_io.</p>
<p>Unless somebody uses a lot of scripts acccessing the VTY, it's also unlikely that the syscall load of a human VTY user would place significant I/O load on an osmocom program. So it's not super criticial.</p> libosmocore - Feature #6388 (New): stats_reporter via osmo_io / io_uring?https://projects.osmocom.org/issues/63882024-03-02T16:54:39Zlaforge
<p>I briefly looked at migrating the osmo_stats_reporter over to osmo_io, and I'm not entirely sure if it's that great an idea. Right now each stats_reporter has one msgb that's allocated at socket-open time. Whenever there's something to write, that buffer is used and then immediately sent off using sendto(). There's no integration into the osmocom select loop. We always assume the [udp] socket is writable. The buffers are hence never free'd or re-allocated at runtime.</p>
<p>If we switch over to osmo_io, then it would mean every stats report allocates a new msgb, and once that's handed over to the io_uring backend there are even more allocations. So yes, we'd save the sendto system call, but at the cost of more load on the heap allocator. The syscall is likely more expensive, sure. But is it worth it? I'm not so sure.</p> OsmoHNBGW - Bug #6380 (New): VTY transcript tests are broken [again]https://projects.osmocom.org/issues/63802024-02-28T18:34:06Zfixeria
<p>The <a href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-hnbgw/" class="external">master-osmo-hnbgw</a> Jenkins job is broken since Feb 27th.</p>
<pre>
Error during transcript step 3:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
sctp-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
Error while verifying transcript file './config//defaults.vty'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 357, in verify_application
interact.verify_transcript_file(transcript_file)
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 111, in verify_transcript_file
result = self.verify_transcript(content)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 199, in verify_transcript
raise Exception('Result mismatch:\n%s\n\nExpected:\n[\n%s\n]\n\nGot:\n[\n%s\n%s\n]'
Exception: Result mismatch:
Mismatch:
Expect:
' sctp-role client'
Got:
' transport-role client'
Expected:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
sctp-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
Got:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
transport-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
RESULTS:
FAIL: ./config//defaults.vty
</pre>
<p>This is a side effect of my patch that has been merged to libosmo-sccp.git:</p>
<p><a class="external" href="https://cgit.osmocom.org/libosmo-sccp/commit/?id=4d7e20193c264585080b9edc91eb630dd005e396">https://cgit.osmocom.org/libosmo-sccp/commit/?id=4d7e20193c264585080b9edc91eb630dd005e396</a></p>
<pre>
commit 4d7e20193c264585080b9edc91eb630dd005e396
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Thu Feb 15 05:29:14 2024 +0700
VTY: rename 'sctp-role' to 'transport-role', add an alias
</pre> libosmocore - Bug #6374 (New): libosmocore --disable-libsctp not tested by jenkinshttps://projects.osmocom.org/issues/63742024-02-23T15:40:23Zpespin
<p>Right now we are not testing build of libosmocore disabling libsctp support, which means it went broken some time ago and which has recently been fixed by:<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/36055/1">https://gerrit.osmocom.org/c/libosmocore/+/36055/1</a></p>
<pre>
$ ./configure --help | grep sctp
--disable-libsctp Do not enable socket multiaddr APIs requiring
libsctp
--disable-sctp-tests Do not run socket tests requiring system SCTP
</pre>
<p>We should ideally test building with those flags above set in the build matrix of the jenkins job when submitting patches to gerrit (and also probably the master jobs?).</p>
<p>We should ideally test the same when building libosmo-netif and libosmo-sccp (they also have similar configure flags iirc, which in turn relate to --disable-libsctp from libosmocore).</p> OsmocomBB SDR PHY - Bug #6372 (New): Cant connect to BS using cell_log and mobile https://projects.osmocom.org/issues/63722024-02-22T07:13:32Zarrowtem
<p>Hello<br />i managed to run usrp , sib's were succesfully decoded and usrp send RACH to station , but i never can decode reply due to CCCH received bad frame error<br />ubuntu 18.04<br />libosmocomcore 0.11.0<br /><img src="https://projects.osmocom.org/attachments/download/7680/clipboard-202402221012-vtk0a.png" alt="" /><br />uhd 3.10.3<br />gnu radio 3.7.11<br />gr-gsm fixeria/trx branch <br />osmocom bb fixeria/gprs branch</p>
<p>On most new branches i even cant managed to start tranciever , i always had <br /><abbr title="'L' indicates a late packet on transmit">LLLLL</abbr> and usrp_sink error , cmd time error so rach was not sent</p>
<p>Is there are any solution ? maybe i need to checkout to another branches/commits ? i seen in demo you could succesfully camp on cell <br />Btw as a BS i use openbts 2g cell , phones easily camp on it <br />Thank you</p> pySim - Feature #6367 (New): PC/SC <-> Android OMAPI bridge for pySim and othershttps://projects.osmocom.org/issues/63672024-02-17T13:34:01Zlaforge
It's a frequent usage pattern that somebody
<ul>
<li>inserts a (sysmocom) USIM/ISIM or even EUICC in their PC/SC card reader, performs some actions with it from the PC (such as changing a file via pySim) and then</li>
<li>inserts it into a phone to test it with the modification, then</li>
<li>restarts the cycle again by removing the card and placing it in the PC/SC reader</li>
</ul>
<p>While working with <a href="https://gitea.angry.im/PeterCxy/OpenEUICC" class="external">EasyEUICC</a> it occurred to me that it has raw APDU-level access via Androids FEATURE_SE_OMAPI_UICC. So it should be possible to write an Android app that acts as a proxy/brige for passing APDUs transparently to between an UICC/eUICC present in the phone and a remote PC running pySim (or any other software that expects a local PC/SC card reader)</p>
<p>In fact, given that the vpcd project alreay has a "APDU over TCP" protocol and has an <a href="https://github.com/frankmorgner/vsmartcard/blob/master/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c" class="external">ifd_handler exposing virtual card readers to pcscd</a>, only the android side would have to be developed.</p>
<p>So in the end, using the approach above, it shoul be possible to have pySim-shell or other tools talk to the UICC/eUICC while it remains inserted into the phone. After changes were made, we have to see if we can somehow trigger the REFRESH proactive command to tell the baseband to discard its cache and re-read the card contents. Likely a manual "Airplane mode on / off" toggle will also do the trick. But no more inserting/removing the card in between iterations.</p>
<p>Of course the same should in theory be possible also via 03.48 OTA / SCP80 without any Android app. However, OTA works with "APDU scripts" and that's not 1:1 the same as a live connection to the card, where the card doesn't loose state like which file was SELECTed between different OTA commands.</p>
Any ideas/comments on this? I'm not an Android developer, but the task looks reasonably simple to me:
<ul>
<li>access the UICC/eUICC the same way as EasyEUICC</li>
<li>create a TCP connection to a user-configured IP/Port (the ifd-vpcd)</li>
<li>implement the super simple VPCD protocol over TCP to transceive APDUs</li>
</ul> libosmocore - Bug #6360 (New): libosmovty fails to parse commands like "test (foo|bar) [(one|two|...https://projects.osmocom.org/issues/63602024-02-14T21:25:23Zfixeria
<p>Support for the <code>[(one|two|three)]</code> syntax was added back in 2019:</p>
<pre>
commit b55f4d2df21b966c3953264d8961f259814f4650
Author: Neels Hofmeyr <neels@hofmeyr.de>
Date: Thu Jan 31 08:13:31 2019 +0100
vty: enable optional-multi-choice syntax: [(one|two)]
</pre>
<p><a class="external" href="https://cgit.osmocom.org/libosmocore/commit/?id=b55f4d2df21b966c3953264d8961f259814f4650">https://cgit.osmocom.org/libosmocore/commit/?id=b55f4d2df21b966c3953264d8961f259814f4650</a></p>
<p>However the VTY parser still hits an assertion if the command has a non-optional choice preceding an optional one:</p>
<pre>
test (foo|bar) [(one|two|three)]
</pre>
<p>Here is a patch extending the existing testing coverage and reproducing the problem:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/35961">https://gerrit.osmocom.org/c/libosmocore/+/35961</a></p>
<pre>
$ gdb ./tests/vty/vty_transcript_test
(gdb) r
Program received signal SIGABRT, Aborted.
0x00007ffff7d8b83c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7d8b83c in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7d3b668 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff7d234b8 in abort () from /usr/lib/libc.so.6
#3 0x00007ffff7f3d511 in osmo_panic_default (fmt=0x7ffff7fb112c "Assert failed %s %s:%d\n", args=0x7fffffffddc0) at panic.c:45
#4 0x00007ffff7f3d4c5 in osmo_panic (fmt=0x7ffff7fb112c "Assert failed %s %s:%d\n") at panic.c:80
#5 0x00007ffff7f96d83 in cmd_make_descvec (string=0x55555555734f "multi3 (foo|bar) [(one|two|three)]", descstr=0x555555557372 "multi3 test command\nfoo\nbar\n1\n2\n3\n") at command.c:439
#6 0x00007ffff7f96add in install_element (ntype=1, cmd=0x555555559388 <multi3_cmd>) at command.c:1009
#7 0x00007ffff7f9718a in install_element_ve (cmd=0x555555559388 <multi3_cmd>) at command.c:1026
#8 0x0000555555556570 in init_vty_cmds () at vty/vty_transcript_test.c:391
#9 0x0000555555556384 in main (argc=1, argv=0x7fffffffe018) at vty/vty_transcript_test.c:429
(gdb) frame 5
#5 0x00007ffff7f96d83 in cmd_make_descvec (string=0x55555555734f "multi3 (foo|bar) [(one|two|three)]", descstr=0x555555557372 "multi3 test command\nfoo\nbar\n1\n2\n3\n") at command.c:439
439 OSMO_ASSERT(multiple);
(gdb) p cp
$1 = 0x555555557365 "|two|three)]"
</pre>
<p>libosmocore.git 9d73503bd09eb164f781d488bf2c839c0822798a</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6354 (New): investigate UE behavior in ...https://projects.osmocom.org/issues/63542024-02-07T16:10:55Zlaforge
<p>As we've seen in <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: connect a real phone to the epdg to test strongswan ipsec configuration (Closed)" href="https://projects.osmocom.org/issues/6114">#6114</a> it might be interesting to control the eDPG hostname so we can generate a certificate for it (signed by letsencrypt which presumably is trusted by default in unmodified android). It's not critical as EAP-only authentication appeared to be working in the test case there.</p>
<p>It would be good to find some time to test with a couple of different UE whether they actually respect the ePDG related files / configs that can be stored in the USIM/ISIM.</p>
<p>A quick look in TS 31.102 revaled:</p>
<ul>
<li><code>EF.ePDGId</code>
<ul>
<li>contains a TLV-wrapped IPv4, IPv6 or hostname of the ePDG</li>
</ul>
</li>
<li><code>EF.ePDGSelection</code>
<ul>
<li>control the <em>Selection of the ePDG</em> proceduer in the UE (3GPP TS 24.302)</li>
<li>contais a number of (plmn, epdg_priority, epdg_fqdn_indicator)
<ul>
<li>the epdg_fqdn_indicator state whether the <em>Operator Identifier FQDN</em>, or a <em>location based FQDN</em> format shall be used</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li><code>EF.ePDGIdEm</code>
<ul>
<li>same as above, but for emergency calls</li>
</ul>
</li>
<li><code>EF.ePDGSelectionEm</code>
<ul>
<li>same as above, but for emergency calls.</li>
</ul></li>
</ul>
<p>So <code>EF.ePDGId</code> is really the most interesting one.</p> OsmocomBB - Feature #6348 (New): virtphy: add Circuit Switched Data (CSD) supporthttps://projects.osmocom.org/issues/63482024-01-26T22:03:21Zfixeria
<p>Since recently, Calypso PHY and trxcon support data traffic channels needed for CSD:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/34694">https://gerrit.osmocom.org/c/osmocom-bb/+/34694</a> firmware/layer1: handle CSD related channel modes<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/32922">https://gerrit.osmocom.org/c/osmocom-bb/+/32922</a> trxcon/l1sched: implement CSD scheduling support</p>
<p>For the sake of completeness, let's add data traffic channel support to virtphy.</p> OsmocomBB - Feature #6347 (New): mobile: support data calls @ 300 bps and 1200/75 bps (TCH/[FH]2.4)https://projects.osmocom.org/issues/63472024-01-26T21:54:56Zfixeria
<p>Currently we implement data rates starting from <code>2400 bps</code> and higher, but not <code>300 bps</code> and <code>1200/75 bps</code>.<br />The problem is that those rates are not specified in ITU-T Rec. V.110, which defines <code>600 bps</code> as the minimum synchronous data rate.</p>
<p>According to 3GPP TS 44.021, section 4.1, the <code>300 bps</code> user data signalling rate shall be adapted to a synchronous <code>600 bps</code> stream.<br />Also, "Incoming asynchronous data is padded by the addition of stop elements" -- this means that we pad bits after stop bit(s):</p>
<pre>
pad bits = ((600 / 300) - 1) * (start + data + parity + stop)
</pre>
<p>This logic most likely needs to be implemented in the soft-UART module of libosmocore.git.</p> OsmocomBB - Feature #6346 (New): mobile: support data calls @ 14400 bps (TCH/F14.4)https://projects.osmocom.org/issues/63462024-01-26T21:44:42Zfixeria
<p>Currently we implement <code>TCH/[FH]2.4</code>, <code>TCH/[FH]4.8</code>, and <code>TCH/F9.6</code>, but not <code>TCH/F14.4</code>. Calypso PHY should be capable of doing <code>TCH/F14.4</code>, as well as trxcon. However, the rate adaptation functions for <code>TCH/F14.4</code> are different from those we implemented so far. According to 3GPP TS 48.020, chapter 10, we would need to implement <code>RA1'/RAA'</code> and <code>RA1'/RAA"</code>. Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6345 (New): osmo-epdg: Implement SWm in...https://projects.osmocom.org/issues/63452024-01-25T16:32:08Zpespin
<p>In current architecture of osmo-epdg, the process contains both the ePDG and the AAA Server nodes.</p>
<p>These 2 nodes speak Diameter SWm interface between them.</p>
<p>We may want to split the 2 nodes into 2 processes and properly implement SWm at some point, or use another AAA server implementation.</p>
<p>Anyway, creating the ticket as a reference point to look up/comment on related communication between ePDG and AAA nodes.</p>
Spec references:
<ul>
<li>TS 29.273 section 7</li>
<li>TS 23.402 (grep for "SWm")</li>
</ul> libosmocore - Feature #6344 (New): New TS 24.008 Bearer Capability codec APIhttps://projects.osmocom.org/issues/63442024-01-24T23:17:59Zfixeria
<p>The current implementation of <code>gsm48_{en,de}code_bearer_cap()</code> lacks support for:</p>
<ul>
<li>encoding/decoding V.34 modem type (octet 6d);</li>
<li>encoding/decoding data rates higher than 9600 bps, like 14400 bps (octets 6d, 6e);</li>
<li>encoding/decoding of other B-channel protocols like V.120 (octets 5a, 5b; see also <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: Incorrect handling of V.120 data calls (New)" href="https://projects.osmocom.org/issues/6330">#6330</a>);</li>
<li>encoding/decoding fields of octet 4 (hard-coded to 0x88).</li>
</ul>
<p>Unfortunately, adding new fields to <code>struct gsm_mncc_bearer_cap</code> (on which these functions operate) is not an option.<br />This struct is part of the MNCC PDU, so changing it would result in modifying the protocol and thus problems with backwards compatibility.</p>
<p>This means that we need the new API, which would depend on the MNCC protocol definitions.</p> OsmocomBB - Bug #6337 (New): bad fr audio with gapk/ms-sdrhttps://projects.osmocom.org/issues/63372024-01-22T21:21:06ZHoernchen
<p>The audio sounds <em>kinda</em> choppy, but not really - one half are apparently decoding issues, the other one.. well.. hard to tell, bad timing doing blocking audio calls?<br />It does not appear to be cpu related.<br />Another problem is is that the (very large!) wq used by l1ctl_client_send keeps filling up, which obviously adds latency, until it overflows. At that point random messages get dropped, which is kinda bad...<br />Sometimes the audio improves after some time - I don't understand why/how.</p>
<p>This might affect phone setups, too.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6332 (New): osmo-epdg: Write User Manualhttps://projects.osmocom.org/issues/63322024-01-18T16:15:34Zpespin
Have an asciidoc user manual documenting:
<ul>
<li>The overall architecture with the different nodes (strongswan, osmo-epdg, PGW, HSS, etc.)</li>
<li>How the iptables and tunnel interface works for user plane.</li>
<li>How to build, configure, run the osmo-epdg program</li>
<li>How to build, configure, run strongswan</li>
<li>Describing the different intefraces: CEAI, SWx, S6b, S2b, etc.</li>
</ul>
It should include some stuff from osmo-gsm-manuals.git:
<ul>
<li>./common/chapters/gsup.adoc</li>
</ul> OsmoMSC - Bug #6330 (New): Incorrect handling of V.120 data callshttps://projects.osmocom.org/issues/63302024-01-18T15:02:29Zfixeria
<p>Current osmo-msc (8236184ef05e5b10505bbb3189357d2050bbdc5d) fails to connect a V.120 data call, see the attached PCAP.</p>
<p>How to reproduce:</p>
<ul>
<li>find phone(s)/modem(s) supporting V.120 data calls
<ul>
<li>the result of <code>AT+CBST=?</code> should contain one of V.120 rates: 39, 43, 47, 48</li>
<li>most Sony Ericsson phones/modems can do V.120: <code>+CBST: (0,7,12,14-17,39,43,47-51,71,75,79-84),(0,4),(1)</code></li>
</ul>
</li>
<li>configure phone(s)/modem(s) to use V.120, for example: <code>AT+CBST=39,0,1</code> for 9600 bps</li>
<li>initiate a data call, for example: <code>ATD15843</code></li>
</ul>
<p>In my case (using SE K800), the call is aborted due to Assignment Failure, because osmo-msc sends weird Assignment Command:</p>
<pre>
GSM A-I/F BSSMAP - Assignment Request
Message Type Assignment Request
Channel Type - (Data)
Element ID: 0x0b
Length: 3
0000 .... = Spare bit(s): 0x00
.... 0010 = Speech/Data Indicator: Data (2)
.000 1010 = Channel rate and type: Full or Half rate TCH channel, Full rate preferred, changes allowed also after first channel allocation as a result of the request (10)
0... .... = Extension: Last Octet
.0.. .... = Service: Transparent
..01 0010 = Rate: 2.4kbit/s
...
</pre>
<p><code>2.4kbit/s</code> / <code>Transparent</code> is definitely not what the calling phone requested, it should be <code>9.6kbit/s</code> / <code>Non-transparent</code>.</p>
<p>Below is how the Bearer Capability looks like for <code>AT+CBST=39,0,1</code>:</p>
<pre>
Bearer Capability 1 - (Full rate support only MS)
Element ID: 0x04
Length: 12
Octet 3
1... .... = Extension: No Extension
.01. .... = Radio channel requirement: Full rate support only MS
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .001 = Information transfer capability: Unrestricted digital information (0x1)
Octet 4
1... .... = Extension: No Extension
.1.. .... = Compression: Allowed
..00 .... = Structure: Service data unit integrity (0)
.... 1... = Duplex mode: Full
.... .0.. = Configuration: Point-to-point
.... ..0. = NIRR: No meaning is associated with this value
.... ...0 = Establishment: Demand
Octet 5
0... .... = Extension: Extended
.00. .... = Access Identity: Octet identifier (0)
...1 1... = Rate Adaption: Other rate adaption (see octet 5a) (3)
.... .001 = Signalling Access Protocol: According to ITU-T Rec. Q.920 and ITU-T Rec. Q.930 (1)
Octet 5a
0... .... = Extension: Extended
.00. .... = Other ITC: Restricted digital information (0)
...0 0... = Other Rate Adaption: According to ITU-T Rec. V.120 (0)
.... .000 = Spare bit(s): 0
Octet 5b
1... .... = Extension: No Extension
.1.. .... = Rate Adaption Header: Included
..1. .... = Multiple frame establishment support in data link: Supported
...1 .... = Mode of operation: Protocol sensitive
.... 0... = Logical link identifier negotiation: Default, LLI=256 only
.... .0.. = Assignor/Assignee: Message originator is default assignee
.... ..0. = In band/Out of band negotiation: Negotiation is done in-band using logical link zero
.... ...0 = Spare bit(s): 0
Octet 6
0... .... = Extension: Extended
.01. .... = Layer 1 Identity: Octet identifier
...0 000. = User information layer 1 protocol: Default layer 1 protocol
.... ...1 = Synchronous/asynchronous: Asynchronous
Octet 6a
0... .... = Extension: Extended
.0.. .... = Number of Stop Bits: 1
..0. .... = Negotiation: In-band negotiation not possible
...1 .... = Number of data bits excluding parity bit if present: 8
.... 0101 = User rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6b
0... .... = Extension: Extended
.11. .... = V.110/X.30 rate adaptation Intermediate rate: 16 kbit/s (3)
...0 .... = Network independent clock (NIC) on transmission (Tx): does not require to send data with network independent clock
.... 0... = Network independent clock (NIC) on reception (Rx): cannot accept data with network independent clock
.... .011 = Parity information: None (3)
Octet 6c
0... .... = Extension: Extended
.01. .... = Connection element: Non transparent (RLP) (1)
...0 0000 = Modem type: None
Octet 6d
0... .... = Extension: Extended
.00. .... = Other modem type: No other modem type specified in this field (0)
...0 0001 = Fixed network user rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6e
0... .... = Extension: Extended
.1.. .... = Acceptable channel codings (TCH/F14.4): Acceptable
..0. .... = Acceptable channel codings (Spare): False
...1 .... = Acceptable channel codings (TCH/F9.6): Acceptable
.... 0... = Acceptable channel codings (TCH/F4.8): Not Acceptable
.... .001 = Maximum number of traffic channels: 1 TCH
Octet 6f
1... .... = Extension: No Extension
.000 .... = UIMI, User initiated modification indication: not allowed/required/applicable (0)
.... 0001 = Wanted air interface user rate: 9.6 kbit/s (1)
</pre> rtl-sdr - Bug #6329 (New): rtl_sdr does not have correct rpath set on OSX buildhttps://projects.osmocom.org/issues/63292024-01-12T21:57:08Zhut8
<p>After building using these commands (copied from the wiki) on OSX:</p>
<pre><code class="shell syntaxhl"><span class="nb">cd </span>rtl-sdr/
<span class="nb">mkdir </span>build
<span class="nb">cd </span>build
cmake ../
make
<span class="nb">sudo </span>make <span class="nb">install
sudo </span>ldconfig
</code></pre>
<p>First, ldconfig won't work on a mac. However, up to that point, everything goes fine. But then when I try to run rtl_sdr, I get:</p>
<pre><code class="shell syntaxhl">dyld[54169]: Library not loaded: @rpath/librtlsdr.2.dylib
Referenced from: <932B34BB-A147-366F-86D0-13D5D959A868> /usr/local/bin/rtl_sdr
Reason: no LC_RPATH<span class="s1">'s found
</span></code></pre>
<p>I'm not familiar at all with CMake, but I was able to get it to run by running:</p>
<pre><code class="shell syntaxhl"><span class="nb">sudo </span>install_name_tool <span class="nt">-add_rpath</span> /usr/local/lib /usr/local/bin/rtl_sdr
</code></pre>
<p>I have to do that for all of the executables. I'm on Sonoma 14.2.1 on an M2.</p>