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)
