Hi Guys!

> If you have time, please check if there are other occurrences in OpenBSC
> or OsmocomBB where the TMSI is printed as integer. Thanks!

No problem! :)

> I think it was a bit too quick. I foresee one problem. Let's assume someone
> is using TMSIs and now upgrade the sourcecode. All CM Service Requests
> will fail because the TMSI is not known. What is the migration/mitigation plan?

I absolutely agree with Holger. Maybe we can add some code that will check
if database still stores TMSIs in old representation style and convert them to
uint32_t? We can change the libmsc/db.c:db_prepare() for this purpose.

> tmsi_from_string will not work for this anymore.

Yes, I forgot to change the gsm_subscriber.c ... Sorry.

> there is no length check but that doesn't seem to be a big issue right now.

We can just write a function that will do this check instead of using #define.

> * a DB schema upgrade and store the TMSI as uint32_t
> * Use hex presentation in VTY

+1

С наилучшими пожеланиями,

Яницкий Вадим.

2016-03-17 19:43 GMT+06:00 Harald Welte <laforge@gnumonks.org>:

Hi Holger,

On Thu, Mar 17, 2016 at 02:29:33PM +0100, Holger Freyther wrote:
> I think it was a bit too quick. I foresee one problem. Let's assume
> someone is using TMSIs and now upgrade the sourcecode. All CM Service
> Requests will fail because the TMSI is not known. What is the
> migration/mitigation plan?

ugh. I failed to see that for some strange reason we store the TMSI as
"TEXT" in the database. That's really odd, especailly as we use %u
formatting when searching for TMSIs in the database.

> * I think the above hunk should be reverted

done.

> * a DB schema upgrade and store the TMSI as uint32_t

correct.

--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)