Open Source Mobile Communications: Issueshttps://osmocom.org/https://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://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://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://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://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) - Bug #6415 (New): osmo_panic after truncated packethttps://osmocom.org/issues/64152024-03-22T17:44:25Zpfassberg
<p>I'm running icE1usb connected to a Raspberry CM3 module.</p>
<p>A few times a day osmo-e1d crashes with the following output:<br /><pre>
Fri Mar 22 17:16:59 2024 DLINP octoi_clnt_fsm.c:242 OCTOI_CLIENT(N11MD)[0x55a37878e0]{ACCEPTED}: Rx OCTOI ECHO_RESP (seq=690, rtt=777)
Fri Mar 22 17:17:02 2024 DE1D usb.c:150 (I0:L0) IN EP 82 ISO packet truncated: len-4 = 173
Assert failed size % 32 == 0 mux_demux.c:450
backtrace() returned 19 addresses
/usr/local/lib/libosmocore.so.21(osmo_generate_backtrace+0x18) [0x7f83880f60]
/usr/local/lib/libosmocore.so.21(+0x30aa0) [0x7f838a0aa0]
/usr/local/lib/libosmocore.so.21(osmo_panic+0xd4) [0x7f838a0b78]
osmo-e1d(+0x6e8c) [0x557f4a6e8c]
osmo-e1d(+0x787c) [0x557f4a787c]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0xb1b4) [0x7f8381b1b4]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0x116ec) [0x7f838216ec]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0x1271c) [0x7f8382271c]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0xabc8) [0x7f8381abc8]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(libusb_handle_events_timeout_completed+0x218) [0x7f8381c09c]
/usr/local/lib/libosmousb.so.0(+0x1908) [0x7f83901908]
/usr/local/lib/libosmocore.so.21(+0x34398) [0x7f838a4398]
/usr/local/lib/libosmocore.so.21(+0x3450c) [0x7f838a450c]
/usr/local/lib/libosmocore.so.21(osmo_select_main+0x14) [0x7f838a4528]
osmo-e1d(+0x39a4) [0x557f4a39a4]
/lib/aarch64-linux-gnu/libc.so.6(+0x27780) [0x7f83627780]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0x7f83627858]
osmo-e1d(+0x3bf0) [0x557f4a3bf0]
signal 6 received
</pre></p>
<p>As the packet is truncated something has gone wrong in the USB communication or maybe in the firmware, but I think that the process should not do abort but try to continue.</p>
<p>// Peter</p> rtl-sdr - Bug #6413 (New): Incorrect Debian/Debian-like binary packageshttps://osmocom.org/issues/64132024-03-22T05:59:54ZFFY00
<p>Hi,</p>
<p>It seems the binary packages for Debian and Debian-like distributions, such as Ubuntu, for librtlsdr are incorrect.</p>
<p>You are shipping a librtlsdr0 package for 2.x version, which has a SO version with a major of 2. The correct package should be librtlsdr2. Not shipping a .so.0 in a librtlsdr0 package means that all software that was built against it will now result in an unresolved linker dependency.</p>
<p>With that said, I would also recommend the SO version to not be tied to the project version, as that would require all existing packages to be rebuilt against the new library package, even if there weren't any ABI changes. I don't know if there were any ABI changes between .so.0 and .so.2, but if there weren't, I would recommend for rtl-sdr 2.x to still ship a SO with a 0 major version (in this case, also a .so.2 now, since version 2.x has already been released with that SO name).</p>
<p>Cheers,<br />Filipe Laíns</p> Cellular Network Infrastructure - Bug #6411 (New): ttcn3: execute testsuites with a more realisti...https://osmocom.org/issues/64112024-03-20T14:24:47Zfixeria
<p>This idea by <a class="user active" href="https://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://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://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://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> pySim - Bug #6398 (New): Add helper for SwMatchErrorhttps://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> libosmocore - Bug #6393 (New): osmo_io conflating osmo_iofd_unregister vs osmo_iofd_closehttps://osmocom.org/issues/63932024-03-07T09:22:49Zlaforge
<p>I've been starting to work on something like an osmo_io API user manual, and as part of that tried to think about how to guard osmo_io against invalid usage.</p>
We have
<ul>
<li>osmo_iofd_unregister</li>
<li>osmo_iofd_close</li>
<li>osmo_iofd_free</li>
</ul>
Oddities:
<ul>
<li>osmo_iofd_unregister sets the IOFD_FLAG_CLOSED flag, even though it does not close
<ul>
<li>osmo_iofd_register clears the IOFD_FLAG_CLOSED, so there's some symmetry, despite the name</li>
</ul>
</li>
<li>osmo_iofd_close also sets the IOFD_FLAG_CLOSED flag, but without unregistering
<ul>
<li>this mean we cannot use the IOFD_FLAG_CLOSED to check in osmo_iofd_unregister if the iofd was already unregistered</li>
<li>it actually doesn't close the fd unless there is an osmo_iofd_ops.close call-back from the backend</li>
<li>however, it does always set iofd->fd to -1, so if no such call-back exists, we have a fd leak</li>
</ul>
</li>
<li>osmo_iofd_free calls osmo_iofd_close, but not osmo_iofd_unregister. So it somehow tries to do whatever is needed before the free, but only half of it.</li>
</ul>
<p>I'm not entirely sure yet how to untangle this. Maybe we need multiple flags to properly distinguish the closed from the unregistered state? Or maybe we don't need another flag and use iofd->fd == -1 to determine the actual closed status, and rename the CLOSED flag to n UNREGISTERED flag?</p> OsmoHNBGW - Bug #6380 (New): VTY transcript tests are broken [again]https://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> OsmoBSC - Bug #6378 (New): Ericsson DUG 20 rejects SI2quaterhttps://osmocom.org/issues/63782024-02-28T00:28:49Zkeith
<p>Sending SI2quater to the DUG20 results in</p>
<pre>
ERROR REPORT (cause=Radio Resource not available [ 21 01 80 ])
</pre>
<p>For what it may be worth, the SI and the error are in the attached pcap.</p>
<p>Maybe the BTS software version I have simply does not support it?</p> libosmocore - Bug #6374 (New): libosmocore --disable-libsctp not tested by jenkinshttps://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://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://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> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6366 (New): strongswan: test if gsup_client...https://osmocom.org/issues/63662024-02-17T01:05:48Zlynxis
<p>Can gsup requests pile up, when the gsup connection was dead when the sender tried to send a packet?</p>
<p>I've seen strongswan not always sending out requests after a reconnect situation.<br />As test case, let osmo-epdg crash or ignore a GSUP Send Auth Info Request.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6365 (New): strongswan: get the PDP type ou...https://osmocom.org/issues/63652024-02-17T00:03:41Zlynxis
<p>According to 33.402 / Section 8.2.2</p>
<blockquote>
<p>The UE sends the "Configuration Payload, Sec. associations, Traffic selectors, APN info" in the first IKE_Auth Request.</p>
</blockquote>
<p>Strongswan doesn't care. It only takes the APN and UE Identity from it. But nothing else.</p>
<p>1) Use a real phone to see the request and get the wireshark decode table<br />2) Find out when those information is available to collect it with the strongswan code (osmo-epdg plugin).<br />3) Send the correct type in SendAuthInfo and/or Location Update Request towards the osmo-epdg (erlang)</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6363 (New): strongswan: Catch IKEv2 disconn...https://osmocom.org/issues/63632024-02-16T23:50:23Zlynxis
<p>When the IKEv2 SA got destroy we should<br />- inform osmo-epdg via GSUP (Msg: Purge MS Request)<br />- remove internal state</p>
<p>Use listener api ike_updown() + ike_rekey() to get notified about changes in the SA.<br />The python SWu-IKEv2 doesn't seem good enough to test this. Only ike_rekey() can be tested.</p>
<p>Reducing the timeout of the ike SA might help to provoke the code path.</p> libosmocore - Bug #6360 (New): libosmovty fails to parse commands like "test (foo|bar) [(one|two|...https://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> libosmo-sccp + libosmo-sigtran - Bug #6356 (New): DLGLOBAL ERROR Trying to dispatch event 17 to n...https://osmocom.org/issues/63562024-02-08T22:27:51Zneelsnhofmeyr@sysmocom.de
<p>ML reports:</p>
<p>DLGLOBAL ERROR Trying to dispatch event 17 to non-existent FSM instance! (osmo_ss7_as.c:118)</p>
<p>during startup of both osmo-msc and osmo-bsc.<br />Probably related: <a class="external" href="https://gerrit.osmocom.org/c/libosmo-sccp/+/35348">https://gerrit.osmocom.org/c/libosmo-sccp/+/35348</a></p> pySim - Bug #6340 (New): exception when using osmo-smdpp with python 3.9https://osmocom.org/issues/63402024-01-24T09:43:35Zdexter
<p>There is an exception when starting osmo-smdpp with python 3.9. This exception does not occur with python 3.10.</p>
<pre>
owner@osmotest:~/git_master/pysim$ python3.9 ./osmo-smdpp.py
Traceback (most recent call last):
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 100, in <module>
class SmDppHttpServer:
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 196, in SmDppHttpServer
def initiateAutentication(self, request: IRequest, content: dict) -> dict:
TypeError: 'staticmethod' object is not callable
</pre>
<p>Commit hash: af87cd544f784e51a41cea303cb57001d9954d9c</p> OsmocomBB - Bug #6337 (New): bad fr audio with gapk/ms-sdrhttps://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> OsmoMSC - Bug #6330 (New): Incorrect handling of V.120 data callshttps://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://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> OsmoBSC - Bug #6328 (New): Channel Mode Modify fails to modify the RTP payload type numberhttps://osmocom.org/issues/63282024-01-12T06:24:55Zneelsnhofmeyr@sysmocom.de
<p>if you look at the pcap in <a class="external" href="https://osmocom.org/attachments/7192">https://osmocom.org/attachments/7192</a> from <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: if MT call leg does not support the assigned codec, re-assign to a compatible codec (In Progress)" href="https://osmocom.org/issues/6258">#6258</a><br />you'll see that the Channel Mode Modify in packet 5368 changes the codec from GSM-FR to AMR,<br />but then the AMR payload in RTP continues to indicate PT=3 instead of the expected PT=112.</p>
<p>This is because osmo-bsc still fails to:</p>
<ul>
<li>tell the MGW about the changed codec and payload type number via MGCP MDCX</li>
<li>tell the BTS to emit the changed payload type number via ipacc.MDCX</li>
</ul>
<p>This should happen in lchan_fsm.c in lchan_fsm_wait_rsl_chan_mode_modify_ack() on rx of LCHAN_EV_RSL_CHAN_MODE_MODIFY_ACK.<br />The lchan_fsm.c should tell the lchan_rtp_fsm.c to change the payload type number and codec.<br />When lchan_rtp_fsm.c is done with both MDCX, it should signal LCHAN_EV_RTP_READY back to lchan_fsm.</p> OsmoBSC - Bug #6324 (New): Making a data call results in B0RKEN lchanshttps://osmocom.org/issues/63242024-01-05T20:31:49Zkeith
<p>I made a data call from a GSM modem and ended up with a CHAN NACK from osmo-bts (as is to be expected, I suppose)</p>
<p>Should we enhance osmo-bsc's NACK handling to do something a little more helpful than just B0RK the channel?</p> OP25 - Bug #6323 (New): Install script is broken on Ubuntu 23.10https://osmocom.org/issues/63232024-01-05T19:33:14ZErikSwan
<p>I am trying to install OP25 on a fresh Ubuntu 23.10 virtual machine, but it appears like the install script is broken.</p>
When running <code>install.sh</code>, I get the following error message:<br /><pre>
CMake Error at op25/gr-op25/swig/CMakeLists.txt:28 (include):
include could not find requested file:
GrSwig
CMake Error at op25/gr-op25/swig/CMakeLists.txt:40 (GR_SWIG_MAKE):
Unknown CMake command "GR_SWIG_MAKE".
-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target 'install'. Stop.
</pre><br />To reproduce:
<ol>
<li>Create a fresh Ubuntu 23.10 installation using default settings in the installer</li>
<li>Follow the <a class="wiki-page" href="https://osmocom.org/projects/op25/wiki/InstallInstructionsPage">installation instructions</a> exactly.</li>
</ol> pySim - Bug #6322 (New): ATR type annotationhttps://osmocom.org/issues/63222024-01-03T21:55:30Zmerlinchlosta
<p>There's a small mixup in the ATR type annotations (<code>Hexstr</code> vs. <code>List[int]</code>) in <code>PcscSimLink</code>:</p>
<pre>
def get_atr(self) -> Hexstr:
return self._con.getATR()
</pre>
<p><code>pyscard</code> actually returns <code>List[int]</code> for an ATR. Depending code seems to convert using <code>i2h</code>.<br /><code>SerialSimLink</code> mimics the behavior (writing <code>self._atr</code> as <code>List[int]</code> in <code>_reset_card</code>).</p> OsmoMSC - Bug #6321 (New): SMS not delivered from corrupted SMS databasehttps://osmocom.org/issues/63212024-01-02T13:07:31Zjolly
<p>When osmo-msc is started with corrupted "sms.db", no SMS is delivered.</p>
<p>Only the earliest SMS is delivered on a location update. All other SMS are not delivered until the next location update triggers the next earliest SMS delivery.</p>
<p>The problem was solved by removing the "sms.db" file and restarting osmo-msc. All queued SMS were delivered instantly. A newly queued SMS was delivered instantly.</p>
<p>To reproduce and debug the problem, I keept the corrupt database file. It is not included with this issue, because it may contain private information. Ask me for it. (/files/auftraege/sysmocom-MSC_SMS_BUG/sms.db_buggy)</p> pySim - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://osmocom.org/issues/63142023-12-23T09:31:02Zlaforge
<p>during execution of our pySim-shell test, even with the included pcap we're getting:</p>
<pre>
WARNING pySim.apdu.ts_102_221: SELECT UNKNOWN AID a00000015141434c00
</pre>
<p>the AID is that of the ARA-M applet. We do support ARA-M in pySim-shell. However, we do not appear to use that code from pySim-shell, probably related to the AID auto-detection missing.</p> OsmoHLR - Bug #6312 (New): Querying HLR for MSISDN-to-IMSI mapping is too cumbersome and inefficienthttps://osmocom.org/issues/63122023-12-17T19:41:38Zfalconia
<p>Thanks to recently implemented features <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Possibility to route SMS messages over GSUP (Resolved)" href="https://osmocom.org/issues/3587">#3587</a> and <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: Implement routing of SMS-over-GSUP messages between connected MSC/VLRs and SMSCs (Stalled)" href="https://osmocom.org/issues/6135">#6135</a>, we now have a way to connect an external SMSC to an OsmoMSC+OsmoHLR core network. However, there is one remaining difficulty: when that external SMSC needs to deliver MT SMS to a subscriber, the mechanism of SMS-over-GSUP requires that the target MS be identified by IMSI, while the SMSC will typically only have MSISDN for the recipient. Elaborating a little:</p>
<ul>
<li>IMSI is a strictly required IE in every GSUP message, and the design of GSUP thoroughly assumes that every entity that initiates a GSUP exchange (beginning with a request message) knows the IMSI it wishes to operate on.</li>
</ul>
<ul>
<li>Because of the previous point, I don't see an obvious way to add an exchange of "I only know MSISDN, please tell me the corresponding IMSI" to GSUP. What would the requestor put into the mandatory IMSI field of the request message? A dummy? Would the response then replace that dummy with the real IMSI and thus no longer match? Various common GSUP code paths will likely break then - hence this type of query just doesn't seem to fit into GSUP architecture.</li>
</ul>
<ul>
<li>The basic paradigmatic principle that MT-SMS recipients are identified by IMSI rather than MSISDN at the low-level MT delivery protocol level seems correct: one can think of special cases of network-originated SMS (e.g., SIM OTA programming) in which a recipient may not have an MSISDN at all, but does have an IMSI and is thus attached to GERAN or UTRAN. Hence it seems logically correct to me to have MSISDN-to-IMSI resolution as a separate step just prior to actual MT SMS delivery attempt.</li>
</ul>
<p>One currently workable approach is to have the external SMSC connect to OsmoHLR not only via GSUP, but also connect to OsmoHLR ctrl interface, issue ctrl GET queries for subscriber.by-msisdn-XXXX.info and fish the IMSI out of the verbose multiline ASCII-formatted response. My current plan is to implement this cumbersome and inefficient MSISDN-to-IMSI resolution mechanism in ThemWi-SMSC (my current real-life-need use case for an external SMSC connecting to Osmocom CN), but it would certainly be nice to have a better way. I also reason that a more efficient and more logically sensible way of doing this mapping resolution will be needed before the approach of a separate SMSC (split from OsmoMSC) can become Osmocom mainstream.</p>
<p>One easy-to-implement relief measure would be to add a subscriber.by-*.imsi ctrl variable (like subscriber.by-*.msisdn, but read-only). The benefits will be shorter TCP-carried messages on the ctrl connection for MSISDN-to-IMSI queries, and simpler parsing code in the SMSC - no need to fish the IMSI out of lots of other irrelevant info. But the whole idea of using this ctrl interface for a key internal function still feels philosophically wrong. Any better ideas?</p> OsmoMGW - Bug #6297 (New): octet-align=0 is the RFC 6871 specified default to use when omitted; b...https://osmocom.org/issues/62972023-12-08T05:31:12Zneelsnhofmeyr@sysmocom.de
<p>In rx_rtp(), we have a check that ensures the right AMR pack mode is arriving in incoming RTP packets.</p>
<p>Currently, the semantics are this:</p>
<p>- when there is no 'octet-align' fmtp at all, then don't check.<br />- for 'octet-align=[01]' fmtp present, verify correct AMR pack mode.</p>
<p>But RFC 6871 (SDP) specifies that if the 'octet-align' parameter is omitted, that means octet-align=0.</p>
<p>No spec conforming client out there will see a need to send an explicit 'octet-align=0', it will just omit 'octet-align=1'.<br />So osmo-mgw should not change its validation behavior based on the presence or absence of the fmtp;<br />It should assume a default of 0 when omitted.</p>
<p>Related: libosmo-mgcp-client currently has a problem that it can only pass the octet-align flag once per entire SDP body; there is a patch pending to fix it [1] and code has been in flux; meaning to say:<br />It seems that osmo-msc has been omitting the octet-align fmtp for a while now; and things worked out ok because absence of it disabled the AMR pack mode validity checks in osmo-mgw. For 2G-to-2G, both sides sent octet-align=1, and osmo-msc's mgw just forwards without checking. If we now enable this check in osmo-mgw when octet-align is absent, that would break 2G-to-2G calls and needs a fix of osmo-msc's fmtp.</p>
<p>But we can also not just ignore this further: when adding interop with 3G, now it is important to indicate the right pack mode, so IuUP-to-AMR conversion results in the right pack mode. In effect, omitting the octet-align fmtp now results in IuUP converted to AMR-octet-align=0, mismatching 2G. So we should really adopt the specified way of indicating octet-align and not imply anything else.</p>
<p>A solution could be to <strong>not fail</strong> when an unexpected pack mode arrives at osmo-mgw.<br />We can complain in the log, but then just convert it to whatever we expected.</p>
In summary, I suggest to
<ul>
<li>always enable the AMR pack mode checks, also when octet-align fmtp is omitted (mgcp_codec_amr_align_mode_is_indicated() == false).</li>
<li>but when the checks indicate a mismatch, convert to what is needed implicitly and continue the call.</li>
<li>a new vty option in osmo-mgw could switch the octet-align checks to be strict and fail instead of converting.</li>
</ul>
<p>This way we get a concise spec conforming representation of octet-align fmtp in our SDP,<br />while at the same time not breaking 2G-2G calls for older osmo-msc that omit the "octet-align=1" by accident.</p>
<p>(I see that the current osmo-msc I am testing omits "octet-align=1" in MGCP to its MGW,<br />but haven't really checked for how long osmo-msc omits that fmtp; forever? since recently?)</p>
<p>[1] <a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/34900">https://gerrit.osmocom.org/c/osmo-mgw/+/34900</a> -- libosmo-mgcp-client patch to fix fmtp</p>