2023-04-17 12:25:51 +00:00
|
|
|
Creating MS object
|
2023-04-19 17:42:05 +00:00
|
|
|
MS(TA-220:MSCLS-0-0): + test_ms_state: now used by 1 (test_ms_state)
|
2023-04-17 12:25:51 +00:00
|
|
|
Modifying MS object, UL TLLI: 0xffffffff -> 0xffeeddbb, not yet confirmed
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Attaching UL TBF: TBF(UL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:UL) Attaching DL TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:UL:DL) Detaching TBF: TBF(UL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:DL) Detaching TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
2023-04-18 17:02:55 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0): - tbf: now used by 0 (-)
|
2022-11-03 13:16:17 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Destroying MS object
|
2023-04-17 12:25:51 +00:00
|
|
|
Creating MS object
|
2023-04-19 17:42:05 +00:00
|
|
|
MS(TA-220:MSCLS-0-0): + test_ms_replace_tbf: now used by 1 (test_ms_replace_tbf)
|
2023-04-17 12:25:51 +00:00
|
|
|
The MS object cannot fully confirm an unexpected TLLI: 0xffeeddbb, partly confirmed
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Attaching DL TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:DL) Attaching DL TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:DL) Attaching UL TBF: TBF(UL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:UL:DL) Detaching TBF: TBF(UL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:DL) Detaching TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:DL) Detaching TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
2023-04-18 17:02:55 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0): - tbf: now used by 0 (-)
|
2022-11-03 13:16:17 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Destroying MS object
|
2023-04-17 12:25:51 +00:00
|
|
|
Creating MS object
|
2023-04-19 17:42:05 +00:00
|
|
|
MS(TA-220:MSCLS-0-0): + test_ms_change_tlli: now used by 1 (test_ms_change_tlli)
|
2023-04-17 12:25:51 +00:00
|
|
|
Modifying MS object, UL TLLI: 0xffffffff -> 0xff001111, not yet confirmed
|
2015-05-15 13:50:43 +00:00
|
|
|
Modifying MS object, TLLI: 0xff001111 confirmed
|
|
|
|
Modifying MS object, UL TLLI: 0xff001111 -> 0xaa000000, not yet confirmed
|
|
|
|
Modifying MS object, TLLI: 0xaa000000 confirmed
|
|
|
|
Modifying MS object, UL TLLI: 0xaa000000 -> 0xff001111, not yet confirmed
|
|
|
|
Modifying MS object, TLLI: 0xff001111 confirmed
|
|
|
|
Modifying MS object, UL TLLI: 0xff001111 -> 0xaa000000, not yet confirmed
|
|
|
|
Modifying MS object, TLLI: 0xaa000000 confirmed
|
|
|
|
Modifying MS object, UL TLLI: 0xaa000000 -> 0xff001111, not yet confirmed
|
|
|
|
The MS object cannot fully confirm an unexpected TLLI: 0xff00eeee, partly confirmed
|
|
|
|
Modifying MS object, TLLI: 0xff001111 confirmed
|
|
|
|
Modifying MS object, UL TLLI: 0xff001111 -> 0xaa000000, not yet confirmed
|
|
|
|
Modifying MS object, TLLI: 0xaa000000 confirmed
|
|
|
|
The MS object cannot fully confirm an unexpected TLLI: 0xff001111, partly confirmed
|
|
|
|
Modifying MS object, TLLI: 0xaa000000 -> 0xff001111, already confirmed partly
|
2023-04-19 17:42:05 +00:00
|
|
|
MS(TLLI-0xff001111:TA-220:MSCLS-0-0): - test_ms_change_tlli: now used by 0 (-)
|
2022-11-03 13:16:17 +00:00
|
|
|
MS(TLLI-0xff001111:TA-220:MSCLS-0-0) Destroying MS object
|
2023-04-17 12:25:51 +00:00
|
|
|
Creating MS object
|
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
|
|
|
Modifying MS object, UL TLLI: 0xffffffff -> 0xffeeddbb, not yet confirmed
|
2015-05-21 09:07:53 +00:00
|
|
|
Modifying MS object, TLLI = 0xffeeddbb, IMSI '' -> '001001987654321'
|
2023-04-17 12:25:51 +00:00
|
|
|
Creating MS object
|
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
|
|
|
Modifying MS object, UL TLLI: 0xffffffff -> 0xffeeddbc, not yet confirmed
|
2015-05-21 09:07:53 +00:00
|
|
|
Modifying MS object, TLLI = 0xffeeddbc, IMSI '' -> '001001987654322'
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(IMSI-001001987654321:TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Attaching UL TBF: TBF(UL:G:IMSI-001001987654321:TLLI-0xffeeddbb){NEW}
|
2023-04-18 17:02:55 +00:00
|
|
|
MS(IMSI-001001987654321:TLLI-0xffeeddbb:TA-220:MSCLS-0-0:UL): + tbf: now used by 1 (tbf)
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(IMSI-001001987654321:TLLI-0xffeeddbb:TA-220:MSCLS-0-0:UL) Detaching TBF: TBF(UL:G:IMSI-001001987654321:TLLI-0xffeeddbb){NEW}
|
2023-04-18 17:02:55 +00:00
|
|
|
MS(IMSI-001001987654321:TLLI-0xffeeddbb:TA-220:MSCLS-0-0): - tbf: now used by 0 (-)
|
2022-11-03 13:16:17 +00:00
|
|
|
MS(IMSI-001001987654321:TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Destroying MS object
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(IMSI-001001987654322:TLLI-0xffeeddbc:TA-220:MSCLS-0-0) Attaching UL TBF: TBF(UL:G:IMSI-001001987654322:TLLI-0xffeeddbc){NEW}
|
2023-04-18 17:02:55 +00:00
|
|
|
MS(IMSI-001001987654322:TLLI-0xffeeddbc:TA-220:MSCLS-0-0:UL): + tbf: now used by 1 (tbf)
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(IMSI-001001987654322:TLLI-0xffeeddbc:TA-220:MSCLS-0-0:UL) Detaching TBF: TBF(UL:G:IMSI-001001987654322:TLLI-0xffeeddbc){NEW}
|
2023-04-18 17:02:55 +00:00
|
|
|
MS(IMSI-001001987654322:TLLI-0xffeeddbc:TA-220:MSCLS-0-0): - tbf: now used by 0 (-)
|
2022-11-03 13:16:17 +00:00
|
|
|
MS(IMSI-001001987654322:TLLI-0xffeeddbc:TA-220:MSCLS-0-0) Destroying MS object
|
2023-04-17 12:25:51 +00:00
|
|
|
Creating MS object
|
2023-04-19 17:42:05 +00:00
|
|
|
MS(TA-220:MSCLS-0-0): + test_ms_timeout: now used by 1 (test_ms_timeout)
|
2023-04-17 12:25:51 +00:00
|
|
|
Modifying MS object, UL TLLI: 0xffffffff -> 0xffeeddbb, not yet confirmed
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Attaching UL TBF: TBF(UL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:UL) Attaching DL TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:UL:DL) Detaching TBF: TBF(UL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:DL) Detaching TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
2023-04-18 17:02:55 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0): - tbf: now used by 0 (-)
|
2023-04-19 19:07:09 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Schedule MS release in 1 secs
|
2022-11-03 13:16:17 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Release timer expired
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Destroying MS object
|
2023-04-17 12:25:51 +00:00
|
|
|
Creating MS object
|
2023-04-19 17:42:05 +00:00
|
|
|
MS(TA-220:MSCLS-0-0): + test_ms_cs_selection: now used by 1 (test_ms_cs_selection)
|
2023-04-17 12:25:51 +00:00
|
|
|
The MS object cannot fully confirm an unexpected TLLI: 0xffeeddbb, partly confirmed
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Attaching DL TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0:DL) Detaching TBF: TBF(DL:G:TLLI-0xffeeddbb){NEW}
|
Make sure GprsMs free() also frees its tbfs
This fixes TBF objects leaking and ending up alive when the MS object is
explicitly freed through talloc_free (and sporadically
crashing TbfTest once a timeout for them occur).
This mostly affects unit tests, where most of the explicit free()
happens.
In osmo-pcu, in general, the GprsMs object only gets _free() called when
its resource count reaches 0, aka no more TBFs are attached to it. Hence
in general GprsMs object is freed() only when no TBFs (to be leaked) are
present.
However, in the unit tests it's usual that we want to wipe the entire
context by eg. feeing the PCU, the BTS or MS object, which should also
free the related TBFs.
When running osmo-pcu this may only be an issue when the MS object is
freed explicitly, which could happen for instance when a BTS is torn down,
ie. PCUIF going down, moment at which all GprsMs of that BTS are freed.
But in there actually it iterates over PDCHs to free all TBFs, so it's
fine.
If we iterated over MS, this could have ended up in a crash, like
it happened in TbfTest sporadically, but it's not a bit problem if we
crash + restart at that time since anyway the BTS is gone ore just
getting up around that time.
Related: OS#6359
Change-Id: Ibbdec94acb8132be20508d3178d88da44bfaf91d
2024-03-25 19:13:47 +00:00
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0): - test_ms_cs_selection: now used by 0 (-)
|
|
|
|
MS(TLLI-0xffeeddbb:TA-220:MSCLS-0-0) Destroying MS object
|
2023-04-17 12:25:51 +00:00
|
|
|
Creating MS object
|
2023-04-19 17:42:05 +00:00
|
|
|
MS(TA-220:MSCLS-0-0): + test_ms_mcs_mode: now used by 1 (test_ms_mcs_mode)
|
2023-04-17 12:25:51 +00:00
|
|
|
The MS object cannot fully confirm an unexpected TLLI: 0xdeadbeef, partly confirmed
|
|
|
|
Creating MS object
|
2023-04-19 17:42:05 +00:00
|
|
|
MS(TA-220:MSCLS-0-0): + test_ms_mcs_mode: now used by 1 (test_ms_mcs_mode)
|
2023-04-17 12:25:51 +00:00
|
|
|
The MS object cannot fully confirm an unexpected TLLI: 0xdeadbef0, partly confirmed
|
2023-05-31 10:52:41 +00:00
|
|
|
MS(TLLI-0xdeadbef0:TA-220:MSCLS-0-0) Attaching DL TBF: TBF(DL:G:TLLI-0xdeadbef0){NEW}
|
|
|
|
MS(TLLI-0xdeadbef0:TA-220:MSCLS-0-0:DL) Detaching TBF: TBF(DL:G:TLLI-0xdeadbef0){NEW}
|
Make sure GprsMs free() also frees its tbfs
This fixes TBF objects leaking and ending up alive when the MS object is
explicitly freed through talloc_free (and sporadically
crashing TbfTest once a timeout for them occur).
This mostly affects unit tests, where most of the explicit free()
happens.
In osmo-pcu, in general, the GprsMs object only gets _free() called when
its resource count reaches 0, aka no more TBFs are attached to it. Hence
in general GprsMs object is freed() only when no TBFs (to be leaked) are
present.
However, in the unit tests it's usual that we want to wipe the entire
context by eg. feeing the PCU, the BTS or MS object, which should also
free the related TBFs.
When running osmo-pcu this may only be an issue when the MS object is
freed explicitly, which could happen for instance when a BTS is torn down,
ie. PCUIF going down, moment at which all GprsMs of that BTS are freed.
But in there actually it iterates over PDCHs to free all TBFs, so it's
fine.
If we iterated over MS, this could have ended up in a crash, like
it happened in TbfTest sporadically, but it's not a bit problem if we
crash + restart at that time since anyway the BTS is gone ore just
getting up around that time.
Related: OS#6359
Change-Id: Ibbdec94acb8132be20508d3178d88da44bfaf91d
2024-03-25 19:13:47 +00:00
|
|
|
MS(TLLI-0xdeadbeef:TA-220:MSCLS-0-0) Destroying MS object
|
|
|
|
MS(TLLI-0xdeadbef0:TA-220:MSCLS-0-0) Destroying MS object
|