OpenBSC

openbsc@lists.osmocom.org

4173 discussions

by Dieter Spaar

Hello Sylvain, I finally found the time to play with the RRLP encoding of the GPS assistance data, sorry for the long delay. When comparing the encoded PDUs with the data from an evaluation version of a commercial ASN1 too, I found several problems which seem to come from a bug in the ASN1 unaligned PER encoder of ASN1C. I can also confirm this problem by simply trying to decode the generated PDUs with the ASN1 decoder from ASN1C, it shows the same error as the commercial tool. I think I have found the bug and a fix for it, however I have not yet confirmed that it really works with a phone, I currently just check the PDUs. I will try to test it with a phone, if anyone is currently playing with RRLP, I can of course send the bug fix (I am just not yet 100% sure with it). Just in case, I use ASN1C from the SourceForge subversion repository. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years, 8 months

pySim: Utility to program SIMs

by Sylvain Munaut

I' ve just added a tool to deal with SIMs more easily (especially when you want to program tens of them ... :) You can check it out at git://bs11-abis.gnumonks.org/pysim.git The currently supported models are : - Super Sim 12-in-1 (the format described in the OpenBSC Wiki) - Magic SIM (2010 model) - 'fake' Magic SIM (some counterfeits ?) Note that I have some marked 'SuperSIM' that need the 'Fake Magic SIM protocol'. In any case, just try 'auto' first and it'll try to autodetect. If you have a card for which that doesn't work, contact me please (or debug and fix it yourself :) I tested it with the 3 models I have here and it worked fine (tested IMSI, PLMN_Sel & Ki). (with the 2010 magic sim model, the ICCID isn't programmed but that has no impact ... and it's not programmed with the official software either ...) Here's the README for reference : This utility allows to : * Program customizable SIMs. Two modes are possible: - one where you specify every parameter manually : ./pySim.py -n 26C3 -c 49 -x 262 -y 42 -i <IMSI> -s <ICCID> - one where they are generated from some minimal set : ./pySim.py -n 26C3 -c 49 -x 262 -y 42 -z <random_string_of_choice> -j <card_num> With <random_string_of_choice> and <card_num>, the soft will generate 'predictable' IMSI and ICCID, so make sure you choose them so as not to conflict with anyone. (for eg. your name as <random_string_of_choice> and 0 1 2 ... for <card num>). You also need to enter some parameters to select the device : -t TYPE : type of card (supersim, magicsim, fakemagicsim or try 'auto') -d DEV : Serial port device (default /dev/ttyUSB0) -b BAUD : Baudrate (default 9600) * Interact with SIMs from a python interactive shell (ipython for eg :) import pySim sl = pySim.SerialSimLink(device='/dev/ttyUSB0', baudrate=9600) print sl.read_binary(['3f00', '7f20', '6f07']) # Print IMSI print sl.run_gsm('00112233445566778899aabbccddeeff') # Run A3/A8 ---------------- Sylvain

15 years, 8 months

[PATCH 1/1] Add a GURU import script for 26C3

by Daniel Willmann

