tree bbcc704521dea6cac10963091ca3d4bf3646cb8c
parent 5e91debe4eb75dcd4990038fb5da6d8db9ef0eba
author Neels Hofmeyr <neels@hofmeyr.de> 1536800752 +0200
committer Neels Hofmeyr <neels@hofmeyr.de> 1537139533 +0200

store classmark in vlr_subscr, not conn

Store all Classmark information in the VLR.

So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.

Rationale:

During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.

In other words, for anything else than a LU Request, we had no Classmark 1
available at all.

During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.

The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.

This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.

Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a