OpenBSC February 2016

openbsc@lists.osmocom.org

20 participants
84 discussions

by Holger Freyther

Hi, I am looking into building a very simple MNCC to SIP bridge to be used with the NITB (and later the CSCN). This will be based on what was learned from adding the RTP bridge which means the audio will not flow through the bridge (eventually later there will be a UDP proxy for NAT traversal) The primary design points are: * Being able to select TCH/F or TCH/H * Decide on the codec very late * Support for AMR parameters through MNCC I just look at MO and MT Call establishment from a high-level point of view: MO-Call: * NITB will send the SETUP indication * MNCC GW will do screening and decide if to proceed * MNCC GW will make TCH/F or TCH/H decision and ask for a source IP, source port * Based on bearer caps (to be handled by MNCC GW?) and TCH/F, TCH/H MNCC GW can offer a SDP file with multiple codecs to the PBX. ... * PBX will decide on a codec (ringing or 200 connect) * MNCC GW will ask NITB to reconfigure and audio will flow * (TODO: check ringtone, check default, check codec change) MT-Call: * MNCC GW will be presented with a list of codecs already * Depending on that TCH/F or TCH/H can/must be chosen (e.g. for AMR even the codec rate can be in the SDP file that decides which TCH/F or TCH/H to use) * Can decide bearer caps once paging has succeeded and call is progressing * Sets audio codec and waits for call to connect Handover support: * IP/port (and then SSRC and timestamp in RTP) will change * MNCC GW could try SIP re-invite with changed parameters * MMCC GW could hope PBX implements RTP annex and re-learns the connection Do you have comments or remarks? The above will lead to a version update, probably a dedicated assignment command in MNCC, and separating socket creation and codec change. Anyone wants to have a go at that? have a nice weekend holger

9 years, 3 months

OsmoDevCon 2016 date poll

by Harald Welte

Dear all, IN-Berlin has confirmed the dates in April where we could book the venue. Can those eligible + interested in attending please quickly indicate their preference at http://doodle.com/poll/if263cpxieavsqiq ? Thanks! Disclaimer: OsmoDevCon is an invitation-only event for developers with proven history of contributing to any of the Osmocom projects. The fact that there is a public poll about the scheduling of the event and/or your participation in that poll does not mean a particular applicant is invited. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option."

9 years, 3 months

Interesting 3GPP specs / work areas to look at

by Harald Welte

Dear all, I've gone through the high-level list of change areas / projects from Rel-4 through Rel-14 and collected a list of those parts that seemed like they could be interesting from an Osmocom point of view. In case you're curious and enjoy reading 3GPP docs as much as I do, feel free to check out http://projects.osmocom.org/projects/cellular-infrastructure/wiki/Interesti… Some parts were just recently mentioned, like Extended Uplink TBF, Network Assisted Cell Change, MNCC-SIP interface, Local Call Local Switch. We also already knew about the "Real" A-over-IP specification (different from the SCCPlite A interface that OsmoBSC implements), and A5/4. There's quite some other interesting bits and pieces, such as for example the feasibility study on GSM/EDGE BTS power saving, where they propose (it's not accepted yet) to reduce the transmit power on the BCCH-carrying TRX at certain points in the time multiplex. Enjoy, Harald -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

9 years, 3 months

Fail in using pySIM to set authentication algorithm

by Wei

Hi, I'm having a trouble when using pySIM to change the authentication algorithm in a USIM-SJS1 card. Basically I want disable the 3G authentication on the card, and only use 2G authentication regardless of the network type. Anyway, here's my procedure. In the beginning, I didn't realize there's a zecke/tmp2 branch. So i modified the the cards.py by myself. I added data, sw = self._scc.update_binary('6F00', '03') in the this line http://cgit.osmocom.org/pysim/tree/pySim/cards.py?h=master#n461 I learned the values '6F00' and '03' from this osmocom webpage <https://openbsc.osmocom.org/trac/wiki/sysmoUSIM-SJS1>. One thing to mention that is I also commented out the self._scc.verify_chv() and update KI/IMSI statements in above. Because it always fails in the self._scc.verify_chv() step (apdu response 69xx), though I provided the adm-1 key in the CLI. After it's done, unfortunately I found that when use ./pySim-read.py to read SIM again, it fails with apdu response 6b00. Also, the attempt to updating authentication algorithm didn't work when test in the phone. Did I already mess up this SIM card at this point? Then, I found there's a zecke/tmp2 branch. Tried it. Still not working either in reading (apdu response 6b00); or writing (still ails in self._scc.verify_chv() with apdu response 6983) Please give suggestion on what I should do. Thank you.

