Hi!
I've now merged the 'laforge/hopping' branch to master, and wanted to update
you on the state of frequency hopping support:
First, the bad news: It is still not working with the BS-11 :(
All OML attributes that I can think of are set correctly, they have been
verified from wireshark, and the BTS acknowledges all those attributes.
On RSL, the channels are activated the right way, and even the SYSTEM
INFORMATIO 1 (cell channel allocation) as well as the chennel description and
mobile allocation parts of the IMMEDIATE ASSIGN are encoded correctly.
Still, the MS and BTS fail to establish any hopping channel. Dieter is now
trying to get the BS-11 hopping configuration working with his Racal 6113.
If that works, the protocol trace should reveal where we still do something
wrong.
If you want to play with it: The BTS attributes as well as the TRX attributes
are not yet 100% finished like they should be. So you need to apply the
attached patch as a hack on top of master. Please note that the
bs11_attr_radio_trx1 contains hard-coded ARFCN 117 and 119, i.e. you will
have to modify this unless your hopping sequence also only consists of those
two ARFCN.
I've also attached a config file for your reference.
--
- 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)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, list!
I have a NanoBTS connected to my KUbuntu Hardy.
I compiled the last version of OpenBSC from GIT (0.9.0.860-71d36) and
it runs.
Now, if I give (from Telnet) the command "sms send pending" I get in
the Log the following message:
<0012> db.c:157 DBI: 1: ambiguous column name: id
And, if I send a "subscriber" command (extension, name, etc.) I get:
<0012> db.c:157 DBI: 1: ambiguous column name: updated
Maybe there are some problem with the SQL-queries?
The same version on Debian lenny does not have problem.
Thanks a lot!
- --
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFMG20/AXzltVKV/2wRAmF6AKCTrG6E8Tw2yYN5fx1nECuv/9UYwQCgsOE0
1CMPlGxfpXa4WlEtHwa+ciA=
=63FZ
-----END PGP SIGNATURE-----
Hi!
This is to all those BS-11 users out there: What was the last version
(git version number preferrably) of OpenBSC that has been working fine
for you?
I've tried today. Everything seems to work fine from the OpenBSC side,
i.e. OML and RSL are initialized. On the Air interface howerver, I can
only see the carrier (RxLev) on the ARFCN go high, but the phones never
get further than decoding the BSIC. They don't list the network in the
network selection, and they never consider selecting this cell if it is
part of a bigger network.
I thought of some problem in the SYstem Information, but after checking them
manually in wireshark (from the bsc_hack generated pcap file), there seems
no obvious mistake.
So I'm suspecting some kind of regression in current OpenBSC. Thus my
question for feedback: Which version did you last use successfully with
the BS-11?
Thanks,
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 landed the first big change, the gsm48_rcvmsg is now inside the
bsc_api.c. And on first msg the BSC API will call the compl_l3 (COMPLETE
LAYER3) callback. This method will always be called for any new
connection and is the perfect place to enable encryption..
I would be very happy if someone could take the task and change the
osmo_msc.c and gsm_04_08.c to first make use of the ACCEPT/REJECT policy
and then enable the auth/security on this new connection and then
dispatch the original message (but CM Service Reject).
Another task would be to move the Cipher Mode code into the BSC API, the
gsm_04_08.c code should not directly change the attributes in the lchan
and should not send the cipher mode RR message.
The next thing to kill is the unconditional usage of &lchan->conn as I
will start allocating the conn dynamically... (one conn can have
multiple lchan's for handover and early assignment).
I will now work on refcounting and moving the transaction into the
subscriber connection...(some other work before) so I will probably not
make it before sunday as I will be out of town.
regards
holger
diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c
index 57d8089..faa5f69 100644
--- a/openbsc/src/gsm_04_11.c
+++ b/openbsc/src/gsm_04_11.c
@@ -340,14 +340,14 @@ static unsigned long gsm340_validity_period(u_int8_t sms_vpf, u_int8_t *sms_vp)
/* ignore additional fi */
if (fi & (1<<7)) sms_vp++;
/* read validity period format */
- switch (fi & 0b111) {
- case 0b000:
+ switch (fi & 0x7) {
+ case 0x0:
return gsm340_vp_default(); /* no vpf specified */
- case 0b001:
+ case 0x1:
return gsm340_vp_relative(sms_vp);
- case 0b010:
+ case 0x2:
return gsm340_vp_relative_integer(sms_vp);
- case 0b011:
+ case 0x3:
return gsm340_vp_relative_semioctet(sms_vp);
default:
/* The GSM spec says that the SC should reject any
----------
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Donnerstag, 17. Juni 2010 16:26
An: openbsc(a)lists.gnumonks.org
Betreff: Re: Problem compiling OpenBSC on Kubuntu Hardy
On 06/17/2010 10:20 PM, Luca Bertoncello wrote:
> Hi, List!
>
> gsm_04_11.c:364:8: Fehler: ungültiger Suffix »b011« an Ganzzahlkonstante
Your compiler does not like to have numbers in binary, please prepare a
patch (I say that once a month and then nothing happens) to use these in
hex.
-------- Original-Nachricht --------
> Datum: Tue, 15 Jun 2010 21:02:12 +0800
> Von: Holger Freyther <zecke(a)selfish.org>
> An: openbsc(a)lists.gnumonks.org
> Betreff: Re: open bsc and lcr: layer_3 thread read socket error
> On 06/15/2010 08:19 PM, Richard Zahoransky wrote:
> > Hello,
> >
> > my name is Richard and I am working on OpenBSC and LCR for my
> university. We plan to deploy a GSM-Network on the campus for research.
>
> Hi,
>
> where is that university located?
It is the Albert-Ludwigs-Universität in Freiburg, Baden-Württemberg, Germany.
> I can't help with LCR but as a general
> hint you can use strace and at least see which filedescriptor returned
> that error, it might be a hint.
>
> Have you tested the BTS with something like bsc_hack? Does this work?
>
Yes, bsc_hack works with no problems.
Thank you for your advice! We have solved the problem. We simply didn't load the mISDN_dsp module. We did not integrate the mISDN_l1loop into the kernel but start it with insmod mISDN_l1loop.ko (located in a subfolder of the mISDN-Folder after running 'make')
Still, if we load the l1loop with -nchannel=30 the lcr would somtimes print out the already said error message but it doesn't hang. It is then still possible to place a phone call from the cell phones. As workaround, we load the module with 8 channels instead of 30. It seems to work without the error message.
Only one error is left. LCR prints:
'ERROR Port 1 already in use by LCR. You can't use a NT port multiple times.'
On startup. Outgoing calls work but we still have to test incoming calls.
Hi all,
here is just a small information of what is going on and what will
happen in the near future.
Done:
- Create bsc_api.c for the BSC API handling
- Create osmo_msc.c for the callbacks...
- Start to remove lchan usage from MSC code
What will happen:
- No MSC code will directly touch/use/know about the lchan
- Move the gsm48_recvmsg into the BSC API and dispatch
- The transaction will be anchored inside the subscriber con
and no transactions will clear the channel immediately
- Need to add API for Cipher, Handover, Assignment handling
- pick a better name for subscriber_connection.
What can happen after this:
- We can reimplement the bottom of the BSC API with SCCP
and have a true MSC codebase...
If any of you is adding new L3 code, please do not use the LCHAN
directly but the subscriber connection.
thanks
holger
>1.) kill the transaction...
>2.) generalize it with the "operation". Right now we do have two
>operations, one for LU, one for AUTH, we should have them for USSD, SMS
>and CC as well.
hi holger,
the "transaction" represents the instance of calling party / called
party / sms sender / ... will the states of it be moved to the
"operation"? (e.g. call state, transaction_id, callref, protocol) in
this case the call control / sms must use "operation" instance instead.
i currently use "transaction" in osmocom-bb for call control and later
sms and supplementary services. i think that the sms code should be
re-usable in osmocom-bb, so the "operation" instance should be equal
(defined in libosmocore) and the sms function sould be available in
something like a "libsms", like the "libvty". note: osmocom-bb is at a
point where SMS could be sent and received, if a shared sms library
would be available.
andreas
Hello,
my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research.
We have successfully installed OpenBSC, Asterisk, LCR and mISDN. Lcr starts correctly (as far as I can say). The nanoBTS connects to OpenBSC and boot up. On the local machine, we can place outgoing calls with asterisk but when we dial from the cellphones, the lcr prints out: "layer3_thread read socket error No space left on device". I don't know if this is an error in LCR, OpenBSC, mISDN or just in my own config files.
We ran through the How-to "OpenBSC_LCR" on http://openbsc.osmocom.org/trac/wiki:
gsm is enabled in options.conf
GSM interface is active in interface.conf
mISDN_l1loop interfaces are created
and the routing.conf looks also as described:
----------------------routing.conf (lcr)----------------------
[main]
interface=GSM : remote application=asterisk context=btsctrl
#interface=xyz : goto ruleset=xyz
extern : goto ruleset=extern
intern : goto ruleset=intern
: disconnect cause=31
-------------------------------------------------------------
the rest of the file is untouched.
on the local asterisk, the chan_lcr.so is loaded.
the context btsctrl is defined is the extensions.conf:
----------------------extension.conf (asterisk)--------------
[default]
exten => _0.,1,Dial(SIP/10${EXTEN}@comsys02)
[btsctrl]
exten => _X.,1,Set,CALLERID(num)=5552342
exten => _X.,n,dial(SIP/10${EXTEN}@comsys02)
-------------------------------------------------------------
it connects to the remote asterisk server as user comsys02, defined in sip.conf
----------------------sip.conf (asterisk)--------------------
register => comsys02:xxx@132.230.4.8/comsys02
[general]
port=5060
bindaddr=0.0.0.0
[btsctrl]
type=friend
context=default
secret=xxx
host=dynamic
[comsys02]
type=friend
context=btsctrl
username=comsys02
fromuser=comsys02
secret=xxx
host=132.230.4.8
qualify=yes
nat=yes
-------------------------------------------------------------
now everything seems to work, but when i dial a number, it prints out: "layer3_thread read socket error No space left on device", many times per second. On the phone I hear static noise. lcradmin prints out the following:
ACTION (match) action remote line 8
EP(1): ACTION remote (setup) number 076719235 remote as*
EP(1): SETUP ACKNOWLEDGE to CH(1)
EP(1): TONE to CH(1) directory default name dialing
EP(1): TONE to CH(1) directory default name cause_10
EP(1): DISCONNECT to CH(1) cause value=16 location=1-Lo*
CH(1): MNCC_DISC_REQ LCR<-BSC port 1 progress coding=3 *
CH(1): MNCC_REL_IND LCR<-BSC port 1 cause coding=0 loca*
EP(1): RELEASE from CH(1) cause value=31 location=1-Loc*
EP(1): ACTION hangup
and the local asterisk output is:
NOTICE[10941]: chan_lcr.c:1731 handle_retry: [call=NULL ast=NULL] Retry to open socket.
NOTICE[10941]: chan_lcr.c:364 send_message: [call=NULL ast=NULL] Sending MESSAGE_NEWREF to socket.
maybe someone also encountered this problem or can help us with the configuration
many thanks in advance and best regards,
richard
