September 2016 - OpenBSC - lists.osmocom.org

MS cannot connect; Location Update Request not received by BTS?

by Bruce Smith

7 years, 5 months

5
7
0 0

Re: Profiling data of decoding EPDAN compressed bitmap

by Holger Freyther

> On 13 Jul 2016, at 12:21, Max <msuraev(a)sysmocom.de> wrote: > Hi all, > After looking at the code, I don't think reusing table implementation > would be easy - the approaches are too different as well as underlying > data structures. okay. then we will need to use the tree based version and from my point of view we should do it the following way: * Remove osmo_t4_decode (and related routines) from libosmocore (last step) * Make the tree based decoder ready in terms of the surrounding style * Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU) @Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore @Radisys: I am afraid the tree based decoding is not ready yet and as it impacts the upcoming encoder (and other RLE code as far as I understand) let me put it here. In osmo-pcu (and all other projects) we use libtalloc for memory allocations. This means the tree should use talloc with proper parent/child allocations. This way the destructor of the decoder will also free all nodes of the tree. There should be no call to malloc/free in the PCU. Please take the tests from libosmocore and make sure they work with the new decoder. Tests are the lifeline and we need more and not less of them. The decoder needs to be robust against invalid input. search_runlen can fail but the caller doesn't check for that. Please test with invalid/truncated or broken inputs to see we don't end in a never terminating while loop. Test using unit tests. Similar the current osmo_t4_decode can return an error that is propagated back to the compressed bitmap decoding and we should have the same. Reduce code duplication. With the decoder the only difference between the if/else is if the data is filled with 0x00 or 0xFF and which table/root to use. Instead of having code clones please parameterize either by having local variables in the beginning or by calling different (inline) functions. kind regards holger

7 years, 5 months

1
1
0 0

multiple phy with osmo-trx

by Max

Hi! I've asked about it before but this seems to have been lost in communication. The question is basically how to enable multi-TRX support for osmo-bts-trx using phy/instance infrastructure similar to other bts? What I've tried so far is documented in http://projects.osmocom.org/issues/1648 but it did not result in working setup yet. In short, I'd like to configure OpenBSC with 1 BTS with 2 TRX, each with its own arfcn and set of channels. I'm running "osmo-bts-trx -t 2" and correspondingly "osmo-trx -c 2" on usrp b210. Any ideas on what's missing to make this actually work are greatly appreciated. -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 6 months

4
15
0 0

Re: OsmoBTS -> libosmogsm code migration

by Vadim Yanitskiy

Hi Max, Thanks for your reply! > I think extending utils/conv_gen.py is the way to go because it will > allow us to have concise description of the convolutional codes in one > place and as close to the description in standards as possible. Ok, I will keep your opinion in my mind. > Could you specify which files exactly are you referring to? Also you can > use 'git blame' to clarify authorship. No problem, they are: - gsm0503_conv.c - gsm0503_interleaving.c - gsm0503_mapping.c - gsm0503_parity.c - gsm0503_tables.c Almost all the gsm0503_*, excluding the 'gsm0503_coding.*'. Thank you for this hint, this command is very usable! :) > I don't think library functions should do any sort of logging by itself > (unless it's a logging functions of course :) > Instead they should return clearly distinguishable values and let caller > do the logging as they see fit. I am agree with you. It's time to use return codes. Have a nice day! With best regards, Vadim Yanitskiy.

7 years, 6 months

6
17
0 0

coverity for osmocom projects

by Neels Hofmeyr

Today, I've taken a quick look at the coverity stuff, because so far I've only seen coverity reports on the Iu code. I see now that actually all of the other osmocom components are also tested by coverity. So far I'm only seeing the "Osmocom" coverity project, which contains only the iu build. In fact that's a bit of a misnomer -- I assumed that "Osmocom" would contain all of the osmos, it should be more like 'Osmocom-3G' or 'Osmocom-Iu'. The other osmos are in coverity projects named "libosmocore", "osmo-bts", etc: https://scan.coverity.com/projects?utf8=%E2%9C%93&search=osmo I see there are "add me to project" buttons e.g. here https://scan.coverity.com/projects/libosmocore so I'm trying that now. Wouldn't it make sense to redirect all the coverity reports to a mailing list? Probably best would be a new mailing list, to avoid noise on openbsc@, like the gerrit-log@ list. Are these coverity reports a matter of secrecy, to avoid publishing security holes before we fixed them, in which case the coverity mailing list should be invite-only? ~Neels

7 years, 6 months

3
6
0 0

Query on run time control of network with VTY

