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