OpenBSC

openbsc@lists.osmocom.org

4 participants
4156 discussions

by Roelf Diedericks

I have FINALLY gotten to play with my sysmoBTS acquired many months ago, and updated to the latest packages using okpg, and am running a NITB. GSM850 test setup in open mode A5/0, and I can SMS and call between devices. However, there is no audio, and BTS console logs reports many repeats of the following during an established call. <0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported <0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported <0006> tch.c:601 (bts=0,trx=0,ts=7,ss=0) Rx Payload Type EFR is unsupported

12 years

[PATCH] Fix: Handle CM service request on already secured channel correctly

by Andreas Eversberg

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 | 3 ++- 2 files changed, 3 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..2ce0e8c 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"); @@ -856,6 +856,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 --------------030304030609050702010202--

12 years

[PATCH] Fix: Handle CM service request on already secured channel correctly

by Andreas Eversberg

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--

12 years

[PATCH] LAPD: Free resume/re-establishment msgb if it carries no content

by Andreas Eversberg

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--

12 years

Re: Nokia Insite handover

by Sipos Csaba

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

12 years

Nokia InSite multiple BTSs with OpenBSC

by Sipos Csaba

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

12 years

[OpenBSC PATCHv2] libmgcp: add enum mgcp_type

by pablo＠gnumonks.org

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

12 years

[ADMIN] Wanted: List moderator

by Harald Welte

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)

12 years

Nokia MetroSite

by Sipos Csaba

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

12 years

Help with Asterisk setup to stop Openbsc registering handsets

by Adam B

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

12 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC