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(a)gnumonks.org>rg>:
> 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(a)gnumonks.org>
>
http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch.
> A6)
>