OpenBSC February 2016

openbsc@lists.osmocom.org

20 participants
86 discussions

milestone: 3G CS Location Update Accept
by Neels Hofmeyr 29 Feb '16

29 Feb '16

Hi list, I've just seen my first Location Update Accept from our UMTS UE+femtoCell using osmo-cscn as IuCS network core :D The Identity Request (IMSI) that the UE used to not answer is now being answered, and I am getting a successful Location Update Accept from osmo-cscn after that. The reason why it didn't work last time isn't entirely clear. All I changed since is the *test* program that simulates the UE+hNodeB, and I merely verified that osmo-cscn works (as far as LU is concerned). A hint is, Daniel told me that the IuPS setup had one day stopped to reply with a message that used to work before, and has since again started working. So it might've been a timing issue in the reply towards UE. Next steps: Next I will briefly try to run Daniel's 3G SGSN together with CSCN to see whether the premature Iu Release (?) he sees still happens when CS is connected successfully. There is also still a segfault in osmo-hnbgw, triggered by reconnecting a second time with our hnb-test that simulates an hNodeB. That's next on the hacking todo list. According to the specs, proper Authentication is mandatory for UMTS, which osmo-cscn should initiate. That's not happening yet. It seems our testing UE is fine with that, so I'll see when I'll get to that. ~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

1 1

gsm 7bit decode: *8/7
by Neels Hofmeyr 29 Feb '16

29 Feb '16

Hi list, I just thought I had fixed gsm_7bit_decode_n(), since its API doc says * \param length The length of the input sequence (in octets). int gsm_7bit_decode_n([...], uint8_t length); but the implementation is int gsm_7bit_decode_n([...], uint8_t septet_l) and indeed the length parameter is handled as septet length. So, logically, I came up with this patch: diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c index e8e452f..a9afc1a 100644 --- a/src/gsm/gsm_utils.c +++ b/src/gsm/gsm_utils.c @@ -184,8 +184,9 @@ return text - text_buf_begin; } -int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t septet_l) +int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t octet_l) { + uint8_t septet_l = ((uint16_t)octet_l * 8) / 7; return gsm_7bit_decode_n_hdr(text, n, user_data, septet_l, 0); } (the cast to uint16_t makes 100% sure the calculation isn't truncated to uint8_t after the *8 multiplication -- I picked this up while hacking on 8bit microcontrollers. That truncation doesn't really happen on our 32bit/64bit machines, but if it did, the length would effectively be limited to 255/8 == 31 characters.) Then I noticed that callers actually do *8/7 before calling the function: parse_process_uss_req(): num_chars = (uss_req_data[6] * 8) / 7; /* Prevent a mobile-originated buffer-overrun! */ if (num_chars > MAX_LEN_USSD_STRING) num_chars = MAX_LEN_USSD_STRING; gsm_7bit_decode_n_ussd((char *)req->ussd_text, sizeof(req->ussd_text), &(uss_req_data[7]), num_chars); (This is gsm_7bit_decode_n_ussd(), its API doc says "see gsm_7bit_decode_n()") So we have the API talking about length "in octets" while the implementation clearly employs septet length. Fixing the implementation to match the API doc would break binary compatibility. I should probably fix the API doc to match that weird implementation, but it nags and hurts a little. Any opinions? ~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

2 1

RFC MNCC to SIP bridge
by Holger Freyther 28 Feb '16

28 Feb '16

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

2 5

OsmoDevCon 2016 date poll
by Harald Welte 28 Feb '16

28 Feb '16

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

1 3

Interesting 3GPP specs / work areas to look at
by Harald Welte 27 Feb '16

27 Feb '16

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

1 0

Fail in using pySIM to set authentication algorithm
by Wei 25 Feb '16

25 Feb '16

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.

2 1

(int)(void*)(int) 64 vs 32
by Neels Hofmeyr 25 Feb '16

25 Feb '16

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

4 4

more CCAN gems
by Harald Welte 25 Feb '16

25 Feb '16

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)

3 2

Move PCU/SGSN/GGSN discussions to osmocom-net-gprs
by Harald Welte 25 Feb '16

25 Feb '16

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)

3 3

fyi, my recent patch sets
by Neels Hofmeyr 25 Feb '16

25 Feb '16

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

1 0

← 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