The TLLI is tried to be updated later anyway during tbf_alloc_ul(), but
this way it's clear that information is stored where it belongs as soon
as possible. The change already shows clearer log lines in TbfTest.err.
Change-Id: I20ce4eb94ecf85ce2835275d0056d9ecd1b558c3
It's perfectly fine receiving a Resource Request message under some
circumstances (as stated in the comment added in the commit).
To print issues only under non-expected circumstances, the function
rcv_resource_request need to be refactored:
* Destroying older UL_TBF is delayed because it is needed further
down.
* When the old UL_TBF is FINISHED, it's an acceptable time to receive a
Resource request, so we check if that's the case and don't print a
warning in that case.
Change-Id: I4b4367126d6a16055cd2f45afc4a6b9c15a7c980
If the information is not found in the message, 0 (unknown MS class)
will be returned. If the MS already had some previous information on the
MS class, let's not lose it by setting it back to 0.
Take the opportunity to drop related log lines which are no needed,
since set_(egprs_)ms_class() functions already log the value changes.
Change-Id: Icd52209fd4395d78dc770e7869d1b1fe45a18ca0
There's no real good explanation on why the DL TBF is dropped there,
since PKT RESOUCE REQUEST is used basically during UL TBF establishment.
Also, as decribed by TS 44.060 11.2.16 "Packet Resource Request":
"""
This message is sent on the PACCH by the mobile station to the network
to request a change in the uplink resources assigned.
"""
Change-Id: Iab4afb66f0d671f7ad54909d2685a1613e12ab4d
According to 3GPP TS 44.018 sec 10.5.2.40, Timing Advance value is 8 bit
and range is 0-63 (0-219 on GSM400). Unsigned value (uint8_t) is used
everywhere else, so avoid using a signed one here, and simply check for
GSM48_TA_INVALID here, which we use everywhere else to initialize when the
value is not known. Ideally we should check for value based on band, but
it makes more sense to check that when receiving the data and storing in
in set_ta().
Change-Id: I82b13561d0fe5ebafb5c3a8b9a501045c29809bc
According to 3GPP TS 44.018 sec 10.5.2.40, Timing Advance value is 8 bit
and range is 0-63 (0-219 on GSM400). So there's no need for 16 bits to
store it. uint8_t is used in all other places in the code.
Change-Id: I38aa063ae30ca5680fef6252d2cef22cea98c123
For instance, that may happen because the len of the message is not
filling the expect size (because padding is missing for example). Still,
in this case we know the channel type, so we set it so that wireshark
tries to decode the message as a data one.
Change-Id: Ifea94095d669b528874e64ca823a776cd6e22b4b
Since commit 322456ed47 (and previous
one), it is expected that a tbf object ALWAYS has a MS object referend
to it, even if it's a temporary copy which will later be merged when
TLLI/IMSI is retrieved and it is found that several MS objects relate to
the same MS.
The purpose of set_tlli_from_ul was mainly to update TBF's ms() to
old_ms before going through usual tbf->update_ms() path. That's not
really needed since ms() is already always set and TBFs for old_ms are
already freed in update_ms() and children function.
Change-Id: Ie8795e7a02032336e53febb65c11f9150c36d2a0
Since not all the the information about the MS is known during TBF
creation in all scenrios, it may happen that when TBF is created it
creates a MS which later will end up being found a duplicate of an
already previously existing MS.
At that point, the old object is dropped and information retrieved from
both is merged into the new one.
The GPRS MS class was being transferred, but the EGPRS MS class was missing.
Change-Id: Ieb9929b60254b12f79392d6acb8b456d71cccb9e
According to 3GPP TS 44.004, section 7.4a, two alternative RACH
block formats are specified: 8 bit (1 octet) and 11 bit. The
bit order is LSB (right to left), byte order is MSB.
In PCUIF RACH.ind structure (see gsm_pcu_if_rach_ind) we use
a field of type uint16_t to store RA values regardles of the
block format. Thus when packing it to bytes, we cannot just
cast uint16_t* to uint8_t*, we need to do some bit shifting.
Change-Id: I08a0a908f855b0d8a002df732e02781126d27dfb
Let's finally use the API we introduced in [1].
[1] I96df3352856933c9140177b2801a2c71f4134183
Change-Id: Ia15761c33c8048d35c7f7bc93dbea781dd0894b7
Related: OS#1548
This patch is a set of tightly related changes:
- group all RACH.ind parameters into struct 'rach_ind_params';
- group Channel Request parameters into struct 'chan_req_params';
- get rid of egprs_mslot_class_from_ra(), priority_from_ra(),
and is_single_block(), introduce unified parse_rach_ind();
- improve logging, get rid of redundant information.
This is needed for proper EGPRS Packet Channel Request handling.
Change-Id: I5fe7e0f51bf5c9eac073935cc4f4edd667c67c6e
Related: OS#1548
According to 3GPP TS 44.004, section 7.4a, two alternative RACH block
formats are specified: 8 bit (1 octet) and 11 bit. This change adds
CSN.1 definitions for 11 bit EGPRS Packet Channel Request as per
3GPP TS 44.060, table 11.2.5a.2.
Change-Id: I96df3352856933c9140177b2801a2c71f4134183
Related: OS#1548
I faced a problem while working on EGPRS Packet Channel Request
coding support: the unit test I wrote for it was passing when
compiled with AddressSanitizer, but failing when compiled
without it o_O. Somehow this was observed only with GCC 10.
Here is a part the standard output diff for that unit test:
*** testEGPRSPktChReq ***
decode_egprs_pkt_ch_req(0x2b5) returns 0
- ==> One Phase Access
+ ==> unknown 0xdd5f4e00
decode_egprs_pkt_ch_req(0x14a) returns 0
- ==> One Phase Access
+ ==> unknown 0xdd5f4e00
decode_egprs_pkt_ch_req(0x428) returns 0
- ==> Short Access
+ ==> unknown 0xdd5f4e01
At the same time, debug output of the CSN.1 decoder looked fine.
So WYSINWYG (What You See Is *NOT* What You Get)! As it turned
out, this was happening because I used an enumerated type to
represent the sub-type of EGPRS Packet Channel Request.
typedef struct
{
EGPRS_PacketChannelRequestType_t Type; // <-- enum
EGPRS_PacketChannelRequestContent_t Content;
} EGPRS_PacketChannelRequest_t;
The problem is that length of an enumerated field, more precisely
the amount of bytes it takes in the memory, is compiler/machine
dependent. While the CSN.1 decoder assumes that the field holding
sequential number of the chosen element is one octet long, so its
address is getting casted to (guint8 *) and the value is written
to the first MSB.
// csnStreamDecoder(), case CSN_CHOICE:
pui8 = pui8DATA(data, pDescr->offset);
*pui8 = i; // [ --> xx .. .. .. ]
Let's make sure that none of the existing RLC/MAC definitions is
using enumerated types, and add a warning comment to CSN_CHOICE.
Affected CSN.1 definitions (unit test output adjusted):
- Additional_access_technologies_struct_t,
- Channel_Request_Description_t.
Change-Id: I917a40647480c6f6f3b0e68674ce9894379a9e7f
The current implementation is not capable of handling more than
256 (UCHAR_MAX) selectors in the choice list. Let's document
this and add a guard check to the M_CHOICE handler.
Change-Id: I40c3c5b9be892804c6cd71cbb907af469ce5d769
This is not a functional change, just fixing misleading function
name. Access Bursts on PTCCH/U have nothing to do with PDTCH.
Change-Id: I4ab710ba026315301cc6970263967616401a9fc8
We have same kind of object splitted into two layers, in coding_scheme
and gprs_coding_scheme. Let's merge them together and get rid of the
class, which is not really useful because it's only a set of functions
operating on one enum value.
This change also fixes gcc 10.1.0 error about memseting a complex type
in rlc.h init().
Change-Id: Ie9ce2144ba9e8dbba9704d4e0000a2929e3e41df
In normal conditions ACKing of UL blocks is only sent every
SEND_ACK_AFTER_FRAMES (20) frames. Which means if CV=0 is received (and
hence no more packets are received) less than 20 frames before a lost,
the PCU won't ask for a retransmission and wait there until some timer
destroys the TBF.
This issue is shown by TTCN3 test PCU_Tests.ttcn
TC_ul_intermediate_retrans.
Unit tests triggering this condition are adapted. Some similar tests are
not triggering it because BSN/CV relation being used is totally wrong
(like CV=0 being sent on a BSN with previous value than others).
Change-Id: I9b4ef7b7277efa645bdb5becf2e9f6b32c99a9b1
Newer gcc 10.1.0 is erroring due to memset being applied on a complex
type, so let's start by removing this only function outside of the
struct.
Change-Id: I20426557d9b3049ab275fadb92e10ea8a860a119
It's super annoying seeing lots of functions being called everywhere
only to find out they are only incrementing a counter. Let's drop all
those functions and increment the counter so people looking at code
doesn't see dozens of code paths evyerwhere.
Most of the commit was generated by following sh snippet:
"""
#!/bin/bash
define_pattern="^CREATE_COUNT_ADD_INLINE"
generic_func="do_rate_ctr_add"
grep -r -l "${define_pattern}" . | xargs cat | grep "${define_pattern}("| tr -d ",;" | tr "()" " " | awk '{ print $2 " " $3 }' >/tmp/hello
while read -r func_name ctr_name
do
#echo "$func_name -> $ctr_name";
files="$(grep -r -l "${func_name}(" .)"
for f in $files; do
echo "$f: $func_name -> $ctr_name";
sed -i "s#${func_name}(#${generic_func}(${ctr_name}, #g" $f
done;
done < /tmp/hello
grep -r -l "void ${generic_func}" | xargs sed -i "/void ${generic_func}(CTR/d"
grep -r -l "$define_pattern" | xargs sed -i "/$define_pattern/d"
"""
Change-Id: I966221d6f9fb9bb4f6068bf45ca2978008a0efed
It's super annoying seeing lots of functions being called everywhere
only to find out they are only incrementing a counter. Let's drop all
those functions and increment the counter so people looking at code
doesn't see dozens of code paths evyerwhere.
Most of the commit was generated by following sh snippet:
"""
#!/bin/bash
grep -r -l ^CREATE_COUNT_INLINE . | xargs cat | grep "^CREATE_COUNT_INLINE("| tr -d ",;" | tr "()" " " | awk '{ print $2 " " $3 }' >/tmp/hello
while read -r func_name ctr_name
do
#echo "$func_name -> $ctr_name"
files="$(grep -r -l "${func_name}()" .)"
for f in $files; do
echo "$f: $func_name -> $ctr_name";
sed -i "s#${func_name}()#do_rate_ctr_inc(${ctr_name})#g" $f
done;
done < /tmp/hello
grep -r -l "void do_rate_ctr_inc" | xargs sed -i "/void do_rate_ctr_inc(CTR/d"
grep -r -l "CREATE_COUNT_INLINE" | xargs sed -i "/^CREATE_COUNT_INLINE/d"
"""
Change-Id: I360e322a30edf639aefb3c0f0e4354d98c9035a3
The function is simply setting the ta on the ms, so simply make sure ta
is set on callers before passing the ms object.
Change-Id: Iebb9c57f458690e045ddc45c800209ad8cf621e0
Variable found is used to always call Guard() on MS to avoid possible
unexpected freeing regressions.
Change-Id: I62f24fe04ca10fca19bedda288fe3ed3ce75413f
The default loglevels of some log categories are configured to
LOGL_INFO. This is still to verbose, lets use LOGL_NOTICE here.
Change-Id: Ibb1cd1a94fb4fdd0147e073f8c1c82562c2c14ef
Related: OS#2577
It's really non-sense from architectural point of view to pass an
optional pointer to the MS holding the TBF and creating it otherwise.
TBFs shouldn't be creating MS they belong too.
This simple change requiring so many code line changes really exhibits
how badly entangled the object relationship is.
Another commit will follow doing the same for dl tbf.
Change-Id: I010aa5877902816ae246e09ad5ad87946f96855c
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: Ida8fd3bd7347163567acde34ad67aefee913b0ea
MultislotClass is 5 bit long, so an uint8_t is enough.
In most places we are already storing multislot class as uint8_t.
Change-Id: I1dcaff9d69379453a0b794e5f36b820f5f78531f
In osmo-pcu datatructures, the variables holding multislot classes
simply contain an integer referring to the multislot class number,
instead of coding from 3GPP TS 44.060 Table 11.2.5.3 and Table
11.2.5a.3.
So coding Multislot class 3 is stored as 0x03 in osmo-pcu variables,
while in 3GPP TS 44.060 coding it's coded as 0x02 (N-1).
This allows us using value 0x00 to designate a "yet unknown (EGPRS) Multislot
class".
Hence, we need to add 1 to the decoded value to match our data
structures.
Change-Id: Id3b121272bb7e84c0542ae9b4ce09598c6054edd
This function is actually returning an EGPRS multislot class, so let's
update naming. The variable using the return value was already being
passed as egprs_ms_class to tbf_alloc_ul_tbf().
Change-Id: Idb51836c8c9dd4e865bf2cb0b0c24155662f2ae8
Even if we don't accept it, let's submit GSMTAP with correct channel.
We don't return error like in code below, because otherwise the generic
UNKNOWN gsmtap message will be sent.
Change-Id: I853679ce8907d46fcb84ae4127335c10623f09c9
It's actually counter-productive when analyzing wireshark traces, since
one may not spot a decoding issue and assume PACCH is sent on the wrong
TS.
Change-Id: I7a96148f1ca1ebfa88a3ff714ea3bb8798866046
It was removed in wireshark.git e8407dd6c1378427daee77e8de540d0b5f7a0b73
and it's not there anymore in current master.
Change-Id: I73f4eeca3fd4f00a5bc4f06ef7a9bb9b8a70e37b
Port from wireshark.git 428ee66ae1c524b49f9043729b1f1e9b4f52f409, from
Pascal Quantin.
The original commit is also changing the RRC_Container field to
M_CALLBACK, but we leave them as M_VAR_ARRAY since the callback is
basically used to add more dissection information in wireshark.
Change-Id: I0f374e78300efddff00c4df26a401adcdee18a12
Port of patch (+ later fixes squashed) of wireshark.git commit
dea5452b95dfaf18e38670a8e2b3b38f9175fdfd, from Lei Chen:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6856
Squashed wireshark.git fix commits:
774be29de0b4d93d01aecb1518c41d7d551071a9
51c31cd7bd3d8fc196a9f90a8af466ad84e9e6a8
6aca10831f86c562970b13efa811f46e25ee3091
c1ceac58cdb77051e9bd14c1f6f7669cf5779a86
Change-Id: I08523bc1bbdffde479ef974b4c7b56cfa5639591
Original file from wireshark.git (packet-gsm_csn1.c) is being built and
maintained as a C file. There's no real need for us to maintain it as a
C++, and doing so will make both files derive over time (as already
happened). Let's keep it as a C compiler (which btw seems to be more
strict) to make it easier to port patches back and forth wireshark.git.
Take the chance to move some declarations we added to csn1.h to be able
to build it out of wireshark. Let's keep those in a separate header file
to ease looking for differences.
Change-Id: I818a8ae947f002d35142f9f5473454cfd80e1830
When switching to C compiler, it will warn/error. Use #if 0 as in the
original wireshark.git epan/dissectors/packet-gsm_rlcmac.c code.
Change-Id: If1be50947c02208f15892d99edeb394fb4f52b75
Header files included from libosmocore may potentially contain
some language constructions allowed in C but not in C++, such
as type casting. Let's add 'extern "C" { ... }' and be safe.
Change-Id: I7197f7b34f30b49d5397506ce9d67cbf0e2cc196
Including the <new> header is required as explained by the c++ specs [1]
osmo-pcu/src/tbf.cpp: In function ‘gprs_rlcmac_ul_tbf* tbf_alloc_ul_tbf(gprs_rlcmac_bts*, GprsMs*, int8_t, uint8_t, uint8_t, bool)’:
osmo-pcu/src/tbf.cpp:1002:39: error: no matching function for call to ‘operator new(sizetype, gprs_rlcmac_ul_tbf*&)’
1002 | new (tbf) gprs_rlcmac_ul_tbf(bts->bts);
| ^
Most of the times this issue is not detected because other STL headers
are already including <new>.
[1] http://www.cplusplus.com/reference/new/operator%20new/
Change-Id: Ie5fb536ae29dcf40e2a0dbe67432bebd61b8c7aa
This problem problem was discovered by the Undefined Behavior Sanitizer:
pdch.cpp:210:4: runtime error: load of misaligned address
0x60c00002abf2 for type 'uint32_t',
which requires 4 byte alignment
Do not convert TMSI to number, use osmo_mi_name() from libosmocore.
Also use this function to print other MI types (IMSI or IMEISV).
Change-Id: Icf8836f216793e342b239c8e6645aac1e82bf324
The TMSI/P-TMSI IE in BSSGP PAGING-PS/CS comes without the MI type
header, that must be present in RR Paging Request. Prepend it.
TTCN-3 test case: I7fbec5b2c5c3943a7413417b623f55c135c152d7
Change-Id: I97fd5ffc15a4a58112d7c37c69b7ac42b0741a0e
This patch corrects an error introduced in
6fd8ffb6fe
That commit allowed us to send the data over GSMTAP even
if the Uplink Control Block had invalid content,
that is to say, if decode_gsm_rlcmac_uplink() returned error.
However the check for ul_control_block->u.MESSAGE_TYPE
was place before decode_gsm_rlcmac_uplink()
Change-Id: Ic47602e5c6a13571b92c0a939fc3514110b82444
There's two variants for the Ms Radio Access Capabilities.
* The usual encoding with spare bits (usually to fill up to octet boundary)
as defined in TS 24.008 Table 10.5.146
And there's too:
* MS Radio Access Capabilities 2 IE from TS44.060 section 12.30, which is
the same but removing all spare bits, and which is used in messages like
Packet Resource Request and Additional MS RAC messages.
The later is used basically for messages having extra IEs after the MS
Radio Access capabilities IE, since they are encoded immediatelly
afterwards.
So this patch does:
* Adds the expected spare bits (M_PADDING) to MS_Radio_Access_capability_t
* Creates a new MS_Radio_Access_capability2_t without padding
* Updates code to use the new "2" version where needed.
Note RLCMACTest long de/encoding line logs change only because the name
of the struct changes (the "2" is added).
Change-Id: Ibd756f80a03452a651e2771dbc628d701e55ac4b
It seems the assumptions regarding maximum number of RA capabilitites
in one message were wrong. Doing some rough calculations, each RA
capabilitiy value (without extensions) can take around 20ish bits, which
means for a message containing up to 52 bytes that quite a lot of
different values could be theoretically fed in. Let's be safe and
increase the array size to be able to handle all different access
technologies listed in See TS 24.008 table 10.5.146 following
restrictions:
* "The MS Radio Access capability is a type 4 information element, with a maximum length of 52 octets."
* "Among the three Access Type Technologies GSM 900-P, GSM 900-E and GSM 900-R only one shall be present."
* "the mobile station should provide the relevant radio access
capability for either GSM 1800 band OR GSM 1900 band, not both".
Wireshark requires similar fix (it's not important though because it
currently uses another ad-hoc decoder for RAcap).
Related: OS#4463
Change-Id: I5334eaacfbc238fae8bea50c9e9667c2117f81ff
This way if CSN1 encoded bitstream contains more elements than what the
defintion expects it will fail instead of overflowing the decoded
buffer.
RA cap struct placed in unit test is taken from a real android phone
sending the value when attaching to the network. Then SGSN sends it back
and osmo-pcu would crash similar to unit test:
*** stack smashing detected ***: terminated
Process terminating with default action of signal 6 (SIGABRT): dumping core
at 0x4C62CE5: raise (in /usr/lib/libc-2.31.so)
by 0x4C4C856: abort (in /usr/lib/libc-2.31.so)
by 0x4CA62AF: __libc_message (in /usr/lib/libc-2.31.so)
by 0x4D36069: __fortify_fail (in /usr/lib/libc-2.31.so)
by 0x4D36033: __stack_chk_fail (in /usr/lib/libc-2.31.so)
by 0x124706: testRAcap2(void*) (RLCMACTest.cpp:468)
Related: OS#4463
Change-Id: I9fe0e55e0a6a41ae2cc885fba490c1d4a186231e
This way the macros can be used to access the arrays themselves and
calculate its static size to enable validation later.
In the case of Packet_Access_Reject_t, modify the description to use a
M_REC_TARRAY_1 object to get rid of access to 2nd element. The new
description is the correct one, since the first element is mandatory
according to TS 44.060 Table 11.2.1.
Change-Id: I6f10350d4734360c7a15a702c72b59efd84987ee
low-level text decodes of CSN.1 messages certainly are not NOTICEable
events, but rather something used for debugging.
Right now we get various text CSN.1 log output of osmo-pcu in it's
default configuration. Despite all log levels being relatively high
(NOTICE), we still see those messages as they simply are logged
at the wrong level.
Related: OS#2577
Change-Id: I7b42c9e21ad8d8a5b54e7a3b68490934ce3d3198
This commit is basically a revert of
f4bb42459c, which disabled the code. That
commit claimed the SGSN may have providen inacurate or wrong data at the
time, but then it should be fixed in the SGSN.
Related: OS#1525, OS#3499
Change-Id: Ie36ae23203110018d4b5ae47591e0a64989e23a0
We should really be using monotonic clock in all places that
gettimeofday is used right now. Since clock_gettime() uses timespec,
let's move all code to use timespecs instead to avoid having to convert
in several places between timespec and timeval.
Actually use osmo_clock_gettime() shim everywhere to be able to control
the time everywhere from unit tests.
Change-Id: Ie265d70f8ffa7dbf7efbef6030505d9fcb5dc338
Both csnStreamDecoder() and csnStreamEncoder() shall not return 0
prematurely if no more bits left in the input / output bit-vector.
Returning CSN_ERROR_NEED_MORE_BITS_TO_UNPACK might make more sense,
however we don't know in advance (i.e. without entering the loop)
whether it's an error or not. Some CSN.1 definitions have names
like 'M_*_OR_NULL', what basically means that they're optional
and can be ignored or omitted.
Most of the case statements do check whether the number of remaining
bits is enough to unpack / pack a value, so let's leave it up to
the current CSN_* handler (pointed by pDescr) if no bits left.
Return CSN_ERROR_NEED_MORE_BITS_TO_UNPACK only if the number of
remaining bits is negative as this is an error in any case.
Change-Id: Ie3a15e210624599e39b1e70c8d34efc10c552f6c
Port from wireshark.git de028e81c53f9c45ccc5adb3bffd2f16ae2017bf
This commit breaks transcoding of the test vectors containing
the MS RA Capability IE due to the reasons explained in [1].
The more fields we add, the longer gets the output of the CSN.1
encoder. This is not critical, since we never need to encode
messages containing the MS RA Capability IE on practice.
[1] Ibb4cbd3f5865415fd547e95fc24ff31df1aed4c0
Ported-by: Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: Ibb4cbd3f5865415fd547e95fc24ff31df1aed4c0
This change fixes a bug that was reported by Keith Whyte and
confirmed in [1]. The problem is that a user-defined handler
in case of CSN_SERIALIZE may parse only a part of the given
bit-stream, leaving some bits unhandled. This is expected
because the sender (i.e. the MS) may use more recent RLC/MAC
message definitions containing new fields at the end.
Those bits that were left unhandled by serialize() shall not be
interpreted as continuation of the message, they shall be skipped.
Note that the encoded vector in the RLCMAC unit test still does
not match the original one. That's a known bug explained in [2].
[1] If5873355d52d7ddb06c2716154a88d34100f6ab5
[2] Ic46d6e56768f516203d27d8e7a5adb77afdf32b7
Change-Id: Id4cc042fed68fc54aca0355dcb986cab3f6b49ea
Related: OS#4338
Move the call to send_gsmtap() before the call to decode_gsm_rlcmac_uplink() as if
the latter returns error we return and never get to see the packet on the GSMTAP.
Change-Id: Ia6af9f40590f28fcae3fef50d9c601d8435412cd
The main idea of this change is to demonstrate a weakness of the
CSN.1 codec that most likely causes a unit test breakage in [1].
The problem seems to be that the transitional structures, where
the CSN.1 decoder stores the results, do not contain any details
about presence of the optional fields (such as M_UINT_OR_NULL).
In other words, it's impossible to know whether some optional
field is omitted in the encoded message (NULL), or is it just
set to 0. This means that the encoder will always include all
optional fields, even if they're not present in the original
message.
[1] Ibb4cbd3f5865415fd547e95fc24ff31df1aed4c0
Change-Id: Ic46d6e56768f516203d27d8e7a5adb77afdf32b7
As seen in OS#4420, setting the MetaInfo.recv_time outside of
llc_queue before calling llc_queue::enqueue() and later on using that
value in llc_queue itself at dequeue time is not a good idea, since it
can provoke errors if the recv_time was not set correctly.
For instance, LlcTest was not setting the value for recv_time on some
test, which ended up with a huge millisec value when substracting now()
from it:
"""
llc.cpp:215:29: runtime error: signed integer overflow: 1582738663 * 1000 cannot be represented in type 'long int'
"""
This issue only appeared when started building on a raspberrypi4.
Let's better set/store the MetaInfo.recv_time internally during
llc_queue::enqueue(). Then, enqueue() only needs the
MetaInfo.expire_time, so let's change its arg list to only receive that
to avoid confusions.
Take the chance to move the llc_queue APIs to use osmo_gettimeofday,
since we need to fake the time now that the API itself sets that time.
Also take the chance during this refactor to disallow passing null
pointer by default since no user needs that.
Finally, update the LlcTest accordingly with all API/behavior changes.
Related: OS#4420
Change-Id: Ief6b1464dc779ff22adc2b02da7a006cd772ebce
Found while doing differential analysis (comparison against the
original implementation from Wireshark).
Change-Id: Ibd0b7400d78f7873c2a8d45267332f511b5c6fbb
Found while doing differential analysis (comparison against the
original implementation from Wireshark).
Change-Id: I9f7fa9c3f2f4ff5213dded930cee7ec509b9d799
Found while doing differential analysis (comparison against the
original implementation from Wireshark).
Change-Id: Id2a4f03035cd8354d3fba0ad37571453d3986d21
The implementation of CSN.1 codec was taken from Wireshark, where
it's implemented in pure C. For some reason it was mixed with C++
specific features, mostly using references in parameter
declaration. Not sure what are the benefits.
Change-Id: I56d8b7fbd2f9f4e0bdd6b09d0366fe7eb7aa327a
This would allow us to catch more bugs. Note that I had to remove
printing of pointer address to make the output deterministic.
Change-Id: I1a77441eb957353c919bc73f8e3a2e38f4a383a9
As was discovered recently (see OS#4388), bitvec_read_field()
would never return a negative value because its return type
is unsigned (uint64_t).
We don't really need to get more than one bit, so let's just
use the bitvec_get_bit_pos() instead.
Change-Id: I763a295cd955cd33f542292c85d97ff82f6b49bc
Related: OS#4388
After the recent changes [1], it was noticed that one of the unit
tests fails. In particular, a decode-encode cycle of Packet
Polling Request produces a different vector:
vector1 = 49 13 e0 08 50 88 40 13 a8 04 8b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
vector2 = 49 13 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
vector1 == vector2 : FALSE
As it turns out, the original (input) vector itself is malformed
because it contails no valid identity, and thus violates the
specs. The CSN.1 decoder from Pycrate [2] throws an exception
while trying to decode it. I believe we should do the same.
Let's stop decoding the bit stream and return an error in case
if neither of a given list of the choice items matched.
[1] Ia0f8cc224a4c38e80699f834fd83d4c0d99322ea
[2] https://github.com/P1sec/pycrate
Change-Id: I420144773ed5e80372534e0f18db5e74cdb2999d
Fixes: OS#4392
The problem is that bitvec_free() is not NULL-safe. Ideally we
need to fix it in libosmocore [1], but let's also fix it here,
so OsmoPCU can be safely used with older libosmocore versions.
[1] https://gerrit.osmocom.org/c/libosmocore/+/17114
Change-Id: I7647d17b3d03f8e193ef6e793a2d3c1967744eef
Fixes: CID#208181, CID#208179
Output was incorrect before this patch. LOPC was being called without
having any initial LOGP, and trailing newline was usually missing at the
end.
Since csnDecoder/encoder functions are recursive, it's difficult to
handle logging state in a coherent way inside them. Let's better simply
control start/end of logging related topics in the callers of those
functions, and simply use LOGPC everywhere in csn1.cpp.
Change-Id: I50da7560939fac360b7545e2a6bfaf45ed0c4832
It was noticed that OsmoPCU leaks memory when trying to reconnect
to the BTS. It could be easily fixed, but we don't really need to
allocate the PCU socket state on heap as we never have more than
one connection.
Change-Id: Iea8930f443caa16f522f7c5375e0004e4e2315cb
Since I2b32b4fe20732728db6e9cdac7e484d96ab86dc5, go_parent_cb()
is completely optional. It no longer has the task to determine
the correct parent node. The is_config_node() callback is no
longer needed too. Get rid of them.
Since Ic5e69a396df659933fd4d50298b9925e837a6861 we depend on 1.3.0.
Change-Id: Id7ce8c4e1ac43747ad40a06d01433c366da07b42
As was discovered by pespin, changing logging level of DCSN1 makes
the CSN.1 decoder behave differently (see OS#4375). In particular,
this makes RLCMACTest (encode / decode test) fail.
I did a quick investigation and noticed that some of the logging
statements call bitvec_read_field(). By definition this function
moves the internal pointer (current bit position) of a given
vector and increments readIndex by a given amount of bits.
The problem is that LOGPC would not evaluate its format string if
the logging message is not going to be printed, e.g. if a given
logging level is lower than the current one, or in case if
logging is not enabled at all.
The first two conditional calls to bitvec_read_field() are related
to CSN_PADDING_BITS, so that's not critical because padding is
always in the end of messages. The later two are related to
CSN_RECURSIVE_ARRAY and CSN_RECURSIVE_TARRAY respectively.
Let's use bitvec_get_uint() instead to keep readIndex unchanged.
Change-Id: Ia331048db9f790ca407fd341ced01df12d10a233
Fixes: OS#4375
Same API is kept to more easily keep code compatibility with wireshark's
packet-csn1.c implementation.
Change-Id: I1ce2c52e2357841aa1f31babfdce9011435f866b
The 'gprs_llc' is defined as a pure C structure with C++ specific
extensions (methods), so it's rather a class. Accessing its field
'frame' statically causes Clang to throw a compilation error:
gprs_bssgp_pcu.cpp:111:29: error: invalid use of non-static data member 'frame'
if (len > sizeof(gprs_llc::frame))
Let's avoid this and use LLC_MAX_LEN as the size limitation.
God knows what to expect from such a mix of C++ and C...
Change-Id: I7f84bd776cc780a45880f136107f6e0bc56241d1
This is rather a cosmetic change aimed to make ASAN / Coverity happy.
In general, we never pass any input from an untrusted source.
Change-Id: I26d654da4c3bf5fd86a298c3027fd9820c932308
It does not make sense since INT_MAX is always less than LONG_MAX.
Found by Clang [-Wtautological-constant-out-of-range-compare].
Change-Id: I9934e05aa050bf93b3c795376f5dca3a848a7e11
(as they are part of the RlcMacUplink_t structure that is also used to call csnStreamDissector function).
Port from wireshark.git commit 9f8b638cfa8a660fb64c54dcadb83e6747db0a15.
Ported-by: Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: If46f8cc3f21f527f911dcac6ff1b78f182104a00
Port of wireshark.git 8626bb4cbb4d9926f7b56663585d9ef66252f93f.
We don't really need the other fields added there, let's keep only the
value out of the union.
Change-Id: Ia8889252ee7518a919a15d749815c2803b4b23cd
Port of wireshark.git commit 6aca10831f86c562970b13efa811f46e25ee3091.
From Mike Morrin:
Fix pedantic compiler warnings in csn.1 dissectors.
There is some tricky casting going on in csn.1 structures. To eliminate all
the warnings, the function pointers needed to be moved out of the object
pointer unions. Fortunately macros (mostly) hide these changes from the
protocol dissector tables.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7686
svn path=/trunk/; revision=44899
Change-Id: Ia1a8c50c4b024ca6df4e3fbbf891cd33591ccc9b
This is a port of wireshark.git commit
2f024256bf337400ef3a82fa75e6d48d5707e059.
From 78516187d821b8d19d16987b1d6bc855ee7cbe10 Mon Sep 17 00:00:00 2001
From: Sylvain Munaut <tnt@246tNt.com>
Date: Sat, 4 Feb 2012 10:00:22 +0100
Subject: [PATCH 4/6] packet-csn1: Allow CHOICE elements to re-process the bits used for the choice
We may want to display more detail, or the sub-element should be
displayed with its headers or whatever ...
Change-Id: I3a5a95d5f918b8f17a2400a6d0c4d855ecacea7e
Port of wireshark.git 2f024256bf337400ef3a82fa75e6d48d5707e059.
From c6ee558d3bb00bfd25cca7c534448bf60df3c7cf Mon Sep 17 00:00:00 2001
From: Sylvain Munaut <tnt@246tNt.com>
Date: Sat, 4 Feb 2012 10:24:01 +0100
Subject: [PATCH 6/6] packet-csn: Extend CSN_SERIALIZE to allow 0 bit of length
In some coding there is no 'length' field at the top of a serialized
block, or it's more complex than a single field, in which case we
have to rely on the serialize decoder to consume the correct number
of bits.
We extend the CSN_SERIALIZE processing so that if a '0 bit' length
field is specified, then the length is not displayed and the
consumed bits by the serialize function is taken as the length
at posteriori.
The processing keeps the same behavior for any length > 0.
Change-Id: I9fadc99218594447001f7bb9943f4514b9877799
So that they always occur next to an increment of bit_offset.
Port from wireshark.git 1c81971d4292438ffdf83e9f9b9ab96c133c785b.
Ported-by: Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: I7474e9d632e068d6e33b0a502b81d4fff1f48802
Port from iwireshark.git commit cc6d4341e65ef2e8d8488fe0ac0f236ece0dd844.
It looks like it makes no difference to us now, but other EGPRS messages
may use it in the future.
Ported-by: Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: I34039370c292e62790a38abb59f55c69fffa88e8
Currently code using that function in osmo-pcu is disabled, allegadly
because SGSN was sending incorrect values, but it looks more like a CSN1
issue.
Related: OS#1525, OS#3499
Change-Id: I92c86397f988afaa791871d823a45fa85054f3bb
P-TMSI is optional IE, but IE is mandatory and hence always available.
Since the encoding is actually a Mobile Identity, the IMSI is used in
case P-TMSI is not available.
Change-Id: I4dbf8db04e81f98352a42ce34a5d91326be9bfd1
It's not really needed to have those together in some function calls,
and makes it more difficult to follow the code. Furthermore, new callers
not having content already aligned (len+value) will be using these
functions in forthcoming commits.
Change-Id: Ifb9d3997bfb74b35366c3d1bc51ce458f19abf16
Others projects don't contain a dash in there, and it seems to cause
problems with TTCN3 VTY expectations.
Change-Id: I3430abb5fc622dec293457466e760de95fa3a05c
Some are used to control (M)CS values for downlink while some do it for
uplink. Let's make clear which one is used for what. Take the chance to
document the fields a bit better than they were.
Some more information about the origin of cs_downgrade_threshold can be
found in the commit introducing it: 70b96aa232.
Related: OS#4286
Change-Id: I4e890e924b094a1937fbd3794de96704cf0421a8
So far there was a memory leak, because free()ing 'the_pcu.bctx'
would cause ASAN to complain. And that's reasonable, because it
needs to be freed properly. Moreover, 'the_pcu.bctx' may simply
be uninitialized in some cases, e.g. when OsmoPCU is terminated
before connecting to the SGSN.
Let's use the new bssgp_bvc_ctx_free() from libosmogb.
Change-Id: I274e79e1746c7678b81720ec11e8a564befe38ba
Depends: Ia78979379dbdccd6e4628c16f00d0c06d9212172
Both BSSGP SUSPEND ACK and NACK messages use BVCI=0 (signaling),
which always exists. Claiming that BVCI=0 is unknown is wrong.
Instead of adding both BSSGP_PDUT_SUSPEND_{ACK,NACK} to the 'if'
statement, let's rather avoid rejection for all BVCI=0 messages,
as there may be other unlisted message types.
Change-Id: I780657c1e8f67e0bef0e92a31db7ba61b57d7ec4
Related: OS#4111
Recent commit added an assertion to check for buffer boundaries and it
actually gets hit.
One of the 2 code paths calling pcu_l1if_tx_pch() was passing a buffer
of 23 bytes while one of maximum 22 is expected (because plen is not set
in the buffer but set inside pcu_l1if_tx_pch()).
So it seems before the assert, that code path was actually writing 1
byte outside the boundaries of data buffer, since bitvec_pack() uses
data_len field of bitvec.
Related: OS#4228
Fixes: 8dc09e73d0
Change-Id: I84c5dfd4d5580e9d4c00ed21887cb51bd9abbd2e
For a long time the VTY command to show all active TBFs was broken.
The TBF filtering (by allocation origin) logic allows one to show
TBFs allocated on CCCH, PACCH, or on both of them. In the latter
case we have been checking whether a TBF was allocated on both
logical channels at the same time.
Let's fix this by passing a flag-mask instead of boolean arguments.
To be able to use GPRS_RLCMAC_FLAG_* definitions from "tbf.h", let's
exclude them from "#ifdef __cplusplus ... #endif" block.
Change-Id: I1c9f401368af880a97d32905c4cce0da481ffc21
paging group is 3 bytes and imm assign with plen prepended is 23 bytes,
so there's 1 extra byte not needed and makes code confusing.
Change-Id: Id7835e5aa1506505ff54e019b38f30111f79b5dc
Otherwise, a new meas object is allocated in the stack in upper layers
which doesn't contain the link_qual information (have_link_qual=0),
outputting following error:
osmo-pcu/src/gprs_ms.cpp:644 Unable to update UL (M)CS CS-2 because we don't have link quality measurements.
Change-Id: I1980ca325c8d65f3f6310fa697dd810eec7ab077
Move code in rcv_block_gprs() only needed for rcv_control_block() into
the later. This way rcv_block_gprs() is simplified and shows similar
code paths with regards to rcv_data_block().
It can now be seen that the main difference between both is the meas
param no being passed in the control case.
Change-Id: I2a0133463edced93c72ccc743a0cf00d1d6922cf
This commit would also remove the option from config_write_pcu() since
it's automatically filled in by osmo_tdef, but there was actually a bug
because that param was never printed when saving the config...
Change-Id: Id8e70b0f44ef2f7e20ecdb3fd8ca93ae2a05b9a3
Receive an Application Information Request from the BTS via PCU
interface. Construct a Packet Application Information message from it
(3GPP TS 44.060 11.2.47) and send it to all MS with active TBF.
The TTCN-3 test infrastructure to test this feature is not quite ready
yet, so I've added C unit tests instead.
Related: OS#4048
Change-Id: Ie35959f833f46bde5f2126314b6f96763f863b36
This will allow for configuration of some of the timers by the user,
and allow him to inspect current values being used.
It will be also useful for TTCN3 tests which may want to test some of
the timers without having to wait for lots of time.
Timers are splitted into 2 groups: BTS controlled ones and PCU controlled
ones. The BTS controlled ones are read-only by the user (hence no
"timer" VTY command is provided to change them).
TbfTest.err output changes due to timers being set up correctly as a
consequence of changes. Other application such as pcu_emu.cpp and
pcu_main.cpp had to previosuly set the initial values by hand (and did
so), but apparently TbfTest.c was missing that part, which is now fixed
for free.
Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c
Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
Since [1], OsmoPCU already starts to retransmit downlink blocks before
the MS has had a chance to receive them and/or send the related
acknowledgement in uplink. Make this optional with the new VTY option
"no dl-tbf-preemptive-retransmission".
[1] e25b5b91f6 ("tbf: Only create dummy frames if necessary")
Related: OS#2408
Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
Those namings my collide with usual osmocom "T" variable name associated
to a timer number, which will be added in following patches.
Change-Id: Ic2b5068a4882e4a043bf81496be30a378fdb9a09
The following message is printed by the pcu_tx_txt_ind():
DL1IF INFO pcu_l1_if.cpp:113 Sending XXX TXT as PCU_VERSION to BTS
There is no need to print it twice:
DL1IF INFO osmobts_sock.cpp:74 Sending version XXX to BTS.
DL1IF INFO pcu_l1_if.cpp:113 Sending XXX TXT as PCU_VERSION to BTS
Change-Id: Ic2793f20cf9df2fa08c45070a8f81ef1c08b925a
We don't really need to use the message buffer (on heap), because
it's never getting passed to pcu_rx(). Let's use a buffer on stack.
Change-Id: I4cb8ca80513df7b71e1438da2e82799be6be1fa0
Vadim Yanitskiy
Pau Espin
Philipp Maier
Vadim Yanitskiy
Keith Whyte
Harald Welte
Oliver Smith