OpenBSC July 2013

openbsc@lists.osmocom.org

28 participants
43 discussions

[PATCH] Fix: Handle CM service request on already secured channel correctly
by Andreas Eversberg 10 Jul '13

10 Jul '13

A CM service request must be acknowledged also, when encryption is already enabled. Without encryption enabled, the security status is GSM_SECURITY_NOTAVAIL, which causes a CM service acknowledge. On initial CM service request, the security status is GSM_SECURITY_SUCCEED, if encryption is enabled. This will not lead to an acknowledge, because the cyphering command implies an acknowlege. An additional CM service request requires an acknowledge, so I added a new security status: GSM_SECURITY_ALREADY --- openbsc/include/openbsc/gsm_data.h | 1 + openbsc/src/libmsc/gsm_04_08.c | 8 +++++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/openbsc/include/openbsc/gsm_data.h b/openbsc/include/openbsc/gsm_data.h index d7db887..05e0490 100644 --- a/openbsc/include/openbsc/gsm_data.h +++ b/openbsc/include/openbsc/gsm_data.h @@ -21,6 +21,7 @@ enum gsm_security_event { GSM_SECURITY_NOAVAIL, GSM_SECURITY_AUTH_FAILED, GSM_SECURITY_SUCCEEDED, + GSM_SECURITY_ALREADY, }; struct msgb; diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index 58107e3..3725eb9 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -194,7 +194,7 @@ int gsm48_secure_channel(struct gsm_subscriber_connection *conn, int key_seq, status = GSM_SECURITY_NOAVAIL; } else if (conn->lchan->encr.alg_id > RSL_ENC_ALG_A5(0)) { DEBUGP(DMM, "Requesting to secure an already secure channel"); - status = GSM_SECURITY_SUCCEEDED; + status = GSM_SECURITY_ALREADY; } else if (!ms_cm2_a5n_support(subscr->equipment.classmark2, net->a5_encryption)) { DEBUGP(DMM, "Subscriber equipment doesn't support requested encryption"); @@ -302,6 +302,11 @@ static int _gsm0408_authorize_sec_cb(unsigned int hooknum, unsigned int event, release_loc_updating_req(conn); break; + case GSM_SECURITY_ALREADY: + LOGP(DMM, LOGL_ERROR, "We don't expect LOCATION " + "UPDATING after CM SERVICE REQUEST\n"); + /* fall through */ + case GSM_SECURITY_NOAVAIL: case GSM_SECURITY_SUCCEEDED: /* We're all good */ @@ -856,6 +861,7 @@ static int _gsm48_rx_mm_serv_req_sec_cb( break; case GSM_SECURITY_NOAVAIL: + case GSM_SECURITY_ALREADY: rc = gsm48_tx_mm_serv_ack(conn); break; -- 1.8.1.5 --------------040306030909000104060200--

1 0

[PATCH] LAPD: Free resume/re-establishment msgb if it carries no content
by Andreas Eversberg 09 Jul '13

09 Jul '13

lapdm.c takes the re-establishment message and forwards it to lapd_core.c, so we can assume that msgb is set at primitive. In case there is data in the re-establishment msg, it is moved into send_buffer. In case of no data (0 length), it must be freed. --- src/gsm/lapd_core.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gsm/lapd_core.c b/src/gsm/lapd_core.c index 68b5e78..08143ed 100644 --- a/src/gsm/lapd_core.c +++ b/src/gsm/lapd_core.c @@ -1962,11 +1962,13 @@ static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx) if (dl->send_buffer) msgb_free(dl->send_buffer); dl->send_out = 0; - if (msg && msg->len) + if (msg->len) { /* Write data into the send buffer, to be sent first */ dl->send_buffer = msg; - else + } else { + msgb_free(msg); dl->send_buffer = NULL; + } /* Discard partly received L3 message */ if (dl->rcv_buffer) { -- 1.7.3.4 --------------030109030604040502010001--

1 0

Re: Nokia Insite handover
by Sipos Csaba 09 Jul '13

09 Jul '13

Hi Peter, > It means that some real programming is needed. It's not a small > change. It might work as-is with one phone camping to only one of the > two BTSes at a time, but you will likely have corruptions if you have > a bunch of phones on both BTSes at once. I was able to start two InSite units at the same time, probably because these units has only one TRX per BTS. I was even able to establish an inter-BTS voice call. Cell reselection and SMS was working fine also. But when I tried to enable handover, I got this strange message that I have to enable RTP proxy. If I do so, my voice calls are failing completely (not a surprise, these units are connecting through E1). I could really use a straight answer from any developer, that OpenBSC has handover support for non-IP (E1 based) units or not, because I am not trying to get this done if it is completely missing. > When using nitb with a multi-TRX MetroSite there is a similar pattern > to what you describe - after the BTS is reset using the Nokia BTS > Manager, nitb only ever manages to correctly initialize the first > TRX. An error occurs and nitb exits. Restarting nitb sometimes allows > it to initialize the second TRX, sometimes no. My guess is that > failure or success depends on what phones are sending to the BTS > meanwhile, but it could also be only a matter of timing. Today I was able to setup our MetroSite (2 GSM1800 TRXs) unit and encountered the very same problem: only the first TRX was initialized, though both TRXs are set up in the openbsc config file. For the start and stop process you absolutely right. Out of ten tries, usually 2-3 are successful if I try to start both InSite units, but the chances are better if I previously start openbsc with a single BTS config file, then hit Ctrl+C and start the mutli BTS config file. It is also interesting, that both TRXSIG lapd connections are ON according to the BTS manager with MetroSite, but the second TRX is just not working. > The nokia_site code can definitily be improved when it comes to > startup/shutdown, but I don't know how well known the Nokia OML is. > It would also be nice to listen to the BTS Manager serial port > communication. If I understand correctly, many (all?) things that > BTS Manager can do over serial are also possible over E1. I can do these traces if you let me know what commands are you interested in. For example I can tell you for sure, that the site reset request command sent by OpenBSC (bts_nokia_site.c to be specific) is doing exactly the same, when I hit "Enable Abis" in Nokia BTS Manager. BTW do you have Nokia units too? I am still open to give access to our MetroSite (or the InSite) units if a developer is interested in it. I also have a fine selection of Nokia BTS managers that includes almost all Nokia BTS types (InSite, MetroSite, UltraSite, Flexi HUB, MetroHUB, Flexi EDGE, Metro Hopper etc.) I am happy to share this with any developer, just PM me with an FTP server account and remember: the whole package is 2.2GB. Br, Csaba

1 0

Nokia InSite multiple BTSs with OpenBSC
by Sipos Csaba 08 Jul '13

08 Jul '13

Dear Members, As I previously mentioned, I have two Nokia InSite BTS units that I want to set up for my university. One GSM900 and one GSM1800 unit, and I want to share some findings that can be useful for other users too. First, the informations about the DAHDI configuration at the end of the building page: http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC It sais the following for system.conf: dchan=1 bchan=2-30 I wanted to point out that it is not necessary to define a dchan, because with BTSes this is not a traditional E1 line configuration where you share timeslots and you have to signal it via the traditional E1 signaling channel (dchan), because for every BTS there are dedicated timeslots for OMUSIG, TRXSIG and TCHs etc, that cannot be used by anybody else. And because we are not using that dchan, it is a waste of capacity to allocate it. My DAHDI system.conf looks like this: span=1,0,0,ccs,hdb3,crc4 bchan=1-31 and it works perfectly without a configured dchan (well its far from perfect but at least the problem is not with the E1 configuration). Because every BTS works like this, it would be wise the update that information. For T1 lines and other framing configurations (cas, ami etc.) it is the same. The second thing is that Nokia InSite units (probably others too) can be daisy chained. It is possible to share the first BTS units E1 connection for the daisy chained units with the integrated HDSL cross-connection interface. With this technique it is possible to share one E1 connection between 5 BTSes. But there is a slight problem. I figured out if the BTS is not connecting to the E1 directly, but via this HDSL interface, it needs more time before it can be configured via OML,RSL. So in bts_nokia_site.c the #DEFINE RESET_INTERVAL have to be raise from the current 15 seconds to at least 25 seconds, otherwise the unit is not going to came up. With this modification I was able to use the unity via this HDSL cross-connection interface. The third thing is multiple BTS operation. As I mentioned I want to use two InSite units with OpenBSC. But at the beginning of bts_nokie_site.c there is a big warning: I most certainly going to have problems with multi BTS operation. Despite the warning I tried with two units, and found an interesting thing: if I try to start the two units, only one of the two units are going to came up. But if I start the daisy chained unit first, then stop openbsc and immediately start openbsc again but now with the two unit config file, both BTSes are came up just fine, the phones can camp on both units. I don't know the real reason behind this behavior, but I have log and PCAP traces about the working and non-working scenarios. If someone interested in it I can share the results. Although a possible reason is that in bts_nokia_insite.c the shutdown routine is completely missing. It is not a good solution, but at least we should reset the BTS(es) and all the signalling channels in the shutdown state (like with BS11), until we figure out some proper way of shutting Nokia BTSes down. BR, Csaba

3 3

[OpenBSC PATCHv2] libmgcp: add enum mgcp_type
by pablo＠gnumonks.org 08 Jul '13

08 Jul '13

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> This patch replaces the field 'is_transcoded' in the mgcp_endpoint structure by the enum mgcp_type, that can be further extended with new types. --- v2: remove default: case and move LOGP to before the return 0; as suggested by Peter. openbsc/include/openbsc/mgcp_internal.h | 7 ++++++- openbsc/src/libmgcp/mgcp_network.c | 34 +++++++++++++++++++++++-------- openbsc/src/libmgcp/mgcp_protocol.c | 8 ++++---- 3 files changed, 36 insertions(+), 13 deletions(-) diff --git a/openbsc/include/openbsc/mgcp_internal.h b/openbsc/include/openbsc/mgcp_internal.h index 455bb53..d5bd3dd 100644 --- a/openbsc/include/openbsc/mgcp_internal.h +++ b/openbsc/include/openbsc/mgcp_internal.h @@ -96,6 +96,11 @@ struct mgcp_rtp_tap { struct sockaddr_in forward; }; +enum mgcp_type { + MGCP_RTP_DEFAULT = 0, + MGCP_RTP_TRANSCODED, +}; + struct mgcp_endpoint { int allocated; uint32_t ci; @@ -119,7 +124,7 @@ struct mgcp_endpoint { */ struct mgcp_rtp_end trans_bts; struct mgcp_rtp_end trans_net; - int is_transcoded; + enum mgcp_type type; /* sequence bits */ struct mgcp_rtp_state net_state; diff --git a/openbsc/src/libmgcp/mgcp_network.c b/openbsc/src/libmgcp/mgcp_network.c index a2cfc23..e9b58b2 100644 --- a/openbsc/src/libmgcp/mgcp_network.c +++ b/openbsc/src/libmgcp/mgcp_network.c @@ -371,10 +371,19 @@ static int rtp_data_net(struct osmo_fd *fd, unsigned int what) endp->net_end.octets += rc; forward_data(fd->fd, &endp->taps[MGCP_TAP_NET_IN], buf, rc); - if (endp->is_transcoded) - return send_transcoder(&endp->trans_net, endp->cfg, proto == PROTO_RTP, &buf[0], rc); - else - return send_to(endp, DEST_BTS, proto == PROTO_RTP, &addr, &buf[0], rc); + + switch (endp->type) { + case MGCP_RTP_DEFAULT: + return send_to(endp, DEST_BTS, proto == PROTO_RTP, &addr, + buf, rc); + case MGCP_RTP_TRANSCODED: + return send_transcoder(&endp->trans_net, endp->cfg, + proto == PROTO_RTP, buf, rc); + } + + LOGP(DMGCP, LOGL_ERROR, "Bad MGCP type %u on endpoint %u\n", + endp->type, ENDPOINT_NUMBER(endp)); + return 0; } static void discover_bts(struct mgcp_endpoint *endp, int proto, struct sockaddr_in *addr) @@ -450,10 +459,19 @@ static int rtp_data_bts(struct osmo_fd *fd, unsigned int what) endp->bts_end.octets += rc; forward_data(fd->fd, &endp->taps[MGCP_TAP_BTS_IN], buf, rc); - if (endp->is_transcoded) - return send_transcoder(&endp->trans_bts, endp->cfg, proto == PROTO_RTP, &buf[0], rc); - else - return send_to(endp, DEST_NETWORK, proto == PROTO_RTP, &addr, &buf[0], rc); + + switch (endp->type) { + case MGCP_RTP_DEFAULT: + return send_to(endp, DEST_NETWORK, proto == PROTO_RTP, &addr, + buf, rc); + case MGCP_RTP_TRANSCODED: + return send_transcoder(&endp->trans_bts, endp->cfg, + proto == PROTO_RTP, buf, rc); + } + + LOGP(DMGCP, LOGL_ERROR, "Bad MGCP type %u on endpoint %u\n", + endp->type, ENDPOINT_NUMBER(endp)); + return 0; } static int rtp_data_transcoder(struct mgcp_rtp_end *end, struct mgcp_endpoint *_endp, diff --git a/openbsc/src/libmgcp/mgcp_protocol.c b/openbsc/src/libmgcp/mgcp_protocol.c index dc5e0f9..1e1841a 100644 --- a/openbsc/src/libmgcp/mgcp_protocol.c +++ b/openbsc/src/libmgcp/mgcp_protocol.c @@ -500,7 +500,7 @@ static int allocate_ports(struct mgcp_endpoint *endp) } /* remember that we have set up transcoding */ - endp->is_transcoded = 1; + endp->type = MGCP_RTP_TRANSCODED; } return 0; @@ -1014,7 +1014,7 @@ void mgcp_free_endp(struct mgcp_endpoint *endp) mgcp_rtp_end_reset(&endp->net_end); mgcp_rtp_end_reset(&endp->trans_net); mgcp_rtp_end_reset(&endp->trans_bts); - endp->is_transcoded = 0; + endp->type = MGCP_RTP_DEFAULT; memset(&endp->net_state, 0, sizeof(endp->net_state)); memset(&endp->bts_state, 0, sizeof(endp->bts_state)); @@ -1118,7 +1118,7 @@ static void create_transcoder(struct mgcp_endpoint *endp) int in_endp = ENDPOINT_NUMBER(endp); int out_endp = endp_back_channel(in_endp); - if (!endp->is_transcoded) + if (endp->type != MGCP_RTP_TRANSCODED) return; send_msg(endp, in_endp, endp->trans_bts.local_port, "CRCX", "sendrecv"); @@ -1140,7 +1140,7 @@ static void delete_transcoder(struct mgcp_endpoint *endp) int in_endp = ENDPOINT_NUMBER(endp); int out_endp = endp_back_channel(in_endp); - if (!endp->is_transcoded) + if (endp->type != MGCP_RTP_TRANSCODED) return; send_dlcx(endp, in_endp); -- 1.7.10.4

2 1

[ADMIN] Wanted: List moderator
by Harald Welte 08 Jul '13

08 Jul '13

Dear Osmocom community, I'm currently looking for one or multiple volunteers who are willing to tend to the mailman 'moderator queue' of the various osmocom mailing lists (baseband-devel, openbsc, simtrace, tetra, osmocom-pcu, ...) Our lists are 'member posting only' to protect them from spam. This means that spammers will be caught in the list moderation queue together with the occasional legitimate message from a non-subscriber. You need to manually look over that queue in the mailman web interface, select those legitimate posts as 'approve' and 'defer' all others. The task requires very few minutes, but it requires them every day or second day. It is a perfect opportunity how non-developers can contribute to the project :) Please let me know if anyone is willing to take care of this. Thanks! 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)

3 2

Nokia MetroSite
by Sipos Csaba 08 Jul '13

08 Jul '13

To the MetroSIte topic: I think we have a MetroSite unit with PSU, E1 card, TRE and 2 TRX. Nobody tried it out because we dont have a BSC, but I will try to hook it up to the E1 card and see if it works, I hope I can find a -48V DC supply :-) If it works I will happily set up access for developers if someone interested in it. In the mean time, I will going to do some multi unit tests with the two insite units and figure it out why sometimes both units came up, and the other time why only the first unit came up only. I think it is important to find why is this happening, because InSIte and MetroSite units can both be daisy chained, and due to the extensive network upgrades (in Europe) a lot of these units will be available on the markets (Vodafone and Telenor already dropped these units after the RAN upgrades in Hungary). But it is also true, that maybe a good development direction would be to support femto cells, that are easily and cheaply accessible to anyone, uses IP technology and In general it is easy to work with. BR, Csaba

1 0

Help with Asterisk setup to stop Openbsc registering handsets
by Adam B 08 Jul '13

08 Jul '13

Dear Mailinglist I am having a spot of bother with setting up asterisk with openbsc. I have gone with a basic setup from scratch LCR/ASTERISK/SIP minus mISDN as I dont require it and it would not compile it to my current kernel version in ubuntu 12.04 without downgrading it. Anyway my problem is that I don't know how to prevent OpenBSC from using its own HLR and instead forward all phones that want to register to my nanoBTS to do so via Asterisk. This is causing me grief because asterisk is its verbose logs is providing me this error when I try to make a call: > -- Executing [8690 <at> phones:1] Dial("SIP/IMSI466974600011287-00000000", > "SIP/IMSI466974104638690") in new stack > [Dec 18 16:00:49] WARNING[2934]: app_dial.c:2218 dial_exec_full: > Unable to create channel of type 'SIP' (cause 20 - Unknown) > == Everyone is busy/congested at this time (1:0/0/1) > -- Auto fallthrough, channel 'SIP/IMSI466974600011287-00000000' > status is 'CHANUNAVAIL' when I do show sip peers they are all offline because OpenBSC is registering my handsets and not passing on registration to Asterisk. I believe once OpenBSC is passing on registration all will be healthy with asterisk. I don't have my configurations with me at the moment snipit above is from a google search, hopefully some helpful soul will know my blunders without my configs Thank you all . Regards Adam

4 7

Nokia MetroSite EDGE
by Labs 07 Jul '13

07 Jul '13

Hello, I just found this Nokia MetroSite on eBay DE for who is interested. It seems like there were 2 pieces and one was sold for 300 Euro. http://www.ebay.de/itm/NOKIA-Metrosite-EDGE-CS10-BTS-HVMD11-020586A-102-Bas… Cheers, R.

3 5

Coverity issues in lapd_core/gsm mncc
by Holger Hans Peter Freyther 06 Jul '13

06 Jul '13

Dear Andreas, the coverity prevent utility has found three inconsistencies in the lapd_core.c and the gsm_04_08.c and I think you are suited the best to comment on how to resolve them. src/gsm/lapd_core.c static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx) ... 1943 LOGP(DLLAPD, LOGL_INFO, "perform re-establishment (SABM) length=%d\n", 1944 msg->len); ... CID 1040665 (#1 of 1): Dereference before null check (REVERSE_INULL) check_after_deref: Null-checking "msg" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1956 if (msg && msg->len) so we already dereferenced msg to print the length. So at this point, is it legetimate to a have NULL msgb or shall the null check be removed? src/libmsc/gsm_04_08.c static int gsm48_cc_rx_connect(struct gsm_trans *trans, struct msgb *msg) ... 2090 if (trans->subscr) { 2091 connect.fields |= MNCC_F_CONNECTED; 2092 strncpy(connect.connected.number, trans->subscr->extension, 2093 sizeof(connect.connected.number)-1); 2094 strncpy(connect.imsi, trans->subscr->imsi, 2095 sizeof(connect.imsi)-1); 2096 } ... CID 1040740 (#1 of 1): Dereference after null check (FORWARD_NULL) 6. var_deref_op: Dereferencing null pointer "trans->subscr". 2117 osmo_counter_inc(trans->subscr->net->stats.call.mt_connect); 2118 2119 return mncc_recvmsg(trans->subscr->net, trans, MNCC_SETUP_CNF, &connect); trans->subscr is conditionally dereferenced and then unconditionally, what is correct? static int gsm48_cc_rx_setup(struct gsm_trans *trans, struct msgb *msg) ... 1761 if (trans->subscr) { 1762 setup.fields |= MNCC_F_CALLING; 1763 strncpy(setup.calling.number, trans->subscr->extension, 1764 sizeof(setup.calling.number)-1); 1765 strncpy(setup.imsi, trans->subscr->imsi, 1766 sizeof(setup.imsi)-1); 1767 } ... CID 1040739 (#1 of 1): Dereference after null check (FORWARD_NULL) 14. var_deref_model: Passing null pointer "trans->subscr" to function "subscr_name(struct gsm_subscriber *)", which dereferences it. [show details] 1813 LOGP(DCC, LOGL_INFO, "Subscriber %s (%s) sends SETUP to %s\n", 1814 subscr_name(trans->subscr), trans->subscr->extension, 1815 setup.called.number); 1816 1817 osmo_counter_inc(trans->subscr->net->stats.call.mo_setup); Same thing as above. Can the null check be removed? Would you have the time to do that?

3 14

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2013