- OpenBSC - lists.osmocom.org

[PATCH 0/1] Updated script to handle whitespace
by Daniel Willmann 19 Jul '11

19 Jul '11

Hello, here an updated version of the script that handles whitespace in filennames properly. Thanks Holger for pointing out that such things do exist. :-) Regards, Daniel Willmann (1): contrib: Add a script to clean up in regular intervals Makefile.am | 2 +- configure.ac | 1 + contrib/Makefile.am | 1 + contrib/osmo_pcap_clean_old | 47 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 50 insertions(+), 1 deletions(-) create mode 100644 contrib/Makefile.am create mode 100755 contrib/osmo_pcap_clean_old -- 1.7.5.3

1 1

Making NITB Database code async
by Holger Hans Peter Freyther 19 Jul '11

19 Jul '11

Hi all, I wonder what is the easiest way to make our database code async. Looking at our tables and code we do not seem to have a very complicated use. Problem: libdbi makes queries to SQLite that kills performance (e.g. every SELECT sends out pragma queries for every column to be queried). We have a hacked up libdbi from the last congress. We have some issues inserting new data into the database (e.g. the db being locked). In one way or another we have some issues there (either nitb will block, or the external process will...) When moving to postgres and a database on a different system we will have to deal with latencies and round trip time, but our code is sync. Goal: Most of our setting is 'set and forget'. We don't have complicate transactions (e.g. we don't have two nitb's setting the LAC of a subscriber, or wouldn't really care). When updating the in-memory representation, we don't mind how long it will take until it hits the disk on the remote system. Proposal: Also setting/storing will can remain like they are, the return value does only mean that a request has been sent. Only loading the subscriber, SMS, need to be asynchronous. M1: Change the gsm_subscriber code to load a subscriber asynchronously, this will mostly touch the gsm48 code and the VTY area. On load one can specify a callback. M2: Change the SMS code to load a SMS asynchronously, this will mostly change the SMS queue, some parts of the SMS submit (e.g. to check if there are still SMS to be sent) and the submit in the VTY M3: Probably create our own DB abstraction and provide a SQLite3 and Postgres backend using the native API of both of them (and getting rid of the libdbi and gdb issue) biggest problem: What do we do with the DB queries done from VTY that are asynchronous, e.g to confirm a SMS has been stored? Do we care about it? Do we turn this to a 'notification'? comments holger

2 1

Compile Error with latest Version
by Axel Walsleben 18 Jul '11

18 Jul '11

Hi List, i just tried to build openbsc latest checkout. libosmocore compiles fine (checkout is also from today) i got this error: make[3]: Betrete Verzeichnis '/home/demo/openbsc/openbsc/src/libcommon' CC common_vty.o In file included from common_vty.c:26: ../../include/openbsc/vty.h:32: error: redeclaration of enumerator ‘E1INP_NODE’ /usr/local/include/osmocom/vty/command.h:77: note: previous definition of ‘E1INP_NODE’ was here In file included from common_vty.c:28: ../../include/openbsc/debug.h:16: error: expected identifier before ‘-’ token In file included from ../../include/openbsc/bsc_nat.h:24, from common_vty.c:30: ../../include/openbsc/mgcp.h: In function ‘mgcp_timeslot_to_endpoint’: ../../include/openbsc/mgcp.h:180: error: ‘DMGCP’ undeclared (first use in this function) ../../include/openbsc/mgcp.h:180: error: (Each undeclared identifier is reported only once ../../include/openbsc/mgcp.h:180: error: for each function it appears in.) make[3]: *** [common_vty.o] Fehler 1 make[3]: Verlasse Verzeichnis '/home/demo/openbsc/openbsc/src/libcommon' make[2]: *** [all-recursive] Fehler 1 make[2]: Verlasse Verzeichnis '/home/demo/openbsc/openbsc/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/demo/openbsc/openbsc' so libcommon failes. is there a fix available or it is a unknown problem thanks. Regards axel

1 0

OML issue?
by Holger Hans Peter Freyther 18 Jul '11

18 Jul '11

Hi all, I have seen a strange OML NACK loop in OpenBSC with the ipaccess BTS. When I restart the osmo-nitb it is working again, so I suspect somehow our state of the BTS is corrupted. any ideas holger

3 8

[PATCH] bts-init: Initialize the BTS like it will look after a reset
by Holger Hans Peter Freyther 18 Jul '11

18 Jul '11

