OpenBSC September 2016

openbsc@lists.osmocom.org

19 participants
24 discussions

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

8 years, 9 months

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

8 years, 9 months

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

8 years, 9 months

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.

8 years, 9 months

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

8 years, 9 months

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.

8 years, 9 months

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

8 years, 9 months

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

8 years, 9 months

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!

8 years, 9 months

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

8 years, 9 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2016