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)