by Dhananjay kumar

Hi, While ruining osmo-bts and osmo-trx via VTY we tried to change parameter like Band ,ARFCN MS max power. We observed that once ARFCN is changed on VTY TRX does not switch to new ARFCN. Same behavior has been observed with Band and MS-Max-Power and RF-Locked 0/1 parameter. Request someone who is running osmo-stack has controlled network ,please reply or any document/pointer is appreciated. BR Dhananjay

7 years, 6 months

4
6
0 0

osmo-sip-connector issue

by Anonim Stefan

Hi, I am using osmo-nitb + osmo-sip-connector and I am sending INVITE to it, as in the attached trace. The connector replies with 0.0.0.0 RTP IP and 0/unknown codec and then ends the call. I am seeing the following log: " Sep 23 09:08:00 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:334 call(1073741832) can not be found Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0002> app.c:104 Unknown ptmsg(0). call broken Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:312 leg(5001) rtp connect failed Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:245 Ending leg(0x91ec30) in con Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:304 leg(1073741832) can not be found Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:186 leg(0x91ec30) got bye, releasing. " This issue happens *after* *recently* *updated* *packages* to: " ii osmocom-nitb 0.15.1.20160922 amd64 GSM Network-in-a-Box, implements BSC, MSC, SMSC, HLR, VLR ii osmo-sip-connector 1.20160922 amd64 MNCC to SIP bridge for osmo-nitb " On the osmo-nitb side I am seeing logs [1]. I suspect a bug in the osmo-sip-connector code. Can someone confirm this? [1] http://pastebin.com/giG0HHha

7 years, 6 months

2
5
0 0

Moving from trac to a single redmine

by Holger Freyther

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

7 years, 7 months

6
15
0 0

RFC: use AddressSanitizer by default in gerrit

by Max

Hi. When gerrit check the patch it only cares about "make check" result. There's also a way to use AddressSanitizer for a given branch via http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/ I've just sent patch which fixes latest missing bit in libosmocore which enables running AddressSanitizer with "make check" - see gerrit #863. When this is merged we can enable AddressSanitizer for the "make check" used by gerrit to verify patch submissions. What do you think? Note: we can't enable it yet for OpenBSC but all the libraries seems to be fine. -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 7 months

1
0
0 0

libosmo-abis question

by Max

Hi. Coverity have noticed weird piece of code in libosmo-abis osmo_rtp_socket_fdreg(): ... rs->rtp_bfd.when = rs->rtcp_bfd.when = BSC_FD_READ; rs->rtp_bfd.when = rs->rtcp_bfd.when = 0; ... It's on the border between 2 commits so it's likely merge artifact. Which value is the right one? Or should it be rtcp_bfd? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 7 months

2
1
0 0

Re: New Defects reported by Coverity Scan for Osmocom

by Neels Hofmeyr

