From jerlbeck at sysmocom.de Mon Nov 10 07:27:15 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Mon, 10 Nov 2014 08:27:15 +0100 Subject: [PATCH] bssgp: Fix VTY command 'show bssgp nsei N' Message-ID: <1415604435-10732-1-git-send-email-jerlbeck@sysmocom.de> Currently this command segfaults (at least when ASAN is enabled), because when getting the NSEI the index to argv is wrong and out of bounds. This patch fixes the offset. Sponsored-by: On-Waves ehf --- src/gb/gprs_bssgp_vty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gb/gprs_bssgp_vty.c b/src/gb/gprs_bssgp_vty.c index 656c05e..88ae49f 100644 --- a/src/gb/gprs_bssgp_vty.c +++ b/src/gb/gprs_bssgp_vty.c @@ -135,7 +135,7 @@ DEFUN(show_bvc, show_bvc_cmd, "show bssgp nsei <0-65535> [stats]", "The NSEI\n" "Include Statistics\n") { struct bssgp_bvc_ctx *bvc; - uint16_t nsei = atoi(argv[1]); + uint16_t nsei = atoi(argv[0]); int show_stats = 0; if (argc >= 2) -- 1.9.1 From jerlbeck at sysmocom.de Mon Nov 10 07:30:31 2014 From: jerlbeck at sysmocom.de (Jacob Erlbeck) Date: Mon, 10 Nov 2014 08:30:31 +0100 Subject: [PATCH] bsc: Fix use-after-free on OML NM messages from the BTS Message-ID: <1415604631-10795-1-git-send-email-jerlbeck@sysmocom.de> Currently the sign_link pointer is dereferenced after a call to osmo_signal_dispatch, which can indirectly call e1inp_sign_link_destroy. If that happens, accessing *sign_link is illegal and can lead to a segmentation violation. Since only the bts pointer is needed from sign_link after the call to osmo_signal_dispatch, this patch changes abis_nm_rcvmsg_fom to save that pointer to a local variable earlier. Addresses: <0019> input/ipa.c:250 accept()ed new link from 192.168.1.101 to port 3002 SET ATTR NACK CAUSE=Message cannot be performed <0005> bsc_init.c:52 Got a NACK going to drop the OML links. <001b> bsc_init.c:319 Lost some E1 TEI link: 1 0xb351a830 ================================================================= ==13198== ERROR: AddressSanitizer: heap-use-after-free on address 0xb5d1bc70 at pc 0x80a6e3d bp 0xbfbb33d8 sp 0xbfbb33cc Sponsored-by: On-Waves ehf --- openbsc/src/libbsc/abis_nm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/openbsc/src/libbsc/abis_nm.c b/openbsc/src/libbsc/abis_nm.c index 3bf55ec..89ffea4 100644 --- a/openbsc/src/libbsc/abis_nm.c +++ b/openbsc/src/libbsc/abis_nm.c @@ -565,6 +565,8 @@ static int abis_nm_rcvmsg_fom(struct msgb *mb) struct abis_om_fom_hdr *foh = msgb_l3(mb); struct e1inp_sign_link *sign_link = mb->dst; uint8_t mt = foh->msg_type; + /* sign_link might get deleted via osmo_signal_dispatch -> save bts */ + struct gsm_bts *bts = sign_link->trx->bts; int ret = 0; /* check for unsolicited message */ @@ -593,7 +595,7 @@ static int abis_nm_rcvmsg_fom(struct msgb *mb) nack_data.mt = mt; nack_data.bts = sign_link->trx->bts; osmo_signal_dispatch(SS_NM, S_NM_NACK, &nack_data); - abis_nm_queue_send_next(sign_link->trx->bts); + abis_nm_queue_send_next(bts); return 0; } #if 0 @@ -636,7 +638,7 @@ static int abis_nm_rcvmsg_fom(struct msgb *mb) break; } - abis_nm_queue_send_next(sign_link->trx->bts); + abis_nm_queue_send_next(bts); return ret; } -- 1.9.1 From ciaby at autistici.org Mon Nov 10 18:16:47 2014 From: ciaby at autistici.org (Ciaby) Date: Mon, 10 Nov 2014 12:16:47 -0600 Subject: Possible crash/malfunction in the handover code Message-ID: <5461010F.8070702@autistici.org> We have been experiencing problems with osmo-nitb since we enabled handover. Sometimes osmo-nitb crashes, and our users have reported the fact that sometimes they end up listening to someone's else conversation. This started to happen since we enabled handover. This is the backtrace i got from a core dump of osmo-nitb: (gdb) bt #0 subscr_name (subscr=0x0) at gsm_subscriber_base.c:47 #1 0x00000000004079e3 in ho_gsm48_ho_compl (new_lchan=0x7fb1a80dd0b0) at handover_logic.c:259 #2 ho_logic_sig_cb (signal_data=, signal=, subsys=, handler_data=) at handover_logic.c:353 #3 ho_logic_sig_cb (subsys=, signal=, handler_data=, signal_data=) at handover_logic.c:335 #4 0x00007fb1a76dccec in osmo_signal_dispatch (subsys=4, signal=3, signal_data=0x7ffffe668090) at signal.c:105 #5 0x0000000000408d25 in handle_rr_ho_compl (msg=) at bsc_api.c:524 #6 dispatch_dtap (msg=0x2436980, link_id=, conn=0xc8e070) at bsc_api.c:583 #7 gsm0408_rcvmsg (msg=0x2436980, link_id=) at bsc_api.c:657 #8 0x000000000041fde1 in abis_rsl_rx_rll (msg=0x2436980) at abis_rsl.c:1682 #9 abis_rsl_rcvmsg (msg=0x2436980) at abis_rsl.c:2093 #10 0x00007fb1a74cce5a in handle_ts1_read (bfd=0x90d6b8) at input/ipaccess.c:469 #11 ipaccess_fd_cb (bfd=0x90d6b8, what=1) at input/ipaccess.c:603 #12 0x00007fb1a76dca11 in osmo_select_main (polling=0) at select.c:158 #13 0x0000000000406e34 in main (argc=, argv=0x7ffffe6684f8) at bsc_hack.c:354 Any clue about why this is happening? Cheers Ciaby From ciaby at autistici.org Mon Nov 10 18:33:35 2014 From: ciaby at autistici.org (Ciaby) Date: Mon, 10 Nov 2014 12:33:35 -0600 Subject: [PATCH] Fix debian packaging Message-ID: <546104FF.8060301@autistici.org> - Added debian/libosmosim0.install - Added libosmosim definition in debian/control --- debian/control | 6 ++++++ debian/libosmosim0.install | 1 + 2 files changed, 7 insertions(+) create mode 100644 debian/libosmosim0.install diff --git a/debian/control b/debian/control index cde3713..ccc7331 100644 --- a/debian/control +++ b/debian/control @@ -50,6 +50,12 @@ Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Description: Osmo control library +Package: libosmosim0 +Section: libs +Architecture: any +Depends: ${shlibs:Depends}, ${misc:Depends} +Description: Osmo SIM library + Package: libosmocore-dev Section: libdevel Architecture: any diff --git a/debian/libosmosim0.install b/debian/libosmosim0.install new file mode 100644 index 0000000..8f29c4d --- /dev/null +++ b/debian/libosmosim0.install @@ -0,0 +1 @@ +usr/lib/libosmosim*.so.* -- 1.7.9.5 From holger at freyther.de Mon Nov 10 19:44:00 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 10 Nov 2014 20:44:00 +0100 Subject: Possible crash/malfunction in the handover code In-Reply-To: <5461010F.8070702@autistici.org> References: <5461010F.8070702@autistici.org> Message-ID: <20141110194400.GU27444@xiaoyu.lan> On Mon, Nov 10, 2014 at 12:16:47PM -0600, Ciaby wrote: > Sometimes osmo-nitb crashes, and our users have reported the fact that sometimes they end up listening to someone's else conversation. ouch! > This started to happen since we enabled handover. > This is the backtrace i got from a core dump of osmo-nitb: > > (gdb) bt Can you please make a "bt full" so we see the values of structures > Any clue about why this is happening? Yes. "abnormal" condition. So somehow conn->subscr = NULL. This means the subscriber was never loaded from the database or what is more likely is that subscr_con_free has been called for the old channel. subscr_name(ho->old_lchan->conn->subscr) is crashing because subscr is 0x0. I wonder about the state of conn and the old_lchan in general. My guess would be that the old_lchan has already failed. holger From ciaby at autistici.org Mon Nov 10 20:10:46 2014 From: ciaby at autistici.org (Ciaby) Date: Mon, 10 Nov 2014 14:10:46 -0600 Subject: Possible crash/malfunction in the handover code In-Reply-To: <20141110194400.GU27444@xiaoyu.lan> References: <5461010F.8070702@autistici.org> <20141110194400.GU27444@xiaoyu.lan> Message-ID: <54611BC6.8060100@autistici.org> On 11/10/2014 01:44 PM, Holger Hans Peter Freyther wrote: > On Mon, Nov 10, 2014 at 12:16:47PM -0600, Ciaby wrote: > > >> Sometimes osmo-nitb crashes, and our users have reported the fact that sometimes they end up listening to someone's else conversation. > > ouch! > >> This started to happen since we enabled handover. >> This is the backtrace i got from a core dump of osmo-nitb: >> >> (gdb) bt > > Can you please make a "bt full" so we see the values of > structures > >> Any clue about why this is happening? > > Yes. "abnormal" condition. So somehow conn->subscr = NULL. This > means the subscriber was never loaded from the database or what > is more likely is that subscr_con_free has been called for the > old channel. > > subscr_name(ho->old_lchan->conn->subscr) > > is crashing because subscr is 0x0. I wonder about the state of > conn and the old_lchan in general. My guess would be that the > old_lchan has already failed. Here comes the "bt full" output: #0 subscr_name (subscr=0x0) at gsm_subscriber_base.c:47 No locals. #1 0x00000000004079e3 in ho_gsm48_ho_compl (new_lchan=0x7fb1a80dd0b0) at handover_logic.c:259 net = 0x894690 ho = 0xe1ccb0 #2 ho_logic_sig_cb (signal_data=, signal=, subsys=, handler_data=) at handover_logic.c:353 lchan = 0x7fb1a80dd0b0 #3 ho_logic_sig_cb (subsys=, signal=, handler_data=, signal_data=) at handover_logic.c:335 lchan_data = #4 0x00007fb1a76dccec in osmo_signal_dispatch (subsys=4, signal=3, signal_data=0x7ffffe668090) at signal.c:105 handler = 0x7af060 #5 0x0000000000408d25 in handle_rr_ho_compl (msg=) at bsc_api.c:524 sig = {lchan = 0x7fb1a80dd0b0, mr = 0x0} gh = #6 dispatch_dtap (msg=0x2436980, link_id=, conn=0xc8e070) at bsc_api.c:583 api = 0x6757c0 gh = pdisc = rc = #7 gsm0408_rcvmsg (msg=0x2436980, link_id=) at bsc_api.c:657 rc = api = 0x6757c0 lchan = 0x7fb1a80dd0b0 #8 0x000000000041fde1 in abis_rsl_rx_rll (msg=0x2436980) at abis_rsl.c:1682 rllh = 0x2436a0e ts_name = sign_link = rc = 0 sapi = #9 abis_rsl_rcvmsg (msg=0x2436980) at abis_rsl.c:2093 rslh = 0x2436a0e rc = 0 #10 0x00007fb1a74cce5a in handle_ts1_read (bfd=0x90d6b8) at input/ipaccess.c:469 line = 0x90cb00 link = hh = 0x2436a0b msg = 0x2436980 ret = ts_nr = 2 e1i_ts = 0x90d118 #11 ipaccess_fd_cb (bfd=0x90d6b8, what=1) at input/ipaccess.c:603 rc = 0 #12 0x00007fb1a76dca11 in osmo_select_main (polling=0) at select.c:158 flags = 1 ufd = 0x90d6b8 tmp = 0x8aa118 readset = {__fds_bits = {0 }} writeset = {__fds_bits = {0 }} exceptset = {__fds_bits = {0 }} work = 1 rc = no_time = {tv_sec = 0, tv_usec = 0} #13 0x0000000000406e34 in main (argc=, argv=0x7ffffe6684f8) at bsc_hack.c:354 rc = Cheers Ciaby From ciaby at autistici.org Mon Nov 10 20:19:23 2014 From: ciaby at autistici.org (Ciaby) Date: Mon, 10 Nov 2014 14:19:23 -0600 Subject: [PATCH] Fix debian packaging In-Reply-To: <546104FF.8060301@autistici.org> References: <546104FF.8060301@autistici.org> Message-ID: <54611DCB.40402@autistici.org> On 11/10/2014 12:33 PM, Ciaby wrote: [...] I forgot to mention this warnings at the end of the package generation: dpkg-shlibdeps: warning: symbol bssgp_prim_cb used by debian/libosmogb3/usr/lib/libosmogb.so.3.0.1 found in none of the libraries. dpkg-shlibdeps: warning: symbol ipa_msg_recv_buffered used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol vector_set used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol tall_vty_vec_ctx used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol vector_set_index used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol cmd_make_strvec used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol ipa_prepend_header used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol vector_free used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol ipa_prepend_header_ext used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol vector_lookup used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol vector_lookup_ensure used by debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: 2 other similar warnings have been skipped (use -v to see them all). dpkg-shlibdeps: warning: symbol msgb_length used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol talloc_strdup used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol msgb_alloc used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol gsm48_parse_ra used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol talloc_free used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol osmo_panic used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol _talloc_zero used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol osmo_hexdump used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol _talloc_memdup used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: symbol talloc_strndup used by debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the libraries. dpkg-shlibdeps: warning: 1 similar warning has been skipped (use -v to see it). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if "debian/libosmosim0/usr/lib/libosmosim.so.0.0.0" were not uselessly linked against it (they use none of its symbols). Can/should we do something about it? Cheers Ciaby From holger at freyther.de Mon Nov 10 20:19:23 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 10 Nov 2014 21:19:23 +0100 Subject: Possible crash/malfunction in the handover code In-Reply-To: <54611BC6.8060100@autistici.org> References: <5461010F.8070702@autistici.org> <20141110194400.GU27444@xiaoyu.lan> <54611BC6.8060100@autistici.org> Message-ID: <20141110201923.GC27444@xiaoyu.lan> On Mon, Nov 10, 2014 at 02:10:46PM -0600, Ciaby wrote: > #0 subscr_name (subscr=0x0) at gsm_subscriber_base.c:47 > No locals. > #1 0x00000000004079e3 in ho_gsm48_ho_compl (new_lchan=0x7fb1a80dd0b0) > at handover_logic.c:259 > net = 0x894690 > ho = 0xe1ccb0 frame 1 p *ho p *ho->old_lchan p *ho->old_lchan->conn does it work From ciaby at autistici.org Mon Nov 10 20:29:37 2014 From: ciaby at autistici.org (Ciaby) Date: Mon, 10 Nov 2014 14:29:37 -0600 Subject: Possible crash/malfunction in the handover code In-Reply-To: <20141110201923.GC27444@xiaoyu.lan> References: <5461010F.8070702@autistici.org> <20141110194400.GU27444@xiaoyu.lan> <54611BC6.8060100@autistici.org> <20141110201923.GC27444@xiaoyu.lan> Message-ID: <54612031.7020202@autistici.org> On 11/10/2014 02:19 PM, Holger Hans Peter Freyther wrote: > On Mon, Nov 10, 2014 at 02:10:46PM -0600, Ciaby wrote: > >> #0 subscr_name (subscr=0x0) at gsm_subscriber_base.c:47 >> No locals. >> #1 0x00000000004079e3 in ho_gsm48_ho_compl (new_lchan=0x7fb1a80dd0b0) >> at handover_logic.c:259 >> net = 0x894690 >> ho = 0xe1ccb0 > > > frame 1 > p *ho > p *ho->old_lchan > p *ho->old_lchan->conn > > does it work > (gdb) frame 1 #1 0x00000000004079e3 in ho_gsm48_ho_compl (new_lchan=0x7fb1a80dd0b0) at handover_logic.c:259 259 in handover_logic.c (gdb) p *ho $3 = {list = {next = 0x66eba0, prev = 0x66eba0}, old_lchan = 0x7fb1a80fb128, new_lchan = 0x7fb1a80dd0b0, T3103 = {node = {rb_parent_color = 6785312, rb_right = 0x0, rb_left = 0x0}, list = {next = 0xe1cce8, prev = 0xe1cce8}, timeout = {tv_sec = 1415116971, tv_usec = 619112}, active = 1, cb = 0x407740 , data = 0xe1ccb0}, ho_ref = 92 '\\'} (gdb) p *ho->old_lchan $1 = {ts = 0x7fb1a80fa020, nr = 0 '\000', type = GSM_LCHAN_TCH_F, rsl_cmode = RSL_CMOD_SPD_SIGN, tch_mode = GSM48_CMODE_SIGN, csd_mode = LCHAN_CSD_M_NT, state = LCHAN_S_ACTIVE, bs_power = 0 '\000', ms_power = 5 '\005', encr = {alg_id = 1 '\001', key_len = 0 '\000', key = '\000' }, mr_conf = { smod = 0 '\000', spare = 0 '\000', icmi = 0 '\000', nscb = 0 '\000', ver = 0 '\000', m4_75 = 0 '\000', m5_15 = 0 '\000', m5_90 = 0 '\000', m6_70 = 0 '\000', m7_40 = 0 '\000', m7_95 = 0 '\000', m10_2 = 0 '\000', m12_2 = 0 '\000'}, sapis = "\001\000\000\000\000\000\000", sacch_deact = 0, abis_ip = {bound_ip = 2886729995, connect_ip = 2886729985, bound_port = 50846, connect_port = 553, conn_id = 0, rtp_payload = 3 '\003', rtp_payload2 = 0 '\000', speech_mode = 0 '\000', rtp_socket = 0x0}, rqd_ta = 0 '\000', T3101 = {node = {rb_parent_color = 9338528, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x7fb1a80fb1b0, prev = 0x7fb1a80fb1b0}, timeout = {tv_sec = 1415116967, tv_usec = 917091}, active = 0, cb = 0x41f600 , data = 0x7fb1a80fb128}, T3109 = {node = { rb_parent_color = 6785313, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x7fb1a80fb200, prev = 0x7fb1a80fb200}, timeout = {tv_sec = 1415116956, tv_usec = 113590}, active = 0, cb = 0x41f310 , data = 0x7fb1a80fb128}, T3111 = {node = {rb_parent_color = 6785312, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x7fb1a80fb250, prev = 0x7fb1a80fb250}, timeout = {tv_sec = 1415116952, tv_usec = 273614}, active = 0, cb = 0x41f360 , data = 0x7fb1a80fb128}, error_timer = {node = {rb_parent_color = 8996937, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x7fb1a80fb2a0, prev = 0x7fb1a80fb2a0}, timeout = {tv_sec = 1415116278, tv_usec = 714886}, active = 0, cb = 0x41c910 , data = 0x7fb1a80fb128}, act_timer = {node = { rb_parent_color = 8996937, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x7fb1a80fb2f0, prev = 0x7fb1a80fb2f0}, timeout = {tv_sec = 1415116961, tv_usec = 906814}, active = 0, cb = 0x41b880 , data = 0x7fb1a80fb128}, rel_work = {node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0, data = 0x0}, error_cause = 0 '\000', neigh_meas = {{arfcn = 239, bsic = 63 '?', rxlev = "\r\t\024\024\024\026\026\026\026\027", rxlev_cnt = 58152, last_seen_nr = 6 '\006'}, {arfcn = 0, bsic = 63 '?', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 332, last_seen_nr = 20 '\024'}, {arfcn = 0, bsic = 0 '\000', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 0, last_seen_nr = 0 '\000'}, {arfcn = 0, bsic = 0 '\000', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 0, last_seen_nr = 0 '\000'}, {arfcn = 0, bsic = 0 '\000', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 0, last_seen_nr = 0 '\000'}, {arfcn = 0, bsic = 0 '\000', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 0, last_seen_nr = 0 '\000'}, {arfcn = 0, bsic = 0 '\000', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 0, last_seen_nr = 0 '\000'}, {arfcn = 0, bsic = 0 '\000', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 0, last_seen_nr = 0 '\000'}, {arfcn = 0, bsic = 0 '\000', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 0, last_seen_nr = 0 '\000'}, {arfcn = 0, bsic = 0 '\000', rxlev = "\000\000\000\000\000\000\000\000\000", rxlev_cnt = 0, last_seen_nr = 0 '\000'}}, meas_rep = {{lchan = 0x7fb1a80fb128, nr = 6 '\006', flags = 34, ul = { full = {rx_lev = 13 '\r', rx_qual = 0 '\000'}, sub = {rx_lev = 63 '?', rx_qual = 0 '\000'}}, dl = {full = {rx_lev = 3 '\003', rx_qual = 5 '\005'}, sub = { rx_lev = 4 '\004', rx_qual = 6 '\006'}}, bs_power = 0 '\000', ms_timing_offset = 0 '\000', ms_l1 = {pwr = 33 '!', ta = 12 '\f'}, num_cell = 1, cell = {{ rxlev = 9 '\t', bsic = 63 '?', neigh_idx = 2 '\002', arfcn = 239, flags = 1}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}}}, {lchan = 0x7fb1a80fb128, nr = 1 '\001', flags = 34, ul = {full = {rx_lev = 21 '\025', rx_qual = 0 '\000'}, sub = {rx_lev = 63 '?', rx_qual = 0 '\000'}}, dl = {full = {rx_lev = 22 '\026', rx_qual = 0 '\000'}, sub = {rx_lev = 22 '\026', rx_qual = 0 '\000'}}, bs_power = 0 '\000', ms_timing_offset = 0 '\000', ms_l1 = {pwr = 33 '!', ta = 12 '\f'}, num_cell = 1, cell = {{rxlev = 22 '\026', bsic = 63 '?', neigh_idx = 2 '\002', arfcn = 239, flags = 1}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}}}, {lchan = 0x7fb1a80fb128, nr = 2 '\002', flags = 34, ul = {full = {rx_lev = 20 '\024', rx_qual = 0 '\000'}, sub = {rx_lev = 63 '?', rx_qual = 0 '\000'}}, dl = {full = {rx_lev = 22 '\026', rx_qual = 0 '\000'}, sub = {rx_lev = 22 '\026', rx_qual = 0 '\000'}}, bs_power = 0 '\000', ms_timing_offset = 0 '\000', ms_l1 = {pwr = 33 '!', ta = 12 '\f'}, num_cell = 1, cell = {{rxlev = 22 '\026', bsic = 63 '?', neigh_idx = 2 '\002', arfcn = 239, flags = 1}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}}}, {lchan = 0x7fb1a80fb128, nr = 3 '\003', flags = 34, ul = {full = {rx_lev = 21 '\025', rx_qual = 0 '\000'}, sub = {rx_lev = 63 '?', rx_qual = 0 '\000'}}, dl = {full = {rx_lev = 22 '\026', rx_qual = 0 '\000'}, sub = {rx_lev = 22 '\026', rx_qual = 0 '\000'}}, bs_power = 0 '\000', ms_timing_offset = 0 '\000', ms_l1 = {pwr = 33 '!', ta = 12 '\f'}, num_cell = 1, cell = {{rxlev = 22 '\026', bsic = 63 '?', neigh_idx = 2 '\002', arfcn = 239, flags = 1}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, { rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}}}, {lchan = 0x7fb1a80fb128, nr = 4 '\004', flags = 34, ul = {full = {rx_lev = 22 '\026', rx_qual = 0 '\000'}, sub = {rx_lev = 63 '?', rx_qual = 0 '\000'}}, dl = {full = {rx_lev = 23 '\027', rx_qual = 0 '\000'}, sub = {rx_lev = 22 '\026', rx_qual = 0 '\000'}}, bs_power = 0 '\000', ms_timing_offset = 0 '\000', ms_l1 = {pwr = 33 '!', ta = 12 '\f'}, num_cell = 1, cell = {{rxlev = 23 '\027', bsic = 63 '?', neigh_idx = 2 '\002', arfcn = 239, flags = 1}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}}}, {lchan = 0x7fb1a80fb128, nr = 5 '\005', flags = 34, ul = {full = {rx_lev = 16 '\020', rx_qual = 0 '\000'}, sub = {rx_lev = 63 '?', rx_qual = 0 '\000'}}, dl = {full = {rx_lev = 14 '\016', rx_qual = 0 '\000'}, sub = {rx_lev = 16 '\020', rx_qual = 0 '\000'}}, bs_power = 0 '\000', ms_timing_offset = 0 '\000', ms_l1 = {pwr = 33 '!', ta = 12 '\f'}, num_cell = 1, cell = {{rxlev = 13 '\r', bsic = 63 '?', neigh_idx = 2 '\002', arfcn = 239, flags = 1}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}, {rxlev = 0 '\000', bsic = 0 '\000', neigh_idx = 0 '\000', arfcn = 0, flags = 0}}}}, meas_rep_idx = 1, rqd_ref = 0x0, conn = 0xc8e070} (gdb) p *ho->old_lchan->conn $2 = {entry = {next = 0x66ebb0, prev = 0x66ebb0}, subscr = 0x0, expire_timer_stopped = 0 '\000', next_rp_ref = 0 '\000', loc_operation = 0x0, sec_operation = 0x0, anch_operation = 0x9ceed0, silent_call = 0, put_channel = 0, sccp_con = 0x0, in_release = 0, lchan = 0x7fb1a80fb128, ho_lchan = 0x7fb1a80dd0b0, bts = 0x8a3290, T10 = { node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0, data = 0x0}, secondary_lchan = 0x0} Cheers Ciaby From holger at freyther.de Mon Nov 10 21:57:07 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 10 Nov 2014 22:57:07 +0100 Subject: Possible crash/malfunction in the handover code In-Reply-To: <54612031.7020202@autistici.org> References: <5461010F.8070702@autistici.org> <20141110194400.GU27444@xiaoyu.lan> <54611BC6.8060100@autistici.org> <20141110201923.GC27444@xiaoyu.lan> <54612031.7020202@autistici.org> Message-ID: <20141110215707.GH27444@xiaoyu.lan> On Mon, Nov 10, 2014 at 02:29:37PM -0600, Ciaby wrote: > (gdb) p *ho->old_lchan > $1 = {ts = 0x7fb1a80fa020, nr = 0 '\000', type = GSM_LCHAN_TCH_F, rsl_cmode = RSL_CMOD_SPD_SIGN, tch_mode = GSM48_CMODE_SIGN, csd_mode = LCHAN_CSD_M_NT, > state = LCHAN_S_ACTIVE, bs_power = 0 '\000', ms_power = 5 '\005', encr = {alg_id = 1 '\001', key_len = 0 '\000', key = '\000' }, mr_conf = { > (gdb) p *ho->old_lchan->conn > $2 = {entry = {next = 0x66ebb0, prev = 0x66ebb0}, subscr = 0x0, expire_timer_stopped = 0 '\000', next_rp_ref = 0 '\000', loc_operation = 0x0, sec_operation = 0x0, > anch_operation = 0x9ceed0, silent_call = 0, put_channel = 0, sccp_con = 0x0, in_release = 0, lchan = 0x7fb1a80fb128, ho_lchan = 0x7fb1a80dd0b0, bts = 0x8a3290, T10 = { > node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0, data = 0x0}, > secondary_lchan = 0x0} a.) The lchan has been re-used and "old_lchan" is already for someone new. b.) We start the handover too early. E.g. while still trying to determine the subscriber? diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c index 22f9883..d7e1a16 100644 --- a/openbsc/src/libbsc/handover_logic.c +++ b/openbsc/src/libbsc/handover_logic.c @@ -93,6 +93,9 @@ int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts) if (bsc_ho_by_old_lchan(old_lchan)) return -EBUSY; + if (!old_lchan->conn->subscr) + return -EBUSY; + DEBUGP(DHO, "(old_lchan on BTS %u, new BTS %u)\n", old_lchan->ts->trx->bts->nr, bts->nr); this would be a band-aid and it would be interesting if you still see the crash. From holger at freyther.de Mon Nov 10 21:42:48 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 10 Nov 2014 22:42:48 +0100 Subject: [PATCH] Fix debian packaging In-Reply-To: <54611DCB.40402@autistici.org> References: <546104FF.8060301@autistici.org> <54611DCB.40402@autistici.org> Message-ID: <20141110214248.GG27444@xiaoyu.lan> On Mon, Nov 10, 2014 at 02:19:23PM -0600, Ciaby wrote: > On 11/10/2014 12:33 PM, Ciaby wrote: > [...] > I forgot to mention this warnings at the end of the package generation: > > dpkg-shlibdeps: warning: symbol bssgp_prim_cb used by > debian/libosmogb3/usr/lib/libosmogb.so.3.0.1 found in none of the libraries. by design... so far. > debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the > dpkg-shlibdeps: warning: symbol ipa_msg_recv_buffered used by it should link to ?? for it. > dpkg-shlibdeps: warning: symbol vector_set used by > dpkg-shlibdeps: warning: symbol tall_vty_vec_ctx used by it should link against libosmovty for it. > dpkg-shlibdeps: warning: 2 other similar warnings have been skipped (use > -v to see them all). > dpkg-shlibdeps: warning: symbol msgb_length used by > debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the it should link to libosmocore > Can/should we do something about it? yes. these are issues and violations of link to DSOs that are used principle. From ciaby at autistici.org Mon Nov 10 22:43:46 2014 From: ciaby at autistici.org (Ciaby) Date: Mon, 10 Nov 2014 16:43:46 -0600 Subject: Possible crash/malfunction in the handover code In-Reply-To: <20141110215707.GH27444@xiaoyu.lan> References: <5461010F.8070702@autistici.org> <20141110194400.GU27444@xiaoyu.lan> <54611BC6.8060100@autistici.org> <20141110201923.GC27444@xiaoyu.lan> <54612031.7020202@autistici.org> <20141110215707.GH27444@xiaoyu.lan> Message-ID: <54613FA2.4030403@autistici.org> On 11/10/2014 03:57 PM, Holger Hans Peter Freyther wrote: [...] > a.) The lchan has been re-used and "old_lchan" is already for someone > new. > b.) We start the handover too early. E.g. while still trying to > determine the subscriber? > > diff --git a/openbsc/src/libbsc/handover_logic.c b/openbsc/src/libbsc/handover_logic.c > index 22f9883..d7e1a16 100644 > --- a/openbsc/src/libbsc/handover_logic.c > +++ b/openbsc/src/libbsc/handover_logic.c > @@ -93,6 +93,9 @@ int bsc_handover_start(struct gsm_lchan *old_lchan, struct gsm_bts *bts) > if (bsc_ho_by_old_lchan(old_lchan)) > return -EBUSY; > > + if (!old_lchan->conn->subscr) > + return -EBUSY; > + > DEBUGP(DHO, "(old_lchan on BTS %u, new BTS %u)\n", > old_lchan->ts->trx->bts->nr, bts->nr); > > > this would be a band-aid and it would be interesting if you still see > the crash. Thanks! I'll apply it to the current version we use, deploy it and see if we still see the same issue. Cheers Ciaby From ciaby at autistici.org Tue Nov 11 00:17:48 2014 From: ciaby at autistici.org (Ciaby) Date: Mon, 10 Nov 2014 18:17:48 -0600 Subject: [PATCH] Fix debian packaging In-Reply-To: <20141110214248.GG27444@xiaoyu.lan> References: <546104FF.8060301@autistici.org> <54611DCB.40402@autistici.org> <20141110214248.GG27444@xiaoyu.lan> Message-ID: <546155AC.4070606@autistici.org> On 11/10/2014 03:42 PM, Holger Hans Peter Freyther wrote: > On Mon, Nov 10, 2014 at 02:19:23PM -0600, Ciaby wrote: >> On 11/10/2014 12:33 PM, Ciaby wrote: >> [...] >> I forgot to mention this warnings at the end of the package generation: >> >> dpkg-shlibdeps: warning: symbol bssgp_prim_cb used by >> debian/libosmogb3/usr/lib/libosmogb.so.3.0.1 found in none of the libraries. > > > by design... so far. > > >> debian/libosmoctrl0/usr/lib/libosmoctrl.so.0.0.0 found in none of the >> dpkg-shlibdeps: warning: symbol ipa_msg_recv_buffered used by > > it should link to ?? for it. > >> dpkg-shlibdeps: warning: symbol vector_set used by >> dpkg-shlibdeps: warning: symbol tall_vty_vec_ctx used by > > it should link against libosmovty for it. > > >> dpkg-shlibdeps: warning: 2 other similar warnings have been skipped (use >> -v to see them all). >> dpkg-shlibdeps: warning: symbol msgb_length used by >> debian/libosmosim0/usr/lib/libosmosim.so.0.0.0 found in none of the > > it should link to libosmocore > >> Can/should we do something about it? > > yes. these are issues and violations of link to DSOs that are used > principle. Ok, sounds good. Is the patch good enough to be merged? :) Cheers Ciaby From holger at freyther.de Tue Nov 11 05:19:50 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 11 Nov 2014 06:19:50 +0100 Subject: [PATCH] Fix debian packaging In-Reply-To: <546155AC.4070606@autistici.org> References: <546104FF.8060301@autistici.org> <54611DCB.40402@autistici.org> <20141110214248.GG27444@xiaoyu.lan> <546155AC.4070606@autistici.org> Message-ID: <20141111051950.GI27444@xiaoyu.lan> On Mon, Nov 10, 2014 at 06:17:48PM -0600, Ciaby wrote: > Ok, sounds good. Is the patch good enough to be merged? :) It is already merged. :) > From ciaby at autistici.org Mon Nov 10 17:08:50 2014 From: ciaby at autistici.org (Ciaby) Date: Mon, 10 Nov 2014 11:08:50 -0600 Subject: Possible crash/malfunction in the handover code Message-ID: <5460F122.9040105@autistici.org> We have been experiencing problems with osmo-nitb since we enabled handover. Sometimes osmo-nitb crashes, and our users have reported the fact that sometimes they end up listening to someone's else conversation. This started to happen since we enabled handover. This is the backtrace i got from a core dump of osmo-nitb: (gdb) bt #0 subscr_name (subscr=0x0) at gsm_subscriber_base.c:47 #1 0x00000000004079e3 in ho_gsm48_ho_compl (new_lchan=0x7fb1a80dd0b0) at handover_logic.c:259 #2 ho_logic_sig_cb (signal_data=, signal=, subsys=, handler_data=) at handover_logic.c:353 #3 ho_logic_sig_cb (subsys=, signal=, handler_data=, signal_data=) at handover_logic.c:335 #4 0x00007fb1a76dccec in osmo_signal_dispatch (subsys=4, signal=3, signal_data=0x7ffffe668090) at signal.c:105 #5 0x0000000000408d25 in handle_rr_ho_compl (msg=) at bsc_api.c:524 #6 dispatch_dtap (msg=0x2436980, link_id=, conn=0xc8e070) at bsc_api.c:583 #7 gsm0408_rcvmsg (msg=0x2436980, link_id=) at bsc_api.c:657 #8 0x000000000041fde1 in abis_rsl_rx_rll (msg=0x2436980) at abis_rsl.c:1682 #9 abis_rsl_rcvmsg (msg=0x2436980) at abis_rsl.c:2093 #10 0x00007fb1a74cce5a in handle_ts1_read (bfd=0x90d6b8) at input/ipaccess.c:469 #11 ipaccess_fd_cb (bfd=0x90d6b8, what=1) at input/ipaccess.c:603 #12 0x00007fb1a76dca11 in osmo_select_main (polling=0) at select.c:158 #13 0x0000000000406e34 in main (argc=, argv=0x7ffffe6684f8) at bsc_hack.c:354 Any clue about why this is happening? Cheers Ciaby From ciaby at autistici.org Fri Nov 14 00:00:41 2014 From: ciaby at autistici.org (Ciaby) Date: Thu, 13 Nov 2014 18:00:41 -0600 Subject: Failing test suite (gbproxy) Message-ID: <54654629.7030600@autistici.org> I'm trying to build debian packages of OpenBSC. The test suite is failing on the gbproxy test (core dump). Attached is the testsuite.log file. Cheers Ciaby -------------- next part -------------- A non-text attachment was scrubbed... Name: testsuite.log Type: text/x-log Size: 279288 bytes Desc: not available URL: From holger at freyther.de Fri Nov 14 07:11:12 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 14 Nov 2014 08:11:12 +0100 Subject: Failing test suite (gbproxy) In-Reply-To: <54654629.7030600@autistici.org> References: <54654629.7030600@autistici.org> Message-ID: <20141114071112.GB11871@xiaoyu.lan> On Thu, Nov 13, 2014 at 06:00:41PM -0600, Ciaby wrote: > I'm trying to build debian packages of OpenBSC. The test suite is > failing on the gbproxy test (core dump). Attached is the testsuite.log file. > Cheers > > -NS UNITDATA MESSAGE to SGSN, BVCI 0x0000, msg length 10 (gprs_ns_sendmsg) > MESSAGE to SGSN at 0x05060708:32000, msg length 14 > 00 00 00 00 41 07 81 05 04 82 10 ff 15 80 Odd. I assume you are using the latest version of libosmocore and such. The test is being executed on the jenkins too (on ia32 systems though). a.) libtool --mode=execute gdb the_test. If you set a breakpoint in gprs_ns_sendmsg and execute the test. Do you end in the version inside libosmocore or the mocked version of the test? b.) If you execute the test with valgrind or compile with ASAN. Does it fail as well? holger From meskio at sindominio.net Sat Nov 15 00:47:40 2014 From: meskio at sindominio.net (Ruben Pollan) Date: Fri, 14 Nov 2014 18:47:40 -0600 Subject: [PATCH] Configure the auth token sms text in the database Message-ID: <1416012460-21616-1-git-send-email-meskio@sindominio.net> --- openbsc/include/openbsc/db.h | 2 ++ openbsc/src/libmsc/db.c | 77 +++++++++++++++++++++++++++++++++++++++- openbsc/src/libmsc/token_auth.c | 7 ++-- openbsc/src/osmo-nitb/bsc_hack.c | 5 +++ 4 files changed, 86 insertions(+), 5 deletions(-) diff --git a/openbsc/include/openbsc/db.h b/openbsc/include/openbsc/db.h index 6699a86..348a627 100644 --- a/openbsc/include/openbsc/db.h +++ b/openbsc/include/openbsc/db.h @@ -79,4 +79,6 @@ int db_store_counter(struct osmo_counter *ctr); struct rate_ctr_group; int db_store_rate_ctr_group(struct rate_ctr_group *ctrg); +char * db_get_text(const char *key); + #endif /* _DB_H */ diff --git a/openbsc/src/libmsc/db.c b/openbsc/src/libmsc/db.c index 656c661..1e8f000 100644 --- a/openbsc/src/libmsc/db.c +++ b/openbsc/src/libmsc/db.c @@ -45,11 +45,13 @@ static char *db_basename = NULL; static char *db_dirname = NULL; static dbi_conn conn; -#define SCHEMA_REVISION "4" +#define SCHEMA_REVISION "5" enum { SCHEMA_META, INSERT_META, + SCHEMA_TEXT, + INSERT_TEXT, SCHEMA_SUBSCRIBER, SCHEMA_AUTH, SCHEMA_EQUIPMENT, @@ -73,6 +75,16 @@ static const char *create_stmts[] = { "(key, value) " "VALUES " "('revision', " SCHEMA_REVISION ")", + [SCHEMA_TEXT] = "CREATE TABLE IF NOT EXISTS Text (" + "id INTEGER PRIMARY KEY AUTOINCREMENT, " + "key TEXT UNIQUE NOT NULL, " + "value TEXT NOT NULL" + ")", + [INSERT_TEXT] = "INSERT OR IGNORE INTO Text " + "(key, value) " + "VALUES " + "('auth_token_sms', 'Welcome to the GSM network. " + "Your IMSI is %s, auth token is %08X, phone no is %s.')", [SCHEMA_SUBSCRIBER] = "CREATE TABLE IF NOT EXISTS Subscriber (" "id INTEGER PRIMARY KEY AUTOINCREMENT, " "created TIMESTAMP NOT NULL, " @@ -367,6 +379,40 @@ rollback: return -EINVAL; } +static int update_db_revision_4(void) +{ + dbi_result result; + + result = dbi_conn_query(conn, create_stmts[SCHEMA_TEXT]); + if (!result) { + LOGP(DDB, LOGL_ERROR, + "Failed to create Text table (upgrade from rev 4).\n"); + return -EINVAL; + } + dbi_result_free(result); + + result = dbi_conn_query(conn, create_stmts[INSERT_TEXT]); + if (!result) { + LOGP(DDB, LOGL_ERROR, + "Failed to inserting Text (upgrade from rev 4).\n"); + return -EINVAL; + } + dbi_result_free(result); + + result = dbi_conn_query(conn, + "UPDATE Meta " + "SET value = '5' " + "WHERE key = 'revision'"); + if (!result) { + LOGP(DDB, LOGL_ERROR, + "Failed to update DB schema revision (upgrade from rev 4).\n"); + return -EINVAL; + } + dbi_result_free(result); + + return 0; +} + static int check_db_revision(void) { dbi_result result; @@ -398,6 +444,12 @@ static int check_db_revision(void) dbi_result_free(result); return -EINVAL; } + } else if (!strcmp(rev_s, "4")) { + if (update_db_revision_4()) { + LOGP(DDB, LOGL_FATAL, "Failed to update database from schema revision '%s'.\n", rev_s); + dbi_result_free(result); + return -EINVAL; + } } else if (!strcmp(rev_s, SCHEMA_REVISION)) { /* everything is fine */ } else { @@ -498,6 +550,29 @@ int db_fini(void) return 0; } +char * db_get_text(const char *key) { + dbi_result result; + const char * string; + char * text; + unsigned int len; + + result = dbi_conn_queryf(conn, + "SELECT value FROM Text WHERE key='%s'", key); + if (!result) + return NULL; + + if (!dbi_result_next_row(result)) { + dbi_result_free(result); + return NULL; + } + string = dbi_result_get_string(result, "value"); + text = talloc_strdup(NULL, string); + + dbi_result_free(result); + + return text; +} + struct gsm_subscriber *db_create_subscriber(const char *imsi) { dbi_result result; diff --git a/openbsc/src/libmsc/token_auth.c b/openbsc/src/libmsc/token_auth.c index 45b5a8e..3ee8564 100644 --- a/openbsc/src/libmsc/token_auth.c +++ b/openbsc/src/libmsc/token_auth.c @@ -29,20 +29,19 @@ #include #include -#define TOKEN_SMS_TEXT "HAR 2009 GSM. Register at http://har2009.gnumonks.org/ " \ - "Your IMSI is %s, auth token is %08X, phone no is %s." +extern char * auth_token_sms_text; static char *build_sms_string(struct gsm_subscriber *subscr, uint32_t token) { char *sms_str; unsigned int len; - len = strlen(subscr->imsi) + 8 + strlen(TOKEN_SMS_TEXT); + len = strlen(subscr->imsi) + 8 + strlen(auth_token_sms_text) + strlen(subscr->extension); sms_str = talloc_size(tall_bsc_ctx, len); if (!sms_str) return NULL; - snprintf(sms_str, len, TOKEN_SMS_TEXT, subscr->imsi, token, + snprintf(sms_str, len, auth_token_sms_text, subscr->imsi, token, subscr->extension); sms_str[len-1] = '\0'; diff --git a/openbsc/src/osmo-nitb/bsc_hack.c b/openbsc/src/osmo-nitb/bsc_hack.c index 031cb99..9d552c2 100644 --- a/openbsc/src/osmo-nitb/bsc_hack.c +++ b/openbsc/src/osmo-nitb/bsc_hack.c @@ -67,6 +67,9 @@ static int use_db_counter = 1; #define DB_SYNC_INTERVAL 60, 0 #define EXPIRE_INTERVAL 10, 0 +/* for token auth */ +char * auth_token_sms_text = ""; + static struct osmo_timer_list db_sync_timer; static void create_pcap_file(char *file) @@ -322,6 +325,8 @@ int main(int argc, char **argv) } printf("DB: Database prepared.\n"); + auth_token_sms_text = db_get_text("auth_token_sms"); + /* setup the timer */ db_sync_timer.cb = db_sync_timer_cb; db_sync_timer.data = NULL; -- 2.1.1 From holger at freyther.de Sat Nov 15 09:11:46 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 15 Nov 2014 10:11:46 +0100 Subject: [PATCH] Configure the auth token sms text in the database In-Reply-To: <1416012460-21616-1-git-send-email-meskio@sindominio.net> References: <1416012460-21616-1-git-send-email-meskio@sindominio.net> Message-ID: <20141115091146.GE23528@xiaoyu.lan> On Fri, Nov 14, 2014 at 06:47:40PM -0600, Ruben Pollan wrote: Good Morning, why does this need to go into the DB and not the configuration file? What is your stand on checking the configured string for the right amount of printf placeholders? holger From meskio at sindominio.net Sat Nov 15 20:03:31 2014 From: meskio at sindominio.net (Ruben Pollan) Date: Sat, 15 Nov 2014 14:03:31 -0600 Subject: [PATCH] Configure the auth token sms text in the database In-Reply-To: <20141115091146.GE23528@xiaoyu.lan> References: <1416012460-21616-1-git-send-email-meskio@sindominio.net> <20141115091146.GE23528@xiaoyu.lan> Message-ID: <20141115200331.26049.43667@KingMob> Good morning, Quoting Holger Hans Peter Freyther (2014-11-15 03:11:46) > why does this need to go into the DB and not the configuration > file? Our first attempt was to do it in the configuration file, but we realized that vty doesn't have support for strings with spaces. Or did we miss something? We decided that was easier to add it to the database than to extend vty to parse strings with " or other way to support spaces. > What is your stand on checking the configured string for > the right amount of printf placeholders? You are right, this is not great. After discussing it with ciaby we decided that might make more sense to do something like: snprintf(sms_str, len, "%s IMSI: %s Token: %08X Ext: %s" auth_token_sms_text, subscr->imsi, token, subscr->extension); So the auth_token_sms_text don't have any placeholders it's just the introductory text. What do you think? -- Ruben Pollan | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: signature URL: From meskio at sindominio.net Mon Nov 17 00:45:36 2014 From: meskio at sindominio.net (Ruben Pollan) Date: Sun, 16 Nov 2014 18:45:36 -0600 Subject: [PATCH] Configure the auth token sms text in the database In-Reply-To: <20141115200331.26049.43667@KingMob> References: <20141115200331.26049.43667@KingMob> Message-ID: <1416185136-11924-1-git-send-email-meskio@sindominio.net> --- openbsc/include/openbsc/db.h | 2 ++ openbsc/src/libmsc/db.c | 76 +++++++++++++++++++++++++++++++++++++++- openbsc/src/libmsc/token_auth.c | 18 +++++++--- openbsc/src/osmo-nitb/bsc_hack.c | 5 +++ 4 files changed, 95 insertions(+), 6 deletions(-) diff --git a/openbsc/include/openbsc/db.h b/openbsc/include/openbsc/db.h index 6699a86..348a627 100644 --- a/openbsc/include/openbsc/db.h +++ b/openbsc/include/openbsc/db.h @@ -79,4 +79,6 @@ int db_store_counter(struct osmo_counter *ctr); struct rate_ctr_group; int db_store_rate_ctr_group(struct rate_ctr_group *ctrg); +char * db_get_text(const char *key); + #endif /* _DB_H */ diff --git a/openbsc/src/libmsc/db.c b/openbsc/src/libmsc/db.c index 656c661..bac854c 100644 --- a/openbsc/src/libmsc/db.c +++ b/openbsc/src/libmsc/db.c @@ -45,11 +45,13 @@ static char *db_basename = NULL; static char *db_dirname = NULL; static dbi_conn conn; -#define SCHEMA_REVISION "4" +#define SCHEMA_REVISION "5" enum { SCHEMA_META, INSERT_META, + SCHEMA_TEXT, + INSERT_TEXT, SCHEMA_SUBSCRIBER, SCHEMA_AUTH, SCHEMA_EQUIPMENT, @@ -73,6 +75,15 @@ static const char *create_stmts[] = { "(key, value) " "VALUES " "('revision', " SCHEMA_REVISION ")", + [SCHEMA_TEXT] = "CREATE TABLE IF NOT EXISTS Text (" + "id INTEGER PRIMARY KEY AUTOINCREMENT, " + "key TEXT UNIQUE NOT NULL, " + "value TEXT NOT NULL" + ")", + [INSERT_TEXT] = "INSERT OR IGNORE INTO Text " + "(key, value) " + "VALUES " + "('auth_token_sms', 'Welcome to the GSM network.')", [SCHEMA_SUBSCRIBER] = "CREATE TABLE IF NOT EXISTS Subscriber (" "id INTEGER PRIMARY KEY AUTOINCREMENT, " "created TIMESTAMP NOT NULL, " @@ -367,6 +378,40 @@ rollback: return -EINVAL; } +static int update_db_revision_4(void) +{ + dbi_result result; + + result = dbi_conn_query(conn, create_stmts[SCHEMA_TEXT]); + if (!result) { + LOGP(DDB, LOGL_ERROR, + "Failed to create Text table (upgrade from rev 4).\n"); + return -EINVAL; + } + dbi_result_free(result); + + result = dbi_conn_query(conn, create_stmts[INSERT_TEXT]); + if (!result) { + LOGP(DDB, LOGL_ERROR, + "Failed to inserting Text (upgrade from rev 4).\n"); + return -EINVAL; + } + dbi_result_free(result); + + result = dbi_conn_query(conn, + "UPDATE Meta " + "SET value = '5' " + "WHERE key = 'revision'"); + if (!result) { + LOGP(DDB, LOGL_ERROR, + "Failed to update DB schema revision (upgrade from rev 4).\n"); + return -EINVAL; + } + dbi_result_free(result); + + return 0; +} + static int check_db_revision(void) { dbi_result result; @@ -398,6 +443,12 @@ static int check_db_revision(void) dbi_result_free(result); return -EINVAL; } + } else if (!strcmp(rev_s, "4")) { + if (update_db_revision_4()) { + LOGP(DDB, LOGL_FATAL, "Failed to update database from schema revision '%s'.\n", rev_s); + dbi_result_free(result); + return -EINVAL; + } } else if (!strcmp(rev_s, SCHEMA_REVISION)) { /* everything is fine */ } else { @@ -498,6 +549,29 @@ int db_fini(void) return 0; } +char * db_get_text(const char *key) { + dbi_result result; + const char * string; + char * text; + unsigned int len; + + result = dbi_conn_queryf(conn, + "SELECT value FROM Text WHERE key='%s'", key); + if (!result) + return NULL; + + if (!dbi_result_next_row(result)) { + dbi_result_free(result); + return NULL; + } + string = dbi_result_get_string(result, "value"); + text = talloc_strdup(NULL, string); + + dbi_result_free(result); + + return text; +} + struct gsm_subscriber *db_create_subscriber(const char *imsi) { dbi_result result; diff --git a/openbsc/src/libmsc/token_auth.c b/openbsc/src/libmsc/token_auth.c index 45b5a8e..80660dd 100644 --- a/openbsc/src/libmsc/token_auth.c +++ b/openbsc/src/libmsc/token_auth.c @@ -20,6 +20,7 @@ */ #include +#include #include #include #include @@ -29,23 +30,30 @@ #include #include -#define TOKEN_SMS_TEXT "HAR 2009 GSM. Register at http://har2009.gnumonks.org/ " \ - "Your IMSI is %s, auth token is %08X, phone no is %s." +extern char * auth_token_sms_text; + +#define TOKEN_SMS_FORMAT "%s IMSI: %s Token: %08X Ext: %s" static char *build_sms_string(struct gsm_subscriber *subscr, uint32_t token) { char *sms_str; unsigned int len; - len = strlen(subscr->imsi) + 8 + strlen(TOKEN_SMS_TEXT); + len = strlen(TOKEN_SMS_FORMAT) + strlen(subscr->imsi) + + strlen(auth_token_sms_text) + strlen(subscr->extension); sms_str = talloc_size(tall_bsc_ctx, len); if (!sms_str) return NULL; - snprintf(sms_str, len, TOKEN_SMS_TEXT, subscr->imsi, token, - subscr->extension); + snprintf(sms_str, len, TOKEN_SMS_FORMAT, auth_token_sms_text, subscr->imsi, + token, subscr->extension); sms_str[len-1] = '\0'; + if (strlen(sms_str) > 160) { + fprintf(stderr, "Token auth sms longer than 160 char: '%s'\n", sms_str); + exit(1); + } + return sms_str; } diff --git a/openbsc/src/osmo-nitb/bsc_hack.c b/openbsc/src/osmo-nitb/bsc_hack.c index 031cb99..9d552c2 100644 --- a/openbsc/src/osmo-nitb/bsc_hack.c +++ b/openbsc/src/osmo-nitb/bsc_hack.c @@ -67,6 +67,9 @@ static int use_db_counter = 1; #define DB_SYNC_INTERVAL 60, 0 #define EXPIRE_INTERVAL 10, 0 +/* for token auth */ +char * auth_token_sms_text = ""; + static struct osmo_timer_list db_sync_timer; static void create_pcap_file(char *file) @@ -322,6 +325,8 @@ int main(int argc, char **argv) } printf("DB: Database prepared.\n"); + auth_token_sms_text = db_get_text("auth_token_sms"); + /* setup the timer */ db_sync_timer.cb = db_sync_timer_cb; db_sync_timer.data = NULL; -- 2.1.1 From ciaby at autistici.org Thu Nov 20 17:56:59 2014 From: ciaby at autistici.org (Ciaby) Date: Thu, 20 Nov 2014 11:56:59 -0600 Subject: Problems with token mode Message-ID: <546E2B6B.6050604@autistici.org> Hi, It's me again :) We deployed the first installation with token mode, and we're running into a quite nasty issue: osmo-nitb does its job for a while, but then it goes to 100% cpu and it has to be killed. This doesn't happen in the lab, obviously, but it's happening in a village of about 10.000 people. Any clue? past experiences? Thanks! Ciaby From holger at freyther.de Thu Nov 20 22:57:31 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 20 Nov 2014 23:57:31 +0100 Subject: Problems with token mode In-Reply-To: <546E2B6B.6050604@autistici.org> References: <546E2B6B.6050604@autistici.org> Message-ID: <20141120225731.GB16093@xiaoyu.lan> On Thu, Nov 20, 2014 at 11:56:59AM -0600, Ciaby wrote: > Any clue? past experiences? The code has been written for the HAR2009 (which I didn't attend) so I have no experience with this code. Does it busy loop in one function or is the process just very busy? E.g. attach with gdb to the running process and do the bt full thing again? holger From holger at freyther.de Thu Nov 20 22:59:54 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 20 Nov 2014 23:59:54 +0100 Subject: [PATCH] Configure the auth token sms text in the database In-Reply-To: <20141115200331.26049.43667@KingMob> References: <1416012460-21616-1-git-send-email-meskio@sindominio.net> <20141115091146.GE23528@xiaoyu.lan> <20141115200331.26049.43667@KingMob> Message-ID: <20141120225953.GA16802@xiaoyu.lan> On Sat, Nov 15, 2014 at 02:03:31PM -0600, Ruben Pollan wrote: > Good morning, Good Evening! > You are right, this is not great. After discussing it with ciaby we decided that > might make more sense to do something like: > > snprintf(sms_str, len, "%s IMSI: %s Token: %08X Ext: %s" > auth_token_sms_text, subscr->imsi, token, subscr->extension); > > So the auth_token_sms_text don't have any placeholders it's just the > introductory text. What do you think? Yes, it would be missing i18n.. but so does the entire OpenBSC codebase. I would really prefer to set this through the VTY than to put it into a database. Using ".TEXT" inside the VTY command string you can match more than just a single word. I think '%' is still not possible though. holger From ciaby at autistici.org Fri Nov 21 00:25:34 2014 From: ciaby at autistici.org (Ciaby) Date: Thu, 20 Nov 2014 18:25:34 -0600 Subject: Problems with token mode In-Reply-To: <20141120225731.GB16093@xiaoyu.lan> References: <546E2B6B.6050604@autistici.org> <20141120225731.GB16093@xiaoyu.lan> Message-ID: <546E867E.3000107@autistici.org> On 11/20/2014 04:57 PM, Holger Hans Peter Freyther wrote: > On Thu, Nov 20, 2014 at 11:56:59AM -0600, Ciaby wrote: > >> Any clue? past experiences? > > The code has been written for the HAR2009 (which I didn't attend) so > I have no experience with this code. Does it busy loop in one function > or is the process just very busy? > > E.g. attach with gdb to the running process and do the bt full thing > again? (gdb) bt #0 0x00007f0b2de51663 in select () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f0b2e794a9a in osmo_select_main (polling=0) at select.c:128 #2 0x000000000040691c in main (argc=, argv=0x7fff87fea568) at bsc_hack.c:360 (gdb) bt full #0 0x00007f0b2de51663 in select () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x00007f0b2e794a9a in osmo_select_main (polling=0) at select.c:128 ufd = 0x7f0b2e9a52b0 tmp = readset = {__fds_bits = {258552, 0 }} writeset = {__fds_bits = {96, 0 }} exceptset = {__fds_bits = {0 }} work = 0 rc = no_time = {tv_sec = 0, tv_usec = 0} #2 0x000000000040691c in main (argc=, argv=0x7fff87fea568) at bsc_hack.c:360 rc = From holger at freyther.de Fri Nov 21 09:43:30 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 21 Nov 2014 10:43:30 +0100 Subject: [PATCH] vty: Check with the application before writing the config Message-ID: <1416563010-32684-1-git-send-email-holger@freyther.de> From: Holger Hans Peter Freyther For the BSC/NITB application we see that people modify the band without modifying the ARFCN. This creates an unbootable config. Using the new hook the BSC/NITB can check if the config is consistent and prevent the config file being written. Related: SYS#739 --- TODO-RELEASE | 1 + include/osmocom/vty/vty.h | 2 ++ src/vty/command.c | 9 +++++++++ 3 files changed, 12 insertions(+) diff --git a/TODO-RELEASE b/TODO-RELEASE index 72a27a4..290fb0e 100644 --- a/TODO-RELEASE +++ b/TODO-RELEASE @@ -1,2 +1,3 @@ #library what description / commit summary line libosmocore abi-change logging: Add ability to save/print current log filters +libosmovty abi-change vty: Check with the application before writing the config diff --git a/include/osmocom/vty/vty.h b/include/osmocom/vty/vty.h index ea02e4a..1dcc230 100644 --- a/include/osmocom/vty/vty.h +++ b/include/osmocom/vty/vty.h @@ -159,6 +159,8 @@ struct vty_app_info { enum node_type (*go_parent_cb)(struct vty *vty); /*! \brief call-back to determine if node is config node */ int (*is_config_node)(struct vty *vty, int node); + /*! \brief Check if the config is consistent before write */ + int (*config_is_consistent)(struct vty *vty); }; /* Prototypes. */ diff --git a/src/vty/command.c b/src/vty/command.c index 44a1b6c..3ff5f77 100644 --- a/src/vty/command.c +++ b/src/vty/command.c @@ -2497,6 +2497,15 @@ DEFUN(config_write_file, char *failed_file; int rc; + if (host.app_info->config_is_consistent) { + rc = host.app_info->config_is_consistent(vty); + if (!rc) { + vty_out(vty, "Configuration is not consistent%s", + VTY_NEWLINE); + return CMD_WARNING; + } + } + if (host.config == NULL) { vty_out(vty, "Can't save to configuration file, using vtysh.%s", VTY_NEWLINE); -- 2.1.3 From holger at freyther.de Fri Nov 21 09:51:35 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 21 Nov 2014 10:51:35 +0100 Subject: Problems with token mode In-Reply-To: <546E867E.3000107@autistici.org> References: <546E2B6B.6050604@autistici.org> <20141120225731.GB16093@xiaoyu.lan> <546E867E.3000107@autistici.org> Message-ID: <20141121095135.GQ4921@xiaoyu.lan> On Thu, Nov 20, 2014 at 06:25:34PM -0600, Ciaby wrote: > > E.g. attach with gdb to the running process and do the bt full thing > > again? > > (gdb) bt > #0 0x00007f0b2de51663 in select () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007f0b2e794a9a in osmo_select_main (polling=0) at select.c:128 well that is to be expected? But if the app takes 99% time if you manually sample with continue/CTRL+C/bt full. Where does it spend the time? Alternatively you can use "perf top -p `pidof osmo-nitb`" to have a better overview. From rs515794 at gmail.com Fri Nov 28 21:00:47 2014 From: rs515794 at gmail.com (ramesh shankar) Date: Fri, 28 Nov 2014 16:00:47 -0500 Subject: GPRS attach Message-ID: Hello Getting error on implementation of gprs cannot handle GMM for unknown MM CTX MS identity cannot be derived by the network can somebody suggest why and what can I do to fix it. log file for sgsn. <0010> gprs_ns.c:199 NSVCI=65534 Creating NS-VC <0010> gprs_ns.c:199 NSVCI=65535 Creating NS-VC <0010> gprs_ns.c:1200 Creating NS-VC for BSS at 192.168.2.12:23000 <0010> gprs_ns.c:774 NSVCI=65535(invalid) Rx NS RESET (NSEI=101, NSVCI=101, cause=O&M intervention) <0010> gprs_ns.c:594 NSEI=101 Tx NS RESET ACK (NSVCI=101) <0010> gprs_ns.c:512 NSEI=101 Starting timer in mode tns-test (30 seconds) <0010> gprs_ns.c:512 NSEI=101 Starting timer in mode tns-test (30 seconds) <0010> gprs_ns.c:1281 NSEI=101 Rx NS UNBLOCK <0011> gprs_bssgp.c:249 BSSGP BVCI=0 Rx RESET cause=Transmission capacity modified <0011> gprs_bssgp.c:344 BSSGP BVCI=2 Rx BVC-UNBLOCK <0011> gprs_bssgp_util.c:103 BSSGP BVCI=2 Tx STATUS, cause=Unknown BVCI <0011> gprs_bssgp.c:249 BSSGP BVCI=2 Rx RESET cause=O&M intervention <0011> gprs_bssgp.c:272 Cell 302-720-7-0 CI 8 on BVCI 2 <0011> gprs_bssgp.c:344 BSSGP BVCI=2 Rx BVC-UNBLOCK <0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC <0011> gprs_bssgp.c:790 BSS instructs us to MS default bucket leak rate != 0, restarting DL GPRS! <0011> gprs_bssgp.c:376 BSSGP TLLI=0xb4c2fd41 Rx UPLINK-UNITDATA <0012> gprs_llc.c:568 LLC SAPI=1 C FCS=0x7439ebCMD=UI DATA <0012> gprs_llc.c:95 TLLI 0xb4c2fd41 is foreign, converting to local TLLI 0xf4c2fd41 <0012> gprs_llc.c:95 TLLI 0xb4c2fd41 is foreign, converting to local TLLI 0xf4c2fd41 <0012> gprs_llc.c:254 LLC RX: unknown TLLI 0xb4c2fd41, creating LLME on the fly <0002> gprs_gmm.c:924 -> GMM RA UPDATE REQUEST type="RA updating" LLC XID RESET REJECT <0002> gprs_gmm.c:861 <- ROUTING AREA UPDATE REJECT <0012> gprs_llc.c:95 TLLI 0xb4c2fd41 is foreign, converting to local TLLI 0xf4c2fd41 <0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC <0011> gprs_bssgp.c:376 BSSGP TLLI=0xb4c2fd41 Rx UPLINK-UNITDATA <0012> gprs_llc.c:568 LLC SAPI=1 C FCS=0x9ab10aCMD=UI DATA <0012> gprs_llc.c:95 TLLI 0xb4c2fd41 is foreign, converting to local TLLI 0xf4c2fd41 <0012> gprs_llc.c:241 LLC RX: Found a local entry for TLLI 0xb4c2fd41 <0012> gprs_llc.c:615 TLLI=f4c2fd41 dropping UI, N(U=0) not in window V(URV(UR:3). <0010> gprs_ns.c:530 NSEI=101 Timer expired in mode tns-test (30 seconds) <0010> gprs_ns.c:473 NSEI=101 Tx NS ALIVE (NSVCI=101) <0010> gprs_ns.c:512 NSEI=101 Starting timer in mode tns-alive (10 seconds) <0010> gprs_ns.c:486 NSEI=101 Tx NS ALIVE_ACK (NSVCI=101) <0010> gprs_ns.c:512 NSEI=101 Starting timer in mode tns-test (30 seconds) <0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC <0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC <0011> gprs_bssgp.c:376 BSSGP TLLI=0x9ec3b021 Rx UPLINK-UNITDATA <0012> gprs_llc.c:568 LLC SAPI=1 C FCS=0x79a5b6CMD=UI DATA <0012> gprs_llc.c:95 TLLI 0x9ec3b021 is foreign, converting to local TLLI 0xdec3b021 <0012> gprs_llc.c:95 TLLI 0x9ec3b021 is foreign, converting to local TLLI 0xdec3b021 <0012> gprs_llc.c:254 LLC RX: unknown TLLI 0x9ec3b021, creating LLME on the fly <0002> gprs_gmm.c:924 -> GMM RA UPDATE REQUEST type="RA updating" LLC XID RESET REJECT <0002> gprs_gmm.c:861 <- ROUTING AREA UPDATE REJECT <0012> gprs_llc.c:95 TLLI 0x9ec3b021 is foreign, converting to local TLLI 0xdec3b021 <0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC <0011> gprs_bssgp.c:376 BSSGP TLLI=0x7b549435 Rx UPLINK-UNITDATA <0012> gprs_llc.c:568 LLC SAPI=1 C FCS=0xd1bcf4CMD=UI DATA <0012> gprs_llc.c:254 LLC RX: unknown TLLI 0x7b549435, creating LLME on the fly <0002> gprs_gmm.c:640 -> GMM ATTACH REQUEST MI(302720xxxxxxxxx) type="GPRS attach" <0002> gprs_gmm.c:444 <- GPRS IDENTITY REQUEST: mi_type=02 <0011> gprs_bssgp.c:376 BSSGP TLLI=0x7b549435 Rx UPLINK-UNITDATA <0012> gprs_llc.c:568 LLC SAPI=1 C FCS=0x4567cfCMD=UI DATA <0002> gprs_gmm.c:1033 Cannot handle GMM for unknown MM CTX <0002> gprs_gmm.c:277 <- GPRS MM STATUS (cause: MS identity cannot be derived by the network) <0011> gprs_bssgp.c:753 BSSGP BVCI=2 Rx Flow Control BVC <0011> gprs_bssgp.c:376 BSSGP TLLI=0x9ec20d01 Rx UPLINK-UNITDATA <0012> gprs_llc.c:568 LLC SAPI=1 C FCS=0x365438CMD=UI DATA <0012> gprs_llc.c:95 TLLI 0x9ec20d01 is foreign, converting to local TLLI 0xdec20d01 <0012> gprs_llc.c:95 TLLI 0x9ec20d01 is foreign, converting to local TLLI 0xdec20d01 <0012> gprs_llc.c:254 LLC RX: unknown TLLI 0x9ec20d01, creating LLME on the fly <0002> gprs_gmm.c:924 -> GMM RA UPDATE REQUEST type="RA updating" LLC XID RESET REJECT <0002> gprs_gmm.c:861 <- ROUTING AREA UPDATE REJECT ramesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ciaby at autistici.org Sat Nov 29 17:07:40 2014 From: ciaby at autistici.org (Ciaby) Date: Sat, 29 Nov 2014 11:07:40 -0600 Subject: recurring issue with OpenBSC Message-ID: <5479FD5C.3000708@autistici.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi! First a small update: we finally decided to _not_ use token mode, as it confuses a lot of phones, after receiving the token message the SIM goes into an error state and the only way to recover is to reboot the phone. Now we just read the IMSI straight from the SIM (using the card python library, just like osmo-sim-auth does) and register them. Now, the issue we see is that 1-2 users every day reach a point where they can make phone calls and send messages, but they can't receive neither of them. Sometimes the problem can be fixed by running: > subscriber extension clear-requests but this only work when there are pending requests. In other cases, the phone has to be rebooted. Did anyone encounter the same issue? Cheers Ciaby -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUef1WAAoJEPU83OtbD4fQ69kQAI7peg30lHwbDPMXnTX80gUu 0dGsiK2iB5oWZ6Ohbs3W+/+xVoMseuG1di6Rk0XT9buN2IOR5fMfAs3INQ2EuAlV qz1RRn5Ux8uV0RJWyAJoSt7eFh3gbnDgsJ+x8SXEHQRw4rYHG2P+HXyEtncW6A6y L8/oPeIxH/LlP/55MP3KUY5BnQmN658LnJU9AFSwPkpjn2f/dj4o6mUdWo8haTTQ UWPWEdhQoeXPBqHsn2cKamT13SmiepMYAGuDEJci9LCS+J8vd70ukAP/oa1L6u1w +3+RbcNvC9fwAKDLU01b/cu630v6/mhk0lxWNlIz/kNL1aHPZe8QhP5sM4SuLtzj UaeHLxp4u2Pb7N31b3qtRA4jgl+5YFla5376F3d00jPSfZpmFggFgdRB2qWhF1m8 WucfzLc41dV1AVTdL90ISSRt1LZ/fLHBea8kgUxK+KrhBO7U7AV3PXk9of4EAf7y VKMX3KZWwtEKhpi0v3PihgW8bS/RaG3zEmsr30QXzXVaZknCfjGi8OOOB0JaHY48 o3g40YpzeyEq1gOyKKfBmtf1qk4GgLyPKfMUoTvXE2oNHmrg3ZlJldABKNzR9qz3 5hsHJ6/QGsBST1E3dphI0Zb6ubLnFwqBl02GyeJELLbtPCLPQMDicx03cqT4BjO3 vzDcPdIWg1sfSomYKMK9 =Zw4T -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5B0F87D0.asc Type: application/pgp-keys Size: 7323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5B0F87D0.asc.sig Type: application/octet-stream Size: 543 bytes Desc: not available URL: From holger at freyther.de Sun Nov 30 15:42:52 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 30 Nov 2014 16:42:52 +0100 Subject: recurring issue with OpenBSC In-Reply-To: <5479FD5C.3000708@autistici.org> References: <5479FD5C.3000708@autistici.org> Message-ID: <20141130154252.GU16131@xiaoyu.lan> On Sat, Nov 29, 2014 at 11:07:40AM -0600, Ciaby wrote: > Now, the issue we see is that 1-2 users every day reach a point where > they can make phone calls and send messages, but they can't receive > neither of them. Sometimes the problem can be fixed by running: > > subscriber extension clear-requests > but this only work when there are pending requests. In other cases, > the phone has to be rebooted. Did anyone encounter the same issue? Rebooting the phone? The sourcefile name "bsc_hack.c" is still kind of true for the NITB. This means that at somepoint some part of the code has not called subscr_put_channel. We might add some string parameters to the logic to see which part of the code is to blame. From ciaby at autistici.org Sun Nov 30 19:57:58 2014 From: ciaby at autistici.org (Ciaby) Date: Sun, 30 Nov 2014 13:57:58 -0600 Subject: recurring issue with OpenBSC In-Reply-To: <20141130154252.GU16131@xiaoyu.lan> References: <5479FD5C.3000708@autistici.org> <20141130154252.GU16131@xiaoyu.lan> Message-ID: <547B76C6.3080408@autistici.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/30/2014 09:42 AM, Holger Hans Peter Freyther wrote: [...] > Rebooting the phone? The sourcefile name "bsc_hack.c" is still kind > of true for the NITB. This means that at somepoint some part of the > code has not called subscr_put_channel. Yes, we're aware of that :) > We might add some string parameters to the logic to see which part > of the code is to blame. That would be great. Can you point me in the right direction? Which file/library is responsible for that? Cheers Ciaby -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUe3bEAAoJEPU83OtbD4fQ7bIQAKn2X3sC4vUg/I8nq8kJfr1r dEBmhEfMRzy02ZFc4hkIPmKrqMzHN0X/Fn+FZbrZwVSDXK2UZr+++LmGoevwfnE+ XKAz8hwPElInMun6F/mlpcgSXnBh7SXkw+ShAJjaJVl+uAg/4WKarwG+C9JuYsPE L6agwtljlVQUmxuY2HN9DFdpXMgk4fIC5qWsB+3ZAt31eGoTz/G4bSX0UsRBaASc 3kM5T4fMdFWCt5yQgnmlLuWBu8OFuSUJzazdMl2sb1Wujsxgoq7YDzhyVkwjEcaK 6Qi+mwsNnWq+r1fKTlIjLZ/XWB5/+V3D4oej82BApoetXjBfrtrC/H7Fjv4CFPb7 4AldCr6PIRgO+rZF23S0SLeE/q/4VQcYPiweRXA2RWOhlbmFIRFa5fLq/NH1WHE7 Jdo18UZIALv6MXTtF4q6Gpfd6cKpgkmRy5zTURBuDki0e420GnkSnqSrOnYyKd83 Vhodz8lChEz3e9i3d3brLD6r7bOJShULl4N7kQ1NexdjXjAtge9WDZqobGOyL85k Z/YQvoEwb9vWozEmd0nN30GYL8HIf+0gCLBDbc1SUGDHE02xwmK2XN85hILEA47y q2tsnVVpR+06v+BAqR6pRsi/sWruv9joxJZb+0FdQImRRAu71GtDBQ0KN7SWPh4B 5fRz95XwFKU+AyvsgPLK =WTgb -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5B0F87D0.asc Type: application/pgp-keys Size: 7323 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x5B0F87D0.asc.sig Type: application/octet-stream Size: 543 bytes Desc: not available URL: From perper at o2.pl Sun Nov 30 14:11:54 2014 From: perper at o2.pl (Perper) Date: Sun, 30 Nov 2014 15:11:54 +0100 Subject: Announcing new gr-gsm project Message-ID: <547B25AA.9040409@o2.pl> Dear all, Sorry for spamming here but I thought there is possibility that you might be interested. I was working for some time on a project of a set of GNU Radio tools for receiving GSM transmissions. As the project reached the point where it might be useful for the community I have decided to officially announce it. It is available on github with short installation and usage guides: https://github.com/ptrkrysik Currently there is one gr-gsm application that should work out of the box and it is a more reliable replacement of Airprobe. The gr-gsm has some similarities with it. The GSM receiver that I used is considerably corrected version of the receiver that I've long time ago written for the Airprobe project but with removed Airprobe's stuff that shouldn't be in my opinion mixed with the receiver (like decryption, decoding). However the goal of the project is broader than that and it is to provide a set of tools for people interested in processing of GSM signal in GNU Radio. For example - another possible applications of gr-gsm are GSM network monitor or frequency offset calibrator. For people who want to see the application in action without installing it I've prepared a short video presentation: https://www.youtube.com/watch?v=Eofnb7zr8QE&feature=youtu.be If anyone is interested in developing something for/with use of the project I can provide help and information about the project's internals by e-mail. -- Best Regards, Piotr Krysik