Reset the BTS MO State on BTS bootstrap. This way we will always test the BTS disconnect/reconnect case of the BTS. Do not reset the administrative state of objects. The BSC might have set these and wants to maintain them across disconnect/ reconnect. Right now this is true for the TRX state. --- openbsc/src/libbsc/bsc_init.c | 3 +++ openbsc/src/libcommon/gsm_data_shared.c | 1 - 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c index 1be8cb7..02a3adf 100644 --- a/openbsc/src/libbsc/bsc_init.c +++ b/openbsc/src/libbsc/bsc_init.c @@ -406,6 +406,9 @@ static int bootstrap_bts(struct gsm_bts *bts) bts->si_common.ncc_permitted = 0xff; + /* Initialize the BTS state */ + gsm_bts_mo_reset(bts); + return 0; } diff --git a/openbsc/src/libcommon/gsm_data_shared.c b/openbsc/src/libcommon/gsm_data_shared.c index 58e3bed..b52d58a 100644 --- a/openbsc/src/libcommon/gsm_data_shared.c +++ b/openbsc/src/libcommon/gsm_data_shared.c @@ -36,7 +36,6 @@ void gsm_abis_mo_reset(struct gsm_abis_mo *mo) { - mo->nm_state.administrative = NM_STATE_NULL; mo->nm_state.operational = NM_OPSTATE_NULL; mo->nm_state.availability = NM_AVSTATE_POWER_OFF; } -- 1.7.4.1 --------------050709080504010702000704--

1 0

Different protocols
by Seungju Kim 17 Jul '11

17 Jul '11

I see that pretty much every vendor in GSM industry uses their own dialect in their core network products, I wonder why. What do they achieve from it while killing compatibility with other products from other companies?

4 6

[PATCH] gsm 04.80: fix typo 265->256
by Alexander Huemer 16 Jul '11

16 Jul '11

Commit 79599ba0eb7a9aeaeb9dfbbf4881f0633724a471 contained a double typo. --- include/osmocom/gsm/tlv.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/osmocom/gsm/tlv.h b/include/osmocom/gsm/tlv.h index 1e59cca..f659411 100644 --- a/include/osmocom/gsm/tlv.h +++ b/include/osmocom/gsm/tlv.h @@ -236,11 +236,11 @@ struct tlv_def { }; struct tlv_definition { - struct tlv_def def[265]; + struct tlv_def def[256]; }; struct tlv_parsed { - struct tlv_p_entry lv[265]; + struct tlv_p_entry lv[256]; }; extern struct tlv_definition tvlv_att_def; -- 1.7.6

2 1

Smatch results on openbsc / static code analysis
by Harald Welte 16 Jul '11

16 Jul '11

