Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-02-05T09:25:36ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> OCTOI - Osmocom Community TDM over IP - Bug #5694 (Stalled): BERT testinghttps://osmocom.org/issues/56942022-10-01T06:59:48Zlaforge
<p>Soem initial tests with a PrTel93i doing BERT testing on a single B-channel indicates we have some problems to investigate.</p>
<p>This ticket serves as log of the various tests/attempts so far</p>
<ul>
<li>PrTel93i against same PrTel93i doing internal call through Auerswald COMmander2 PBX
<ul>
<li>0 errors in several 1min and 15min calls. So the PrTel and the wiring are good.</li>
</ul></li>
</ul>
<ul>
<li>PrTel93i against same PrTel93i doing external call through same PBX but going out via icE1usb to OCTOI hub and calling back through the same path:
<ul>
<li>first 1min call was with 0 errors</li>
<li>first 15min call was with 6.62 E-2 BER</li>
<li>second 15min call was with 5.92 E-2 BER</li>
<li>no lost / reordered OCTOI frames observed during that time</li>
</ul></li>
</ul>
<ul>
<li>PrTel93i against bchan_loop from capi-hacks (hfc-usb, mISDN, CAPI20) doing internal call through Auerswald COMmander2 PBX
<ul>
<li>1min call with 4.25 E-1 BER</li>
<li>so clearly there are some problems in the misdn/capi integration</li>
</ul></li>
</ul> OCTOI - Osmocom Community TDM over IP - Bug #5693 (Stalled): no progress tones in yatehttps://osmocom.org/issues/56932022-09-30T13:04:16Zlaforge
<p>We've never had call progress tones from yate in our network and had ignored that until now.</p>
This is the case in
<ul>
<li>any outbound call setup from a phone, where there are no dial tones, alerting tones, etc.</li>
<li>calls routed to tone/*</li>
</ul>
<p>The respective ToneSource() class instances are created and provide the respective quantity of samples. It works for SIP, but not for ISDN.</p>
<p>I think it's related to the Q.931 signaling side. It states:</p>
<blockquote>
<p><strong>5.4 In-band tones and announcements</strong></p>
<p>When in-band tones/announcements not associated with a call state change are to be provided by the network before reaching the Active state, a PROGRESS message is returned simultaneously with the application of the in-band tone/announcement. The PROGRESS message contains the progress indicator No. 8, in-band information or appropriate pattern is now available.</p>
<p>When tones/announcements have to be provided together with a call state change, then the appropriate message [e.g. for ALERTING, DISCONNECT, etc., (see clause 3)] with progress indicator No. 8, in-band information or appropriate pattern is now available, is sent simultaneously with the application of the in-band tone/announcement.</p>
</blockquote> Core testing infrastructure - Bug #5665 (Stalled): ERROR: files left in build directory after dis...https://osmocom.org/issues/56652022-08-28T09:21:41Zfixeria
<p>Since recently we're observing sporadic master-* job failures on Jenkins. There is always a coredump file, which makes 'distcleancheck' target fail:</p>
<pre>
ERROR: files left in build directory after distclean:
./tests/core
make[1]: Leaving directory '/build/libosmocore-1.7.0.26-862dd/_build/sub'
make[1]: *** [Makefile:1010: distcleancheck] Error 1
make: *** [Makefile:941: distcheck] Error 1
</pre>
<p>This is not specific to libosmocore, I saw master-osmo-{bsc,msc} failing with the same verdict too.</p> osmo-remsim - Bug #5527 (Stalled): warn on duplicate client (id) connectionshttps://osmocom.org/issues/55272022-04-12T17:37:27Zlaforge
<p>Every client must have its own unique tuple of (client_id/slot_nr).</p>
<p>If a remsim-server receives a duplicate connection, it should pring a clear warning message to the log.</p>
<p>This might not always be a bug, as in csae of network outages / restarts a new connection might arrive before the old one is closed.</p>
<p>The same should apply to remsim-bankd.</p> OsmoBSC - Bug #5308 (Stalled): confusion around mgw e1 line vs trunk dichtomyhttps://osmocom.org/issues/53082021-11-14T14:48:15Zlaforge
<p>there seems to be some lack of logical clarity how the MGCP endpoint names are constructed for use with E1.</p>
<ul>
<li>osmo-mgw uses the trunk number to construct the "e1-N" part in "ds/e1-0/s-1/su16-0"
<ul>
<li>any e1_input line_nr can be mapped to any trunk_nr in the config</li>
</ul>
</li>
<li>osmo-bsc unconditionally uses the e1_input line_nr to construct the "e1-N" part in "ds/e1-0/s-1/su16-0"</li>
</ul>
This means that the entire setup will only work, if osmo-mgw is confiugred to use the same trunk_nr as e1_input line_nr, which
<ol>
<li>is weird, as why would you make something configurable if it only works in one way, and</li>
<li>is not mentioned or documented anywhere in either the osmo-mgw or osmo-bsc documentation, and also not really visible from the example configs, AFAICT</li>
</ol>
<p>So I think we have two ways forward:</p>
<ol>
<li>make osmo-mgw always use the e1 line_nr for constructing the enpdoint names</li>
<li>allow osmo-bsc to configure the mgw-side trunk number [for each timeslot?]</li>
</ol> Core testing infrastructure - Bug #5301 (Stalled): Run TTCN3 docker tests with sanitizer enabledhttps://osmocom.org/issues/53012021-11-10T10:49:12Zdaniel
<p>After updating libosmocore I noticed that the TTCN3 GbProxy tests start to fail with an ASan issue when run locally.</p>
<p>I think at least for the TTCN3 tests on master we should enable <code>*San</code> to catch hidden bugs early. Unfortunately this has a large impact on how the <code>osmo-*-master</code> docker images are built if we want to enable it for the libraries as well - currently we install the nightly packages and build the target from master.</p>
<p>Instead we could build an image that builds all the libraries from master (with sanitizer enabled) and installs those and then use that as base for osmo-*-master.</p>
<p>Not sure what the downsides are, any ideas?</p> OsmoBTS - Bug #5242 (Stalled): A-bis/RSL: CRCX ACK indicates '0.0.0.0' as the local/bind addresshttps://osmocom.org/issues/52422021-09-30T09:25:47Zfixeria
<p>Currently both TC_speech_rtp_tchf and TC_speech_rtp_tchh fail, because CRCX ACK from osmo-bts indicates '0.0.0.0' as the local/bind address. The local/bind address of osmo-bts is needed in order to know where to send RTP packets for the RTP_Emulation component, and of course '0.0.0.0' cannot be used as the remote address for send(). See the attached PCAP file.</p> osmo-e1d - Bug #4916 (Stalled): USB unplug / replug renders e1d unusablehttps://osmocom.org/issues/49162020-12-18T10:28:45Zlaforge
right now the behavior on USB unplug (or - god forbid - a firmware crash) is not very user friendly:
<ul>
<li>e1d keeps running</li>
<li>e1d does not re-open the device when it comes back</li>
</ul>
IMHO, we have the following options
<ol>
<li>fail fast - simply exit when the device is lost, assume systemd or some other management instance will keep respawning us until the device is back
<ul>
<li>but what about client programs like osmo-bsc / osmo-mgw ?</li>
</ul>
</li>
<li>implement re-opening of a single icE1usb device, knowing our blocking control transfers would corrupt any other ongoing communication
<ul>
<li>is it worth the effort, assuming this is only an interim solution</li>
</ul>
</li>
<li>go for a full-blown hot-plug capable architecture lined out in <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: consider a one-thread-per-line architecture (New)" href="https://osmocom.org/issues/4915">#4915</a>
<ul>
<li>will probably take significant effort</li>
</ul></li>
</ol>
<p>I think right now we mostly have to worry about situations with a single icE1usb, so I'm tempted to go for the fail-fast approach, assuming osmo-bsc/osmo-mgw recover in some way.</p> osmo-gbproxy - Bug #4891 (Stalled): gbproxy2: Implement processing of BVC-Flow-Control via BVC FSMhttps://osmocom.org/issues/48912020-12-08T07:46:02Zlaforge
<p>This is a FIXME in the new post-rewrite, pool-capable gbproxy code base</p> osmo-clock-gen - Bug #4857 (Stalled): TLV9001IDBVR no longer in stock ag digikeyhttps://osmocom.org/issues/48572020-11-10T17:06:55Zlaforge
<p>It seems this part is no longer available in digikey (below 3000 units MOQ).</p>
<p>We can source it elsewhere, but that complicates the purchasing process.</p>
<p>Digikey does have a TLV9001UIDBVR in stock. I couldn't find any differences in the TLV9001 datasheet: They both are in SOT-23-5 package, etc. Please investigate.</p> OsmoBSC - Bug #4832 (Stalled): osmo-bsc hard-releases lchan if no MSC is foundhttps://osmocom.org/issues/48322020-10-25T20:52:07Zlaforge
<p>As described in <a class="issue tracker-1 status-7 priority-3 priority-high3" title="Bug: OsmocomBB Rx bit errors in dedicated mode (Stalled)" href="https://osmocom.org/issues/4829">#4829</a>:</p>
<p>So.... the problem is something else altogether, or at least a large part of the problem.</p>
For some reason, osmo-bsc these days <strong>immediately hard-releases the lchan</strong> if there is no MSC. There is no signaling sent back to the MS about this:
<ul>
<li>no spoofing of MM/CM (LU REJECT, CM SERV REJECT, ...) which is still understandable, as it's a layering violation and those messages normally originat e at the MSC</li>
<li><strong>No RR CHANNEL RELEASE is sent to the MS</strong>. That is a big fat bug.</li>
</ul>
<p>Instead, we simply immedaitely close the lchan on the BTS side. This of course means that from that point onwards there re only bit-errors in downlink in the UE.</p>
<pre>
DRSL INFO <0003> ../../../git/src/osmo-bsc/abis_rsl.c:1453 (bts=0) CHAN RQD: reason: Location updating (ra=0x0f, neci=0x01, chreq_reason=0x03)
DCHAN INFO <000f> ../../../git/src/osmo-bsc/lchan_select.c:247 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: (type=SDCCH) Selected
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1657 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: (type=SDCCH) MS: Channel Request: reason=LOCATION_UPDATE ra=0x0f ta=0
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:329 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:548 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: state_chg to WAIT_TS_READY
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/gsm_data.c:861 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: (type=SDCCH) MS Power level update requested: 15 dBm
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/gsm_data.c:893 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: (type=SDCCH) MS Power level update (power class 0): 0 -> 7
DCHAN INFO <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:626 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: (type=SDCCH) Activation requested: FOR_MS_CHANNEL_REQUEST voice=no MGW-ci=none type=SDCCH tch-mode=SIGNALLING encr-alg=A5/0 ck=none
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/timeslot_fsm.c:106 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: Received Event LCHAN_EV_TS_READY
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:644 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_TS_READY}: state_chg to WAIT_ACTIV_ACK
DRSL DEBUG <0003> ../../../git/src/osmo-bsc/abis_rsl.c:476 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) Tx RSL Channel Activate with act_type=INITIAL
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1152 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_ACTIV_ACK}: (type=SDCCH) Rx CHAN_ACTIV_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1164 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_ACTIV_ACK}: Received Event LCHAN_EV_RSL_CHAN_ACTIV_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:772 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_ACTIV_ACK}: (type=SDCCH) Tx RR Immediate Assignment
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:822 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_ACTIV_ACK}: state_chg to WAIT_RLL_RTP_ESTABLISH
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1899 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) SAPI=0 ESTABLISH INDICATION
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1932 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RLL_RTP_ESTABLISH}: Received Event LCHAN_EV_RLL_ESTABLISH_IND
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:850 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RLL_RTP_ESTABLISH}: state_chg to ESTABLISHED
DRSL ERROR <0003> ../../../git/src/osmo-bsc/gsm_08_08.c:483 MM GSM48_MT_MM_LOC_UPD_REQUEST: IMSI-001010000000001: No suitable MSC for this Complete Layer 3 request found
DRSL DEBUG <0003> ../../../git/src/osmo-bsc/abis_rsl.c:644 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:1595 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{ESTABLISHED}: state_chg to WAIT_RF_RELEASE_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/bsc_subscr_conn_fsm.c:778 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: conn SUBSCR_CONN(msc4294967295-conn4294967295_subscr-IMSI-001010000000001)[0x28adc0] detaches lchan (primary lchan)
DMSC ERROR <0007> ../../../git/src/osmo-bsc/bsc_subscr_conn_fsm.c:153 SUBSCR_CONN(msc4294967295-conn4294967295_subscr-IMSI-001010000000001)[0x28adc0]{INIT}: Unable to deliver BSSMAP Clear Request message, no MSC for this conn
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:1644 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: lchan detaches from conn SUBSCR_CONN(msc4294967295-conn4294967295_subscr-IMSI-001010000000001)[0x28adc0]
DLINP ERROR <0017> ../../git/src/input/ipaccess.c:412 Bad signalling message, sign_link returned error: No such file or directory.
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1152 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: (type=SDCCH) Rx RF_CHAN_REL_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/abis_rsl.c:1184 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: Received Event LCHAN_EV_RSL_RF_CHAN_REL_ACK
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:1206 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_RF_RELEASE_ACK}: state_chg to WAIT_AFTER_ERROR
DLSS7 ERROR <0021> ../../git/src/m3ua.c:507 XUA_AS(as-clnt-A-0-m3ua)[0x253d70]{AS_DOWN}: Event AS-TRANSFER.req not permitted
DCHAN DEBUG <000f> ../../git/src/fsm.c:322 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_AFTER_ERROR}: Timeout of X3111
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:1550 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{WAIT_AFTER_ERROR}: state_chg to UNUSED
DCHAN DEBUG <000f> ../../../git/src/osmo-bsc/lchan_fsm.c:382 lchan(0-0-0-CCCH_SDCCH4-0)[0x28a0d0]{UNUSED}: (type=SDCCH) Clearing lchan state
</pre>
<p>We should at the very minimum send a proper RR CHANNEL RELEASE to the MS, so it knows the channel is closed. That's the least we can do. However, it also means that the MS will likely start re-trying again and again. After all, it did not receive any reject with a cause value that would tell it to back off.</p>
<p>So I think we actually should either simply not hard-fast-close but let things run into some timeout (send SCCP connect request but then no response received?), or do the effort of spoofing a LU REJECT / CM SERVICE REJECt with a suitable Reject Cause IE ("Network Failure" or "Service option temporarily out of order" look good to me).</p>
<p>Another oddity about this problem is that it only shows if the MSC is absent when the BSC starts up. If the BSC has once seen the MSC, then it considers it 'eligible'. Even if the MSC then is gone at a later point, it will not go back to this hard-fast-clear behavior (at least not quickly?).</p> osmo-ccid-firmware - Bug #4822 (Stalled): sysmoOCTSIM with osmo-ccid-firmware sometimes fails to ...https://osmocom.org/issues/48222020-10-20T19:48:41Zlaforge
<p>I've never had this before, for many months. However, with recent firmware (0.2.48) I've observed this:<br /><pre>
[179007.559048] usb 1-4.4.3: new full-speed USB device number 32 using xhci_hcd
[179007.639242] usb 1-4.4.3: device descriptor read/64, error -32
[179007.827237] usb 1-4.4.3: device descriptor read/64, error -32
[179008.015187] usb 1-4.4.3: new full-speed USB device number 33 using xhci_hcd
[179008.095235] usb 1-4.4.3: device descriptor read/64, error -32
[179008.283233] usb 1-4.4.3: device descriptor read/64, error -32
[179008.391179] usb 1-4.4-port3: attempt power cycle
[179008.995200] usb 1-4.4.3: new full-speed USB device number 34 using xhci_hcd
[179008.995416] usb 1-4.4.3: Device not responding to setup address.
[179009.203351] usb 1-4.4.3: Device not responding to setup address.
[179009.411047] usb 1-4.4.3: device not accepting address 34, error -71
[179009.491114] usb 1-4.4.3: new full-speed USB device number 35 using xhci_hcd
[179009.491311] usb 1-4.4.3: Device not responding to setup address.
[179009.699411] usb 1-4.4.3: Device not responding to setup address.
[179009.907037] usb 1-4.4.3: device not accepting address 35, error -71
[179009.907219] usb 1-4.4-port3: unable to enumerate USB device
[179039.515037] usb 1-4.4.3: new full-speed USB device number 36 using xhci_hcd
[179039.595097] usb 1-4.4.3: device descriptor read/64, error -32
[179039.782880] usb 1-4.4.3: device descriptor read/64, error -32
[179039.971039] usb 1-4.4.3: new full-speed USB device number 37 using xhci_hcd
[179040.051067] usb 1-4.4.3: device descriptor read/64, error -32
[179040.239072] usb 1-4.4.3: device descriptor read/64, error -32
[179040.347191] usb 1-4.4-port3: attempt power cycle
[179040.954828] usb 1-4.4.3: new full-speed USB device number 38 using xhci_hcd
[179040.954974] usb 1-4.4.3: Device not responding to setup address.
[179041.167074] usb 1-4.4.3: Device not responding to setup address.
[179041.374849] usb 1-4.4.3: device not accepting address 38, error -71
[179041.454915] usb 1-4.4.3: new full-speed USB device number 39 using xhci_hcd
[179041.455125] usb 1-4.4.3: Device not responding to setup address.
[179041.667065] usb 1-4.4.3: Device not responding to setup address.
[179041.879032] usb 1-4.4.3: device not accepting address 39, error -71
[179041.879256] usb 1-4.4-port3: unable to enumerate USB device
</pre></p>
<p>twice in a row while attaching the same sysmoOCTSIM using the same cable attached to the same USB hub, ... that has litrally worked hundreds of times before.</p>
<p>As sysmocom also received a similar report on raspi a few days ago, there may be something wrong.</p>
<p>I removed one SIM card and re-plugged it, and it worked. Unforunately it currently also works with that SIM card re-inserted. Weird.</p> OsmoBTS - Bug #4801 (Stalled): BTS_Tests.TC_tch_sign_l2_fill_frame_dtxd failshttps://osmocom.org/issues/48012020-10-11T19:52:01Zlaforge
<p>The tests fails with the sttement</p>
<pre>
TC_tch_sign_l2_fill_frame_dtxd(6)@nataraja: received only 2+0 (SACCH+other) out of 3 expected fill frames
MTC@nataraja: Test case TC_tch_sign_l2_fill_frame_dtxd finished. Verdict: fail reason: "BTS_Tests.ttcn:6675 : Not enough fill frames received"
</pre>
<p>So it seems like the SACCH in downlink is received, but the fill frames that should be sent by the related code in osmo-bts (<a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/10415">https://gerrit.osmocom.org/c/osmo-bts/+/10415</a>) are either not sent, or somehow lost, or not detected by the test case.</p> OsmoBTS - Bug #4771 (Stalled): Don't log NOTICE messages on missing uplink burstshttps://osmocom.org/issues/47712020-10-01T12:05:51Zlaforgelibosmocore - Bug #4731 (Stalled): LAPDm does not implement SAPI priorities between data link layershttps://osmocom.org/issues/47312020-08-26T19:34:40Zlaforge
<p>AFAIR, The 3GPP specifications contain some very strict rules regarding priorities among different concurrent LAPDm data links for the same subscriber. For example, SAIP0 always has higher priority than SAPI3.</p>
<p>We've just encountered a situation where in MT-SMS, the SAPI3 SABM from BTS to MS was sent <strong>before</strong> the BTS replied with the UA for SAPI0 (contetion resolution procedure, where we echo the PAGING RESPONSE back to the MS).</p>
<p>A quick look at the LAPDm code in libosmocore reveals that it is doing a round-robin rather than implementing the rules.</p>
<p>TS 44.005 Section 4.2.2 states the priorities for SDCCH and SACCH. I guess we can think of FACCH == SDCCH in this context.</p> OsmoBSC - Bug #4614 (Stalled): "bogus channel load sample" when using BS-11, Nokia or Ericsson BTShttps://osmocom.org/issues/46142020-06-15T13:47:09Zlaforge
<pre>
Mon Jun 15 15:36:12 2020 DRLL chan_alloc.c:208 (bts=0) bogus channel load sample (used=0 / total=0)
Mon Jun 15 15:36:13 2020 DRLL chan_alloc.c:208 (bts=0) bogus channel load sample (used=0 / total=0)
</pre>
<p>Also, interestingly:<br /><pre>
OsmoBSC> show trx
TRX 0 of BTS 0 is on ARFCN 121
Description: (null)
RF Nominal Power: 24 dBm, reduced by 0 dB, resulting BS power: 24 dBm
NM State: Oper 'NULL', Admin 'Unlocked', Avail 'Power off'
RSL State: connected
Baseband Transceiver NM State: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
E1 Signalling Link:
E1 Line 2, Type dahdi: Timeslot 1, Mode RSL
E1 TEI 1, SAPI 0
</pre></p>
<p>I think the problem is that the Siemens BS-11 MO structure is quite unlike what TS 12.21 describes, so the baseband transceiver object is simply never initialized.</p>
<p>The " OC=<abbr title="a5">SIEMENSHW</abbr> INST=(03,00,00)" might be can idea?</p> OsmoBTS - Bug #4592 (Stalled): osmo-bts-trx: make sure that handover detection workshttps://osmocom.org/issues/45922020-06-07T08:18:06Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: osmo-bts-trx leaks memory (Resolved)" href="https://osmocom.org/issues/4586">#4586</a>, I noticed that <strong>osmo-bts-trx never sends <em>TRXC HANDOVER</em> command</strong>. It looks like <em>TRXC NOHANDOVER</em> is being sent twice.</p>
<pre>
1401 3.835299624 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
1404 3.835525858 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
1673 3.947655470 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
1674 3.947925293 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2028 4.071425165 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2031 4.071810374 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2334 4.186607520 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2337 4.187177856 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2648 4.295164236 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2649 4.295823750 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
10759 7.367793910 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
10762 7.368688082 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
11205 7.532400900 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
11206 7.532637365 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
</pre>
<p>The purpose of these TRXC commands is to control handover detection in transceiver. By default, handover detection is enabled on all inactive channels. As soon as the BSC activates a logical channel, osmo-bts-trx needs to send <em>TRXC NOHANDOVER</em> to the transceiver, so handover detection is disabled for that channel. As soon as a logical channel is deactivated, osmo-bts-trx needs to send <em>TRXC HANDOVER</em> to the transceiver, so handover detection is on again.</p>
<p>I quickly checked the source code, and indeed there is a bug:</p>
<pre><code class="c syntaxhl"><span class="cm">/* setting all logical channels given attributes to active/inactive */</span>
<span class="kt">int</span> <span class="nf">trx_sched_set_lchan</span><span class="p">(</span><span class="k">struct</span> <span class="n">l1sched_trx</span> <span class="o">*</span><span class="n">l1t</span><span class="p">,</span> <span class="kt">uint8_t</span> <span class="n">chan_nr</span><span class="p">,</span> <span class="kt">uint8_t</span> <span class="n">link_id</span><span class="p">,</span> <span class="n">bool</span> <span class="n">active</span><span class="p">)</span>
<span class="p">{</span>
<span class="cm">/* Skipped code here... */</span>
<span class="cm">/* disable handover detection (on deactivation) */</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">active</span><span class="p">)</span>
<span class="n">_sched_act_rach_det</span><span class="p">(</span><span class="n">l1t</span><span class="p">,</span> <span class="n">tn</span><span class="p">,</span> <span class="n">ss</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
<span class="k">return</span> <span class="n">rc</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>Even the comment near the 'if' statement is wrong.</p> Core testing infrastructure - Bug #4576 (Stalled): ttcn3-hlr-tests need to route multicast traffi...https://osmocom.org/issues/45762020-06-02T22:29:38Zneelsnhofmeyr@sysmocom.de
<p>The MSLookup tests in the ttcn3-hlr-test send out multicast-DNS queries,<br />and these should be answered by osmo-hlr running in the osmo-hlr-master container.</p>
<p>Running wireshark on the docker-hosting machine on 'any', the DNS queries are visible:</p>
<pre>
No. Time Arrival Time Source Source Port Destination Destination Port Info
102721 4919.259341 Jun 3, 2020 00:16:05.287612000 CEST 172.18.10.103 4266 239.192.23.42 4266 Standard query 0x5ca3 ANY sip.voice.491618327224.msisdn.mdns.osmocom.org
102722 4919.259341 Jun 3, 2020 00:16:05.287612000 CEST 172.18.10.103 4266 239.192.23.42 4266 Standard query 0x5ca3 ANY sip.voice.491618327224.msisdn.mdns.osmocom.org
</pre>
<p>Running tcpdump in the osmo-hlr-master container shows no such activity.</p>
<p>When running the osmo-mslookup-client commandline tool with the same query, osmo-hlr does receive it and responds in the way that the test expects it:</p>
<pre>
# osmo-mslookup-client sip.voice.262422543586245.imsi
query result last age v4_ip v4_port v6_ip v6_port
sip.voice.262422543586245.imsi result last 257 66.66.66.66 5060
</pre>
<p>But also, the tester does not receive that response<br />(as I found out by "infinitely" looping the MSLookup send and receive in HLR_Tests.ttcn).</p>
<p>I am not sure how <a class="user active" href="https://osmocom.org/users/301771">osmith</a> managed to test the MSLookup tests successfully,<br />there must be some way to get the multicast traffic to pass through the containers.</p> OsmoBTS - Bug #4500 (Stalled): osmo-bts-{sysmo,oc2g,litecell15}: PTCCH/U is not enabled on PDCH t...https://osmocom.org/issues/45002020-04-17T20:05:03Zfixeria
<p>Enabling <em>GsmL1_Sapi_Ptcch</em> on direction <em>GsmL1_Dir_RxUplink</em> fails for the black-box DSP based models:</p>
<pre>
<0006> oml.c:511 activating (bts=0,trx=0,ts=7,ss=0) pchan=PDCH ts_connect_as(PDCH) logChComb=pdtch
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 7 <-- Downlink
<0006> oml.c:808 Successful activation of L1 SAPI PTCCH on TS 7 <-- Downlink
<0006> oml.c:808 Successful activation of L1 SAPI PRACH on TS 7 <-- Uplink
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 7 <-- Uplink
<0006> oml.c:813 Error activating L1 SAPI PTCCH on TS 7: Invalid parameter <-- Uplink
</pre>
<p>This is needed in order to support Continuous Timing Advance procedures on PDCH (see <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: continuous timing advance loop using PTCCH (Stalled)" href="https://osmocom.org/issues/1545">#1545</a>).</p>
<p>At the moment we can only send PTCCH blocks on Downlink, while the Access Burst (PTCCH/U) detection task is not enabled:</p>
<pre><code class="c syntaxhl"><span class="k">static</span> <span class="k">const</span> <span class="k">struct</span> <span class="n">sapi_dir</span> <span class="n">pdtch_sapis</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Ptcch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Prach</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="c">#if 0
{ GsmL1_Sapi_Ptcch, GsmL1_Dir_RxUplink }, // <-- PTCCH/U
{ GsmL1_Sapi_Pacch, GsmL1_Dir_TxDownlink },
#endif
</span><span class="p">};</span>
</code></pre>
<p>This SAPI has been disabled on purpose, because the error indication breaks dynamic timeslots in the BSC (see <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: PTCCH activation breaks dyn TS (Closed)" href="https://osmocom.org/issues/1796">#1796</a>).</p>
<p>My best guess is that the DSP does not allow to enable both <em>GsmL1_Sapi_Prach</em> (Uplink) and <em>GsmL1_Sapi_Ptcch</em> (Uplink) at the same time. As was pointed out by Max, according to the DSP's docs the only channel combination with PTCCH support is <em>GsmL1_LogChComb_XIII</em>. As per 3GPP TS 45.002, this combination XIII includes the following channels:</p>
<ul>
<li>PDTCH/F</li>
<li>PACCH/F</li>
<li>PTCCH/F</li>
</ul>
<p>and PRACH is not a part of it! Perhaps we should enable <em>GsmL1_Sapi_Pacch</em> on <em>GsmL1_Dir_RxUplink</em> instead of <em>GsmL1_Sapi_Prach</em> in order to support Packet Control Ack in form of four Access Bursts, and try enabling <em>GsmL1_Sapi_Ptcch</em> on <em>GsmL1_Dir_RxUplink</em>:</p>
<pre><code class="c syntaxhl"><span class="k">static</span> <span class="k">const</span> <span class="k">struct</span> <span class="n">sapi_dir</span> <span class="n">pdtch_sapis</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="cm">/* PTCCH/D and PTCCH/U for Continuous Timing Advance loop */</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Ptcch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Ptcch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="cm">/* Packet Control Ack in form of four Access Bursts */</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pacch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="p">};</span>
</code></pre>
<p>I don't have a possibility to verify my (potentially wrong) assumption, so waiting for remote access to be provided by <a class="user active" href="https://osmocom.org/users/7">laforge</a>.</p> osmo-remsim - Bug #4409 (Stalled): osmo-remsim-client-st2 (or firmware?) gets stuck on PTShttps://osmocom.org/issues/44092020-02-20T21:02:21Zlaforge
<p>In the test setup at my home office, I can occasionally see osmo-remsim-client-st2 get stuck when the Modem (in this case a Quectel EC20) is performing PTS with the card.</p>
<p>In the log of osmo-remsim-client-st2 I can see:<br /><pre>
SIMtrace => PTS req: ff 10 94 7b 00 00 ^M
SIMtrace -> 01 07 00 00 00 00 15 00 04 ff 10 94 7b 00 00 ff 10 94 7b ^M
SIMtrace => PTS req: ff 10 94 7b 00 00 ^M
SIMtrace IRQ 01 04 00 00 00 00 15 00 13 00 00 00 00 00 09 04 0a 80 25 00 00 ^M
</pre></p>
<p>after which the communication doens't proceed. After a long time, the modem seems to retry without PTS and then proceeds with normal SIM card communication.</p>
<p>The SIM Card ATR in this case is 3b7d9400005555530a7486930b247c4d5468.</p> Cellular Network Infrastructure - Bug #4131 (Stalled): osmo-gsm-manuals: Use leveloffset attribut...https://osmocom.org/issues/41312019-07-26T13:04:49Zpespin
<p>Right now, all documents under osmo-gsm-manuals.git/commons/ start with title level 1 (==). However, if one wishes to add a document with level 2 (===) so it can also be included in other repository document, it will make osmo-gsm-manuals.git "make check" fail due to osmo-gsm-manuals/tests/Makefile.am:22:<br /><pre>
echo "include::$${chapter}[]" >> $@; \
</pre></p>
<p>Which includes stuff under a test document with level 0 (=). If a document with level different than 1 (==) is added, then it will fail on some versions (like jenkins):<br /><pre>
"asciidoc: WARNING: mgcp_extension_osmux.adoc: line 2: section title out of sequence: expected level 1, got level 2"
</pre></p>
<p>See for instance commit osmo-gsm-manuals.git 061cca4d7345bc4f496324d0b4d30bc51e1f8d23, which had to be fixed up later.</p>
<p>The solution here is to use "leveloffset" attribute. To make our life easier in the future, we need to move all documents under common/ to start with level 0 (=), and then use "leveloffset" on all includes in all other repositories using them. This way same document can easily be added on different levels on different documents.</p>
<p>Important! It seems this syntax doesn't work for me:<br /><pre>
include::chapter2.adoc[leveloffset=+1]
</pre></p>
<p>However, this does and it's basically the same:<br /><pre>
:leveloffset: 1
include::chapter1.adoc[]
:leveloffset: 0
</pre></p>
<p>Related information:<br /><a class="external" href="https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc">https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc</a><br /><a class="external" href="https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html">https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html</a><br /><a class="external" href="http://asciidoc.org/userguide.txt">http://asciidoc.org/userguide.txt</a></p> OsmoBSC - Bug #4070 (Stalled): Implement IPA PING/PONG mechanism on RSL and OMLhttps://osmocom.org/issues/40702019-06-21T14:46:51Zlaforge
<p>Let's make sure the RSL and OML links use the IPA PING/PONG mechanism to the BTSs and disconnect if no PONG is received. the interval and timeout should ideally be user(vty)-configurable. It might be that the actual code has to reside in libosmo-abis, not in OsmoBSC itself. Keep in mind that classic E1 BTSs don't have IPA or TCP.</p> OsmoBTS - Bug #4023 (Stalled): Missing coverage of PCU interface in osmo-btshttps://osmocom.org/issues/40232019-05-24T20:19:52Zlaforge
<p>let's use this as a separate ticket from <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Extension of BTS_Tests.ttcn test coverage (Resolved)" href="https://osmocom.org/issues/3750">#3750</a> to provide a more verbose list of the tests related to the PCU interface</p> libosmo-netif - Bug #3812 (Stalled): stream_test fails depending on where it is runhttps://osmocom.org/issues/38122019-02-21T15:18:52Zneelsnhofmeyr@sysmocom.de
<p><a class="user active" href="https://osmocom.org/users/119">msuraev</a>, your new stream_test fails for me.<br />On my home laptop sporadically, on my office box reliably.</p>
<pre>
1: stream_test FAILED (testsuite.at:8)
▶ cat tests/testsuite.dir/1/testsuite.log
# -*- compilation -*-
1. testsuite.at:4: testing stream_test ...
../../../src/libosmo-netif/tests/testsuite.at:8: $abs_top_builddir/tests/stream/stream_test
--- experr 2019-02-21 16:12:24.956776809 +0100
+++ /n/s/dev/make/libosmo-netif/tests/testsuite.dir/at-groups/1/stderr 2019-02-21 16:12:33.984665754 +0100
@@ -12,8 +12,7 @@
autoreconnecting test step 6 [client OK, server OK], FD reg 1
autoreconnecting test step 5 [client OK, server OK], FD reg 1
-[ CONNECTED] osmo_stream_cli_recv(): connection closed with srv
-[ NONE] osmo_stream_cli_reconnect(): retrying in 9 seconds...
+connection closed with srv
autoreconnecting test step 4 [client OK, server OK], FD reg 0
@@ -37,7 +36,6 @@
non-reconnecting test step 2 [client OK, server OK], FD reg 1
non-reconnecting test step 1 [client OK, server OK], FD reg 1
-[ CONNECTED] osmo_stream_cli_recv(): connection closed with srv
-[ NONE] osmo_stream_cli_reconnect(): not reconnecting, disabled.
+connection closed with srv
-non-reconnecting test step 0 [client OK, server OK], FD reg 0
+non-reconnecting test step 0 [client OK, server OK], FD reg 1
1. testsuite.at:4: 1. stream_test (testsuite.at:4): FAILED (testsuite.at:8)
</pre> OsmoBSC - Bug #3806 (Stalled): OsmoBSC accepts BSSAP with wrong length fieldhttps://osmocom.org/issues/38062019-02-18T13:17:55Zlaforge
<p>As seen in <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoMSC sends invalid BSSMAP length field on CSFB CLEAR COMMAND (Resolved)" href="https://osmocom.org/issues/3805">#3805</a>, OsmoBSC would happily accept BSSMAP CLEAR COMMAND messages with IEs that extend beyond the length field of the BSSAP header.</p>
<p>This is definitely wrong. We should</p>
<ul>
<li>parse the length field</li>
<li>ensure we have a minimum of that number of bytes of payload as specified by the length field</li>
<li>truncate the msgb to a payload length as specified</li>
</ul>
<p>This way any additional garbage at the end of a message would simply be ignored, with us only parsing the specified "length" number of bytes.</p>
<p>Let's also make sure to add TTCN-3 tests for this, intentionally sending length field values too large and too short.</p>
<p>Once implemented in OsmoBSC, we should also implement it on the MSC side.</p> libosmo-ranap - Bug #3420 (Stalled): ranap_transp_assoc_decode() decodes X.213 NSAP address heade...https://osmocom.org/issues/34202018-07-26T13:51:46Zneelsnhofmeyr@sysmocom.de
<p>The SysmoCell5000 series sends RAB-AssignmentResponse with X.213 NSAP addresses, which get parsed by ranap_transp_assoc_decode().<br />These contain a three byte header followed by the IP address, typically it is 0x350001 followed by the Ipv4 address in hex.</p>
<p>ranap_transp_assoc_decode() however starts at the header and decodes as 53.0.1.N where N is the first octet of the actual IPv4 address, e.g. 192.<br />Hence switching RTP streams to the cell fails, since obviously 53.0.1.192 is not the correct IP address.</p>
<p>a) fix the check for the address length, should be len == 7, not len > 7.</p>
<p>b) generally be stricter about the lengths.</p> GSM Audio Pocket Knife - Bug #2514 (Stalled): GSM HR encoding result does not match the referencehttps://osmocom.org/issues/25142017-09-15T14:39:13Zfixeria
<p>Implementing the automake transcoding tests, I found that GSM HR related<br />encoding tests are always fail, while decoding from the reference files<br />is ok.</p>
<p>Regression tests summary:</p>
<pre><code>1: procqueue ok<br /> 2: io/pq_file ok<br /> 3: io/pq_rtp ok<br /> 4: conv/enc/amr_efr ok<br /> 5: conv/enc/gsm ok<br /> 6: conv/enc/racal_hr FAILED (testsuite.at:49)<br /> 7: conv/enc/racal_fr ok<br /> 8: conv/enc/racal_efr ok<br /> 9: conv/enc/ti_hr FAILED (testsuite.at:79)<br /> 10: conv/enc/ti_fr ok<br /> 11: conv/enc/ti_efr ok<br /> 12: conv/enc/rtp_efr ok<br /> 13: conv/enc/rtp_hr_etsi FAILED (testsuite.at:119)<br /> 14: conv/enc/rtp_hr_ietf FAILED (testsuite.at:129)<br /> 15: conv/dec/amr_efr ok<br /> 16: conv/dec/gsm ok<br /> 17: conv/dec/racal_hr ok<br /> 18: conv/dec/racal_fr ok<br /> 19: conv/dec/racal_efr ok<br /> 20: conv/dec/ti_hr ok<br /> 21: conv/dec/ti_fr ok<br /> 22: conv/dec/ti_efr ok<br /> 23: conv/dec/rtp_efr ok<br /> 24: conv/dec/rtp_hr_etsi ok<br /> 25: conv/dec/rtp_hr_ietf ok</code></pre>
<p>The same problem can be discovered using the built-in shell<br />script named 'test_all_formats.sh'.</p>
<p>I have also attempted to compare the encoding results with<br />the reference files and found, that the mismatching bytes are<br />starting from 128th until 352 bytes.</p> osmo-sip-connector - Bug #1683 (Stalled): osmo-sip-connector: Implement codec selection / move co...https://osmocom.org/issues/16832016-03-31T18:39:48Zzecke
<p>We need to select codecs.. There were multiple mails on the OpenBSC list. For GSM MO call we need to check the bearer calls and the availability of channels and then can offer different codecs. The FR vs. HR decision needs to be done early but then codec can be changed.</p>
<p>The MNCC protocol needs to change in many still to be defined ways. This includes:</p>
<ul>
<li>NITB needs to inform which TCH/F.. TCH/H are available</li>
<li>RTP_CREATE/RTP_CONNECT needs to include AMR mode-sets</li>
<li>Need to test switching codec</li>
<li>BTS needs to support Payload2 to allow asymentric PayloadType for the same codec!</li>
</ul> OsmoBSC - Bug #1614 (Stalled): better identification of BTS model / capabilities to BSChttps://osmocom.org/issues/16142016-02-23T16:24:51Zlaforge
Right now, there is a lot of implied knowledge at the BSC level about the BTS, i.e.
<ul>
<li>the BSC needs to be told which BTS model it is</li>
<li>the BSC needs to be told the nominal transmit power of each TRX</li>
<li>the BSC needs to be told about the codec capabilities, etc.</li>
</ul>
<p>In order to reduce the currently seemingly endless possbilities how somebody can end up with a non-working<br />configuration, it would be good if the BTS would express its capabilities towards the BSC. As there is<br />no standard in the Abis specs for this, we have to come up with a mechanism of our own.</p>
<p>It might be a vendor-specific OML request from BSC to BTS, which we could use to determine from BSC side if the BTS supports this request at all (if not, proceed as usual). This would also ensure backwards compatibility with nanoBTS or older OsmoBTS versions.</p>