OpenBSC November 2009

openbsc@lists.osmocom.org

18 participants
54 discussions

[PATCH 0/1] Add bport0/1 support for bs11_config
by Daniel Willmann 14 Dec '10

14 Dec '10

Hello, second try to add support to bs11_config for bport0/1 configuration. This time with enum abis_bs11_line_cfg. It seems sometimes creating bport1 fails, even LMT shows create obj greyed out. Don't know why yet. Regards, Daniel Willmann Daniel Willmann (1): Add {create,delete}-bport1 and bport0-{star,multidrop} to bs11-config openbsc/include/openbsc/abis_nm.h | 10 +++++++++- openbsc/src/abis_nm.c | 31 +++++++++++++++++++++++++++++-- openbsc/src/bs11_config.c | 26 ++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 3 deletions(-)

4 5

Disabling RF for a TRX / Tracking abis NM state
by Harald Welte 22 Dec '09

22 Dec '09

Hi Holger! I'm currently reviewing changeset 2d501ea26a219176b1c556449e45ebd90d4accfb and just noticed that you introduce a new 'int rf_locked' member to struct gsm_bts_trx, which I believe is not needed. We are already tracking the administrative state of all objects in the BTS and mirror their state. The specific state you are looking for should be in gsm_bts_trx.nm_state.administrative I would appreciate if you could fix this. -- - 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 5

system_information branch updates
by Harald Welte 02 Dec '09

02 Dec '09

Hi! While enroute to FOSS.in in Bangalore, I took the time to test and debug the various issues I could find with the code in the system_information branch. At least in all of my tests, the system information messages, including rest octets and neighbor cell lists are looking perfectly fine. Especially now that with my latest patch, wireshark is able to dissect the SI messages properly, it is much easier to debug :) If you want to give it a try, I recommend using something like git revision 63b152ebb74355acfde76e9ce1113f2d823c0804 of that branch. Please note: We currently only support the relative bitmask format for the neighbor cell lists. That means, you cannot have neighbors with ARFCN's spanning a range of more than 111, i.e. your lowest and highest ARFCN have to be within a distance of 111 ARFCN's. Unless there are major objections, I intend to merge this branch ASAP (or rather do a 'git diff master..system_information' and apply the resulting diff as one commit to master) 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)

1 1

Howto collect MSISDN numbers
by Mohammad Halawah 01 Dec '09

01 Dec '09

Dear openBSC users, This project sounds interesting and promising. I would like to collect MSISDN (mobile numbers) for people attending a fundraising gallery. Then I send them SMS (using the MSISDN list I made) with 5 bucks donation link. Of course I can run with a pen and paper and do that, but instead I would like to use technology to help me. Is this possible to do with openBSC? Or even other GNURadio modules? I am not interested in: using openBSC to make/receive phone calls nor IMSI and TMSI. Bands of interest are: 900/1800 GSM 2100 UMTS In case this is not possible using GNU Radio modules. Is there commercial solutions to do that? Peace, Mohammad Halawah Project Engineer JETZT REGISTRIEREN: Vierteljährlicher Newsletter über die Welt der mobilen Lösungen! http://www.smartmachine.net/newsletter.html <http://www.smartmachine.net/newsletter.html> REGISTER NOW: Quarterly newsletter about the world of mobile solutions! http://www.smartmachine.net/en/newsletter.html <http://www.smartmachine.net/en/newsletter.html> smartmachine Forschung & Entwicklung GmbH Sterneckstraße 33 5020 Salzburg Austria O: + 43 662 880440-52 F: + 43 662 880440-99 M: + 43 664 1101 206 E: mohammad.halawah(a)smartmachine.net <mailto:martin.leitner@smartmachine.net>

1 0

OpenBSC, 16-in-1 SIM and COMP128v1 authentication
by Harald Welte 28 Nov '09

28 Nov '09

Hi! Today I spent some time investigating the cheap 16-in-1 SIM cards on which we can set our own Ki. This means that those cards can be used for cryptographic authentication with OpenBSC. Finally, we will have not only IMSI-based identification, but actual authentication! I've created a page in the Wiki about those cards: http://openbsc.gnumonks.org/trac/wiki/MagicSIM Using this information, I could send the RUN GSM ALGORITHM APDU to the card and retreive SRES + Kc. The result matched what I can also obtain using the COMP128v1 code from http://www.scard.org/gsm/a3a8.txt I will add Comp128v1 support to OpenBSC as soon as I have tested acutal authentication using this 16-in-1 SIM card. By the way: It would really be great if somebody could hack up a small command line program that can be used to program the Operator Name, Ki, ICCID, IMSI and preferred PLMN into the 16-in-1 SIM. 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