Hi! I've started to play a bit with Smatch (http://smatch.sourceforge.net/) and fixed a number of bugs in libosmocore. When applying it to openbsc, I get: CC ipaccess.o /home/laforge/projects/git/openbsc/openbsc/src/libabis/input/ipaccess.c +455 ipaccess_drop(28) info: loop could be replaced with if statement. /home/laforge/projects/git/openbsc/openbsc/src/libabis/input/ipaccess.c +451 ipaccess_drop(24) info: ignoring unreachable code. The point herer is: we loop over a list, but we return from the first iteration of the loop. Zecke? CC abis_nm.o /home/laforge/projects/git/openbsc/openbsc/src/libbsc/abis_nm.c +810 sw_load_segment(38) warn: unsigned 'len' is never less than zero. 'len' has to be signed, I fixed that one. CC paging.o /home/laforge/projects/git/openbsc/openbsc/src/libbsc/paging.c +134 can_send_pag_req(25) info: ignoring unreachable code. We have a goto statement in each possible caes (including defualt) above it. So the return 0 will never be hit. That's ok and not a bug. But I think the code is too convoluted this way. I think we should have one function that just returns (sdcch/tch) based on the rsl_type and net->pag_any_tch, and then a second function that has a simple if/else. I'm not against goto - but I think this time it really can be avoided easily. CC bsc_vty.o /home/laforge/projects/git/openbsc/openbsc/src/libbsc/bsc_vty.c +1062 show_e1ts(25) warn: variable dereferenced before check 'line' /home/laforge/projects/git/openbsc/openbsc/src/libbsc/bsc_vty.c +1075 show_e1ts(38) warn: buffer overflow 'line->ts' 32 <= 32 /home/laforge/projects/git/openbsc/openbsc/src/libbsc/bsc_vty.c +1080 show_e1ts(43) error: potential null derefence 'line'. fixed two of them, the third is bogus CC db.o /home/laforge/projects/git/openbsc/openbsc/src/libmsc/db.c +254 db_fini(6) info: redundant null check on db_dirname calling free() /home/laforge/projects/git/openbsc/openbsc/src/libmsc/db.c +256 db_fini(8) info: redundant null check on db_basename calling free() /home/laforge/projects/git/openbsc/openbsc/src/libmsc/db.c +280 db_create_subscriber(20) warn: variable dereferenced before check 'subscr' /home/laforge/projects/git/openbsc/openbsc/src/libmsc/db.c +1062 sms_from_result(36) warn: 256 is more than 255 (max 'sms->user_data_len' can be) so this is always false. fixed the first 3, the last remains as a safeguard CC gsm_04_08.o /home/laforge/projects/git/openbsc/openbsc/src/libmsc/gsm_04_08.c +550 mm_rx_loc_upd_req(46) error: we previously assumed 'conn->loc_operation' could be null. /home/laforge/projects/git/openbsc/openbsc/src/libmsc/gsm_04_08.c +1891 gsm48_cc_rx_setup(68) error: we previously assumed 'trans->subscr' could be null. /home/laforge/projects/git/openbsc/openbsc/src/libmsc/gsm_04_08.c +2193 gsm48_cc_rx_connect(40) error: we previously assumed 'trans->subscr' could be null. The first is bogus, the others need to be investigated CC gsm_04_11.o /home/laforge/projects/git/openbsc/openbsc/src/libmsc/gsm_04_11.c +599 gsm340_rx_tpdu(46) error: sms_alphabet is never equal to 4294967295 (wrong type 0 - 255). I fixed that one! CC ussd.o /home/laforge/projects/git/openbsc/openbsc/src/libmsc/ussd.c +54 handle_rcv_ussd(9) error: req.text[0] is never equal to 255 (wrong type -128 - 127). CC bsc_ussd.o /home/laforge/projects/git/openbsc/openbsc/src/osmo-bsc_nat/bsc_ussd.c +385 bsc_check_ussd(62) error: req.text[0] is never equal to 255 (wrong type -128 - 127). This is due to 'struct ussd_request.text' being 'char', I changed it to uint8_t. CC bs11_config.o /home/laforge/projects/git/openbsc/openbsc/src/utils/bs11_config.c +223 linkstate_name(5) error: buffer overflow 'bs11_link_state' 3 <= 3 /home/laforge/projects/git/openbsc/openbsc/src/utils/bs11_config.c +240 mbccu_load_name(5) error: buffer overflow 'mbccu_load' 6 <= 6 /home/laforge/projects/git/openbsc/openbsc/src/utils/bs11_config.c +905 main(34) info: ignoring unreachable code. fixed. CC ipaccess-firmware.o /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 2 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-firmware.c +64 ipaccess_analyze_file(26) warn: buffer overflow 'firmware_header->more_magic' 2 <= 3 zecke? CC ipaccess-proxy.o /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +173 store_idtags(14) error: buffer overflow 'ipbc->id_tags' 255 <= 255 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +173 store_idtags(14) error: buffer overflow 'ipbc->id_tags' 255 <= 255 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +175 store_idtags(16) error: buffer overflow 'ipbc->id_tags' 255 <= 255 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +178 store_idtags(19) error: buffer overflow 'ipbc->id_tags' 255 <= 255 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +500 ipaccess_rcvmsg(66) error: buffer overflow 'ipbc->rsl_conn' 4 <= 4 /home/laforge/projects/git/openbsc/openbsc/src/ipaccess/ipaccess-proxy.c +504 ipaccess_rcvmsg(70) error: buffer overflow 'ipbc->bsc_rsl_conn' 4 <= 4 fixed CC gprs_bssgp_util.o /home/laforge/projects/git/openbsc/openbsc/src/libgb/gprs_bssgp_util.c +114 bssgp_tx_status(17) warn: variable dereferenced before check 'orig_msg' fixed. CC gb_proxy_main.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/gb_proxy_main.c +284 main(81) info: ignoring unreachable code. bogus, sa it's jus an exit(0) CC gprs_gmm.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/gprs_gmm.c +757 gsm48_rx_gmm_att_req(133) warn: variable dereferenced before check 'ctx' fixed CC gprs_sndcp.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/gprs_sndcp.c +478 sndcp_unitdata_req(37) info: ignoring unreachable code. comment in the code says it is not reached CC sgsn_main.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/sgsn_main.c +284 main(83) info: ignoring unreachable code. comment in the code says it is not reached CC sgsn_libgtp.o /home/laforge/projects/git/openbsc/openbsc/src/gprs/sgsn_libgtp.c +504 sgsn_rx_sndcp_ud_ind(32) info: ignoring unreachable code. fixed CC bsc_nat.o /home/laforge/projects/git/openbsc/openbsc/src/osmo-bsc_nat/bsc_nat.c +1553 get_next_free_bsc_id(20) info: ignoring unreachable code. zecke? -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

Re: Hardware required to setup an SGSN
by Naveen Kumar 15 Jul '11

15 Jul '11

Hi Harald Thanks for the options. I will need to look into it in a bit more detail. Which part of the code base do I need to concentrate on to get the Fr over E1 functionality? Naveen

2 2

merge of 'daniel/controlif' branch
by Harald Welte 14 Jul '11

14 Jul '11

Hi! After many delays on my side (it kept falling off my TODO list), I have finally merged the daniel/controlif branch earlier today. For those who haven't heard about it so far: It is code that allows us to remotely get and/or set attributes of the BSC. Furthermore, it supports traps (similar to SNMP traps). The idea of it is to allow us to have centralized management of networks with many OpenBSC installations, offering SNMP-like feel but without adding the complexity of SNMP (asn.1, etc.) to OpenBSC itself. We might at some point have an independent gateway process that exports the attributes through real SNMP, but that mostly depensd on whether any production networks have such a requirement or not. The control interface is implemented either stand-alone (for osmo-nitb) or via the regular A and A-bis/IP as an additional ip.access stream identifier. Thanks to Daniel for writing the code, to On-Waves for funding the development and once again my apologies for the delays. btw: I have done a couple of cosmetic clean up commits in addition to Daniels branch, hopefully I didn't break anything while doign that... Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1