2015-05-12 15:54:33 +00:00
|
|
|
/* gprs_ms_storage.cpp
|
|
|
|
*
|
|
|
|
* Copyright (C) 2015 by Sysmocom s.f.m.c. GmbH
|
|
|
|
* Author: Jacob Erlbeck <jerlbeck@sysmocom.de>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
#include "gprs_ms_storage.h"
|
|
|
|
|
|
|
|
#include "tbf.h"
|
2015-11-27 18:05:13 +00:00
|
|
|
#include "bts.h"
|
2018-01-26 12:31:42 +00:00
|
|
|
|
|
|
|
extern "C" {
|
|
|
|
#include <osmocom/core/linuxlist.h>
|
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
|
|
|
#include <osmocom/gsm/gsm48.h>
|
2018-01-26 12:31:42 +00:00
|
|
|
}
|
2015-05-12 15:54:33 +00:00
|
|
|
|
2015-08-16 19:36:32 +00:00
|
|
|
#define GPRS_UNDEFINED_IMSI "000"
|
|
|
|
|
2015-06-02 12:06:12 +00:00
|
|
|
GprsMsStorage::GprsMsStorage(BTS *bts) :
|
|
|
|
m_bts(bts)
|
2015-05-12 15:54:33 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
GprsMsStorage::~GprsMsStorage()
|
2016-01-20 21:02:19 +00:00
|
|
|
{
|
|
|
|
cleanup();
|
|
|
|
}
|
|
|
|
|
|
|
|
void GprsMsStorage::cleanup()
|
2015-05-12 15:54:33 +00:00
|
|
|
{
|
|
|
|
LListHead<GprsMs> *pos, *tmp;
|
|
|
|
|
|
|
|
llist_for_each_safe(pos, tmp, &m_list) {
|
|
|
|
GprsMs *ms = pos->entry();
|
|
|
|
ms->set_callback(NULL);
|
|
|
|
ms_idle(ms);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void GprsMsStorage::ms_idle(class GprsMs *ms)
|
|
|
|
{
|
|
|
|
llist_del(&ms->list());
|
2015-11-27 18:05:13 +00:00
|
|
|
if (m_bts)
|
2020-05-12 20:45:04 +00:00
|
|
|
m_bts->stat_item_add(STAT_MS_PRESENT, -1);
|
2015-05-12 15:54:33 +00:00
|
|
|
if (ms->is_idle())
|
|
|
|
delete ms;
|
|
|
|
}
|
|
|
|
|
|
|
|
void GprsMsStorage::ms_active(class GprsMs *ms)
|
|
|
|
{
|
|
|
|
/* Nothing to do */
|
|
|
|
}
|
|
|
|
|
|
|
|
GprsMs *GprsMsStorage::get_ms(uint32_t tlli, uint32_t old_tlli, const char *imsi) const
|
|
|
|
{
|
2015-05-21 09:07:53 +00:00
|
|
|
GprsMs *ms;
|
2015-05-12 15:54:33 +00:00
|
|
|
LListHead<GprsMs> *pos;
|
|
|
|
|
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
|
|
|
if (tlli != GSM_RESERVED_TMSI || old_tlli != GSM_RESERVED_TMSI) {
|
2015-05-21 09:07:53 +00:00
|
|
|
llist_for_each(pos, &m_list) {
|
|
|
|
ms = pos->entry();
|
|
|
|
if (ms->check_tlli(tlli))
|
|
|
|
return ms;
|
|
|
|
if (ms->check_tlli(old_tlli))
|
|
|
|
return ms;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* not found by TLLI */
|
2015-05-12 15:54:33 +00:00
|
|
|
|
2015-08-16 19:36:32 +00:00
|
|
|
if (imsi && imsi[0] && strcmp(imsi, GPRS_UNDEFINED_IMSI) != 0) {
|
2015-05-21 09:07:53 +00:00
|
|
|
llist_for_each(pos, &m_list) {
|
|
|
|
ms = pos->entry();
|
|
|
|
if (strcmp(imsi, ms->imsi()) == 0)
|
|
|
|
return ms;
|
|
|
|
}
|
2015-05-12 15:54:33 +00:00
|
|
|
}
|
|
|
|
|
2015-05-21 09:07:53 +00:00
|
|
|
return NULL;
|
2015-05-12 15:54:33 +00:00
|
|
|
}
|
|
|
|
|
2015-06-19 08:59:58 +00:00
|
|
|
GprsMs *GprsMsStorage::create_ms()
|
|
|
|
{
|
|
|
|
GprsMs *ms;
|
|
|
|
|
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
|
|
|
ms = new GprsMs(m_bts, GSM_RESERVED_TMSI);
|
2015-06-19 08:59:58 +00:00
|
|
|
|
|
|
|
ms->set_callback(this);
|
|
|
|
llist_add(&ms->list(), &m_list);
|
2015-11-27 18:05:13 +00:00
|
|
|
if (m_bts)
|
2020-05-12 20:45:04 +00:00
|
|
|
m_bts->stat_item_add(STAT_MS_PRESENT, 1);
|
2015-06-19 08:59:58 +00:00
|
|
|
|
|
|
|
return ms;
|
|
|
|
}
|