AC_SEARCH_LIBS was finding the function correctly, but later on
AC_CHECK_FUNCS was not including the found LIBRARY_RT so the function
was not found, and hence HAVE_CLOCK_GETTIME ended up undefined (which in
turns disables support for osmo_clock_gettime() API).
This happened in systems like the soekris where the clock_gettime sybmol
is available in external lib -lrt.
Let's avoid double-checking for the function twice, and simply define
HAVE_CLOCK_GETTIME when AC_SEARCH_LIBS succeeds (the success action is
guaranteed to be called even if there's no extra lib required).
Change-Id: Iced1e0542cee6beb9f08f5299aad49fab142cfb4
Each struct already contains different definition based on endianess, so
there's no reason to re-define all of them again based on endianess.
Probably at some point somebody run the script
./contrib/struct_endianess.py on those structures but forgot to remove
the old way of supporting differnet endianess.
Change-Id: Ibd002e52979950e09013767fa643b2a3c52dfea9
/usr/bin/ld: .libs/gsm0503_coding.o:/home/laforge/projects/git/libosmocore/src/coding/../../include/osmocom/coding/gsm0503_parity.h:16: multiple definition of `gsm0503_mcs_crc12'; .libs/gsm0503_parity.o:/home/laforge/projects/git/libosmocore/src/coding/../../include/osmocom/coding/gsm0503_parity.h:16: first defined here
Change-Id: I15945bbf59c873e50154c40fed0ba3d6b4d7c399
This is implicitly used by the libosmocore select abstraction, which
might be used in multiple threads at the same time.
Change-Id: I5a3802c94af6ff0315f1553f20870342d51ce726
The signalfd(2) mechanism of Linux allows signals to be delivered
and processed via normal file descriptor I/O. This avoids any of the
usual problems about re-entrancy of signal processing, as signals can
be processed from the osmocom select() loop abstraction just like any
other event.
Change-Id: If8d89dd1f6989e1cd9b9367fad954d65f91ada30
For a process running as root, it may be desirable to drop privileges
down to a normal user before executing an external command. Let's
add a new API function for that.
Change-Id: If1431f930f72a8d6c1d102426874a11b7a2debd9
When switching the l2 structures passes to test_pdtch() to be constant,
it was noted that output of the test changes. This happens because same
array is tested several times with different length, incrementing each
time. Since the test was modifying the input array directly, it means
each new run of test_pdtch() the array was further modified.
Upon constifying the structures, we copy the array and hence only modify
the required bits each time.
Change-Id: Iffd0ca3669eb8d0d2e80d754fc8acbf72f1bebe8
gsm0503_coding contains AMR decoder functions for HR and FR. Those can
only decode AMR payload frames but not amr DTX frames. Lets add
functionality to detect DTX frames. Also lets add decoding for SID_UPDATE
frames as well as error checking for the SID frame recognition patterns.
Related: OS#2978
Change-Id: I2bbdb39ea20461ca08b2e6f1a33532cb55cd5195
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I8ebd9c6d4efda41c7c8196f963d1f04d65160754
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
Pau Espin
Harald Welte
Eric Wild
Philipp Maier
Vadim Yanitskiy