9 years, 3 months

(int)(void*)(int) 64 vs 32

by Neels Hofmeyr

On my 64bit system, I get warnings about casting int to pointer of different size and vice versa. However, below patch only shifts the warnings to 32bit systems, right? Should we encapsulate in some #ifdef __i386__ or is there an always-native int type? Thanks ~Neels From f25f8cebb58ad1f5241a33d9bac76654cd2a68a2 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Date: Wed, 24 Feb 2016 19:31:33 +0100 Subject: [PATCH] remove warning on 64bit, add warning on i386? --- openbsc/src/osmo-bsc/osmo_bsc_vty.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/openbsc/src/osmo-bsc/osmo_bsc_vty.c b/openbsc/src/osmo-bsc/osmo_bsc_vty.c index d871f01..1e4e6ee 100644 --- a/openbsc/src/osmo-bsc/osmo_bsc_vty.c +++ b/openbsc/src/osmo-bsc/osmo_bsc_vty.c @@ -43,7 +43,7 @@ static struct osmo_bsc_data *osmo_bsc_data(struct vty *vty) static struct osmo_msc_data *osmo_msc_data(struct vty *vty) { - return osmo_msc_data_find(bsc_gsmnet, (int) vty->index); + return osmo_msc_data_find(bsc_gsmnet, (int)(long int) vty->index); } static struct cmd_node bsc_node = { @@ -70,7 +70,7 @@ DEFUN(cfg_net_msc, cfg_net_msc_cmd, return CMD_WARNING; } - vty->index = (void *) index; + vty->index = (void *)(long int) index; vty->node = MSC_NODE; return CMD_SUCCESS; } -- 2.1.4 -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

9 years, 3 months

more CCAN gems

by Harald Welte

structeq looks like a great candidate to have type-aware memmp() of two structures: https://github.com/rustyrussell/ccan/tree/master/ccan/structeq type-safe callbacks rather than 'void *' pointers: https://github.com/rustyrussell/ccan/blob/master/ccan/typesafe_cb/_info assert at build time: https://github.com/rustyrussell/ccan/blob/master/ccan/build_assert/_info fast pseudo-random generator. Too sas that we want real random numbres for authentication challenges in GSUP/OAP? https://github.com/rustyrussell/ccan/blob/master/ccan/isaac/_info -- - 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)

9 years, 3 months

Move PCU/SGSN/GGSN discussions to osmocom-net-gprs

by Harald Welte

Hi all, several years ago at an OsmoDevCon, we decided to rename the PCU mailinglist into osmocom-net-grps to expand it to cover all parts of the GPRS/packet-switched systm, and then continue to discuss circuit-switched stuff in openbsc. Over the years it seems the list was more and more forgotten, and all patches were posted here. I would like to propose to move all GPRS / PS related discussion to the osmo-net-gprs mailing list again. Now you can argue that osmo-sgsn, osmo-gbproxy and gtphub are all built inside the openbsc repository. The presence of osmo-sgsn, osmo-gbproxy etc. inside one single OpenBSC git reposiory is a historic legacy, and one that I'm not very proud of. Rather than having more of that overlap/confusion we should probably aim for less and more separation. However, let's wait for the Iu-CS / Iu-PS integration and osmo-cscn (nitb without integrated bsc) first, and then look at how to lay out the source code repositories. Meanwhile, let's please aim at discussing GPRS related topics + patches (particularly PCU bits) on the osmocom-net-gprs list. Thanks for your attention! I think there are a lot of people on the openbsc lists who are primarily interested in OsmoNITB and who are not neccessarily interested in the low-level-bits of the GPRS/EGPRS RLC/MAC layers .... 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)

