commit cb98894eb1d9dfa8a2b040224a0a5605db38a2cf
author Vadim Yanitskiy <vyanitskiy@sysmocom.de> Sun Nov 08 13:27:35 2020 +0700
committer fixeria <vyanitskiy@sysmocom.de> Tue Nov 10 17:06:39 2020 +0000
tree 64091d033624e58fde52c61a3e17eba0bb5cf8c7
parent 305763dc6f63feada8636f05e9ce22b8d880e152

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