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