I just fixed some things (gsm_subscriber.c, VTY tmsi parsing)
and did some tests. It works!

Location Update Request with TMSI from previous network:
<0002> gsm_04_08.c:1127 LOCATION UPDATING REQUEST: MI(TMSI)=0x68044a6c type=NORMAL
<0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS.
<0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS.

Outgoing SMS from OpenBSC VTY:
OpenBSC> subscriber tmsi 0xb7f861b6 sms sender tmsi 0xb7f861b6 send TEST
<0002> gsm_subscriber.c:175 Subscriber <IMSI> not paged yet.
<0004> abis_rsl.c:1465 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(***) SS(0) lctype SDCCH r=OTHER ra=0x1a ta=1
<0004> abis_rsl.c:1199 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK
<0000> abis_rsl.c:1653 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION
<0000> gsm_04_08.c:3573 Dispatching 04.08 message, pdisc=6
<0003> gsm_04_08.c:1180 PAGING RESPONSE: MI(TMSI)=0xb7f861b6
<0003> gsm_04_08.c:1198 <- Channel was requested by <IMSI>
<0003> gsm_04_08.c:1259 TX APPLICATION INFO id=0x00, len=4
<0001> gsm_04_08.c:144 (bts 0 trx 0 ts 0 pd 06) Sending 0x38 to MS.
<0001> transaction.c:71 subscr=0x2363f00, net=0x2333e90

USSD request also works:
<0002> gsm_04_08.c:956 <- CM SERVICE REQUEST serv_type=0x08 MI(TMSI)=0xb7f861b6
<0002> gsm_04_08_utils.c:692 -> CM SERVICE ACK

As you can see, now TMSI displays in hex.
I'll provide a new patch soon.


С наилучшими пожеланиями,
Яницкий Вадим.

2016-03-22 18:58 GMT+06:00 Вадим Яницкий <axilirator@gmail.com>:
Hello, Harald! Good day, Holger!

It looks like SQLite3 doesn't have support of unsigned 64-bit integers. :(
Of course, we can write some custom functions, which can emulate it,
but it isn't good solution, I think.

My suggestion is to keep the TMSI column type in string format: 0xffffffff.
I need to know your opinions before starting to write a new patch.


С наилучшими пожеланиями,
Яницкий Вадим.

2016-03-17 22:34 GMT+06:00 Holger Freyther <holger@freyther.de>:

> On 17 Mar 2016, at 17:21, Вадим Яницкий <axilirator@gmail.com> wrote:
>
> 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.


yes, we have a schema version and can just increase it. E.g. have a look at how we migrate SMS.



>
> > tmsi_from_string will not work for this anymore.
>
> Yes, I forgot to change the gsm_subscriber.c ... Sorry.


it happens. thanks for contributing



>
> > 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.

I think you will not need to touch this define at all. We might want to change the name to _from_mi_string.


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


looking forward for the follow up.


holger