On Mon, Sep 19, 2016 at 06:02:45AM -0700, scan-admin(a)coverity.com wrote: > > Hi, > > Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan. > > 5 new defect(s) introduced to Osmocom found with Coverity Scan. > 6 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 5 of 5 defect(s) > > > ** CID 148210: Error handling issues (NEGATIVE_RETURNS) > /source-iuh/openbsc/openbsc/src/gprs/gprs_llc.c: 273 in rx_llc_xid() > > > ________________________________________________________________________________________________________ > *** CID 148210: Error handling issues (NEGATIVE_RETURNS) > /source-iuh/openbsc/openbsc/src/gprs/gprs_llc.c: 273 in rx_llc_xid() > 267 > 268 response_len = > 269 gprs_llc_process_xid_ind(gph->data, gph->data_len, > 270 response, sizeof(response), > 271 lle); > 272 xid = msgb_put(resp, response_len); > >>> CID 148210: Error handling issues (NEGATIVE_RETURNS) > >>> "response_len" is passed to a parameter that cannot be negative. @dexter ^ check that response_len > 0 > 273 memcpy(xid, response, response_len); > 274 > 275 gprs_llc_tx_xid(lle, resp, 0); > 276 } else { > 277 LOGP(DLLC, LOGL_NOTICE, > 278 "Received XID confirmation from phone.\n"); > > ** CID 148209: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libmsc/db.c: 414 in check_db_revision() > > > ________________________________________________________________________________________________________ > *** CID 148209: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libmsc/db.c: 414 in check_db_revision() > 408 > 409 /* Incremental migration waterfall */ > 410 switch (db_rev) { > 411 case 2: > 412 if (update_db_revision_2()) > 413 goto error; > >>> CID 148209: Control flow issues (MISSING_BREAK) > >>> The above case falls through to this one. add: /* fall through */ ? > 414 case 3: > 415 if (update_db_revision_3()) > 416 goto error; > 417 > 418 /* The end of waterfall */ > 419 break; > > ** CID 148208: Control flow issues (DEADCODE) > /source-iuh/openbsc/openbsc/src/osmo-bsc/osmo_bsc_ctrl.c: 408 in set_net_timezone() > > > ________________________________________________________________________________________________________ > *** CID 148208: Control flow issues (DEADCODE) > >>> CID 148208: Control flow issues (DEADCODE) > >>> Execution cannot reach the expression "0L" inside this statement: "tz->hr = (hourstr ? atol(ho...". The website has more detail: " > static int set_net_timezone(struct ctrl_cmd *cmd, void *data) > 386{ > 387 char *saveptr, *hourstr, *minstr, *dststr, *tmp = 0; > 388 int override; > 389 struct gsm_network *net = (struct gsm_network*)cmd->node; > 390 > 391 tmp = talloc_strdup(cmd, cmd->value); > 392 if (!tmp) > 393 goto oom; > 394 > 395 hourstr = strtok_r(tmp, ",", &saveptr); > 396 minstr = strtok_r(NULL, ",", &saveptr); > 397 dststr = strtok_r(NULL, ",", &saveptr); > 398 > 399 override = 0; > 400 cond_notnull: Condition hourstr != NULL, taking true branch. Now the value of hourstr is not NULL. > 401 if (hourstr != NULL) > 402 override = strcasecmp(hourstr, "off") != 0; > 403 > 404 struct gsm_tz *tz = &net->tz; > 405 tz->override = override; > 406 > 407 if (override) { notnull: At condition hourstr, the value of hourstr cannot be NULL. dead_error_condition: The condition hourstr must be true. CID 148208 (#1 of 1): Logically dead code (DEADCODE)dead_error_line: Execution cannot reach the expression 0L inside this statement: tz->hr = (hourstr ? atol(ho.... > 408 tz->hr = hourstr ? atol(hourstr) : 0; > 409 tz->mn = minstr ? atol(minstr) : 0; > 410 tz->dst = dststr ? atol(dststr) : 0; > 411 } > 412 > 413 talloc_free(tmp); > 414 tmp = NULL; > 415 > 416 return get_net_timezone(cmd, data); > 417 > 418oom: > 419 cmd->reply = "OOM"; > 420 return CTRL_CMD_ERROR; > 421} " So override == 0 by default. override will only be set if hourstr != NULL. So inside 'if (override)', hourstr will always be != NULL, and the first '?' is superfluous. This exists since the function was added in 2013. > ________________________________________________________________________________________________________ > *** CID 148207: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libbsc/abis_rsl.c: 415 in channel_mode_from_lchan() > 409 default: > 410 LOGP(DRSL, LOGL_ERROR, > 411 "unsupported lchan->csd_mode %u\n", > 412 lchan->csd_mode); > 413 return -EINVAL; > 414 } > >>> CID 148207: Control flow issues (MISSING_BREAK) > >>> The above case falls through to this one. This missing 'break' is an error introduced in e4227988665cae6e44fc0f77c2463aae759f15ca "RSL: Add basic support for CSD transparent mode" > 415 default: > 416 LOGP(DRSL, LOGL_ERROR, > 417 "unsupported lchan->tch_mode %u\n", > 418 lchan->tch_mode); > 419 return -EINVAL; > 420 } > > ** CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > /source-iuh/openbsc/openbsc/src/gprs/gprs_gmm.c: 560 in gsm48_tx_gmm_auth_ciph_req() > > > ________________________________________________________________________________________________________ > *** CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > /source-iuh/openbsc/openbsc/src/gprs/gprs_gmm.c: 560 in gsm48_tx_gmm_auth_ciph_req() > 554 /* 10.5.5.7: */ > 555 acreq->force_stby = force_standby; > 556 /* 3GPP TS 24.008 10.5.5.19: */ > 557 if (RAND_bytes(&rbyte, 1) != 1) { > 558 LOGP(DMM, LOGL_NOTICE, "RAND_bytes failed for A&C ref, falling " > 559 "back to rand()\n"); > >>> CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > >>> "rand" should not be used for security related applications, as linear congruential algorithms are too easy to break. well spotted, coverity :) Do they actually analyse whether that it is security related code? rand() is only the fallback for RAND_bytes(). ~Neels > 560 acreq->ac_ref_nr = rand(); > 561 } else > 562 acreq->ac_ref_nr = rbyte; > 563 mm->ac_ref_nr_used = acreq->ac_ref_nr; > 564 > 565 /* Only if authentication is requested we need to set RAND + CKSN */ > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… > > To manage Coverity Scan email notifications for "nhofmeyr(a)sysmocom.de", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… > -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 7 months