Use it like this: ./26c3-guru-import.py hlr.sqlite3 <GURU_URL> This script will check if the imXi is an IMSI and authorize the subscriber. If it isn't it checks whether it's an IMEI that has an IMSI associated with it and authorize the first IMSI that was seen with that particular IMEI. It will not touch subscribers that are already authorized. --- openbsc/tools/26c3-guru-import.py | 90 +++++++++++++++++++++++++++++++++++++ 1 files changed, 90 insertions(+), 0 deletions(-) create mode 100755 openbsc/tools/26c3-guru-import.py diff --git a/openbsc/tools/26c3-guru-import.py b/openbsc/tools/26c3-guru-import.py new file mode 100755 index 0000000..99a982b --- /dev/null +++ b/openbsc/tools/26c3-guru-import.py @@ -0,0 +1,90 @@ +#!/usr/bin/python2.6 + +# Based loosely on hlrsync.py from Jan Lübbe +# (C) 2009 Daniel Willmann +# 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. + +from __future__ import with_statement + +import urllib +from pysqlite2 import dbapi2 as sqlite3 +import sys + +hlr = sqlite3.connect(sys.argv[1]) +web = urllib.urlopen(sys.argv[2]).read() + +# switch to autocommit +hlr.isolation_level = None + +hlr.row_factory = sqlite3.Row + +web = web.split("\n") + +# Remove last empty newline +# List of extension - imei/imsi tuples from GURU2 +web_tuple = [ (int(i.split(" ")[0]), int(i.split(" ")[1])) for i in web if len(i) > 0 ] + +for x in web_tuple: + exten = x[0] + imxi = x[1] + + # Enforce numering plan of 26c3 + if exten < 9100 or exten > 9999: + continue + + # Test if it is an IMSI and hasn't yet been authorized + subscr = hlr.execute(""" + SELECT * FROM Subscriber WHERE imsi=="%015u" and authorized==0 + """ % (imxi) ).fetchall() + + # Not an IMSI + if len(subscr) == 0: + equip = hlr.execute(""" + SELECT * FROM Equipment WHERE imei="%015u" + """ % (imxi) ).fetchall(); + #print equip + + if len(equip) == 0: + continue + + subscrid = hlr.execute(""" + SELECT * FROM EquipmentWatch WHERE equipment_id=%015u ORDER BY created LIMIT 1 + """ % (int(equip[0]['id'])) ).fetchall(); + + #print subscrid + + if len(subscrid) == 0: + continue + + subscr = hlr.execute(""" + SELECT * FROM Subscriber WHERE id==%u and authorized==0 + """ % subscrid[0]['subscriber_id']).fetchall(); + + if len(subscr) == 0: + continue + + subscr = subscr[0] + # Now we have an unauthorized subscriber for the imXi + print exten, imxi + print subscr + + # Strip leading 9 from extension and authorize subscriber + hlr.execute("""UPDATE Subscriber SET authorized = 1,extension="%s" \ + WHERE id = %u + """ % (str(exten)[1:], subscr['id']) ); + +hlr.close() -- 1.6.5.2

15 years, 8 months

Re: URGENT: range 1024/512/256 encoding of neighbor cell list required

by Dieter Spaar

Hello Harald, On Sat, 26 Dec 2009 09:37:20 , "Dieter Spaar" <spaar(a)mirider.augusta.de> wrote: > > Sorry, no time to code the algorithm, however here is a handcrafted > list: > > 0x83, 0x64, 0x5C, 0x00, 0xFF, 0x3F, 0xC0, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > It contains ARFCN 536, 540, 868, 870 und 871, I have not yet checked it > with a phone. I verified with two different phones that the list is correct. However Wireshark does not properly decode this format, it tells you that the ARFCNs are 448 and 868 (DTAP decoder). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years, 8 months

Re: URGENT: range 1024/512/256 encoding of neighbor cell list required

by Dieter Spaar

Hello Harald, On Sat, 26 Dec 2009 00:40:05 +0100, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > If anyone understands (and/or has time to implement) the specification > in GSM TS 04.08 10.5.2.13.3 / 10.5.2.13.4 / 10.5.2.13.5, or even the full > algorithm as specified in "Annex J: Algorithm to encode frequency list > information elements", I would be extremely grateful. Sorry, no time to code the algorithm, however here is a handcrafted list: 0x83, 0x64, 0x5C, 0x00, 0xFF, 0x3F, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, It contains ARFCN 536, 540, 868, 870 und 871, I have not yet checked it with a phone. I guess its OK to use it for all five BTS units, T-Mobile also includes the main BCCH ARFCN in the neighbor cell list, at least here in my area, so this should work for us too. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years, 8 months

statistics tools for OpenBSC

by Harald Welte

Hi all! I've just added some code to OpenBSC which keeps counters for various events, such as the number of channel requests, how often we were out of channels, the number of delivered/submitted sms, paging statistics, etc. Those counters are available through the VTY for evaluation at runtime. There is now a "Counters" table in our database schema. It stores those counters in a generic way. The counters are stored to the database every minute. Each counter is identified by a string like "net.sms.delivered" The counters increment all the time, until OpenBSC terminates, when they will re-start from zero. I did not want to make the counters persistent (i.e. load them from the database) as it would cofuse users of the VTY. What's still missing now is some kind of script that uses those counters to generate something like nice charts. Given the way how the counters are stored in the database, it should be relatively easy to write a fairly generic tool that does not need any modification even if we add new counters. What I'm thinking is something like specifying the specific counters one is interested in at the command line, maybe also providing a start and end time. The graphs should then generally show the increments of the counters between two counter stores in the database. So if e.g. one minute ago the number of delivered SMS was '10', and now it is '15, then the actual value plotted in the graph should only be '5'. The only "difficulty" is to handle restarts of OpenBSC... but that's quite easy. All counters are monotonically incrementing, i.e. whenever you see a smaller counter, you can safely assume that openbsc was restarted and that we simply continue with the next diff, ignoring the negative one. If anyone is interested in working in such a tool (preferrably in python or perl, using their respective sqlite3 bindings), it would be greatly appreciated. However, please do coordinate on this mailing list... your time is too precious to be wasted by code duplication. Thanks in advance, 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)