Wireshark: Decoding of System Information on BCCH
by Harald Welte 27 Nov '09

27 Nov '09

Hi! As Dieter has noticed, GSM traces from gammu / nokia DCT3 phones show the complete SYS INFO decode inside wireshark. However, the RSL messages BCCH INFORMATION do not decode it. I've revolved this problem and submitted a patch to the wireshark team, you can get it from https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4268 Please note: This patch does not yet address the problem for the SI5/SI6 in SACCH FILLING. The solution is not as easy, since in this case a generic L3 IE is handed of to the GSM_A_DTAP rather than GSM_A_CCCH dissector. If anyone wants to help out with fixing this for the SACCH, I'm sure many OpenBSC users and wireshark guys will be happy to receive a patch/fix. 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)

1 0

ARFCN 123 / System Information Type 1
by Harald Welte 27 Nov '09

27 Nov '09

Hi All! While looking at a wireshark trace (with the newly discovered wireshark system information dissector, for which I'll submit a patch to wireshark later tonight), I just realized that in SI1 we still shend a Cell Allocation of a hardcoded ARFCN 123. So unless you run in GSM900 and you use ARFCN 123, the SI1 content will disagree with the actual radio carrier. This is likely to cause confusion with at least some phones. We already have code to generate the channel lists inside SI messages, but this code is so far not used in the master branch. So this is just a reminder "There is a known Issue". If you want to experiment with a supposed fix for it, try using the system_information branch. 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)

1 0

nanoBTS 139 for sale
by WoMax 25 Nov '09

25 Nov '09

Sorry for this posting, but due a timewaster from berlin the last nanoBTS type 139 is for sale again. It is a siemens branded (MOGIS) nanoBTS type 139, pictures you can see on http://umts.zerber.us It is my last one, there is no PoE included, so the special price is 1900 euro plus shipping. I am currently not in switzerland, I try to get some TETRA equipment, so the shipment will be in the second week of december. Payment to my bank account or PayPal. I sold already a lot of this nanoBTS to members from the openBSC-Group for a good price, thank you to all of you.

1 0

Re: Fail messages while applying patch
by ನಾಗೇಶ್ 25 Nov '09

25 Nov '09

Thank you, Rohit for the link. N. On Mon, 2009-11-23 at 09:04 +0530, Rohit Joshi wrote: > It suggest patch found conflict in code. Read this to get started on > handling patch rejects http://elinux.org/Handling_Patch_Rejects > > > 2009/11/23 ನಾಗೇಶ್ <openbscuser(a)gmail.com>: > > Hi, > > When applying patch (as described in Debian_Getting_Started page), I get > > messages as shown in screenshot. What do these mean ? > > > > N. > > > > >

1 0

On Waves branch status and the road ahead
by Holger Freyther 24 Nov '09

24 Nov '09

Hey Guys, this is just a small head about the current work and how it relates to the OpenBSC project. So far I had developed in a branch and used rebase on it but I'm going to do regular releases so I have to stop modifying the history. Now I have the following branches: on-waves/mgcp: - This includes the MGCP media gateway implementation. The MSC in use has a mapping from the Circuit Identity Code (Multiplex + Timeslot) to an MGCP Endpoint. To ease development I have one bsc process and one mgcp one. To properly "connect" audio bsc and mgcp share a secret which is the RTP port to be used... E.g. I can bind all RTP ports ahead of time (also nice for tunneling data). There is some overlap with the current rtp proxy code but I'm not yet sure how these two fit together... So the future might be I include the MGCP code in the BSC and use the existing proxy code.. but I really don't know right now. on-waves/sccp: - This includes the SCCP implementation. It has a test case and is working quite reliable. Addressing (SSN) is achieved with something like a sockaddr and it is mostly following the socket semantic. Instead of accept and select I do have callbacks... this might change in the future. - There is no MTP* implementation in the code base... - The one "problem" with it is the memcpy... and "queuing" inside the code but both will be addressed over time. on-waves/gsm0808: - This is the current BSC app and GSM080 (BSSMAP/DTAP) code.. - This branch will rename the bssap.c to gsm_08_08.c and remove all traces of SCCP from it, some code will move from bsc_msc_ip.c to the bssap. - an API will be created that can be used by the bsc_msc_ip.c and the bsc_hack.c/gsm_04_08.c code. - In terms of OpenBSC I want this to be done after the congress to not create a mess right now. on-waves/bsc-master: - This will be my release branch. I will pull from the three branches, update version, put in hacks, or short term things that are necessary. - Think of it as a incubator for "master" as there is little danger of breaking things I have merged the MGCP and SCCP branches into master as well. I hope there is agreement (otherwise there is always git revert) z.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2009