1
0
0 0

Loopback call on osmo-bts

by Dhananjay kumar

Hi all, I am trying to make loopback call on osmo-bts VTY interface using ettus B200/B210 hw. in vty.c file i can see options available for loopback call , but loopback call is not started once triggered from osmobts VTY interface. Can some one help ? DEFUN(bts_t_t_l_loopback, bts_t_t_l_loopback_cmd, "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", BTS_T_T_L_STR "Set loopback\n") -- Thanks & Regards Dhananjay 9686184214 Luck is what happens when preparation meets opportunity.

7 years, 7 months

1
0
0 0

Query regarding Loopback support in Osmobts

by Mayuri Tendulkar

Hi We are looking for a feature at L1 Physical layer loopback in Osmo-bts-trx. Is this feature available and how it can be tested? Regards Mayuri

7 years, 7 months

1
0
0 0

GSM 05.03 code re-licensing

by Vadim Yanitskiy

Hello everyone! Right now I am moving some code from OsmoBTS to libosmocore, exactly OsmoBTS/src/osmo-bts-trx/gsm0503*. And there is a licensing conflict, because this code licensed under AGPLv3+, but libosmocore code is GPLv2+. So, this is why I am contacting all authors/copyright holders. The question is: does everyone agree to re-license the code under GPLv2-or-later and move it code to libosmocore? Thanks in advance! With best regards, Vadim Yanitskiy.

7 years, 7 months

4
3
0 0

MS Initial Registration failure observed in osmo-trx setup

by Mrinal Mishra

Hello All, We are trying to bring up osmo-trx setup in Ettus USRP B200 Board for Testing CS and PS call . When we tried to do the initial Registration for UE it is failing. Could you please help to point out what could be the issue and how to resolve this. Please find below the observation and log snippet for reference: After MS power Up Network is getting detected on the MS , Rach is received at BTS , Channel Activation is successful at A-bis interface and later Immediate Assignment is seen in the log. After Immediate assignment no further message is observed in Uplink/Downlink and later BSC is releasing the SDCCH/SACCH channel as observed from the log. BTS LOG Snippet: OsmoBTS# <0000> rsl.c:2209 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL CHAN_ACTIV <0000> rsl.c:926 chan_nr=0x20 type=0x00 mode=0x00 <0006> scheduler.c:1344 Activating SDCCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1344 Activating SACCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on SDCCH/4(0) of trx=0 ts=0 <0006> scheduler.c:1458 Set a5/0 uplink for SDCCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1458 Set a5/0 uplink for SACCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1458 Set a5/0 downlink for SDCCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1458 Set a5/0 downlink for SACCH/4(0) on trx=0 ts=0 <0000> rsl.c:559 (bts=0,trx=0,ts=0,ss=0) Tx CHAN ACT ACK <000b> trx_if.c:485 Tx burst length 0 invalid <0000> rsl.c:2236 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD <000b> trx_if.c:485 Tx burst length 0 invalid <000b> trx_if.c:485 Tx burst length 0 invalid <000b> trx_if.c:485 Tx burst length 0 invalid <0006> scheduler_trx.c:867 Received incomplete data frame at fn=0 (0/102) for SDCCH/4(0) <0006> scheduler_trx.c:867 Received incomplete data frame at fn=0 (0/102) for SACCH/4(0) <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL DEACTIVATE_SACCH <0006> scheduler.c:1344 Deactivating SACCH/4(0) on trx=0 ts=0 <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL RF_CHAN_REL <0006> scheduler.c:1344 Deactivating SDCCH/4(0) on trx=0 ts=0 <0000> rsl.c:519 (bts=0,trx=0,ts=0,ss=0) Tx RF CHAN REL ACK <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1421484 (12/104) for PTCCH <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1421484 (12/104) for PTCCH <0000> rsl.c:2209 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL CHAN_ACTIV <0000> rsl.c:926 chan_nr=0x0a type=0x00 mode=0x00 <0006> scheduler.c:1344 Activating TCH/F on trx=0 ts=2 <0006> scheduler.c:1344 Activating SACCH/TF on trx=0 ts=2 <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on TCH/F of trx=0 ts=2 <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on PDTCH of trx=0 ts=2 <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on PTCCH of trx=0 ts=2 <0006> scheduler.c:1458 Set a5/0 uplink for TCH/F on trx=0 ts=2 <0006> scheduler.c:1458 Set a5/0 uplink for SACCH/TF on trx=0 ts=2 <0006> scheduler.c:1458 Set a5/0 downlink for TCH/F on trx=0 ts=2 <0006> scheduler.c:1458 Set a5/0 downlink for SACCH/TF on trx=0 ts=2 <0000> rsl.c:559 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK <0000> rsl.c:2236 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD <0006> scheduler.c:267 Prim for trx=0 ts=2 at fn=1085114 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=1436721) <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1436997 (29/104) for TCH/F <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (399/456 bits) <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1436997 for TCH/F <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (286/456 bits) <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1437213 for TCH/F <0006> gsm0503_coding.c:1706 tch_fr_decode(): error checking CRC8 for the FR part of an FR frame <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438301 for TCH/F <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1438522 (98/104) for TCH/F <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (159/456 bits) <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438522 for TCH/F <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1438652 (20/104) for TCH/F <0006> gsm0503_coding.c:1706 tch_fr_decode(): error checking CRC8 for the FR part of an FR frame <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438652 for TCH/F <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL DEACTIVATE_SACCH <0006> scheduler.c:1344 Deactivating SACCH/TF on trx=0 ts=2 <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL RF_CHAN_REL <0006> scheduler.c:1344 Deactivating TCH/F on trx=0 ts=2 <0000> rsl.c:519 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1462772 (12/104) for PTCCH BSC log Snippet : OpenBSC# <0000> chan_alloc.c:342 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(990) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0d ta=0 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=0,ss=0) is back in operation. <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:342 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(990) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=0 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=0,ss=0) is back in operation. <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:342 (bts=0,trx=0,ts=2,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(990) SS(0) lctype TCH_F r=OTHER ra=0xe7 ta=0 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=2,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=2,ss=0) is back in operation. <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state RELEASE DUE ERROR -> NONE Note : We are using internal clock of osmo-trx no external Clock is connected. Thanks and Regards, Mrinal