15 years, 8 months

URGENT: range 1024/512/256 encoding of neighbor cell list required

by Harald Welte

Hi! We've just finished most of the build-up of the GSM network at 26C3, and I've noticed that the ARFCN's that we've been allocated are further than 111 apart, i.e. we cannot use the 'variable bitmap' format that OpenBSC implements so far. If anyone understands (and/or has time to implement) the specification in GSM TS 04.08 10.5.2.13.3 / 10.5.2.13.4 / 10.5.2.13.5, or even the full algorithm as specified in "Annex J: Algorithm to encode frequency list information elements", I would be extremely grateful. Off to bed, will be yet another long day tomorrow. -- - 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)

15 years, 8 months

SMS status

by Sylvain Munaut

Hi, Here's a little report on the SMS status: First, the good news is that in practice everything works fine with the handsets I tested. There are a few issues left to address but they don't seem to cause any operational troubles so far : * In MO transfers, the channel should be closed after the reception of CP-ACK, _unless_ a CM SERVICE REQUEST was sent just before on the channel. Currently the channel is just not closed AFAICT and it times out some time afterwards. * Double RF Channel Release : Here's the log of the end of a typical SMS transfer (MO in this case but MT has a similar problem) : <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=3 DATA INDICATION <0007> gsm_04_11.c:918 trans_id=c RX SMS CP-ACK [ pause ] <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1138 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=3 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1138 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK As you see, when we receive a RELEASE INDICATION in abis_rsl_rx_rll, we call rsl_rf_chan_release directly. But we'll receive RELEASE INDICATION for both SAPI 0 & 3 and so we'll call it twice which is bad. I tried releasing channel _only_ if all SAPI are unused but the resulting effect was not what I expected : <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=3 DATA INDICATION <0007> gsm_04_11.c:927 trans_id=b RX SMS CP-ACK [ pause ] <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=0 RELEASE INDICATION [ pause ] <0004> abis_rsl.c:1137 (bts=0,trx=0,ts=1) <0004> abis_rsl.c:967 CONNECTION FAIL: RELEASINGCAUSE=0x01(Radio Link Failure) <0004> abis_rsl.c:975 <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1148 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK <0013> gsm_subscriber_base.c:subscr 35414 usage decreased usage to: 0 <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=3 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1148 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK I need to read the spec and see what happens on a commercial network to understand better what should be done because I'm obviously missing something ... Sylvain

15 years, 8 months

About the ipaccess-proxy

by Harald Welte

Hi all, I've committed a new program called ipaccess-proxy to openbsc git. It is - like the name implies - a proxy for the ip.access A-bis over IP protocol. Why would you want to do that? 1) to keep the BCCH live while you restart OpenBSC. This keeps the phones nice and happy on the network while you test/deploy new code 2) to inject packets into the A-bis stream, e.g. from a packet generation tool like scapy. ipaccess-proxy creates udp ports to do this. More documentation after the 26C3. -- - 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)

15 years, 8 months

christmas present

by WoMax

As a christmas present a friend of mine showed me some nanoBTS documents, I can't make copies but I remember some details I will post here ... LED status codes: red/steady: sw error, power-on fails orange/slow flash: ethernet disconnected red/fast blink: dongle attached, factory reset done red-green/fast flash: unit not configured orange/fast flash: code loading in progress orange/slow blink: TRX is waiting for OML orange/steady: self test in progress green/fast flash: OML established, NWL test running green-orange/slow blink: calibrating in progress green/slow flash: no radio carrier transmitted green/steady: operational state TIB pinout: Output-connector - pin 1-spare/fpga 2-spare/fpga 3-26mhz - 4-26mhz + 5-sync out + 6-sync out - 7-ppc serial out 8-ppc serial in 9-fpga serial out 10-gnd Input-connector - pin 1-10mhz in - 2-10mhz in + 3-26mhz in - 4-26mhz in + 5-sync in + 6-sync in - 7-frame sync 8-nc 9-reset 10-gnd A merry christmas, WoMax

15 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC