This commit actually addresses 2 errors:
1- gprs_bssgp_pcu_rx_paging_ps() called gprs_rlcmac_paging_request()
with MI which can be either TMSI or IMSI, and the later always called
bts_pch_timer_start() passing mi->imsi regardless of the MI type. Hence,
trash was being accessed & stored into bts_pch_timer structures if MI
type used for paging was TMSI.
2- When the MS received the PS paging on CCCH and requests an UL TBF, it
will send some data. If one phase access is used for whatever reason,
the IMSI may not be yet available in the GprsMs object since we never
received it (and we'd only have it by means of PktResourceReq). Hence,
let's better first try to match the paging by TLLI/TMSI if set in both
places, and otherwise use the IMSI.
Related: OS#5297
Change-Id: Iedffb7c6978a3faf0fc26ce2181dde9791a8b6f4
This counter is related to succPDTCHSeizures,
(3GPP TS 52.402 B.2.1.51 Successful PDTCH seizures).
The relevant event when the first RLC block on the PDCH from the MS is
received is the fact that contention resolution is considered as done in
the network side. Hence, name the counter that way to ease
interpretation.
Related: SYS#4878
Change-Id: I3d67e3e68907921b43f2ca4398ad9578c0b2618c
This allows distinguishing when a TBF didn't set the TFI. Useful to
identify dummy reject TBFs, etc, and make sure a non-dummy TBF set its
TFI properly.
Change-Id: Iecf54a24041bd14f4ef5b86e57c3732e1b69d463
This way it's easier to distinguish when this value was not properly
filled when debugging or looking at logs.
Change-Id: I0c9c9fdcfca9eb15125ea49efcbb76711850052e
This way the timestamp is also set for dummy reject TBFs. For other
TBFs, setup() is called immediatelly after calling the constructor, so
we are fine too.
Change-Id: I2966ec7f3f9161d528a173d94797b72d1398c747
Let's set them to match expectancies for this type of dummy TBFs, in
order to avoid acidental use/access of other timeslots to the one where
the reject was associated to.
Also use tbf_assign_control_ts() to log the TS used for the TBF, similar
to what's used in other places where control_ts is assigned.
Related: OS#5293
Change-Id: I32dcb29ad24519082b8665921efcce0b5a16d12e
These new counters allow the user to find out which kind of access are
MS requesting.
Related: SYS#4878
Change-Id: Id87c3a53d3acee92499987c843130e358f54742c
Since a while a go, a TBF is guaranteed to always have a MS assigned.
Hence, there's no point in checking it.
Change-Id: I89e062432ac671c73731ce68c889aeb5e24277f5
That's one of the most important information bits about a TBF when
debugging, and it's not shown currently, only when "show ms" is used.
Change-Id: I98e3c9cac4ca6fc29695768ecc6e0444e618b945
Previous code did use a ctrg based on MS being EGPRS capable or not.
However, an MS being EGPRS capable doesn't mean necessarily that all its
TBFs are EGPRS, since we may known about the capability after we already
created some previous TBF, so it was not ugpraded. Hence, we were
sometimes accessing the wrong NULL ctrg.
Let's simply check for non NULL ctrg when deciding what to print.
"""
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7561ea6 in vty_out_rate_ctr_group (vty=vty@entry=0x897850, prefix=prefix@entry=0x4482cd " ", ctrg=0x0) at utils.c:82
82 utils.c: No such file or directory.
(gdb) bt
#0 0x00007ffff7561ea6 in vty_out_rate_ctr_group (vty=vty@entry=0x897850, prefix=prefix@entry=0x4482cd " ", ctrg=0x0) at utils.c:82
#1 0x000000000041437b in tbf_print_vty_info (vty=vty@entry=0x897850, tbf=0x3fb61f0) at pcu_vty_functions.cpp:98
#2 0x0000000000414acc in pcu_vty_show_tbf_all (vty=vty@entry=0x897850, bts=bts@entry=0x7be650, flags=4294967295) at pcu_vty_functions.cpp:127
#3 0x000000000041206f in show_tbf (self=<optimized out>, vty=0x897850, argc=<optimized out>, argv=0x7fffffffe040) at pcu_vty.c:1150
#4 0x00007ffff755d167 in cmd_execute_command_real (vline=vline@entry=0x7bc300, vty=vty@entry=0x897850, cmd=<optimized out>) at command.c:2604
"""
Related: SYS#5689
Change-Id: I3979bfc12dd3b9a53b34b284537f271c356a3024
This way it fits better the structure where the general one counts all
rachs, and 11bit only the 11 bits. More per-type splitting will be done
in follow-up commits where new types are added.
Change-Id: Ibdfb10dcc65d71e98e2fe8b05001cafea786f071
If it's not single block packets access, then it's one phase packet
access. TS 44.018 Table 9.1.8.1:
"""
One phase packet access with request for single timeslot uplink transmission;
one PDCH is needed.
"""
Change-Id: Ic6beb6dcfebb77fd264b179b028f99a29c644fb1
ns_configure_nse() only sets bind when it doesn't exist yet. If it
already exists bind[i] stays NULL and causes a segfault in
gprs_ns2_is_ip_bind() later on.
This patch ensures bind[i] is either created of set to the existing
bind.
Change-Id: I103e82e6c64324c087a4ff325a83eeab0e5a4ee9
Related: SYS#4971
Fixup for previous patch, which forgot to update the pui using the new
variable, as done already in the same patch for M_NEXT_EXIST.
Change-Id: I92a04c708bcc6c15348324321e8890361bbc5c31
Fixes: 72cdb30ee2b1c0d71ff6d9583d51f46b2e5fdcea
If we decode Exist bit as "1" but we are at the end of the message, and
all the Next items we'd read are expected to be possibly NULL, then swap
the Exist bit in the decoded structure as "0" in order to tell the
decoder user that the related information structure is actually unset,
as if "0" was received.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I38602e4b680ed87297c7e440691a494c07cad446
All additional release fields are considered optional, and the
CSN_DESCR for Content_t already marks almost all as such, except
DownlinkDualCarrierCapability_r7.
It has been found that some MS transmits a MS RA Capability with a Length=61 bits
where the last bit in the buffer is setting the Exist bit for
DownlinkDualCarrierCapability_r7 as 1. Hence, the CSN1 decoder failed to
decode the whole message because it expected to keep reading there
despite there's no more bytes to read.
While this is could actually be considered an MS bug, let's relax our
expectancies and simply consider the case { 1 <end> } as it was { 0 },
and mark skip decoding DownlinkDualCarrierCapability_r7. That waht
wireshark (packet-gsm_a_gsm.c) or pycrate do for instance.
This patch itself doesn't fix the problem where actually the Exist bit
is stored as 1 in the output decoded structure, but simply allows keep
ongoing with decoding until the end. This issue will be fixed in a
follow-up patch.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I9a2541bd3544802a646890f32725201836abb0da
This RA Cap creaes a decoding error on our CSN1 decoder, but seems to be
handled properly by wireshark's own decoder as well as pycrate.
The ending bit of last byte in "MS RA capability 1" has a "1" which
according to spec should flag the existance of
DownlinkDualCarrierCapability_r7, but nothing else comes after it. This
matches the expectancies as per Length field of the first RA Cap.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I51235e8575f4b992b44078713ec67bbccfd13293
The CSN1 encoder/decoder code is already lengthy and complex enough,
there's no need to keep it in the same file, specially because when
debugging, only is interested in one of the 2 functions, and they both
look really similar (long spaghetti switches).
Change-Id: I7d1b1f7e6d7f89b052b3fd73a960419bb2673020
This way PCU always answers DATA.ind and the BTS can still clearly
identify idle frames. It also simplifies testing and verification of
correct behavior.
Related: SYS#4919
Change-Id: Ife718eeed2af011479c03099ea109518f04567bc
This function is expected to be used only on DL TBF so far, so let's
really assert to avoid going through if something is wrong and ending up
later with other issues.
Change-Id: If398ee48364fce5b5e38830b2b278b3bad9a48a2
Code above setting the timer in same tbf_fsm already has this kind of
assert, but it helps understanding the code having this assert here.
Change-Id: I7588deef5073694eb5fecdb516c241a04594e2b0
In that function, previous PDCHs are unlinked and then alloc_algorithm
is expected to assign new TFIs.
Change-Id: I7bcbb223ca32400bede7ab638695ba3c015c9946
Off the top of my head: The tbf_ was kept during a previous refactoring
a while ago to avoid changing lots of more lines in the same patch.
Change-Id: I8ae689a272b7c4d244576ff157f6019a87041abc
TSC is not really a property of a TBF, so let's drop it in order to avoid
confusing and possible misuse of that accessor.
Change-Id: I105eb65d507e45631faddb23420c42bc9560e580
There's no real need to pass a tlli per separate, the information is
already contained in the MS. Furthermore, when doing so, it becomes
clear the TLLI was only passed to set it again on the MS, so actually
that ms_update() can be totally dropped since it will act as a no-op.
Change-Id: Ie761c3c7c222458ab0514117ae637ad3267139a0
The situation holds true as long as the assignment is resolved. Hence,
it can also happen that the TBF is in RELEASE state, because it was
unable to do the assignment (and after retrying, MAX_N3105 moved it into
RELEASING).
Let's not explicitly check states, the other conditions should be
enough.
Related: SYS#5647
Change-Id: I05fb0ea44aeb3fbda9e8e1c449e9366efaa2c511
It doesn't make sense to keep asking the scheduler to retransmit Pkt Ul
Ass if the tbf_fsm already decided we are going to release the TBF.
It can be seen in following log extract:
"""
tbf_ul_ass_fsm.c:112 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
tbf_ul_ass_fsm.c:131 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS) Scheduled UL Assignment polling on PACCH (FN=612941, TS=7)
tbf_ul_ass_fsm.c:188 UL_ASS_TBF(UL-TFI_1)[849e50]{SEND_ASS}: state_chg to WAIT_ACK
pdch_ul_controller.c:330 PDCH(bts=0,trx=1,ts=7) Timeout for registered POLL (FN=612937, reason=DL_ASS): TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS)
tbf.cpp:550 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS) poll timeout for FN=612937, TS=7 (curr FN 612937)
tbf.cpp:392 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS) N3105 exceeded MAX (8)
tbf.cpp:602 TBF(UL-TFI_1)[7bd530]{ASSIGN}: Received Event MAX_N3105
tbf_fsm.c:194 TBF(UL-TFI_1)[7bd530]{ASSIGN}: state_chg to RELEASING
pdch_ul_controller.c:330 PDCH(bts=0,trx=1,ts=7) Timeout for registered POLL (FN=612941, reason=UL_ASS): TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS)
tbf.cpp:550 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS) poll timeout for FN=612941, TS=7 (curr FN 612941)
tbf.cpp:589 UL_ASS_TBF(UL-TFI_1)[849e50]{WAIT_ACK}: Received Event ASS_POLL_TIMEOUT
tbf_ul_ass_fsm.c:224 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS) Timeout for polling PACKET CONTROL ACK for PACKET UPLINK ASSIGNMENT: |Assignment was on PACCH|No uplink data received yet|
tbf_ul_ass_fsm.c:226 UL_ASS_TBF(UL-TFI_1)[849e50]{WAIT_ACK}: state_chg to SEND_ASS
tbf_ul_ass_fsm.c:308 UL_ASS_TBF(UL-TFI_1)[849e50]{SEND_ASS}: Received Event CREATE_RLCMAC_MSG
tbf_ul_ass_fsm.c:112 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS) start Packet Uplink Assignment (PACCH)
tbf_ul_ass_fsm.c:131 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS) Scheduled UL Assignment polling on PACCH (FN=612976, TS=7)
tbf_ul_ass_fsm.c:188 UL_ASS_TBF(UL-TFI_1)[849e50]{SEND_ASS}: state_chg to WAIT_ACK
"""
Change-Id: I94243ff99dfaf3664a1a4b3c4c87b5104ba4f7d1
When MS sends us the Packet Resource Request as RRBP from final UL ACK/NACK, we create a new TBF
with a different set of allocated TS. However, we must send the Pkt UL Assignment with information
of the new TBF using that same TS where we receive the Packet Resource Request, which happens to
be the control TS of the previous/old TBF. The original control TS of the new TBF is kept in
tbf->first_common_ts.
Hence the code does gprs_rlcmac_pdch::rcv_resource_request():
"""
ul_tbf->control_ts = ts_no;
"""
And later, when we receive a CTRL ACK answering the Pkt UL Assigment, we change the control TS of
the new TBF back to the new one, by calling tbf_assign_control_ts(), which basically does:
"""
tbf->control_ts = tbf->first_common_ts;
"""
So, for instance we have a TBF which was allocated with tbf->control_ts=4 and hence is only attached
to PDCH 4 (tbf->pdch[]), but for which is temporarily applied tbf->control_ts=7. Hence, when a poll
is requested, it is done in control_ts, aka 7, which is not in the array of attached PDCH.
The problem is of course if we never reach the point where the final control_ts is set, due to never
receiving the CTRL ACK. If the TBF is freed (due to timer X2001) before receiving the CTRL ACK and
hence tbf_assign_control_ts() is called, a crash may occur, because potentially a poll for the TBF is
left in TS 7 because it's not a PDCH attached to the TBF and hence poll
entries on that TS are not released, hence keeping a pointer to the
freed TBF.
Related: SYS#5647
Change-Id: I0c49f2695e0d932d956c01976c9458eebee63cd4