Hi All,
in the last couple of days I have implemented Software Loading for the
nanoBTS. Use this at your own risk but it is working here(tm).
Software Load is implemented as of the GSM 12.21 with some quirks and extra
messages compared to the BS11.
- BS11 got the length of the "length" wrong and it should have been
a short. ipaccess got this right so I needed to change that part
- For the nanoBTS in the SW Load Init and Load End message one needs
to add the SW_DESCR IE but without a length. 12.21 would probably
require the length but this is omitted. The other part is that the
file id must be set to "id\0" and the version to "version\ 0" or at
least was set like this in the example trace I had.
- Strings must be written with the '\0' in it.
- After the Software Load End ACK one needs to send a special
SET NVATTR to set the software as default. The message must
contain the ID and Version of two firmware parts. I'm not sure which
funtional part they relate to but they have the "more more magic"
ids of 0x1000 and 0x2001.
I have changed ipaccess-config to exit after the software load, or setting the
primary OML IP by handling the ACK and carrying a state. One can also chain
"-r" and the above two so the primary action will be executed first and then
the reset will be issue and with a reset ack/nack the app will exit.
With doing the above it becomes aware that we should change ipaccess-config a
lot, all the options you could enable should generate an operation and we
should put these into a queue and then execute them one after another and exit
once all of them are done but this will be a bigger project as we need some
more cooperation with abis_nm.c. Is anyone volunteering to fix the structure of
this small application helper?
regards
holger
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
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
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
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
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
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)
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)
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
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)