7 years, 7 months

2
4
0 0

Re: libosmo-abis[master]: osmo_ortp.c: fix order of set_connected_mode and set_remote_...

by Neels Hofmeyr

On Tue, Sep 13, 2016 at 04:39:38PM +0000, Max wrote: > To view, visit https://gerrit.osmocom.org/815 > > This is revert of 8c119f7a0510b75e7fa1b96a37f2a6650e13824f - would be better if it were marked as such. whoa, I wasn't aware of this. It is a patch from the Quickstart Guide for the new litecell15 board. Well, since it's already merged, I guess we won't mark it as a revert then, sorry about that. I've also posted a comment at OS#1661 https://osmocom.org/issues/1661 ~Neels

7 years, 7 months

1
1
0 0

Help Interpreting Classmark and sqlite BLOB storage

by Keith Whyte

Hi All, 2 (related) questions in 1 thread here: I'm looking at Chapter 10.5.1.7 of GSM 04.08, also Figure 10.5.7 there, but I am not quite getting how to interpret it in relation to either openBSC log output such as: <000d> db.c:1130 Sync Equipment IMEI=357371048322730, classmark1=33, classmark2=33 18 82 , classmark3=00 08 00 52 20 00 00 4b or equally: root@bsc:~# echo "SELECT classmark1 FROM Equipment where id='505';" | sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd 0000000: 3531 0a 51. root@bsc:~# echo "SELECT classmark2 FROM Equipment where id='505';" | sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd 0000000: 0132 1781 0a .2... root@bsc:~# echo "SELECT classmark3 FROM Equipment where id='505';" | sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd 0000000: 01ff 07ff 511f ffff 4a0a ....Q...J. Specifically, in this case, not having the mathematical theory, I don't understand how to map 01ff 07ff 511f ffff 4a0a to 00 08 00 52 20 00 00 4b It doesn't /quite/ match, but more importantly mapping to Classmark 3 Value Part Could you help me understand how to map 01ff 07ff 511f ffff 4a0a to Figure 10.5.7 BTW, I get that the BLOBs in sqlite are somehow encoded, (if that is not completely the wrong term to use) as hex_value-1, I've also noted this in the SMS table when trying to identify an sms in the sms_queue. So question part 2: what is that about? Is there an easy way I could "decode" on the command line, as in: echo "SELECT user_data FROM sms limit 1;" | sqlite3 /var/lib/osmocom/hlr.sqlite3 | some magic to display readable SMS content Any tips? Thanks!

