2019-09-05 15:13:33 +00:00
|
|
|
--- test_enc_zero_len ---
|
|
|
|
Application Information Request with zero length received!
|
|
|
|
|
|
|
|
--- test_enc ---
|
|
|
|
exp: 03 fc 03 fc 00 00 00 00 00 00 00 00 00 00 00 00
|
|
|
|
msg: 03 fc 03 fc 00 00 00 00 00 00 00 00 00 00 00 00
|
|
|
|
|
|
|
|
--- test_pcu_rx_no_subscr_with_active_tbf ---
|
|
|
|
Application Information Request received: type=0x00000000 len=0
|
|
|
|
Packet Application Information will not be sent, no subscribers with active TBF
|
|
|
|
|
|
|
|
--- prepare_bts_with_two_dl_tbf_subscr ---
|
TLLI 0x00000000 is a valid TLLI, use 0xffffffff instead
The assumption that TLLI 0x00000000 is invalid and can be used
as the initializer is wrong. Similar to TMSI, 0x00000000 is a
perfectly valid value, while 0xffffffff is reserved - use it.
According to 3GPP TS 23.003, section 2.4, a TMSI/P-TMSI with
all 32 bits equal to 1 is special and shall not be allocated by
the network. The reason is that it must be stored on the SIM,
where 'ff'O represents the erased state. According to section
2.6 of the same document, a local/foreign TLLI is derived from
P-TMSI, so the same rule applies to TLLI.
I manually checked and corrected all occurances of 'tlli' in the
code. The test expectations have been adjusted with this command:
$ find tests/ -name "*.err" | xargs sed -i "s/0x00000000/0xffffffff/g"
so there should be no behavior change. The only exception is
the 'TypesTest', where TLLI 0xffffffff is being encoded and
expected in the hexdump, so I regenerated the test output.
Change-Id: Ie89fab75ecc1d8b5e238d3ff214ea7ac830b68b5
Related: OS#4844
2020-11-08 06:27:35 +00:00
|
|
|
Creating MS object, TLLI = 0xffffffff
|
|
|
|
Modifying MS object, TLLI = 0xffffffff, MS class 0 -> 10
|
|
|
|
Modifying MS object, TLLI = 0xffffffff, EGPRS MS class 0 -> 11
|
|
|
|
MS(TLLI=0xffffffff, IMSI=, TA=220, 10/11,) Enabled EGPRS, mode EGPRS
|
2019-09-05 15:13:33 +00:00
|
|
|
[DL] algo B <multi> (suggested TRX: 0): using 4 slots
|
2021-02-25 16:49:30 +00:00
|
|
|
PDCH(bts=0,trx=0,ts=4) Attaching TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS), 1 TBFs, USFs = 00, TFIs = 00000001.
|
|
|
|
PDCH(bts=0,trx=0,ts=5) Attaching TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS), 1 TBFs, USFs = 00, TFIs = 00000001.
|
|
|
|
PDCH(bts=0,trx=0,ts=6) Attaching TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS), 1 TBFs, USFs = 00, TFIs = 00000001.
|
|
|
|
PDCH(bts=0,trx=0,ts=7) Attaching TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS), 1 TBFs, USFs = 00, TFIs = 00000001.
|
TLLI 0x00000000 is a valid TLLI, use 0xffffffff instead
The assumption that TLLI 0x00000000 is invalid and can be used
as the initializer is wrong. Similar to TMSI, 0x00000000 is a
perfectly valid value, while 0xffffffff is reserved - use it.
According to 3GPP TS 23.003, section 2.4, a TMSI/P-TMSI with
all 32 bits equal to 1 is special and shall not be allocated by
the network. The reason is that it must be stored on the SIM,
where 'ff'O represents the erased state. According to section
2.6 of the same document, a local/foreign TLLI is derived from
P-TMSI, so the same rule applies to TLLI.
I manually checked and corrected all occurances of 'tlli' in the
code. The test expectations have been adjusted with this command:
$ find tests/ -name "*.err" | xargs sed -i "s/0x00000000/0xffffffff/g"
so there should be no behavior change. The only exception is
the 'TypesTest', where TLLI 0xffffffff is being encoded and
expected in the hexdump, so I regenerated the test output.
Change-Id: Ie89fab75ecc1d8b5e238d3ff214ea7ac830b68b5
Related: OS#4844
2020-11-08 06:27:35 +00:00
|
|
|
Attaching TBF to MS object, TLLI = 0xffffffff, TBF = TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS)
|
2020-10-30 17:18:06 +00:00
|
|
|
ws(64)
|
TLLI 0x00000000 is a valid TLLI, use 0xffffffff instead
The assumption that TLLI 0x00000000 is invalid and can be used
as the initializer is wrong. Similar to TMSI, 0x00000000 is a
perfectly valid value, while 0xffffffff is reserved - use it.
According to 3GPP TS 23.003, section 2.4, a TMSI/P-TMSI with
all 32 bits equal to 1 is special and shall not be allocated by
the network. The reason is that it must be stored on the SIM,
where 'ff'O represents the erased state. According to section
2.6 of the same document, a local/foreign TLLI is derived from
P-TMSI, so the same rule applies to TLLI.
I manually checked and corrected all occurances of 'tlli' in the
code. The test expectations have been adjusted with this command:
$ find tests/ -name "*.err" | xargs sed -i "s/0x00000000/0xffffffff/g"
so there should be no behavior change. The only exception is
the 'TypesTest', where TLLI 0xffffffff is being encoded and
expected in the hexdump, so I regenerated the test output.
Change-Id: Ie89fab75ecc1d8b5e238d3ff214ea7ac830b68b5
Related: OS#4844
2020-11-08 06:27:35 +00:00
|
|
|
Creating MS object, TLLI = 0xffffffff
|
|
|
|
Modifying MS object, TLLI = 0xffffffff, MS class 0 -> 12
|
|
|
|
Modifying MS object, TLLI = 0xffffffff, EGPRS MS class 0 -> 13
|
|
|
|
MS(TLLI=0xffffffff, IMSI=, TA=220, 12/13,) Enabled EGPRS, mode EGPRS
|
2019-09-05 15:13:33 +00:00
|
|
|
[DL] algo B <multi> (suggested TRX: 0): using 3 slots
|
2021-02-25 16:49:30 +00:00
|
|
|
PDCH(bts=0,trx=0,ts=4) Attaching TBF(TFI=1 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS), 2 TBFs, USFs = 00, TFIs = 00000003.
|
|
|
|
PDCH(bts=0,trx=0,ts=5) Attaching TBF(TFI=1 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS), 2 TBFs, USFs = 00, TFIs = 00000003.
|
|
|
|
PDCH(bts=0,trx=0,ts=6) Attaching TBF(TFI=1 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS), 2 TBFs, USFs = 00, TFIs = 00000003.
|
TLLI 0x00000000 is a valid TLLI, use 0xffffffff instead
The assumption that TLLI 0x00000000 is invalid and can be used
as the initializer is wrong. Similar to TMSI, 0x00000000 is a
perfectly valid value, while 0xffffffff is reserved - use it.
According to 3GPP TS 23.003, section 2.4, a TMSI/P-TMSI with
all 32 bits equal to 1 is special and shall not be allocated by
the network. The reason is that it must be stored on the SIM,
where 'ff'O represents the erased state. According to section
2.6 of the same document, a local/foreign TLLI is derived from
P-TMSI, so the same rule applies to TLLI.
I manually checked and corrected all occurances of 'tlli' in the
code. The test expectations have been adjusted with this command:
$ find tests/ -name "*.err" | xargs sed -i "s/0x00000000/0xffffffff/g"
so there should be no behavior change. The only exception is
the 'TypesTest', where TLLI 0xffffffff is being encoded and
expected in the hexdump, so I regenerated the test output.
Change-Id: Ie89fab75ecc1d8b5e238d3ff214ea7ac830b68b5
Related: OS#4844
2020-11-08 06:27:35 +00:00
|
|
|
Attaching TBF to MS object, TLLI = 0xffffffff, TBF = TBF(TFI=1 TLLI=0xffffffff DIR=DL STATE=NULL EGPRS)
|
2020-10-30 17:18:06 +00:00
|
|
|
ws(64)
|
2019-09-05 15:13:33 +00:00
|
|
|
|
|
|
|
--- test_sched_app_info_ok ---
|
|
|
|
Application Information Request received: type=0x00000000 len=15
|
|
|
|
Sending Packet Application Information to 2 subscribers with active TBF
|
|
|
|
Sending Packet Application Information message
|
|
|
|
Sending Packet Application Information message
|
|
|
|
Packet Application Information successfully sent to all MS with active TBF
|
|
|
|
|
|
|
|
--- test_sched_app_info_missing_app_info_in_bts ---
|
|
|
|
Application Information Request received: type=0x00000000 len=15
|
|
|
|
Sending Packet Application Information to 2 subscribers with active TBF
|
|
|
|
MS has app_info_pending flag set, but no Packet Application Information message stored in BTS!
|
|
|
|
|
|
|
|
--- test_pcu_rx_overwrite_app_info ---
|
|
|
|
Application Information Request received: type=0x00000000 len=15
|
|
|
|
Sending Packet Application Information to 2 subscribers with active TBF
|
|
|
|
Application Information Request received: type=0x00000000 len=15
|
|
|
|
Previous Packet Application Information was not sent to all subscribers, overwriting with new one
|
|
|
|
Sending Packet Application Information to 2 subscribers with active TBF
|
|
|
|
|
|
|
|
--- cleanup ---
|
2021-02-25 16:49:30 +00:00
|
|
|
PDCH(bts=0,trx=0,ts=4) Detaching TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS), 1 TBFs, USFs = 00, TFIs = 00000002.
|
|
|
|
PDCH(bts=0,trx=0,ts=5) Detaching TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS), 1 TBFs, USFs = 00, TFIs = 00000002.
|
|
|
|
PDCH(bts=0,trx=0,ts=6) Detaching TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS), 1 TBFs, USFs = 00, TFIs = 00000002.
|
|
|
|
PDCH(bts=0,trx=0,ts=7) Detaching TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS), 0 TBFs, USFs = 00, TFIs = 00000000.
|
Convert GprsMS and helpers classes to C
As we integrate osmo-pcu more and more with libosmocore features, it
becomes really hard to use them since libosmocore relies heavily on C
specific compilation features, which are not available in old C++
compilers (such as designated initializers for complex types in FSMs).
GprsMs is right now a quite simple object since initial design of
osmo-pcu made it optional and most of the logic was placed and stored
duplicated in TBF objects. However, that's changing as we introduce more
features, with the GprsMS class getting more weight. Hence, let's move
it now to be a C struct in order to be able to easily use libosmocore
features there, such as FSMs.
Some helper classes which GprsMs uses are also mostly move to C since
they are mostly structs with methods, so there's no point in having
duplicated APIs for C++ and C for such simple cases.
For some more complex classes, like (ul_,dl_)tbf, C API bindings are
added where needed so that GprsMs can use functionalitites from that
class. Most of those APIs can be kept afterwards and drop the C++ ones
since they provide no benefit in general.
Change-Id: I0b50e3367aaad9dcada76da97b438e452c8b230c
2020-12-16 14:59:45 +00:00
|
|
|
Detaching TBF from MS object, TLLI = 0xffffffff, TBF = TBF(TFI=0 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS)
|
2021-02-25 16:49:30 +00:00
|
|
|
PDCH(bts=0,trx=0,ts=4) Detaching TBF(TFI=1 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS), 0 TBFs, USFs = 00, TFIs = 00000000.
|
|
|
|
PDCH(bts=0,trx=0,ts=5) Detaching TBF(TFI=1 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS), 0 TBFs, USFs = 00, TFIs = 00000000.
|
|
|
|
PDCH(bts=0,trx=0,ts=6) Detaching TBF(TFI=1 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS), 0 TBFs, USFs = 00, TFIs = 00000000.
|
Convert GprsMS and helpers classes to C
As we integrate osmo-pcu more and more with libosmocore features, it
becomes really hard to use them since libosmocore relies heavily on C
specific compilation features, which are not available in old C++
compilers (such as designated initializers for complex types in FSMs).
GprsMs is right now a quite simple object since initial design of
osmo-pcu made it optional and most of the logic was placed and stored
duplicated in TBF objects. However, that's changing as we introduce more
features, with the GprsMS class getting more weight. Hence, let's move
it now to be a C struct in order to be able to easily use libosmocore
features there, such as FSMs.
Some helper classes which GprsMs uses are also mostly move to C since
they are mostly structs with methods, so there's no point in having
duplicated APIs for C++ and C for such simple cases.
For some more complex classes, like (ul_,dl_)tbf, C API bindings are
added where needed so that GprsMs can use functionalitites from that
class. Most of those APIs can be kept afterwards and drop the C++ ones
since they provide no benefit in general.
Change-Id: I0b50e3367aaad9dcada76da97b438e452c8b230c
2020-12-16 14:59:45 +00:00
|
|
|
Detaching TBF from MS object, TLLI = 0xffffffff, TBF = TBF(TFI=1 TLLI=0xffffffff DIR=DL STATE=RELEASING EGPRS)
|
|
|
|
Destroying MS object, TLLI = 0xffffffff
|
|
|
|
Destroying MS object, TLLI = 0xffffffff
|