LDADD var contains both local and system libraries. Use it at the right
place (after list of local libs, before list of system libs).
Change-Id: Ifb3686f78432ac877c596004646506c540b23c53
3GPP TS 44.021 specifies the format for modified V.110 frames as used
on the GSM air (radio) interface. Implement encoders and decoders for
this modified V.110 format.
Related: OS#1572
Change-Id: I60a2f2690459359437df20cf4da9043fa7c3ad11
V.110 defines a B-channel protocol for transmission of synchronous and
asynchronous serial data of V-series interfaces via terminal adapters
over ISDN.
Let's add (unoptimized but easy to debug) functions for encoding and
decoding of V.110 frames for various bit-rates.
Related: OS#1572
Change-Id: I1b5fd3847d3bfb0a0f763e0574893962ec699680
Use the same 32k0, 29k0, 14k4, … notation for GSM0808_DATA_RATE, as
it is already used in RSL_CMOD_CSD. As GSM0808_DATA_RATE enumes were
just added to libosmocore and aren't used yet, don't add backwards
compatible defines.
Related: OS#4393
Change-Id: Ia965cdd9f53af756e5ffaff9b8f389b5ad629969
Improve the test output to make it easier to confirm that the fix in an
upcoming patch (I900fda192742fa8f6dd54e9131ef1704b14cc41a) is indeed
correct.
Spell out each S0-S15 mode along with the bitmask.
Rejigger the format of printing the mr_cfg flags, so that the AMR modes
line up vertically with the S0-S15 modes.
This clearly shows that the mr_cfg <-> s15_s0 conversion is wrong.
For example, in this test only 4k75 is enabled, yet we allow configs
featuring 6 other rates:
Input:
cfg.smod=0 spare=0 icmi=0 nscb=0 ver=0
m4_75=1 ------- ------- ------- ------- ------- ------- -------
Result (fr):
S15-S0 = 0x5701 = 0b0101011100000001
S0 4.75
S8 4.75 5.90
S9 4.75 5.90 6.70
S10 4.75 5.90 6.70 7.40
S12 4.75 5.90 6.70 10.2
S14 4.75 5.90 7.95 12.2
Result (hr):
S15-S0 = 0x0701 = 0b0000011100000001
S0 4.75
S8 4.75 5.90
S9 4.75 5.90 6.70
S10 4.75 5.90 6.70 7.40
In this test, an s15_s0 featuring a configuration with 6k70 allowed does
not result in m6_70 == 1:
Input:
S15-S0 = 0x0c12 = 0b0000110000010010
S1 4.75 5.90 7.40 12.2
S4 7.40
S10 4.75 5.90 6.70 7.40
S11 4.75 5.90 6.70 7.40
Output:
cfg.smod=0 spare=0 icmi=1 nscb=0 ver=1
m4_75=1 ------- m5_90=1 ------- m7_40=1 ------- ------- m12_2=1
Almost every conversion contains errors like this.
Related: I900fda192742fa8f6dd54e9131ef1704b14cc41a
Change-Id: Iec7c491d9fadd37d9e43fbaac8e709c2029f8a8e
According to 3GPP TS 48.008 3.2.2.11, it is inverted.
0: Transparent service
1: Non-transparent service
Change-Id: I2e5786ad053ee871079b4a8d95caccd6b03b59b6
This patch adds the convolutional code definitions for CSD (circuit
switched data) on TCH/F channels with user bit rates of 2400, 4800, 9600
and 14400 bps.
Related: OS#4396, OS#1572
Change-Id: I412131d7ee2e676402bf8d88394af17c4447b664
Stop iterating if the extension bit (0x80) is set but elem is too short
to read another byte.
Related: OS#4393
Change-Id: Id37109dba0f5d40f4b83f0cef9b1dbd9d6bb2c68
There are some parts of libosmogsm which are not really GSM specific,
but rather ISDN bits that were inherited by GSM. This includes the
I.460 multiplex as well as the core LAPD protocol.
Let's move those bits to its own libosmoisdn library, before we add
more ISDN specific bits to the wrong place.
Backwards-compatibility is created by making libosmogsm depend on
libosmoisdn, and by providing wrapper include files for source
compatibility.
Change-Id: Ib1a6c762322fd5047be3188b1df22408ef06aa50
config.h is created in $(top_buildir)/config.h.
Let's make sure all CPPFLAGS add correct -Ipath includes,
and that all code includes the correct file.
Change-Id: Ie9ea38bb009bc715b01cde4d66d181f7bec2e7bd
This way we have all libosmocore.so in an own subdir instead of having
lots of files in the parent dir, which also contains subdirs to other
libraries.
This also matches the schema under include/osmocom/.
Change-Id: I6c76fafebdd5e961aed88bbecd2c16bc69d580e2
Implementation is imported from osmo-ggsn.git
97f60e3dca581797007524e0006ca9fafad59713 in46a_netmasklen() and adapter
to work with an osmo_sockaddr.
This will be used by osmocom-bb's "modem" app.
Change-Id: I75e75e251c6776801fffdde745aebedf21c68799
The function gsm_gsmtime2fn(), which is used to compute a frame number
value from given starting time values T1, T2 and T3 has no unit test.
Due to to the modulo that is used the computation can be a bit tricky.
Lets add a unit-test to make sure the function works as expected.
Change-Id: I8b9b71c8dcccf3b44326b5e61229f4637689d763
C/C++ only implements a so called "truncated modulo" function. Lets also
add a floored and an euclidian modulo function to be more complete.
The functions will be used to generalize the following Change:
I5fb2b0ada8d409730ac22963741fb4ab0026abdd
Change-Id: If61cd54f43643325c45f64531c57fe4c5802a9cf
The motivation behind adding and using the new API is explained in
the preceeding change [1]. Whenever any of the encoding functions
fails to encode either a Speech Codec or a Codec List IE, free()
the msgb and return NULL.
Change-Id: I28219b61b9347f0652f9fd0c717f6cdf3c63e8f9
Related: [1] I199ffa0ba4a64813238519178155dfc767aa3975
Related: SYS#6229
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: I84fd99442d0cc400fa562fa33623c142649230e2
Ranges can now be specified in hexadecimal notation. In this case, only
hexadecimal values are accepted (prefixed with "0x").
In order to allow using a hexadecimal value as an input argument, the
command must specify the range in hexadecimal form.
This way all existing commands (decimal) won't get an hexadecimal value
unless they are further extended in the future, avoiding hard to notice
breakage due to use of stroul() without using base=0 or even worse,
using atoi() directly (which only understands decimal and provides no
error checking mechanism).
A command argument can be expanded to accept both decimal and hex in a
range by means of specifying both, example:
"mycmd (<0-255>|<0x0-0xff>)".
Related: OS#5631
Change-Id: Ia2b7fbbf5502c28374c21dbff548232680da27d4
The errno values are platform dependent. Printing them in the expected
output causes failure on some systems that don't match my development
system.
Still check for match with the expected errno value, but don't print the
actual value in gsm0408_test.ok.
Related: OS#4842
Change-Id: I87d125fb4e04b2130f653db1ed76691528e43411
This reverts commit e145e28a91.
Reason for revert:
The function osmo_sockaddr_strs_to_str() should not be part of the
osmo_sockaddr_str API. The implementation of this should live in
the function multiaddr_snprintf() added in patch
Icef53fe4b6e51563d97a1bc48001d67679b3b6e9
and should not use dynamic allocation.
Change-Id: I263dfd68313b896c5b474025fbca13c22ce41cdc
The decoding pointer was not increased correctly, ending up in reading
by 1 byte offset for each item in the list.
Change-Id: I16ed9bd65109a7ce32ff43c5789b4544479838e7
Some initial testing for that module was writen to apparently do some
manual tests (rand()) but were never added to testsuite.at.
Let's make sure they run during make check (make the test deterministic
by removing rand()).
Change-Id: Icd4feced06afb749de994195c6b338df006749ad
Coverity complains that we do check if osmo_tdef_get_entry() returns
NULL 39 out of 40 times. Check it in test_tdef_set_and_get() too.
Change-Id: I96041eab2786d850a49cb38a60a368cef2e476d3
Related: CID#274729
As was demonstrated in [1], osmo_fsm_inst_state_chg_ms() is broken.
The problem is in state_chg(): this function is passing *milli*seconds
to osmo_timer_schedule(), while it expects *micro*seconds.
Change-Id: Ib0b6c3bdb56e4279df9e5ba7db16841645c452aa
Related: [1] I5a35730a8448292b075aefafed897353678250f9
Fixes: I35b330e460e80bb67376c77e997e464439ac5397
Fixes: OS#5622
This change adds test_state_chg_Ts() and test_state_chg_Tms() checking
state timeout s/ms accuracy when using osmo_fsm_inst_state_chg() and
osmo_fsm_inst_state_chg_ms() calls, respectively.
test_state_chg_Tms() demonstrates that osmo_fsm_inst_state_chg_ms()
is not working as expected: the timeout fires earlier than expected.
Change-Id: I5a35730a8448292b075aefafed897353678250f9
Related: OS#5622
The testcase in gsm0408_test is still failing because the encoder
produces a different result (with octet 3a present). There is no
way to tell the encoder to use the implicit coding, and in general
this is not that critical, so we can live with that.
Change-Id: I722c168f01bffa915cb155eac234a796549d3762
The new testcase contains a Bearer capability IE from Siemens S11E,
which does not use octet 3a (no extension bit set in octet 3).
gsm48_decode_bearer_cap() currently fails to parse it.
Change-Id: Ia19f3f6d80bc09ca3f8d39d35b148a0c0245141f
Currently, if one of the testcases fails, test_bearer_cap() would
abort and skip the remaining testcases. Also, a msgb would not
be free()ed making the LeakSanitizer unhappy.
Instead of returning early, jump to the end of loop to ensure that:
* the verdict ('passed' or 'failed') is always printed,
* all remaining testcases are still executed,
* the msgb is free()ed.
Change-Id: I39ac801e59ba56dfe3bcd4603b48f6fbf7cfb21c
osmo_bssap_le_dec() dereferences value of the given pointer and
checks it against NULL. The caller must always initialize it.
Change-Id: Id91dc73da1ca71827183564eb68b12c03ba332b3
Once the IuUP FSM moved away from Init state, it stopped handling
Initialization messages received from peers and simply ignored them
starting from that point. As a result, if the first IuUP Init ACK it
sent to the peer was lost, the peer would keep retrying with more IuUP
Init and getting no answer.
In any case, it seems possible and desirable that a peer may send an
IuUP Init at a later point, as pointed out vaguely in 3GPP TS 25.415.
sec 6.5.2.1:
"""
Upon reception of a frame indicating that an Initialisation procedure is
active in the peer Iu UP entity, the Iu UP protocol layer forwards the whole
protocol information contained in the INITIALISATION control frame to the
upper layers. It also stores the RAB sub-Flow Combination set (and thus
replaces a possible previous set) in order to control during the transfer of
user data, that the Iu UP payload is correctly formatted (e.g. RFCI matches
the expected Iu UP frame payload total length). The peer Iu UP entity
receiving the INITIALISATION control frame shall choose a version that it
supports among the proposed versions indicated by the sender for which it
has enough initialisation information.
"""
sec B.2.2 "Initialisation State":
"""
After sending a positive acknowledgement of the last INITIALISATION control
frame, the Iu UP instance enters SMpSDU data transfer ready state. Note that
CN does not know if the initialisation ACK was correctly received by the RNC
(and Initialisation procedure successfully completed) until it receives RAB
assignment response, or use data from the RNC. The CN must therefore be able
to continue receiving INITIALISATION control frames by re-entering the
Initialisation state (from Support Mode Data Transfer Ready State), if the CN
has started to send user data before receiving the indication that
Initialisation was successfully completed
"""
sec B.2.3 "Support Mode Data Transfer Ready State":
"""
In case of handover or relocation, Initialisation procedures may have to be
performed and Iu UP instance may have to enter the initialisation state.
"""
Related: SYS#5995
Change-Id: I5cb740702805693cc7f0a550e2e093f9bfdd507c
This test shows a bug in IuUP stack which makes it only handle the first
Initialization IuUP message. After it moves to SMpSDU, it stops handling
Initialization messages.
A fix is provided in a follow up patch.
Related: SYS#5995
Change-Id: I72c2c2d88f158f3ef35724fcb73854a1827aaab4
The new functions accept an additional mode_id poiner, which is
currently set for the following frames: AFS_ONSET, AHS_ONSET,
AHS_SID_FIRST_P2 with N * 16 - M bit pattern.
Also, the new API accepts soft-bits instead of hard-bits.
Converting bits from soft to hard is now performed internally.
Change-Id: Ibcac395f800bb64150c97fcdaca3523ecfc5fcee
Related: OS#5570
The initially merged IuUP API and implementation assumed that RFCI with
ID was always in the position of its ID inside the list of RFCIs. This
was the case for messages sent by ip.access nano3g as well as our own
osmocom implementation. However it was noticed that other nodes from
other vendors actually use other order, as allowed by the IuUP message
format.
Hence, we need to break the assumption and provide explicit ID
information in the list.
NOTICE: This commit breaks API and ABI compatibility with older versions
of libosmogsm, but not with any previous release of libosmocore since
the API is only available in master so far (it was added in
9fe1f9fb0b).
Similary, it's only user (osmo-mgw) only uses the API in master, so
there's no API breakage with older releases.
Related: SYS#5969
Change-Id: Ib21cee2e30bf83dff4e167f79541796007af9845
As was demonstrated in [1], there is a TCH/AHS specific problem in
libosmocoding causing unexpected BER ~50% in decoded AHS_SID_UPDATE
frames. The reason is that A[H]S_SID_UPDATE employs quite tricky
interleaving algorithm, which is different from the algorithm used
by normal TCH/AHS speech frames or A[F]S_SID_UPDATE frames.
An AHS_SID_UPDATE frame consists of two halves (228 bits each):
+---------+--------------------|---------+--------------------+
| in-band | SID marker | in-band | coded data |
+---------+--------------------|---------+--------------------+
| 16 bits | 212 bits | 16 bits | 212 bits |
The first half contains coded in-band signalling data (16 bits) and
the identification marker (212 bits), which allows to detect that
it's an AHS_SID_UPDATE. This half is carried by even bits of the
first two bursts and odd bits of the last two bursts.
The other half also contains the in-band data (16 bits), while the
remaining 212 bits contain encoded SID_UPDATE (212 bits). This
half is carried by even bits of the last two bursts and odd bits
of the first two bursts.
Current implementation does not use odd bits of the first two
bursts at all, so buffer cB[] in gsm0503_tch_ahs_decode_dtx()
contains only 114 out of 228 bits.
This patch changes the logic, so that gsm0503_tch_ahs_decode_dtx()
would not split AHS_SID_UPDATE onto two frames anymore like its
TCH/AFS equivalent does, but attempt to deinterleave the second
half and attempt to decode the payload immediately.
Change-Id: I8686d895e96fa0e606c1898b6574cc80a8f46983
Related: [1] I434157e2091a306c039123cea08d84bd8533c937
Related: SYS#5853
Neels Hofmeyr
Neels Hofmeyr
Pau Espin
Harald Welte
Oliver Smith
Philipp Maier
Eric Wild
Vadim Yanitskiy