7 years, 7 months

3
3
0 0

tcp port 4252 used twice

by Neels Hofmeyr

When updating https://osmocom.org/projects/cellular-infrastructure/wiki/PortNumbers I noticed that 4252 is used both for OpenGGSN Ctrl as well as sysmobts-mgr VTY. Should we do something about that? Technically, we have VTY commands available to redirect the vty bind port, but sysmobts-mgr does not heed that VTY command yet. Related: https://gerrit.osmocom.org/754 ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 7 months

3
4
0 0

PRACH fails

by Sipos Csaba

Dear Tom and List, I am in the process of updating the wiki for USRP radios, therefor I am recompiling everything Osmocom related with the latest master branches. I managed to setup the system, the CS services are working just fine (only fullrate and SMS is tested yet), but the GPRS service seems to be not working. I am using my well tested setup on 1800MHz (ARFCN 885), with duplex filters. On the Osmo-BTS end I get this message: <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access Osmo-PCU in the same time shows the following (repeatedly): Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) timer 3169 expired. Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:893 - Assignment was on CCCH Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:899 - No uplink data received yet Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:879 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) will be freed due to timeout Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:334 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) free Thu Sep 8 12:48:30 2016 DRLCMAC <0002> bts.cpp:1501 PDCH(TS 6, TRX 0): Detaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN), 0 TBFs, USFs = 00, TFIs = 00000000. Thu Sep 8 12:48:30 2016 DRLCMAC <0002> gprs_ms.cpp:323 Detaching TBF from MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) Thu Sep 8 12:48:30 2016 DRLCMAC <0002> gprs_ms.cpp:140 Destroying MS object, TLLI = 0x00000000 Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:355 ********** TBF ends here ********** Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:486 MS requests UL TBF on RACH, so we provide one: Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:672 ********** TBF starts here ********** Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:674 Allocating UL TBF: MS_CLASS=0/0 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_ms.cpp:114 Creating MS object, TLLI = 0x00000000 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:413 Searching for first unallocated TFI: TRX=0 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:423 Found TFI=0. Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:525 Slot Allocation (Algorithm B) for unknown class (assuming 12) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:560 - Rx=4 Tx=4 Sum Rx+Tx=5 Tta=2 Ttb=1 Tra=2 Trb=1 Type=1 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 0, because not enabled Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 1, because not enabled Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 2, because not enabled Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 3, because not enabled Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:579 - Possible DL/UL slots: (TS=0)"....CCCC"(TS=7) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:940 - Selected UL slots: (TS=0)"......U."(TS=7), single Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single slot at TS 6 for UL Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:990 - Reserved DL/UL slots: (TS=0)"......C."(TS=7) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:1017 - Assigning UL TS 6 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:1481 PDCH(TS 6, TRX 0): Attaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001. Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:385 - Setting Control TS 6 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_ms.cpp:267 Attaching TBF to MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:625 Allocated TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL): trx = 0, ul_slots = 40, dl_slots = 00 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) changes state from NULL to FLOW Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:409 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) starting timer 3169. Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:530 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) [UPLINK] START Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:534 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) RX: [PCU <- BTS] RACH qbit-ta=0 ra=0x78, Fn=1011875 (27,35,7) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:536 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) TX: START Immediate Assignment Uplink (AGCH) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:549 - TRX=0 (885) TS=6 TA=0 TSC=7 TFI=0 USF=0 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) changes state from FLOW to WAIT ASSIGN Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:792 Sending flow control info on BVCI 2 Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:705 Computed BVC leak rate = 10000, num_pdch = 4, cs = CS-4 Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:729 Computed MS default leak rate = 10000, ms_num_pdch = 4, cs = CS-4 Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:758 Sending FLOW CONTROL BVC, Bmax = 100000, R = 10000, Bmax_MS = 100000, R_MS = 10000, avg_dly = 0 Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:385 rx BVCI_PTP gprs_bssgp_rx_ptp Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:245 rx BSSGP_PDUT_FLOW_CONTROL_BVC_ACK Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) timer 3169 expired. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:893 - Assignment was on CCCH Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:899 - No uplink data received yet Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:879 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) will be freed due to timeout Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:334 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) free Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:1501 PDCH(TS 6, TRX 0): Detaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN), 0 TBFs, USFs = 00, TFIs = 00000000. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_ms.cpp:323 Detaching TBF from MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_ms.cpp:140 Destroying MS object, TLLI = 0x00000000 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:355 ********** TBF ends here ********** Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:486 MS requests UL TBF on RACH, so we provide one: Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:672 ********** TBF starts here ********** Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:674 Allocating UL TBF: MS_CLASS=0/0 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_ms.cpp:114 Creating MS object, TLLI = 0x00000000 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:413 Searching for first unallocated TFI: TRX=0 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:423 Found TFI=0. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:525 Slot Allocation (Algorithm B) for unknown class (assuming 12) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:560 - Rx=4 Tx=4 Sum Rx+Tx=5 Tta=2 Ttb=1 Tra=2 Trb=1 Type=1 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 0, because not enabled Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 1, because not enabled Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 2, because not enabled Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 3, because not enabled Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:579 - Possible DL/UL slots: (TS=0)"....CCCC"(TS=7) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:940 - Selected UL slots: (TS=0)"......U."(TS=7), single Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single slot at TS 6 for UL Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:990 - Reserved DL/UL slots: (TS=0)"......C."(TS=7) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:1017 - Assigning UL TS 6 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:1481 PDCH(TS 6, TRX 0): Attaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:385 - Setting Control TS 6 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_ms.cpp:267 Attaching TBF to MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:625 Allocated TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL): trx = 0, ul_slots = 40, dl_slots = 00 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) changes state from NULL to FLOW Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:409 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) starting timer 3169. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:530 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) [UPLINK] START Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:534 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) RX: [PCU <- BTS] RACH qbit-ta=0 ra=0x79, Fn=1013049 (27,36,11) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:536 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) TX: START Immediate Assignment Uplink (AGCH) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:549 - TRX=0 (885) TS=6 TA=0 TSC=7 TFI=0 USF=0 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) changes state from FLOW to WAIT ASSIGN Thu Sep 8 12:48:41 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) timer 3169 expired. Thu Sep 8 12:48:41 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission The SGSN and GGSN logs are empty. The RX gain is on 5dB, the UHD version is 3.10.0-release. Only GPRS is allowed so far on 4 PDCHs. Osmo-TRX is started with default set: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 The CS call and SMS are both working fine, the audio quality is quite good. Can someone give me a hint where this goes wrong? From what I see the PRACH is failing to succeed. Regards, Csaba

