In tx_pdtch_fn(), delay sending DATA.cnf until bid=3. Otherwise we
send it too early (at bid=0) and trick the upper layers (RLC/MAC)
to believe that the whole block (all bursts) has been transmitted.
Change-Id: If32fafeef0ea347ed3800e6b67349bf12e66047f
The current timeout is too low, taking into account that SM PDP
Activation timeout is already 30. When SM fails, it will retry sending
PDP Context Activation Req. Hence, give it enough time to at least retry
once, plus some extra buffer time (eg to go through GMM attach once).
Change-Id: I34f9b0a5ad5767155dc3e4c0ac1c4bf1521be596
* assert() the given TDMA Tn before accessing gprs->pdch[]
* do not check TDMA Fn, as there can be no RTS.ind for PTCCH/U
** unlike PTCCH/D, we send Access Bursts on PTCCH/U
Change-Id: Ie74d1c4123715d61875c4c956eb4a1ce97ed5f24
It's unlikely to happen as long as all TCH_DATA_IOF_* variants are
handled in the switch statements, but still gcc does complain.
Change-Id: I0a81d5c4f11feb7cf73771c23848dee9ce6ec620
We already have VTY commands to configure data call parameters at
run-time, but so far there was no way to save and restore them.
This commit adds the respective commands to TCH_DATA_NODE.
Change-Id: I4453f2e7e048b3f3ebb1727f6d26f018c792c92d
Related: OS#4396
Currently we unconditionally expect the rate adaption (octet 5) in
the Bearer Capability IE to be GSM48_BCAP_RA_V110_X30. This is
correct for UDI (GSM48_BCAP_ITCAP_UNR_DIG_INF), but not for 3.1 kHz
audio (GSM48_BCAP_ITCAP_3k1_AUDIO) and fax (GSM48_BCAP_ITCAP_FAX_G3)
calls. For the later two it should be GSM48_BCAP_RA_NONE.
Change-Id: I70d36b3540ed2469068e050809a17ed07b434ad7
Related: OS#4396
So far we supported the Texas Instruments format (TCH_DATA_IOF_TI),
which is used by Calypso based phones (e.g. Motorola C1xx), but not
the format that trxcon speaks/understands (TCH_DATA_IOF_OSMO).
Change-Id: Ib17e800e91ad536db53aa55661076089f0ce34b0
Related: OS#4396
We cannot initiate V.34 data calls because gsm48_encode_bearer_cap()
does not support octet 6d. This variant should not be selectable.
Change-Id: Ibafb9a693654672fb9a6abf665c500a27c87bf22
Related: OS#4396, OS#6344
This is basically a back-port of the fix that was merged to
libosmocore.git back in 2013. Our ancient copy of libosmocore,
which is used for building the firmware, predates this commit.
Ideally, we should rip off this ancient copy and build the firmware
against recent master (see OS#2378). But for now, let's just fix
our local copy. Otherwise TCH/[FH]2.4 support is broken.
Change-Id: I99f528f3e1cd4c04ebb9d8becf1572688dd531ae
Related: libosmocore.git 31e844bfe2
Related: OS#4396
We will need to know the current Bearer Capability of a CC
transaction in the upcoming patches adding CSD support.
Change-Id: Ifc3ecf832a552c65444f49711ac836b6cd984715
Related: OS#4396
This allows driving logic in other modules based on transaction
related events, such as allocation, deallocation, or a state change.
These new signals will be used in the upcoming CSD implementation.
Change-Id: Idae5da24cb517878a26cc14b2ba6976e60f0b31b
Related: OS#4396
Fix a regression: check if Location Area Information IE fits.
Change-Id: I51e2ae1be1c51a6359f8b0faad56f654251f1413
Fixes: bb0ac02e "mobile: always check return value of tlv_parse()"
Fixes: CID#341618
A similar check was recently added to gsm48_cc_data_ind().
Change-Id: Ibc5153df41e2c6365a3c65b1906d440a1074514b
Related: 273d412a "mobile: gsm48_cc_data_ind(): check if struct gsm48_hdr fits"
The L1 PHY may emit empty TRAFFIC.ind in case of decoding errors.
Abort execution of pq_audio_sink early, otherwise we hit an assert.
Change-Id: Ice11b72ddfd51fbfb17a4c609c664b86a8f69591
This patch fixes [currently missing] Jenkins build verification.
Currently it's just skipping the firmware due to errors:
make -C target/firmware CROSS_COMPILE=arm-none-eabi-
make[1]: Entering directory '/build/src/target/firmware'
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
...
Change-Id: Ibfcc17ca2736da82d60db3b0e350b74e788031b0
* Migrate from deprecated gsm48_mi_to_string() API.
* Take a chance to unfify printing of mobile identity.
* Use osmo_load32be() for printing TMSI - this is what
the osmo_mobile_identity API does internally.
Change-Id: Ida67adaa61689c55505a89e1a1bebde041c91139
Depends: libosmocore.git If4f7be606e54cfa1c59084cf169785b1cbda5cf5
Checking the stderr makes a little sense, since it's an integer
value (usually equal to 2). The actual intention, most likely,
was to check 'stderr_target' against NULL.
Change-Id: Id597f766142f928135f9fd2b7cf4d69de7bc72f0
Related: OS#6299
After adding the strongest cell to the measurement report, the variables
'strongest' and 'strongest_i' are used to prevent that already added
cells are added again.
Please note that there are no neighbor cell measurements available,
because current layer 1 does not report BSIC of neighbor cells. This
means that there is no neighbor cell reported.
Related: OS#6280
Change-Id: Iaeeaf978da31611c47a20af41790bfa6640dcffd
A wrong index was used, causing the first neighbor cell to be
uninitialized. This uninitialized neighbor cell was reported by
MEASUREMENT REPORT.
Related: OS#6280
Change-Id: I192c0777450cbe24abb3c7c8736c678b97725e9f
While it is correct to use the band indicator from SI1 rest octets,
it may only be applied for ARFCN values in the range 512..810.
The function gsm_refer_pcs() is used to determine, if the cell (which
'talks' about ARFCNs) refers to them PCS or DCS channels. It returns
true, if it refers to PCS, but this only means that ARFCNs in the range
512..810 are PCS channels, not all ARFCNs.
The new function gsm_arfcn_refer_pcs() is used to add the PCS flag to an
ARFCN, if the given cell refers to PCS and the given ARFCN is in the PCS
range 512..810.
Change-Id: Id99c8534bf853f4f24f99364790c1ac1df6cc007
Related: OS#6078
Setting the flag was not required in earlier versions of libosmogsm,
because this feature was enabled by default.
The roundtrip delay for a LAPD link must be less than T200.
Osmocom-bb runs LAPDm on the host machine via serial interface and USB
interface that may cause a roundtrip delay that exceeds T200. Also
osmo-bts may have that problem, due to latency between physical
interface and osmo-bts software.
What may happen:
An I frame gets lost.
The sending side transmits the next I frame. The receiving side detects
the send-sequence error and responds with a REJ frame.
Due to the round trip delay, the T200 expires on the sending side and
causes the I frame to be retransmitted with the P bit set, it enters
the timer recovery state. The receiving side detects the send-sequence
error and responds with a REJ frame with the F bit set.
The sending side will then receive two REJ frames. The first REJ frame
will clear the timer recovery state. The second REJ frame (with F bit
set) is received when not in timer recovery state, causing an
MDL-ERROR-INDICATION.
The layer 2 connection is broken.
Early tests with osmocom-bb in a real network showed exactly this
problem.
The solution is to suppress every second REJ frame at the receiving
side, until the sequence error condition is cleared. If the first REJ
frame gets lost, the sending side would retransmit the I frame again
after another expiry of T200. Then the receiving side would respond
with a REJ frame again.
Relates: OS#5969
Depends: libosmocore.git I93994dbbd1fc2c9edb8f3015c6b18ecd0fce0565
Change-Id: Iaa1645fb1970fe513d71bc1b03f7c5eac62f35d7
It seems that those flags have always been gcc flags, and not ld flags.
After decades of tolerating this, binutils 2.36.x no longer tolerates
those flags but prints an error:
arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you mean --nostartfiles ?)
See also https://github.com/apache/nuttx/issues/3826 and the related
https://github.com/apache/nuttx/pull/3836 how this was solved in another
project - I adopted that solution here 1:1
Change-Id: Id199e4d03d5aae07a347c98f47791f42c12008c6
As was reported by roox, osmocom-bb currently fails to build on OBS:
https://build.opensuse.org/build/home:mnhauke:osmocom:nightly/openSUSE_Tumbleweed/x86_64/osmocom-bb/_log
[ 24s] layer1/prim_tch.c: In function 'l1s_tch_meas_avg':
[ 24s] layer1/prim_tch.c:183:2: error: 'for' loop initial declarations are only allowed in C99 mode
[ 24s] layer1/prim_tch.c:183:2: note: use option -std=c99 or -std=gnu99 to compile your code
We don't specify the C standard explicitly, so let's move the variable
declaration out of the for-loop in l1s_tch_meas_avg().
Change-Id: I6c65fbead4e612c81728e9c6601d5f2107616ee6
Fixes: 7286560a3 "firmware/layer1: fill-in DL info for L1CTL TRAFFIC.ind"
Vadim Yanitskiy
Pau Espin
Harald Welte
Andreas Eversberg