9 years, 3 months

fyi, my recent patch sets

by Neels Hofmeyr

This is just to say that all my currently waiting patch sets have been merged to the respective master branches, after due nitpicking by Holger in person (thanks!) with various style/simplicity modifications applied. (The one still open is the int/void* thing, not intended as a patch anyway but more as a question.) So the road is clear now for configuring osmo-nitb with its entire set of own IP addresses, and as a side effect various other osmo-programs also have configurable telnet-VTY, Ctrl-interface and Abis addresses now. To summarize the final result: (1) Abis/IP e1_input ipa bind 10.9.8.7 (2) telnet VTY line vty bind 10.9.8.7 (3) ctrl interface ctrl bind 10.9.8.7 (4) MNCC unix domain socket -M /path/to/socket/file (5) SMPP SMSC smpp local-tcp-ip 10.9.8.7 2775 Is this worth a Wiki entry? ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

9 years, 3 months

Smalltalk scalable SMSC project

by Holger Freyther

Hi all, new year, new approaches. In December I was tasked to think about a real SMSC with SMPP input and SS7 output (or SMPP in the future) and I wrote down my ideas[1] about data storage, approach, how to achieve scaling. What is missing fail-over but there are some ideas for this as well. The implementation will be done using Pharo and at least the first data storage will use mongodb >= 3.2. In the past my Pharo work has not been hosted in git but for this project it will change and maybe it creates some more visibility, historically documentation and debian packages were not too visible but that will be different this time as well. If you are interested in specification, Smalltalk, testing, load testing, SS7 or such please join me in the development. happy hacking holger [1] https://github.com/zecke/osmo-smsc/blob/master/README.asciidoc it will move to git.osmocom.org but I just wanted to have online asciidoc rendering.

9 years, 3 months

[PATCH 3/3] Add VTY section for Control interface bind address

by Neels Hofmeyr

