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/.
Thomas Cooper tacooper at vt.eduI seem to have it working now, it wasn't clear but the subscriber wasn't explicitly authorized. I fixed it via the telnet commands; like I guessed, I just wasn't well knowledged in operating OpenBSC. I would still like to hear about my other question regarding the LAC=65534 being reserved though. On Feb 22, 2012 2:15 PM, "Thomas Cooper" <tacooper at vt.edu> wrote: > Hey Osmoworld, > Just a little intro before my rambling questions... I've been working on > connecting OpenBTS and osmo-bts/OpenBSC together, and everything works well > enough to at least send messages between the two (it's somewhat hackish but > it works for me so far). The phone sees the network and when I attempt to > connect, it is assigned a SDCCH and starts the typical location update > process. This makes me think the underlying issue is in my OpenBSC/network > setup. > > Now for the problems: (probably best to check the console output below > first) > Even though the MS receives an ID request and returns an ID response, the > LU Request times out and returns cause=13 (default from config). I'm not > sure what happens after the ID response since it doesn't seem to have sent > anything else down to the MS. > I also don't know too much about the MS's job, but it seems to send 3 LU > requests every time (2 of which are unnecessary and rejected as > duplicates). I assume that's what the preceding ERROR IND messages are > referring to, but I don't know for certain. > > My BTS BCCH has LAI=001/01/1, which is correctly set in both OpenBTS and > OpenBSC config files. The Location Updating Request contains > LAI=001/01/65534, which I think may be the main issue since LAC=65534 is > reserved (even looking in GSM-04.08, I couldn't find any details about > this; can you shed some light please?). The MS works with standard OpenBTS > by the way. > > I've looked through the gsm_04_08 code and Wireshark capture, but no clues > stick out. I'm not too familiar with OpenBSC in general, so this could be > as simple as setting some kind of config parameter. I figured I'd ask on > here for help in case I'm just missing something basic. > > Here is the console output (with debug and authorize-everyone flags on): > > Wed Feb 22 13:06:24 2012 <0004> abis_rsl.c:1317 (bts=0,trx=0,ts=0,ss=0) > Activating ARFCN(51) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0e ta=0 > Wed Feb 22 13:06:24 2012 <0004> abis_rsl.c:1064 (bts=0,trx=0,ts=0,ss=0) > CHANNEL ACTIVATE ACK > Wed Feb 22 13:06:25 2012 <0000> abis_rsl.c:1493 (bts=0,trx=0,ts=0,ss=0) > SAPI=0 ESTABLISH INDICATION > Wed Feb 22 13:06:25 2012 <0002> gsm_04_08.c:1023 LOCATION UPDATING > REQUEST: mi_type=0x01 MI(460020020292786) type=NORMAL > Wed Feb 22 13:06:25 2012 <0001> gsm_04_08.c:114 (bts 0 trx 0 ts 0 pd 05) > Sending 0x18 to MS. > Wed Feb 22 13:06:25 2012 <0000> abis_rsl.c:1493 (bts=0,trx=0,ts=0,ss=0) > SAPI=0 Wed Feb 22 13:06:25 2012 <0000> abis_rsl.c:1439 > (bts=0,trx=0,ts=0,ss=0) ERROR INDICATION cause=unknown 0x0 > Wed Feb 22 13:06:25 2012 <0000> abis_rsl.c:1493 (bts=0,trx=0,ts=0,ss=0) > SAPI=0 ESTABLISH INDICATION > Wed Feb 22 13:06:25 2012 <0002> gsm_04_08.c:1023 LOCATION UPDATING > REQUEST: mi_type=0x01 MI(460020020292786) type=NORMAL ignoring request due > an existing one: 0x20f1350. > Wed Feb 22 13:06:25 2012 <0002> gsm_04_08.c:383 Subscriber > 460020020292786: LOCATION UPDATING REJECT LAC=1 BTS=0 > Wed Feb 22 13:06:25 2012 <0001> gsm_04_08.c:114 (bts 0 trx 0 ts 0 pd 05) > Sending 0x04 to MS. > Wed Feb 22 13:06:25 2012 <0000> abis_rsl.c:1493 (bts=0,trx=0,ts=0,ss=0) > SAPI=0 Wed Feb 22 13:06:25 2012 <0000> abis_rsl.c:1439 > (bts=0,trx=0,ts=0,ss=0) ERROR INDICATION cause=unknown 0x0 > Wed Feb 22 13:06:25 2012 <0000> abis_rsl.c:1493 (bts=0,trx=0,ts=0,ss=0) > SAPI=0 ESTABLISH INDICATION > Wed Feb 22 13:06:25 2012 <0002> gsm_04_08.c:1023 LOCATION UPDATING > REQUEST: mi_type=0x01 MI(460020020292786) type=NORMAL ignoring request due > an existing one: 0x20f1350. > Wed Feb 22 13:06:25 2012 <0002> gsm_04_08.c:383 Subscriber > 460020020292786: LOCATION UPDATING REJECT LAC=1 BTS=0 > Wed Feb 22 13:06:25 2012 <0001> gsm_04_08.c:114 (bts 0 trx 0 ts 0 pd 05) > Sending 0x04 to MS. > Wed Feb 22 13:06:25 2012 <0000> abis_rsl.c:1493 (bts=0,trx=0,ts=0,ss=0) > SAPI=0 DATA INDICATION > Wed Feb 22 13:06:25 2012 <0003> bsc_api.c:430 CLASSMARK CHANGE CM2(len=3) > CM3(len=4) > Wed Feb 22 13:06:27 2012 <0000> abis_rsl.c:1493 (bts=0,trx=0,ts=0,ss=0) > SAPI=0 DATA INDICATION > Wed Feb 22 13:06:27 2012 <0002> gsm_04_08.c:446 IDENTITY RESPONSE: > mi_type=0x02 MI(357966009107140) > Wed Feb 22 13:06:30 2012 <0002> gsm_04_08.c:484 Location Updating Request > procedure timedout. > Wed Feb 22 13:06:30 2012 <0002> gsm_04_08.c:383 Subscriber > 460020020292786: LOCATION UPDATING REJECT LAC=1 BTS=0 > Wed Feb 22 13:06:30 2012 <0001> gsm_04_08.c:114 (bts 0 trx 0 ts 0 pd 05) > Sending 0x04 to MS. > Wed Feb 22 13:06:30 2012 <0000> chan_alloc.c:429 (bts=0,trx=0,ts=0,ss=0) > starting release sequence > Wed Feb 22 13:06:30 2012 <0003> gsm_04_08_utils.c:231 Sending Channel > Release: Chan: Number: 0 Type: 1 > Wed Feb 22 13:06:30 2012 <0004> abis_rsl.c:579 (bts=0,trx=0,ts=0,ss=0) > DEACTivate SACCH CMD > Wed Feb 22 13:06:31 2012 <0000> abis_rsl.c:1493 (bts=0,trx=0,ts=0,ss=0) > SAPI=0 RELEASE INDICATION > Wed Feb 22 13:06:31 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=0,ss=0) RF > Channel Release CMD due error 0 > Wed Feb 22 13:06:31 2012 <0004> abis_rsl.c:658 (bts=0,trx=0,ts=0,ss=0) RF > CHANNEL RELEASE ACK > > Thanks for any help, > Tom Cooper > > -- > Graduate Research Assistant > Wireless @ Virginia Tech > tacooper at vt.edu > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120222/9637407e/attachment.htm>