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(-)
Hi Harald,
I have a stack corruption due the above method and here is my analysis of the
problem...
set_system_infos is having a u_int8_t array with 23 bytes on the stack and is
asking to generate system infos into this array...
Now what happens is:
1.) some system information types structs are already bigger
than the 23 bytes...
2.) this does not take the rest octets into account..
I would like to fix it like this:
1.) Turn bitvec_spare_padding to return void
2.) In the rest_octets_siX method return the bit_vec.data_len
3.) Change the generate_siX to return the sizeof the struct
+ return value of the rest_octets_siX instead of the fixed
MACBLOCK_LEN (23)
4.) always use this rc value instead of the size of the buffer...
(due to 1. of the above we set truncated values as well)
do you have a better idea? would you just increase the buffer size?
z.
Hi first i wan't to intoduce myself, i m henrik and am from germany.
my english isn't good as is should be but i hope everyone can understand
me. :)
I'm searching for a Siemens BS-11 GSM1800.
Why?
Im the technical operator of the biggest summer-camp in lower saxony /
germany of youth-fire-fighters.
I know hard to understand. :D
My plan is it, to operate a GSM zell on our camp next year.
some background informations:
-2000 youth member at the camp-ground.
-up to 200 tecnical supporters.
-300 youth supporters.
more informations about the event 2009: http://www.zeltlager-2009.de/
The Mainorganisators of the camp know about this idea, and are willing to
get a short-time licence for the event. The first contact to the
"Bundesnetzagentur" is already done.
What can i give the openBSC community?
A place to test / benchmark OpenBSC.
Also i'm a c / php developer and maybe i can help develope some external
features for openBSC.
Greetings from cold old Germany
Henrik
Dear List,
some entities in the GSM Industry seem to have started to discredit our efforts
for an Open Source implementation of GSM protocols.
In order to prove them wrong and demonstrate the usefulness of OpenBSC, I would
like to ask everyone who uses OpenBSC in a commercial or educational context
(companies, universities, schools) to show their support by writing a letter
of support.
This is a way how you can contribute back to the OpenBSC project, even without
writing any code.
Simply put a couple of sentences on your letterhead where you explain that you
use OpenBSC, and if or how you think it is a useful tool for your research
and/or development.
I will collect those letters and forward them to those who try to discredit us,
and if that is not sufficient, put the letters on the project homepage and
take that dispute somewhat more public.
I'm looking forward to your letter.
Thanks for your support!
--
- 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 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)
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
Hi everyone,
I've just pushed a branch sylvain/encryption on the OpenBSC git that
contains my current patches to support encryption.
Even if you don't have programmable SIMs, test it still works :) If a
subscriber doesn't have a Ki set in the HLR or encryption isn't enabled in
the config, the executed code path should be the exact same as before.
It uses COMP128 as a3/a8 so you can use common programmable SIMs. Currently
a secure channel is established for
- LOCATION UPDATEs
- CM SERVICE REQUEST.
Support for PAGING RESPONSE is a little trickier and I haven't looked deeply
into it.
To enable :
- Either recreate your HLR sqlite3,
or update it like this (do a backup before hand !) :
bash# sqlite3 hlr.sqlite3
sqlite> ALTER TABLE Subscriber ADD COLUMN ki BLOB;
sqlite> UPDATE Meta SET value = '3' WHERE key='revision';
- Add a "a5 encryption 1" line to your openbsc.cfg to enable encryption
using A5/1
- Set the Ki of the subscriber. Using the vty interface is the simplest :
bash# telnet 127.0.0.1 4242
openbsc> enable
openbsc# conf t
openbsc# subscriber YOURIMSI
openbsc# ki 0123456789abcdef0123456789abcdef
Sylvain
Beware!
Ciphering on nanoBTS is depending on the installed software.
If you have a model 139/140 and the software is 120a... the A5/1 and A5/2
encryption is available;
120b... is A5/2 only and
120c... there is no encryption available.
When you have a model 108/110 the software should start with 119 and with
model 165 it starts with 168.
Dear Daniel and Jan,
you have been working very closely with and on the u-blox GPS receiver
during your work on the Openmoko GTA02.
As far as I know, it is possible to obtain the ephemeris data from a u-blox
receiver.
I would like to see some code that obtains and converts that ephemeris data
into the format described by the RRLP protocol specification. I know this
involves asn.1 PER ugliness, but this can all be done well outside the OpenBSC
codebase.
What I'll propose is to simply use some pattern matching to determine the RRLP
request for assistance data, and if such a request exists, open some file in
the filesystem and send the contents binary as-is to the phone in response.
Any responses from the phone are already stored in the database anyway.
In case any of you are interested in working on something to generate the
required ephemeris data and have time before or even at the 26C3, you can
simply give me the resulting binary file, I can drop it into the OpenBSC
directory and we'll see what happens.
If this doesn't happen right now, it doesn't matter all that much, as the 26C3
is an indoor event and I don't think we'll be getting that many GPS fixes
in such an environment anyway. But eventually, for the next outdoor test,
and to do some more RRLP security research, the ephemeris data formatter
would be really great!
Cheers,
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)
If there is a solution for UMTS (W-CDMA) coming, we don't need the expensive
nanoBTS anymore.
BTW I've still one for sale ... see at http://umts.zerber.us
There are cheap W-CDMA BTS's out there, like Netgear DVG834GH, AT&T 3G
Microcell, Alcatel-Lucent 9365 or the Vodafone Access Gateway you can buy in
England for just 160 GBP each.
All the femtocell's I know have built in GPS for timebase and security
reason, so there is a lot to do for our purpose ...
I guess the future is W-CDMA and I hope there will be openUMTS available
soon ;-)
Regards from Switzerland
Hi Holger,
I'm happy with the new architecture. During testing I made a couple of bug
fixes, which I applied to the new 'new-debug-arch' branch in the root directory
of the git branch namespace. (i.e. not prefixed with holger/).
It would be great if you could finish this work so we can benefit of it
before the congress.
I'll probably merge some initial parts already now (at least the new macro
definitions) to start using log levels in the actual code - even if it
doesn't get used yet.
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)
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)
From: Sylvain Munaut <tnt(a)246tNt.com>
If a RF channel is assigned but no response is ever heard from
the phone, we will receive a CONNECTION FAIL from the BTS,
triggering a RF release freeing the channel. Then sometime later,
T3101 will expire as well and free the channel again ...
Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com>
---
openbsc/src/chan_alloc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/openbsc/src/chan_alloc.c b/openbsc/src/chan_alloc.c
index 786e8b1..a23192a 100644
--- a/openbsc/src/chan_alloc.c
+++ b/openbsc/src/chan_alloc.c
@@ -251,6 +251,7 @@ void lchan_free(struct gsm_lchan *lchan)
/* stop the timer */
bsc_del_timer(&lchan->release_timer);
+ bsc_del_timer(&lchan->T3101);
/* clear cached measuement reports */
lchan->meas_rep_idx = 0;
--
1.6.5.1
Hi!
Just a "quick" status report about the progress I've made with the code
over the last three days, and what is now in 'master':
1) handover is not only working on a signalling level, but also fully working
with actual voice traffic
This turned out to be a major headache, since we don't [yet?] have a proper
RTP media gateway and so far decided to simply relay the RTP frames rather
than doing proper processing. In case of handover though, the RTP source
changes (different SSRC / timestamp / sequence) - plus we also get some
dropped frames and have to ensure that we don't hide that fact from the
receiver.
In order to make it work, I added a new "MNCC RTP Proxy" mode, which is
automatically selected if you
a) enable the RTP Proxy mode with "-P" on the command line, and
b) enable handover using the 'handover 1' command on the VTY
The Handover decision (handover_decision.c) is currently still based on
a single MEASUREMENT REPORT, i.e. way too volatile. This was intended
for testing, where we need as many handovers as possible.
I've meanwhile written a lot of additional code to implement proper measurement
averaging and neighbor cell selection. This is not committed yet, but
will be committed by tomorrow.
2) Support for MNCC (lcr) with RTP based BTS is in 'master'
There's no need for any old branches or patches for this anymore
3) Support for EFR frames with RTP based BTS in MNCC
4) No half-rate support at 26C3. The integration with lcr is likely
too much work, and I think we should try not to implement even more
features that have not yet received lots of testing
5) fixing tons of compiler warnings all over the code
6) fix segfault in RRLP in case of unsuccessful paging (sorry sylvain,
I fixed this independently before seeing your patch, but I actually
prefer your solution, will look at it tomorrow)
7) correct System Information Type 5 and 6 on ip.access
The two BTS types implement the RSL SACCH FILLing slightly different,
resulting in broken neighbor cell lists on ip.access systems.
Any testing of current master that you can do is very much appreciated,
let's hope we can catch more bugs before we go live at 26C3.
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)
Hi,
I have a nanobts unit 139 with a software that somehow only accepts GSM FR
(and not EFR), unless I also send the RTP payload type IE (
RSL_IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the "RTP
payload type" IE, the "RTP payload type 2" has no effect I can see).
hi,
here are two patches (attached):
the lcr_rtp.fix will make the current lcr_rtp branch compile. also it
works with LCR.
the systeminfo.fix contains a pointer fix and a question why there is a
value cleared again. (don't apply it, just apply the line with the
pointer fix)
regards,
andreas
Here's a small series with some minor fixes I found when looking at multiple
SMS in a single RR connection.
For the MO case, it actually now works as described in the spec in the
no-error case. But what can happen is that after the second
CM SERVICE REQUEST, we may never receive the last CP-ACK of the previous
transaction (and thus leak a transaction). The spec says than when receiving
a CP-DATA after a CM SERVICE REQUEST we should consider we also implicitely
received the last CP-ACK of the previous transaction ... that's not
implemented yet.
For the MT case, it currently makes several RR connection which is quite
bad ... to be fixed.
Sylvain
Is there anyone well knowing about the signaling part in openbsc project
there might be interested in the solving of a few specific tasks against
payment?
the results will be posted in the openbsc project also.
Please contact me.
Med venlig hilsen / Best regards
Kasper Hessellund Hansen
Denmark
Khh at viptel.dk
Is there anyone well knowing about the signaling part in openbsc project
there might be interested in the solving of a few specific tasks against
payment?
the results will be posted in the openbsc project also.
Please contact me.
Med venlig hilsen / Best regards
Kasper Hessellund Hansen
Denmark
Hi Andreas + List,
I have now studied the new "RTP capable" lcr integration in detail. My
sincere apologies once again for the long delay that this has been taking
me.
I really like the interface (like its predecessor). The major restriction
at the moment seems to be its limitation to support only GSM Version 1
Full Rate.
After doing some testing with the current 'lcr_rtp' branch in git, as well
as the attempt to integrate handover support with the lcr/mncc interface,
I am considering to add support for other codec types, too.
GSM EFR (only exists in full-rate) is interesting for everyone, as almost
all phones support it, and it renders significantly higher quality.
GSM V1 halfrate is important for BS-11 users who want increased capacity, since
this BTS does not support AMR-halfrate.
GSM V1 full-rate is important for ip.access, since it is the only half-rate
codec it supports, and thus the only way to increase capacity for this BTS.
GSM AMR full-rate is probably of the least interest, but still nice to have.
For the 26C3, I would love to run in a EFR-fullrate and AMR-halfrate
configuration, depending on the phone's capabilities.
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)
Hi!
I've just committed the current state of the handover code to git.
What is working so far:
* receiving + parsing the measurement reports from both MS and BTS
* performing the actual handover process, i.e. allocating / activating
the new logical channel on the new BTS, waiting for the ACK, sending
handover command to the MS, waiting for HO complete, HO fail or timeout,
...
* a minimalistic handover decision making. without any averaging: If we
have a cell that's >= 3dB better than the current one, try a handover.
What's missing:
* switching the actual traffic channel contents (i.e. re-configuring the RTP
streams in the ip.access case, or reconfiguring the TRAU mux in E1 case)
* better handover algorithm implementation including averaging
I'm on a business trip tomorrow, but the code is already seeming to work quite
fine, and it looks like:
<0400> abis_rsl.c:980 MEASUREMENT RESULT NR=13 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 10dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-61dBm RXL-SUB-dl=-56dBm RXQ-FULL-dl=6 RXQ-SUB-dl=4 NUM_NEIGH=1
<0400> abis_rsl.c:1010 ARFCN=868 BSIC=63 => -70 dBm
<80000> handover_decision.c:61 process meas res: No better cell
<0400> abis_rsl.c:980 MEASUREMENT RESULT NR=14 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 10dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-87dBm RXL-SUB-dl=-83dBm RXQ-FULL-dl=6 RXQ-SUB-dl=4 NUM_NEIGH=1
<0400> abis_rsl.c:1010 ARFCN=868 BSIC=63 => -69 dBm
<80000> handover_decision.c:61 process meas res: Cell on ARFCN 868 is better, starting handover
<80000> handover_logic.c:92 (old_lchan on BTS 0, new BTS 1): <0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE ACK
<80000> handover_logic.c:151 handover activate ack, send HO Command
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 2 pd 06) Sending 0x2b to MS.
<0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1082 HANDOVER DETECT access delay = 0
<0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1082 HANDOVER DETECT access delay = 0
<0001> abis_rsl.c:1396 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a sapi=0 ESTABLISH INDICATION
<0001> abis_rsl.c:1396 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a sapi=0 DATA INDICATION
<0008> gsm_04_08.c:1595 HANDOVER COMPLETE cause = Normal event
<0002> handover_logic.c:203 lchan (bts=0,trx=0,ts=2,ch=0) decreases usage to: 0
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)
Dear All,
as you will know, we have applied for an experimental GSM license for the
26C3 (http://events.ccc.de/congress/2009/).
Last week, the license was granted. However, only two ARFCN's have been
granted (I applied for 8). As it turns out, this was a communication problem.
Today they have acknowledged a third ARFCN. So we can have at least one
single-TRX BTS on each floor. On wednesday they will determine whether
we can have more than three, or if we'll have to live with three ARFCN only.
If we get 6, it will be one dual-TRX BTS for each floor. If we get even more,
the surplus ones can be used for random experiments.
TODO items before 26C3 (for the next couple of days):
* finish handover implementation (critical)
* do some more testing with LCR integration (Andreas did it, but I also want
to have more hands-on experience with it)
* introduce log levels and/or per-subscriber tracing functionality to
"see the signal among all the noise" while debugging problems in an otherwise
busy network
* ensure SMS implementation is more robust than at HAR
* log all measurement reports to database for later analysis of handover
performance. We could also get them from pcap files, so not strictly
neccessary.
Optional:
* finish AMR-halfrate implementation, as this will increase our capacity.
This includes dynamically selecting the codec that is used for each call.
I don't think we'll manage finishing this, especially with the LCR
integration. Standalone might be possible - but that is useless for 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)
> Does it means that we won't be able to do OpenBTS experiments there?
> We planned to test new USSD code in OpenBTS and it will be a shame to
> cancel this plans.
i think, if you don't transmit "too loud", i.e ranges lower than a few
meters, no one would care. i use a leaky dummy load for testing.
Hye everyone,
i'm trying to build a small GSM Network using OpenBSC and nanoBTS.
After the start of bsc_hack, when i try to scanned the network with my
mobile station, i do find the right network. But when i try to
register into this network, i'm not coming through. It's the first
time that i'm trying to used OpenBSC and i do not exactly known how it
works.
below, a part of the output coming out after the start of bsc_hack:
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS.
DB: Failed to find the Subscriber. '0' '262##########'
DB: Failed to find the Subscriber. '0' '262##########'
DB: New Subscriber: ID 28, IMSI 262##########
DB: Allocated extension 43234 for IMSI 262##########.
<0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0
DATA INDICATION
<0004> gsm_04_08.c:948 IDENTITY RESPONSE: mi_type=0x02 MI(35#############)
DB: New Equipment: ID 124, IMEI 35#############
DB: New EquipmentWatch: ID 124, IMSI 262##########, IMEI 35#############
DB: Sync Equipment IMEI=35#############, classmark1=30
<0010> abis_rsl.c:1273 Activating ARFCN(514) TS(0) SS(1) lctype SDCCH
chan_nr=0x28 r=LOCATION_UPDATE ra=0x10
<0010> abis_rsl.c:1088 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CHANNEL
ACTIVATE ACK
<0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 sapi=0
ESTABLISH INDICATION
<0004> gsm_04_08.c:1402 LOCATION UPDATING REQUEST: mi_type=0x04
MI(23########) type=NORMAL <0002> gsm_04_08.c:293 lchan
(bts=0,trx=0,ts=0,ch=1) increases usage to: 1
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS.
DB: Found Subscriber: ID 28, IMSI 262############, NAME '', TMSI
42########, EXTEN '43234', LAC 0, AUTH 0
DBI: The requested variable type does not match what libdbi thinks it
should be
libdbi: dbi_result_get_int_idx: field `classmark1` is not integer type
<0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0
DATA INDICATION
<0004> gsm_04_08.c:948 IDENTITY RESPONSE: mi_type=0x02 MI(35#############)
DB: Updated EquipmentWatch: ID 124, IMSI 262############, IMEI 35#############
DB: Sync Equipment IMEI=35#############, classmark1=30, classmark2=13
25 , classmark3=13 25
<0010> abis_rsl.c:1273 Activating ARFCN(514) TS(0) SS(1) lctype SDCCH
chan_nr=0x28 r=LOCATION_UPDATE ra=0x06
<0010> abis_rsl.c:1088 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CHANNEL
ACTIVATE ACK
<0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 sapi=0
ESTABLISH INDICATION
<0004> gsm_04_08.c:1402 LOCATION UPDATING REQUEST: mi_type=0x01
MI(262############) type=NORMAL <0002> gsm_04_08.c:293 lchan
(bts=0,trx=0,ts=0,ch=1) increases usage to: 1
can someone please explains me if those outputs (about the Subscriber
ID '28') are OK?
Best regards;
--
Fabrice Ismael Poundeu Tchouatieu
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Hi List,
i am searching for a used or new nanoBTS. Best would be an 900Mhz Model,
but i take 'everything' i can get.
I tried the Haralds Contact, but from there i didn't get any response.
It seems that they are not willing to sell anything. :(
Regards
Axel
Hi,
Attached is a direct port of the IML dissector code from the ip.access
code to wireshark SVN head with a few changes to make it work with the
current API. This was done as part of Harald's GSM workout during
FOSS.IN and he suggested I post it to this list. I haven't really
tested this code since I dont have access to IML traces, but assuming
the original code worked, this one should too.
Hope this is possibly useful to someone :)
--
Jai Menon
The patch is attached ("bugfix").
You can simply merge the stefreak/trivia branch (but there is one more
change in it, see the second patch attached. abis_nm.c was
executable, that's a really trivial change).
Greetings,
Steffen
Hello Paul,
On Thu, 03 Dec 2009 17:51:45 +0000, "Paul Dolan" <paul(a)dolan.ie> wrote:
>
> Any other ideas/things to try/etc. would be greatly appreciated!
Can you check the "PLL set" and "PLL work" values with bs11_config ?
If the BS-11 is locked to the E1 clock, it could be that the
clock of the BS-11 is too far away from the correct value so
that a phone will only find the official networks but not the
one of the BS-11.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Paul,
On Wed, 02 Dec 2009 22:36:53 +0000, s4dd(a)losers.yore.ma wrote:
> Any help you guys could give is much appreciated!
I think the problem is the "Invalid Channel Combination!!!"
error message. Try to change "phys_chan_config" of timeslot
1 from "SDCCH8" to "TCH/F". From my understanding of
verify_chan_comb() "SDCCH8" is not allowed on the same TRX that
already has "CCCH+SDCCH4" so I wonder why it is set in the
config file (this only applies to the BS11). Sorry, I don't
have a ready BS11 configuration at hand right now, so I can't
test it.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello David,
On Thu, 3 Dec 2009 01:07:56 -0800, "David A. Burgess" <dburgess(a)jcis.net> wrote:
>
> I don't know if that's valid by the spec or not, but it's part of a
> pretty standard configuration in IMSI-catchers: CCCH+SDCCH4 +
> 6*SDCCH8 + TCH/F. That maximizes location updating capacity and
> leaves one TCH/F for other ... mischief. Most of those IMSI-catchers
> are based on commercial mini/nano-BTS equipment.
Thanks for this input. I think this a limitation of the BS11 only,
I have read that there are some limitations related to the SDCCH/8
of the BS11:
- only one SDCCH/8 per TRX
- not allowed together with SDCCH/4 on BCCH-TRX
Maybe the BS11 does not have enough processing power to handle it ? Of
course it could be that the documentation is wrong and it would work, I
have not yet tried it.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
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)