7 years, 7 months

3
5
0 0

octasic build failure / header versions

by Neels Hofmeyr

Yesterday we had problems building the current osmo-bts-octphy with the current octphy-2g-headers. To resolve, we've reverted two commits and added a change in osmo-bts. (1) osmo-bts included a struct member not present anywhere in octphy-2g-headers. https://gerrit.osmocom.org/820 https://gerrit.osmocom.org/821 On our test setup at sysmocom, I found a version of the headers called OCTSDR-2G-02.05.00-B780-DEBUG that includes this struct member, but those headers have proprietary licensing. Also, the current version apparently is 2.07, while the one with the unknown struct header seems to be older: 2.05. So it looks like the usCentreArfcn item has been removed in a newer version, even though it looks really useful to me. It would be good to resolve this confusion, probably as soon as Max is back from vacation (Max is the author of the reverted commits). (2) In the most recent version, a #define naming has changed. In https://gerrit.osmocom.org/822 Holger asks: > Do we have any precedence of using #if for version checks? You can > use #ifdef for both of them to support old and new headers? We could use a check like #if cOCTVC1_HW_VERSION_MAJOR <=2 && cOCTVC1_HW_VERSION_MINOR < 7 [...]_IDLE[...] #else [...]_UNUSED[...] #endif but I doubt that we will want to go back to old headers. If I'm the only one in doubt, we'd have a check like above in three places in osmo-bts. Thanks for your opinions, ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 7 months

2
2
0 0

chan_alloc.c help

by Abdulghafar Shabaneh

