https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092019-12-23T18:52:28ZOpen Source Mobile CommunicationsOsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169562019-12-23T18:52:28Zpespin
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/16956/diff?detail_id=28003">diff</a>)</li></ul> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169582019-12-23T18:53:15Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/4286">Feature #4286</a>: Support configuration using 8PSK on dowlink while staying GMSK-only on uplink</i> added</li></ul> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169592019-12-23T18:53:28Zpespin
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/16959/diff?detail_id=28007">diff</a>)</li></ul> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169602019-12-23T19:06:45Zpespin
<ul></ul><p>The interesting IE for PACKET RESOURCE REQUEST is: TS 44.060 sec 12.30 MS Radio Access Capability 2</p>
<p>That one basically redirects to TS 24.008 sec 10.5.5.12a MS Radio Access capability</p>
<p>In there there seems to be some configs related to 8PSK support per band, etc.</p>
<p>Regarding TTCN3: RLCMAC_CSN1_Types.ttcn has "type record PacketResourceReq", "resource_req, msg_type = PACKET_RESOURCE_REQUEST;"</p>
<p>That record contains:<br /><pre>
/* 11.2.16 Packet Resource Request */
type record PacketResourceReq {
BIT1 acc_type_presence,
RlcAccessType acc_type optional,
BIT1 id_type,
PacketResourceReqID id,
BIT1 ms_rac2_presence,
MSRadioAccCap2 ms_rac2 optional,
ChannelReqDescription ch_req_desc,
BIT1 change_mark_presence,
BIT2 change_mark optional,
BIT6 C_val,
BIT1 sign_var_presence,
BIT6 sign_var optional,
ILevels I_levels
/* TODO: additional contents for further Releases (starting from 1999) */
} with {
variant (acc_type) "PRESENCE(acc_type_presence = '1'B)"
variant (id) "CROSSTAG(gtfi, id_type = '0'B; tlli, id_type = '1'B)"
variant (ms_rac2) "PRESENCE(ms_rac2_presence = '1'B)"
variant (change_mark) "PRESENCE(change_mark_presence = '1'B)"
variant (sign_var) "PRESENCE(sign_var_presence = '1'B)"
};
</pre></p>
<p>But the interesting IE is not yet implemented, so we need to add support for it TTCN3, then create a new templates in RLCMAC_Types.ttcn:<br /><pre>
/* 12.30 MS Radio Access Capability 2 (feature bitmask)
* (value part, see 3GPP TS 24.008, 10.5.5.12a) */
type union MSRadioAccCap2 {
/* TODO: see table 10.5.146/3GPP TS 24.008 */
bitstring other
};
</pre></p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169622019-12-23T19:52:19Zlaforge
<ul></ul><p>Please note that those templates were all written at a time where TITAN<br />didn't yet understand the 'L' / 'H' notation in the raw codec. I<br />requested that upstream and it has been implemented as part of TITAN for<br />quite some time (for sure the version we use already has it).</p>
<p>For many data types, this syntax is a precondition for describing the<br />RLC/MAC data types correctly. In absence of L/H logic, the offset of<br />the message in the packet determines whether '1'/'0' is sufficient for<br />decoding it or not.</p>
<p>For many GSM rest octets it didn't matter, as they always appear at a<br />fixed position in the packet. In GPRS and EGPRS, this luxury doesn't<br />exist.</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169642019-12-24T10:25:56Zpespin
<ul></ul><p>L/H references:<br /><a class="external" href="https://www.eclipse.org/forums/index.php/m/1807304/?srch=csn#msg_1807304">https://www.eclipse.org/forums/index.php/m/1807304/?srch=csn#msg_1807304</a><br /><a class="external" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=548969">https://bugs.eclipse.org/bugs/show_bug.cgi?id=548969</a><br /><a class="external" href="https://github.com/eclipse/titan.core/commit/231012acb95c68cba7e029eb6901ac76216dcd5b">https://github.com/eclipse/titan.core/commit/231012acb95c68cba7e029eb6901ac76216dcd5b</a><br /><a class="external" href="https://github.com/eclipse/titan.core/blob/master/usrguide/referenceguide/4-ttcn3_language_extensions.adoc">https://github.com/eclipse/titan.core/blob/master/usrguide/referenceguide/4-ttcn3_language_extensions.adoc</a> (grep "CSN.1 L/H")</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169652019-12-24T15:43:00Zpespin
<ul></ul><p>I have code in TTCN3 already sending the Packet Resource Request asking to use EGPRS (<a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16677">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16677</a>). I see the EGPRS Multislot class updated correctly in osmo-pcu, but it's still not enabling EGPRS for that TBF. TbfTest.cpp does something similar in test_tbf_egprs_two_phase_spb() -> establish_ul_tbf_two_phase_spb(), but in there the logs (TbfTest.err) show some differences and in there EGPRS is enabled for the TBF:<br /><pre>
Modifying MS object, TLLI = 0x00000000, EGPRS MS class 0 -> 1 <<---- This one I get it too during TTCN3
TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL EGPRS) Enabled EGPRS, mode EGPRS <<-- This one I don't get in TTCN3.
</pre></p>
<p>The difference seems to appear due to:<br /><pre>
if (egprs_ms_class > 0 && bts->egprs_enabled) {
tbf->enable_egprs();
setup_egprs_mode(bts, ms);
LOGPTBF(tbf, LOGL_INFO, "Enabled EGPRS, mode %s\n", mode_name(ms->mode()));
}
</pre></p>
<p>So in unit test TbfTest, it manually sets bts->egprs_enabled=1. The only way I see that param is modified is throught the VTY param "no egprs" (=0) and "egprs only" (=1). I am a bit surprised because over last months I have been using in osmo-bsc "gprs mode egprs" and I have no "egprs only" setting in my osmo-pcu.cfg, which seems not inline...</p>
<p>Looking at what "gprs mode egprs" does in osmo-bsc: It sets some enum to <code>bts->gprs.mode = BTS_GPRS_EGPRS</code>, which is then used when sending info_ind over pcu_sock #info_ind->flags |= PCU_IF_FLAG_MCS1;@ (same for MCS2, and so on).</p>
<p>However, it seems osmo-pcu is doing nothing with those flags (it does for CS, but not for MCS):<br /><pre>
for (i = 0; i < 9; i++) {
if ((info_ind->flags & (PCU_IF_FLAG_MCS1 << i)))
LOGP(DL1IF, LOGL_DEBUG, " Use MCS%d\n", i+1);
}
</pre></p>
<p>In osmo-bsc, it is also used to tell MS that egprs is supported:<br /><pre>
case BTS_GPRS_EGPRS:
si13_default.cell_opts.ext_info_present = 1;
si13_default.cell_opts.ext_info.egprs_supported = 1;
</pre></p>
<p>So all in all, I was unaware I had to use the "egprs only" VTY cmd to enable EGPRS support in osmo-pcu. I fail to see though why is that command necessary and the bts->egprs_enabled is not set dynamically based on what's received during info_ind in pcu_sock (for instance, when any flag PCU_IF_FLAG_MCS* is received). Any thoughts from someone else on this?</p>
<p>TODO: Fix osmo-gsm-tester templates/osmo-pcu.cfg to have "no egprs" or "egprs only" based on whether egprs is enabled.</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169662019-12-25T04:59:35Zfixeria
<ul></ul><blockquote>
<p>So all in all, I was unaware I had to use the "egprs only" VTY cmd to enable EGPRS support in osmo-pcu.<br />Any thoughts from someone else on this?</p>
</blockquote>
<p>AFAIR, EDGE never worked for me out of the box, and I had to use that VTY option all the time...</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169672019-12-25T13:52:20Zlaforge
<ul></ul><p>On Tue, Dec 24, 2019 at 03:43:00PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>So all in all, I was unaware I had to use the "egprs only" VTY cmd to enable EGPRS support in osmo-pcu. I fail to see though why is that command necessary</p>
</blockquote>
<p>Because osmo-pcu supports <strong>either</strong> GPRS <strong>or</strong> EGPRS. That means, as soon as you turn on EGPRS,<br />you loose backwards compatibility to non-EGPRS phones. Due to that somewhat strange and unusual<br />(in terms of other implementations) behavior, it shouldn't happen dynamically/automatically,<br />but should be very explicit choice by the user. the "only" in the vty command also expresses<br />that.</p>
<p>I believe there are some ancient tickets about this. The reason for<br />lack of GPRS backwards compatibility was to first get GPRS and EGPRS by<br />themselves working reliably and tested, and then (if ever) implement the<br />backwards compatibility. I think the main problem is that there are<br />some parts of downlink PDCH which all (or at least all MS with active<br />TBF) need to be able to parse, and in a mixed GPRS + EGPRS cell you then<br />need to not only look at your own TBF/MS capabilities, but also at those<br />of all the other MS to determine if you can send such information in MCS<br />or if you must send it in CS. I think it already starts with things<br />like TFI and USF, which must be decoded by all MS with active TBF.</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=169732019-12-30T19:37:57Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><ul>
<li>I did some refactoring to get NS tests out of the same .ttcn file (it's already big and growing, and those tests use different components, etc.). There's now PCU_Tests_RAW_NS.ttcn<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16685">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16685</a></li>
</ul>
<ul>
<li>I added support to enable EGPRS through VTY at the start of the test to be able to test both "egprs only" and "no egprs" behaviors, and added a test which reproduces 8-bit rach requests are rejected during "egprs only" mode:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16687">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16687</a></li>
</ul>
<ul>
<li>I continued work on ping pong with egprs TBF and added support to encode EGPRS related fields:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16688">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16688</a> RLCMAC_CSN1_Types.ttcn: Support encoding of MS Radio Access Capability 2<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16689">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16689</a> GSM_RR_Types.ttcn: Support encoding of EGPRS Packet Uplink Assignment<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16677">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16677</a> WIP: EGPRS [WIP]</li>
</ul>
Current situation / TODO:
<ul>
<li>Test TC_mo_ping_pong_egprs currently fails because f_establish_tbf() fails when using "is_11bit := 1, burst_type := BURST_TYPE_1". The problem afaiu is that tr_IMM_TBF_ASS() doesn't match 11-bit RA correctly, because <code>tr_compute_ReqRef()</code> and <code>f_compute_ReqRef()</code> don't support decoding 11-bit RA sent back by osmo-pcu (we support sending them already through PCUIF because there we simply fill a struct we send over the unix socket). I'd welcome some hints on how to add support for it.</li>
</ul>
<ul>
<li>I'd expect osmo-pcu to accept non-11 bit RACH (how's it called?) even if egprs is enabled because it can later on announce edge capabilities (through sending PACKET RESOURCE REQUEST), but I guess it's one of the shortcomings of current implementation.</li>
</ul> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=172992020-01-22T14:43:17Zpespin
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>On Tue, Dec 24, 2019 at 03:43:00PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>So all in all, I was unaware I had to use the "egprs only" VTY cmd to enable EGPRS support in osmo-pcu. I fail to see though why is that command necessary</p>
</blockquote>
<p>Because osmo-pcu supports <strong>either</strong> GPRS <strong>or</strong> EGPRS. That means, as soon as you turn on EGPRS,<br />you loose backwards compatibility to non-EGPRS phones. Due to that somewhat strange and unusual<br />(in terms of other implementations) behavior, it shouldn't happen dynamically/automatically,<br />but should be very explicit choice by the user. the "only" in the vty command also expresses<br />that.</p>
<p>I believe there are some ancient tickets about this.</p>
</blockquote>
<p>Found it: <a class="issue tracker-2 status-5 priority-1 priority-lowest closed" title="Feature: EGPRS/GPRS multiplexing on single PDCH (Closed)" href="https://projects.osmocom.org/issues/1559">#1559</a></p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=173012020-01-22T14:43:35Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-1 priority-lowest closed" href="/issues/1559">Feature #1559</a>: EGPRS/GPRS multiplexing on single PDCH</i> added</li></ul> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=173052020-01-22T14:52:23Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/1548">Bug #1548</a>: 11bit RACH support</i> added</li></ul> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=173192020-01-22T15:55:33Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-1 priority-lowest closed" href="/issues/1529">Feature #1529</a>: Support MCS 5-9 in uplink</i> added</li></ul> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=176142020-03-03T00:32:10Zkeith
<ul></ul><p><a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> I wonder if these log entries are related to this ticket;</p>
<pre>
csn1.c:253 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at I_LEVEL (idx 160)
csn1.c:1441 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at EGPRS_TimeslotLinkQualityMeasurements (idx 164): End AdditionsR99
</pre>
<p>If I comment the two related return ProcessError() lines and return 0 in line 1441, things actually go ahead and "work".</p>
<p>Stopping in csn1.cpp:253, I can see:<br /><pre>
(gdb) p pDescr
$1 = (const CSN_DESCR *) 0x66efd0 <CSNDESCR_InterferenceMeasurementReport_t+48>
(gdb) p *pDescr
$2 = {type = 2, i = 4, descr = {ptr = 0x0, value = 0}, offset = 4, may_be_null = 0, sz = 0x4561b4 "I_LEVEL", value = 0, aux_fn = 0x0}
(gdb) p remaining_bits_len
$3 = 3
</pre></p>
<p>Breaking at line 1441:</p>
<pre>
(gdb) p pDescr
$6 = (const CSN_DESCR *) 0x670230 <CSNDESCR_PRR_AdditionsR99_t+144>
(gdb) p *pDescr
$7 = {type = 3, i = 0, descr = {ptr = 0x66f040 <CSNDESCR_EGPRS_TimeslotLinkQualityMeasurements_t>, value = 6746176}, offset = 24,
may_be_null = 0, sz = 0x456728 "EGPRS_TimeslotLinkQualityMeasurements", value = 0, aux_fn = 0x0}
(gdb) p remaining_bits_len
$8 = -1
</pre>
<p>EDIT: The above is with a HTC "Desire 628 dual sim" phone model. At the same time, this config and version don't exhibit this error with iPhone 5c for example.</p>
<p>Further edit, maybe a full backtrace helps to see the context, and when this happens. (It's before I even get an MM context with this phone)</p>
<pre>
(gdb) bt
#0 csnStreamDecoder (ar=0x7fffffffde30, pDescr=0x670230 <CSNDESCR_PRR_AdditionsR99_t+144>, vector=0x793540,
readIndex=0x7fffffffded8, data=0x7924f8) at csn1.c:1442
#1 0x000000000043f14b in csnStreamDecoder (ar=0x7fffffffdee0, pDescr=0x6706f0 <CSNDESCR_Packet_Resource_Request_t+816>,
vector=0x793540, readIndex=0x7fffffffded8, data=0x792410) at csn1.c:471
#2 0x0000000000439f4d in decode_gsm_rlcmac_uplink (vector=0x793540, data=0x792410) at gsm_rlcmac.cpp:5027
#3 0x000000000042a5d7 in gprs_rlcmac_pdch::rcv_control_block (this=0x68de88 <s_bts+4264>,
data=0x7fffffffe136 "@\027\340q\227i\357&2\262Yd \006", data_len=23 '\027', fn=709804, meas=0x7fffffffe090, cs=...)
at pdch.cpp:708
#4 0x000000000042b054 in gprs_rlcmac_pdch::rcv_block_gprs (this=0x68de88 <s_bts+4264>,
data=0x7fffffffe136 "@\027\340q\227i\357&2\262Yd \006", data_len=23 '\027', fn=709804, meas=0x7fffffffe090, cs=...)
at pdch.cpp:852
#5 0x000000000042aa3d in gprs_rlcmac_pdch::rcv_block (this=0x68de88 <s_bts+4264>,
data=0x7fffffffe136 "@\027\340q\227i\357&2\262Yd \006", len=23 '\027', fn=709804, meas=0x7fffffffe090) at pdch.cpp:771
#6 0x000000000040ebfc in pcu_rx_data_ind_pdtch (trx_no=0 '\000', ts_no=7 '\a',
data=0x7fffffffe136 "@\027\340q\227i\357&2\262Yd \006", len=23 '\027', fn=709804, meas=0x7fffffffe090) at pcu_l1_if.cpp:287
#7 0x000000000040ef66 in pcu_rx_data_ind (data_ind=0x7fffffffe134) at pcu_l1_if.cpp:336
#8 0x00000000004110f9 in pcu_rx (msg_type=2 '\002', pcu_prim=0x7fffffffe130) at pcu_l1_if.cpp:731
#9 0x0000000000435fbd in pcu_sock_read (bfd=0x6968e0 <pcu_sock_state>) at osmobts_sock.cpp:141
#10 0x000000000043619b in pcu_sock_cb (bfd=0x6968e0 <pcu_sock_state>, flags=1) at osmobts_sock.cpp:196
#11 0x00007ffff70e4fd7 in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
#12 0x00007ffff70e5656 in osmo_select_main () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
#13 0x000000000040470f in main (argc=1, argv=0x7fffffffe558) at pcu_main.cpp:355
</pre> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=176152020-03-03T08:32:18Zfixeria
<ul></ul><p>Hi <a class="user active" href="https://projects.osmocom.org/users/4282">keith</a>!</p>
<blockquote>
<p>csn1.c:253 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at I_LEVEL (idx 160)<br />csn1.c:1441 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at EGPRS_TimeslotLinkQualityMeasurements (idx 164): End AdditionsR99</p>
</blockquote>
<p>Could you please attach a *.pcap withe the RLC/MAC packets triggering this?</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=176202020-03-04T15:54:19Zkeith
<ul></ul><p><a class="user active" href="https://projects.osmocom.org/users/67">fixeria</a> - Yep.. sorry, remind me how to get that, GSMTAP in the pcu?</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=176272020-03-04T19:05:19Zfixeria
<ul><li><strong>File</strong> <a href="/attachments/4046">osmo-pcu.cfg</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4046/osmo-pcu.cfg">osmo-pcu.cfg</a> added</li></ul><blockquote>
<p>fixeria - Yep.. sorry, remind me how to get that, GSMTAP in the pcu?</p>
</blockquote>
<p>Attaching a configuration example. Most likely, you can use it as-is.</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=176342020-03-05T04:29:31Zkeith
<ul></ul><p><a class="user active" href="https://projects.osmocom.org/users/67">fixeria</a> Thanks, yes I already refreshed my memory on this. :)</p>
<p>I do not know WTF is up with my systems, but after initially seeing the desired messages in the GSMTAP, I now cannot get GSMTAP to work again. I've tried sending to 127.0.0.1 and also to a remote host running wireshark, (-i) I've tried various combinations of all and few gsmtap-category. All to no avail. "dummy" category does work for some reason, otherwise, nothing that corresponds to the log (which by the way, also does not turn up, with log gsmtap active.)</p>
<p>It's highly bizarre, not to mention frustrating.</p>
<p>I even, in desperation, turned the damn thing off and turned it on again. :-/</p>
<p>I'll try again... but another day. Right now I need to get away from technology before something gets smashed to tiny pieces.</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=176442020-03-05T20:29:50Zkeith
<ul><li><strong>File</strong> <a href="/attachments/4047">offending_UL_RR.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4047/offending_UL_RR.pcap">offending_UL_RR.pcap</a> added</li></ul><p>slightly less frustrating today, working with the lime-sdr on x86 rather than on ARM</p>
<p>Here is a pcap of a packet that causes "NEED_MORE BITS TO UNPACK"</p>
<p>Thanks!</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=176452020-03-06T00:52:01Zfixeria
<ul></ul><blockquote>
<p>Here is a pcap of a packet that causes "NEED_MORE BITS TO UNPACK"</p>
</blockquote>
<p>Thanks, <a class="user active" href="https://projects.osmocom.org/users/4282">keith</a>! Your packet uncovered another bug in the OsmoPCU's CSN.1 decoder:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/17390">https://gerrit.osmocom.org/c/osmo-pcu/+/17390</a> tests/rlcmac: add a new test vector for Packet Resource Request</p>
<p>that should be fixed by:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/17391">https://gerrit.osmocom.org/c/osmo-pcu/+/17391</a> csn1: fix csnStreamDecoder(): skip bits unhandled by serialize()</p>
<p>Please test and add V+1 in Gerrit if that helps.</p> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=180632020-04-23T20:03:35Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/4510">Feature #4510</a>: Support EGPRS RLC/MAC blocks in ttcn3</i> added</li></ul> OsmoPCU - Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAWhttps://projects.osmocom.org/issues/4338?journal_id=203992020-11-25T18:33:28Zpespin
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>10</i> to <i>100</i></li></ul><p>We are nowadays running several EGPRS tests in TTCN3, so I think the general topic here is done and the ticket can be closed.</p>