osmo-gsm-tester raised an ASan warning in osmo-bts-trx during execution
of a test with EGPRS enabled and a modem connecting to it (see OS#4483
for full trace):
==12388==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fa20b9ab8d0 at pc 0x7fa20b982894 bp 0x7ffdfea8b9c0 sp 0x7ffdfea8b9b8
READ of size 1 at 0x7fa20b9ab8d0 thread T0
#0 0x7fa20b982893 in gsm0503_mcs1_dl_interleave /home/osmocom-build/jenkins/workspace/osmo-gsm-tester_build-osmo-bts/libosmocore/src/coding/gsm0503_interleaving.c:165
Function gsm0503_mcs1_dl_interleave() was being passed the 6-bit USF
encoding while clrearly expecting a 12 element array. TS 05.03 5.1.5.1.2
"USF precoding" also clearly states that 12bit encoding is to be used
for MCS1-4.
Fixes: OS#4483
Change-Id: I94db14de770070b17894a9071aa14391d26e776c
According to 3GPP TS 44.004, figure 7.4a.b, the format of 11-bit
RACH uplink / Uplink access burst block is as defined follows:
<---------------------------------------------------
8 7 6 5 4 3 2 1
+--------------------------------------------------+
| 11 bit RACH uplink / Uplink access burst block | OCT1
+--------------------------------------------------+
| | OCT2
+-------------------+
As was (correctly) assumed in [1], the bit ordering in 11-bit RACH
coding functions is wrong. The problem is that neither of generic
functions from bit16gen.h can be used to load / store the RA11
value (regardless of the endianness), because they assume that
the payload is 16 bit long.
With this patch applied, RA11 values from [1] look correct:
< EGPRS Packet channel request message content > ::=
< Signalling : 110011 < RandomBits : 00111 > > |
< Signalling : 110011 < RandomBits : 00110 > > |
< Signalling : 110011 < RandomBits : 01111 > > |
< Signalling : 110011 < RandomBits : 01100 > > |
< Signalling : 110011 < RandomBits : 00111 > > |
< Signalling : 110011 < RandomBits : 10110 > > ;
[1] Id80e471d252b9416217b56f4c8c0a8f5f1289fee
Change-Id: I43d30611dd69f77f2b3b46f4b56056a8891d3c24
Related: OS#1548
This change adds several soft-bit (-127 .. 127) sequences containing
EGPRS Packet Channel Request message (11-bit, payload only) sent by
an EGPRS capable phone, and captured on the BTS/PCU side using a
tool from the TRX Toolkit - trx_sniff.py.
As can be seen from the test output, none of decoded RA11 values
looks like a valid EGPRS Packet Channel Request message (see
table 11.2.5a.2 of 3GPP TS 44.060). All test sequences contain
the same message with several random bits:
< EGPRS Packet channel request message content > ::=
< Signalling : 110011 < RandomBits : bit (5) > >;
since the phone was trying to perform Attach Request. It seems
the bit order of decoded messages is somehow wrong.
Change-Id: Id80e471d252b9416217b56f4c8c0a8f5f1289fee
Related: OS#1548
We don't really need additional 1.4M of debug output, given that
we test every possible 8-bit and 11-bit RA value. It's enough
to print error message if the resulting value does not match.
Otherwise it's hard to read the expected output without commenting
the related log statements out. Note that it's still possible to
re-enable verbose debug output by defining DEBUG.
Change-Id: I0d5ed90cb0a2b3007d665520a73b0fa0b86a4099
an USIM application can very well exist on a UICC without supporting
classic DF.GSM access. However, most commonly, both are found on
cards.
Change-Id: I6180a3f81a7d3006e8ece4302c2433db2588bfaa
Before this change, a card application (USIM, ISIM, ...) didn't
exist as a separate concept from a card profile. This meant,
we had a manual combination of UICC card profile with USIM application,
and another one of UICC card profile and ISIM application. But what
if there's a combined USIM+ISIM?
In reality, applications exist as separate objects, on top of an
ETSI UICC. Lets therefore register all known applications to the
osim library core, and add code to osmo-sim-test which dynamically
detects all applications present on a given card (by reading EF.DIR).
Change-Id: Ic4b4ac433a9976842b30a017fb0fc347d87201cd
Using the new '--output-dir' command line argument, the user can
instruct osmo-sim-test to dump the file content to a local directory.
osmo-sim-test will create one sub-directory per DF, and create a
text file for each EF. The contents of the text files are a hexdump
of the contents. Transparent EF are dumped as one line of hex,
while linear fixed EF are dumped as one record per line, i.e. the
number of lines corresponds to the number of records.
Change-Id: I35176f4a13c3537eaa8de550e231818a22b4c07c
The 3GPP spec document also contains this error at one point, and
it seems I copied it from there :/
Change-Id: I7ad9f491c06f6540747b77017678ee37e6a1550d
This small fix enables cross compilation using dpkg-buildpackage on multiarch:
https://wiki.debian.org/CrossCompiling#Building_with_dpkg-buildpackage
`apt build-dep -a<arch>` incorrectly installed non-native python for building
Change-Id: I85994447657cda757348855c3ee9978e8c7c2377
libosmosim contains a variety of definitions and utility fuinctions
useful when working with SIM card [protocol]. They can not only
be used with PC/SC readers but also in other contexts.
Change-Id: I741940d3dc2a5653c760e9d1597d7f08afb3b631
The table amr_len_by_ft represents the length of the raw AMR speech bits
in bytes. The table is based on the Table found in RFC 4867 §3.6, Table 1,
Column "Total speech bits". The number of bits is divided by 8 and then
rounded up to get the number of consumed octets.
An AMR SID frame (including STI and MI) takes up 39 bits, this will
result in 5 octets, not in 7. Lets correct this.
Related: OS#2978
Change-Id: Icf330450981b32be5d1cee5b10aa92bac4cb72f5
AMR SID update frames are protected using an 1/4 convolutional coder,
wich is similar to the one used with 6,7 kbit voice frames. Except that
there is no puncturing and the length is different.
Change-Id: Ia35ed4178a7f0d816052b7e5d6478b93a1d9744f
Related: OS#2978
AMR not only specifies a 6 bit CRC for regular voice information. It also
specifies a 14 bit CRC to protect the comfort noise updates contained in
the SID_UPDATE frames.
Change-Id: I5cfd8ca806aba8d42cb9787f69605cea7de6e900
Related: OS#2978
* What we used to call TCH/F and TCH/H in gsmtap are actually only
FACCH/F and FACCH/H, i.e. the signaling part of Bm/Lm channels
* Give them proper names with backwards compatibility #define
* Split VOICE into VOICE_F and VOICE_H. If we don't differentiate this,
a receiver is not able to determine the RSL channel ID of a frame
without looking at external state/context. That in turn has been a
design feature of GSMTAP Um format so far, and programs like
osmo-bts-virtual rely on it.
Change-Id: I952044a17334f35712e087dc41781805000aebc1
Related: OS#2557
In Change-Id If223020933b083fe359a2e8ff5fab1ce64a363d8 we introduced
GSMTAP_CHANNEL_VOICE, but we didn't add it to gsmtap_gsm_channel_names[]
Change-Id: I7ab696d3e0edb13632e048a9e05be03612d3d28c
Related: OS#2557
We so far are only able to transmit signalling data inside GSMTAP,
but not actual voice / user plane payload data.
we cannot use the existing TCHF/TCHH sub-types, as those are already
used [without further discrimination] for FACCH + SACCH Data on those
channels.
Instead, we will introduce a new GSMTAP_CHANNEL_VOICE sub-type, which
then will have the first byte for a sub-sub-type specifying the payload
format in detail.
Change-Id: If223020933b083fe359a2e8ff5fab1ce64a363d8
Related: OS#2557
The variable struct tlv_parsed tp in dump_file() conditionally
initalized by tlv_parse() but later it is accessed under a different
condition without a check that makes sure that tp is only accessed when
tlv_parse() was called beforehand. Lets introduce a check that makes
sure tp can not be accessed when it is uninitalized.
Change-Id: I6b0209b966127a4195e6f4bcb43d49387c7646ce
Fixes: CID#208435
This adds missing entries for CBCH in the conversion between RSL-style
channel numbers and GSMTAP channel types.
Without this change, you will see tons of messages like
virtphy[19865]: Wed Feb 26 16:16:28 2020 DVIRPHY <0002> gsmtapl1_if.c:267 MS 0000: Ignoring unknown channel type UNKNOWN (0)
if running virtphy of osmocom-bb with a BTS that broadcasts CBCH.
Change-Id: I19bbd2942adf441f58955ac896ef968bfd8aec5f
This function is supposed to return 0 on success or 1 in case of
error. However, it used to return 1 even in case of success. The
reason is that length of the input string was not taken into
account and sscanf() was failing on '\0'.
Let's use osmo_hexparse() and rely on its return value.
P.S. Funny that the unit test expectations were wrong too.
Change-Id: I441a22c7964bb31688071d8bcf6a282d8c0187ff
The aim of this unit test is to demonstrate the problem described
in OS#4388: bitvec_read_field() can never return negative value
on error (e.g. out of bounds access).
Change-Id: I340ab5799fa53d5345edb02f3e2a3655527705c0
Related: OS#4388
If selection of ADF_USIM fails, let's fall-back to reading/dumping
a classic TS 11.11 (51.011) SIM card.
Change-Id: I5a986fc65de76c24c5af52ce7e8c699cf302fda9
Don't just iterate over all files in the current working
directory (cwd), but also recurse through all sub-directories.
Change-Id: I737b01d9a845e37d8be9d4709ef0de04e749daec
If (!env_whitelist && addl_env), osmo_environment_append() would
access uninitialized memory. If both are false, execle() would
also deal with garbage values. Let's ensure that at least the
first element of new_env[] is initialized.
Change-Id: Id3901de4692ef44e9e9c67b1804e027fc4ce7c18
Fixes: CID#206571
Most likely, we should not assert() here, but let's at least log
an error message in case if osmo_fd_register() fails.
Change-Id: Ia20755ec12ee9fb0eba8322551642a96e68e1570
Related: CID#206572
Some osmo-* applications may need to use their own VTY node as a
parent for the timer configuration commands. Therefore it makes
more sense to use 'unsigned int' instead of 'enum node_type'.
Let's also clarify that osmo_tdef_vty_groups_init() accepts parent
node for configuration commands only: 'parent_node' -> 'parent_cfg_node'.
Change-Id: Ifb4c406c85d76a25fc53fc235484599aa87dc77c
There's nothing really preventing a user from user negative values.
Otherwise if we keep it like this then g++ is not happy when passing eg.
{ -2, "foobar" } when initializing a value_string array.
Change-Id: I754fa7e054cb89801ef82edc82199dcfbe59c6ab
Pau Espin
Vadim Yanitskiy
Harald Welte
Philipp Maier
Eric Wild