Hi Neels and everyone in the list, Thanks for your help in installing OpenBSc on my Raspberry Pi :) It was as you said that I should delete it and build from scratch. The prefix command fixed the issue as well ./configure --prefix=/usr .. I was unable to install lcr due to an error: Makefile:1306: recipe for target 'chan_lcr.po' failed I don't know if that will fix the problem, though, its optional, and osmo-nitb should do the job by it self. Now I ran the osmo-nitb, osmo-bts-trx and osmo-trx all together with the USRP2 with FLEX900 daughter board GSM900 band, it all works well except the mobile is not able to register on the network. osmo-nitb shows this error: (towards the end) my file >trybsc.cfg contains this: ! password foo ! line vty no login ! e1_input e1_line 0 driver ipa network network country code 416 mobile network code 77 short name GSMab long name GSMab auth policy accept-all location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 10 timer t3141 0 dtx-used 0 subscriber-keep-in-ram 0 bts 0 type sysmobts band GSM900 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 0 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 channel allocator descending rach tx integer 9 rach max transmission 7 ! channel-descrption attach 1 ! channel-descrption bs-pa-mfrms 5 ! channel-descrption bs-ag-blks-res 1 ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic trx 0 rf_locked 0 arfcn 100 nominal power 0 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 pi@dwarfabd:~ $ sudo osmo-nitb -c ~/trybsc.cfg -l hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM <0005> bsc_init.c:498 VTY at 127.0.0.1 4242 <0005> bsc_init.c:427 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! <0005> bsc_hack.c:318 CTRL at 127.0.0.1 4249 DB: Database initialized. DB: Database prepared. <0005> abis_nm.c:316 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:1768 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:316 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) <0005> abis_nm.c:1449 Set BTS Attr (bts=0) <0005> abis_nm.c:1768 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART <0005> abis_nm.c:316 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) <0005> abis_nm.c:316 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) <0005> abis_nm.c:316 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) <0005> abis_nm.c:316 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) <0005> abis_nm.c:1768 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1466 Set TRX Attr (bts=0,trx=0) <0005> abis_nm.c:1768 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1768 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:2587 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=0) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=1) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=2) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=3) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=4) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=5) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=6) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=7) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART <0005> abis_nm.c:316 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:2429 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK <0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 100 using MCC=416 MNC=77 LAC=1 CID=0 BSIC=63 <0003> system_information.c:525 Serving cell: 100 <0003> bsc_init.c:104 SI1: 55 06 19 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b <0003> bsc_init.c:104 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 <0003> bsc_init.c:104 SI3: 49 06 1b 00 00 14 f6 77 00 01 49 03 05 27 53 40 e5 04 00 39 2b 2b 2b <0003> bsc_init.c:104 SI4: 31 06 1c 14 f6 77 00 01 53 40 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0003> bsc_init.c:104 SI5: 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b <0003> bsc_init.c:104 SI6: 2d 06 1e 00 00 14 f6 77 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0000> chan_alloc.c:367 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(100) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=3 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0000> chan_alloc.c:367 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=1 as SDCCH <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=0,ss=1) Activating ARFCN(100) SS(1) lctype SDCCH r=OTHER ra=0x1f ta=2 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=0,ss=1) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=0,ss=0) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=0,ss=1) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=0,ss=1) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=PAGING ra=0x37 ta=0 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=CALL ra=0xc4 ta=5 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=OTHER ra=0x51 ta=1 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE ************************************************************************************************************************************************ ************************************************************************************************************************************************ Part of osmo-bts-trx output: :375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611408 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611412 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611412 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1611449 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1611449 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611453 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611453 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611459 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611459 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611463 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611463 ts=0 trx=0 9 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613809 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1613846 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1613846 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613850 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613850 ts=0 trx=0 7 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616247 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616253 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616253 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616257 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616257 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1616294 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1616294 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616298 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616298 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616304 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616304 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616308 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616308 ts=0 trx=0 <0006> scheduler_trx.c:1517 GSM clock jitter: -2556 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613856 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613856 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613860 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613860 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1613897 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1613897 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613901 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613901 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613907 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613907 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613911 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613911 ts=0 trx=0 Thanks Abdulghafar

7 years, 7 months

3
3
0 0

OsmoBTS -> libosmogsm code migration

by Vadim Yanitskiy

Dear all, We recently discussed with Harald, that there is a lot of code related to GSM L1 should be migrated from OsmoBTS to libosmogsm. The reason is that it would be better to have one shared implementation of the convolutional codes, mapping, interleaving, etc., because then in near future it can be used not only from OsmoBTS, but also from OsmocomBB and even from foreign projects, such as GR-GSM. I just started to work on this direction, and found that there is already some code, related to the conventional codes, in libosmogsm. But unlike OsmoBTS, where all the tables can be found within the single file named 'gsm0503_conv.c', these tables appears in separate files during building process. So, I have several questions: 1) Which approach is better to use? To store everything in a single file or to use auto generation (utils/conv_gen.py)? 2) What about the copyright? I have not seen any license/author info at the top pf these files. Who is the author? Also, there is the 'gsm0503_coding.c' file, which uses the following external dependences: * The DL1C logging category, which isn't defined in libosmocore; * The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h' as well. So, there is regarding questions: 3) Which logging category it would be better to use after migration? 4) What to do with the 'osmo-bts/gsm_data.h'? 5) I don't think, that it's a good way to require something from the OpenBSC sources during OsmoBTS build... How can we change it? With best regards, Vadim Yanitskiy.

7 years, 7 months

4
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2016