This may seem like overkill for a mere const char * config item, but it makes the Control interface VTY commands reusable in any main() scope (inspired by libosmo-abis' VTY config). Add API functions ctrl_vty_init() and ctrl_vty_get_bind_addr(), in new files src/ctrl/control_vty.c and include/osmocom/ctrl/control_vty.h, compiled and/or installed dependent on ENABLE_VTY. Using these functions allows configuring a static const char* with the VTY commands ctrl bind A.B.C.D which callers shall subsequently use to bind the Control interface to a specific local interface address, by passing the return value of ctrl_vty_get_bind_addr() to control_interface_setup(). Add CTRL_NODE to enum node_type, "eating" RESERVED4_NODE to heed that comment on avoiding ABI changes. --- include/Makefile.am | 3 +- include/osmocom/ctrl/control_vty.h | 9 ++++ include/osmocom/vty/command.h | 3 +- src/ctrl/Makefile.am | 4 ++ src/ctrl/control_vty.c | 90 ++++++++++++++++++++++++++++++++++++++ 5 files changed, 107 insertions(+), 2 deletions(-) create mode 100644 include/osmocom/ctrl/control_vty.h create mode 100644 src/ctrl/control_vty.c diff --git a/include/Makefile.am b/include/Makefile.am index a965fb9..ac22ee6 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -117,7 +117,8 @@ nobase_include_HEADERS += \ osmocom/vty/telnet_interface.h \ osmocom/vty/vector.h \ osmocom/vty/vty.h \ - osmocom/vty/ports.h + osmocom/vty/ports.h \ + osmocom/ctrl/control_vty.h endif noinst_HEADERS = \ diff --git a/include/osmocom/ctrl/control_vty.h b/include/osmocom/ctrl/control_vty.h new file mode 100644 index 0000000..d0ef69f --- /dev/null +++ b/include/osmocom/ctrl/control_vty.h @@ -0,0 +1,9 @@ +#pragma once + +/* Add the 'ctrl' section to VTY, containing the 'bind' command. */ +int ctrl_vty_init(void *ctx); + +/* Obtain the IP address configured by the 'ctrl'/'bind A.B.C.D' VTY command. + * This should be fed to ctrl_interface_setup() once the configuration has been + * read. */ +const char *ctrl_vty_get_bind_addr(void); diff --git a/include/osmocom/vty/command.h b/include/osmocom/vty/command.h index 2078e1b..937d2f8 100644 --- a/include/osmocom/vty/command.h +++ b/include/osmocom/vty/command.h @@ -84,6 +84,8 @@ enum node_type { L_NS_NODE, /*!< \brief NS node in libosmo-gb. */ L_BSSGP_NODE, /*!< \brief BSSGP node in libosmo-gb. */ + CTRL_NODE, /*!< \brief Control interface node. */ + /* * When adding new nodes to the libosmocore project, these nodes can be * used to avoid ABI changes for unrelated projects. @@ -91,7 +93,6 @@ enum node_type { RESERVED1_NODE, /*!< \brief Reserved for later extensions */ RESERVED2_NODE, /*!< \brief Reserved for later extensions */ RESERVED3_NODE, /*!< \brief Reserved for later extensions */ - RESERVED4_NODE, /*!< \brief Reserved for later extensions */ _LAST_OSMOVTY_NODE }; diff --git a/src/ctrl/Makefile.am b/src/ctrl/Makefile.am index e6ccafb..b4a3da4 100644 --- a/src/ctrl/Makefile.am +++ b/src/ctrl/Makefile.am @@ -13,3 +13,7 @@ libosmoctrl_la_LIBADD = \ $(top_builddir)/src/libosmocore.la \ $(top_builddir)/src/gsm/libosmogsm.la \ $(top_builddir)/src/vty/libosmovty.la + +if ENABLE_VTY +libosmoctrl_la_SOURCES += control_vty.c +endif diff --git a/src/ctrl/control_vty.c b/src/ctrl/control_vty.c new file mode 100644 index 0000000..7df53b8 --- /dev/null +++ b/src/ctrl/control_vty.c @@ -0,0 +1,90 @@ +/* VTY configuration for Control interface + * + * (C) 2016 by sysmocom s.m.f.c GmbH <info(a)sysmocom.de> + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include <stdlib.h> +#include <talloc.h> +#include <osmocom/ctrl/control_vty.h> +#include <osmocom/vty/command.h> + +static void *ctrl_vty_ctx = NULL; +static const char *ctrl_vty_bind_addr = NULL; + +DEFUN(cfg_ctrl_bind_addr, + cfg_ctrl_bind_addr_cmd, + "bind A.B.C.D", + "Set bind address to listen for Control connections\n" + "Local IP address (default 127.0.0.1)\n") +{ + if (ctrl_vty_bind_addr) { + talloc_free((void*)ctrl_vty_bind_addr); + ctrl_vty_bind_addr = NULL; + } + ctrl_vty_bind_addr = talloc_strdup(ctrl_vty_ctx, argv[0]); + return CMD_SUCCESS; +} + +const char *ctrl_vty_get_bind_addr(void) +{ + if (!ctrl_vty_bind_addr) + return "127.0.0.1"; + return ctrl_vty_bind_addr; +} + +struct cmd_node ctrl_node = { + CTRL_NODE, + "%s(config-ctrl)# ", + 1, +}; + +DEFUN(cfg_ctrl, + cfg_ctrl_cmd, + "ctrl", "Configure the Control Interface") +{ + vty->index = NULL; + vty->node = CTRL_NODE; + + return CMD_SUCCESS; +} + +static int config_write_ctrl(struct vty *vty) +{ + /* So far there's only one element. Omit the entire section if the bind + * element is omitted. */ + if (!ctrl_vty_bind_addr) + return CMD_SUCCESS; + + vty_out(vty, "ctrl%s", VTY_NEWLINE); + vty_out(vty, " bind %s%s", ctrl_vty_bind_addr, VTY_NEWLINE); + + return CMD_SUCCESS; +} + +int ctrl_vty_init(void *ctx) +{ + ctrl_vty_ctx = ctx; + install_element(CONFIG_NODE, &cfg_ctrl_cmd); + install_node(&ctrl_node, config_write_ctrl); + + install_element(CTRL_NODE, &cfg_ctrl_bind_addr_cmd); + return 0; +} + -- 2.1.4

9 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2016