This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Вадим Яницкий axilirator at gmail.comI 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 at 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 at freyther.de>: > >> >> > On 17 Mar 2016, at 17:21, Вадим Яницкий <axilirator at 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160322/d58aaa9c/attachment.htm>