Hi!
Collin Mulliner, Tobias Engel and myself have been meeting yesterday to
discuss a generic application interface for OpenBSC.
They are both doing security analysis and want to achieve a clean way
how an external application can get access to a more or less transparent
communication channel to the phone.
The purpose of this is to be able to send intentionally malformed
packets to the mobile phone GSM stack at various different levels within
the stack.
As of now, they have both hacked some custom code into openbsc that gets
them half way where they want to be - but not quite all the way.
The requirements can be summarized as follows:
1) Ability to establish a SDCCH or TCH channel by paging the phone
As of now, the 'silent call' feature from the VTY already does this.
2) Ability to send arbitrary layer3 protocol messages to the phone
Adding this is relatively easy (use rsl_sendmsg on the lchan from the
silent call)
3) Ability to receive responses from the phone, as well as error
conditions such as 'readio link failure'. We don't have a solution
for this yet, and we also have no clean way to identify what might
be a response from the phone to the external app, and what might
be a message from the phone to the normal network code in OpenBSC
4) Ability to selectively disable partial protocol handling in
OpenBSC. Let's say you want to play with the mobile phone call
control implementation. In this case, you want to make sure all CC
related messages go from/to the external program and not from the
regular OpenBSC network code.
So what I've been thinking of as a solution to the problem:
* store a bypass_flags bitmask related to the subscriber structure,
where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC,
BYPASS_SAPI3.
* if we process an incoming message from the MS in gsm0408_rcvmsg(),
we check if a bypass flag matching the message is found. If yes,
forward the message to the external program
* if we want to send a message from our own protocol stack to the MS,
we check if a bypass flag matching the message is found. If yes,
we drop the message that we were about to send.
* any messages received from the application will be forwarded to the MS
The application interface protocol will likely have a close resemblance
to RSL RLL. We need to exchange the following primitives with the
application, like:
* ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI)
* ESTABLISH CONFIRM -- network confirms a channel has been established
* ESTABLISH INDICATION -- network tells app connection was made by MS
* [UNIT] DATA REQUEST -- app requests data to be sent to MS
* [UNIT] DATA INDICATION -- network indicates data was received from MS
* ERROR INDICATION -- network tells app something went wrong
* RELEASE REQUEST -- app asks network to release channel
* RELEASE CONFIRM -- net tells app that channel was released (as rqd)
* RELEASE INDICATION -- net tells app that channel was released (by MS)
The channel_number of RSL (indicating on-air timeslot) doesn't make much
sense in this context, of course.
The link_identifier on the other hand is great as it allows the app to
indicate SDCCH/FACCH or SACCH as well as the SAPI.
The actual RSL-like protocol would be encapsulated by UDP and available
on a socket of the MSC.
What do you think?
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)
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!
I'm getting to a point where we need to associate more and more state
and/or references with every individual msgb.
In the circuit switched BSC case, every message (msgb) is associated with
a logical channel (lchan) through which it is sent.
However, in the packet switched case, this is not the case. Rather, a msgb
is received on a particular NS-VC, inside a particular BSSGP-VC, inside a LLC
session, etc.
When we pass a msgb through the protocol layers and back, we somehow need
to identify where to send the response to. Once we actually reach the
04.08/04.11 layer, things become a bit less difficult. In the end, all
messages are at least somehow associated with a 'subscriber'.
If a message passes from the UDP socket into the NS protocol and into BSSGP, we
need to know the BSVCI and NSVCI if we want to send a response back. One
option would be to pass those values as explicit function call arguments,
which is partially what my current code is doing. But the more layers we traverse, the longer the function arguments get.
Furthermore, there are parts of our protocol (04.08 and 04.11 particularly)
that can either be transported on top of 08.58 (RSL) or LLC/BSSGP/NS. Those
upper layers shouldn't really care what the underlying transport looks like.
One possible option is to somehow identify the NS-VC and BSSGP-VC by putting
an identifier or pointer into a 'struct msgb' member. This would require
libosmocore changes every time we add some bits here or there.
Another option is to introduce something similar to the skb->cb in the
linux kernel: A 'control buffer' area of unspecified content provide by the
core networking code as part of every sk_buff, which gets type-casted
to the IPCB or TCB-CB when the msgb enters the respective protocol layer.
The advantage is that we could have one msgb structure definition with the
typecasting functions/macros being part of the application (e.g. openbsc)
The problem with this is: Its scope is limited to whatever is the current layer
of the protocol stack. The IPCB is overwritten with the TCBCB once the
message enters TCP.
In our case, we would actually want to have the associated data to persist
even while the msgb passes from one layer into another. This would mean
that there is a more-or-less static structure containing all the various
identifiers, which is then typecasted to the control buffer.
While this might not be ideal, it definitely keeps the details hidden
away from libosmocore, which is good.
Any comments are welcome,
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)
>> output of "misdn_info"
>Found 2 ports
> Port 0 'mISDN_l1loop.1': TE/NT-mode PRI E1 (for phone lines & E1
devices)
> 30 B-channels: 1-15 17-31
> B-protocols: RAW HDLC X75slp
> --------
> Port 1 'mISDN_l1loop.2': TE/NT-mode PRI E1 (for phone lines & E1
devices)
> 30 B-channels: 1-15 17-31
> B-protocols: RAW HDLC X75slp
hi fabrice,
the mISDN_l1loop interfaces are used to bring audio channels from the
BTS into the kernel (mISDN driver). there they can be connected to other
ISDN ports or used by chan_lcr (asterisk channel driver). both
interfaces are used by the [GSM] interface. (see gsm.conf) there are two
interfaces: one is for the BTS side and the other for the chan_lcr
(asterisk) side.
since you have no physical interface, i assume that you want to use
asterisk in combination with chan_lcr. but you also have [Int] and [Ext]
interfaces defined. you may only use them if you actually have physical
interfaces. what happens here: the given port numbers 0 and 1 match you
virtual l1loop interfaces, which are already in use for [GSM] interface.
unless you don't have physical cards, remove them. (interface.conf)
now you may route all call from the GSM interface (or any interface to
the chan_lcr:
see routing.conf
[main]
: remote application=asterisk
and from asterisk to lcr:
Dial(LCR/GSM/<extension from hlr>[/<options>])
try a test first:
[main]
: test prefix=5
and you should hear music...
regards,
andreas
p.s. i think we may require a howto. also i think i must put some
'working' packages together at one point to download. sometimes api
changes a bit, so always latest packets may not work together.
Hi all,
this is just a small head ups on the current differences between the
on-waves/bsc-master branch and HEAD.
New apps:
1.) bsc_msc_ip is the OpenBSC BSC that is speaking the A interface
2.) bsc_nat is a NAT/Multiplexer for BSCs and MGCP. One reason for it is
easy nat penetration.
I will look into git filter branch to merge the NAT into master as there
is nothing that is preventing it, for the bsc_msc_ip I need to continue
some merging.
Changes:
*) RF Failure handling. When a RF Channel fails, I switch it over to a
failure state, then ignore all SAPIs releases... and then set it back to
operational state.
*) RF bring down in SAPI order. So at first I will bring down SAPI=3,
then send SACH deactivate, then SAPI=0, then send the RF Channel
release. This is done as the nanoBTS likes to send a SAPI release
indication after the RF Channel Release ACK.
*) channel release reason, when closing a lchan one can set the release
reason. This is used on early assignment when closing down the old
signalling channel.
*) and of course the much talked about removal of ref counts from the lchan.
Hello Holger,
On Mon, 19 Apr 2010 12:37:12 +0800, "Holger Freyther" <zecke(a)selfish.org> wrote:
>
> The other problem is with the 20 paging requests every two seconds I'm
> creating a RACH DoS for my BTS to a point that I think (didn't bother to
> do the easy math, and I don't have the spec here right now) we have two
> MS picking the same random number. At least the symptom is that even if
> we assign a channel, it gets closed down with a RF Failure.
I wonder how frequently it happens with 20 MS that a RACH is sent on the
same frame and with the same random number. There are at least 16 possible
random numbers for the "Answere to Paging" Channel Request and there are
27 frames in the MF to chooses from (in the "Combined Configuration").
Do you use the same phones for testing and does the RF Failure happen
frequently (this probably would mean a bad random number generator in
this phone firmware) ? Also I would expect that two RACH burst will
disturb each other, at least in a testing environment where all the
MS have the same distance to the BTS and send with the same power.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Quoting "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de>:
hye andreas,
> output of "misdn_info"
Found 2 ports
Port 0 'mISDN_l1loop.1': TE/NT-mode PRI E1 (for phone lines & E1 devices)
30 B-channels: 1-15 17-31
B-protocols: RAW HDLC X75slp
--------
Port 1 'mISDN_l1loop.2': TE/NT-mode PRI E1 (for phone lines & E1 devices)
30 B-channels: 1-15 17-31
B-protocols: RAW HDLC X75slp
> /usr/local/lcr/interface.conf
# The MSN numbers will equal the subscriber number.
[GSM]
gsm
nt
layer1hold no
layer2hold no
tones yes
earlyb no
channel-in free
channel-out any
nodtmf
# Hint: Enter "lcr interface" for quick help on interface options.
# Add your interfaces here:
[Ext]
extern
portnum 0
[Int]
extension
msn 200,201,202,203
portnum 1
nt
> /usr/local/lcr/openbsc.cfg (or whatever your config file name is
> defined in gsm.conf)
!
! OpenBSC configuration saved from vty
!
password foo
!
line vty
no login
!
network
network country code 1
mobile network code 1
short name OpenBSC
long name OpenBSC
timer t3101 10
timer t3113 60
bts 0
type nanobts
ip.access unit_id 1801 0
band GSM1800
location_area_code 1
training_sequence_code 7
base_station_id_code 63
trx 0
arfcn 514
max_power_red 20
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
timeslot 2
phys_chan_config TCH/F
timeslot 3
phys_chan_config TCH/F
timeslot 4
phys_chan_config TCH/F
timeslot 5
phys_chan_config TCH/F
timeslot 6
phys_chan_config TCH/H
timeslot 7
phys_chan_config TCH/H
and here is the content of the /usr/local/lcr/gsm.conf
# LCR GSM options
#################
# Enable debugging of OpenBSC library.
# Refer to OpenBSC project for debugging options.
# By default, debugging is turned off.
#debug DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNCC:DMNSMS:DPAG:DMUX:DMEAS
# Two Loopback interfaces for audio transfer between OpenBSC and mISDN.
# The first interface must provide B-channelis for each call mobile call.
# The seond interface links them to LCR.
# Use 30 B-channels unless you need more due to many TRXs.
# -> Load with: "modprobe mISDN_l1loop pri=1 nchannel=30"
# By default "mISDN_l1loop.1" and "mISDN_l1loop.2" is used.
#interface-bsc mISDN_l1loop.1
#interface-lcr mISDN_l1loop.2
# Give openbsc.cnf config file
# It will be located at /usr/local/lcr by default.
config /opt/openbsc/src/openbsc.cfg
# Give database of Home Location Register (HLR)
# HLR stores all subscribers. It will be used to grant access to the network.
# It is an Sqlite3 database. Refer to OpenBSC project for handling.
# The database is located at /usr/local/lcr by default.
hlr /opt/openbsc/src/hlr.sqlite
# To keep layer 2 connection to BS11 when quitting, use this option.
# It is only usefull for developing. TRX will stay on.
# Also changes in frequency, mcc, mnc, lac while keeping layer 2 will cause
# malefunction of BSC.
# Warning: Keeping layer 2 link may prevent emergency calls. (See below)
#keep-l2
# Shutdown on emergency calls:
# This option will prevent a shutdown if an emergency call is received. In
# case of an emergency, a mobile phone may log onto you GSM network and may
# use it to set up an emergency call.
# The received emergency call will have 'emergency' as dialed number. But this
# number can't be dialed on PSTN networks without chaning.
# If you disable shutdown, be sure to provide routing of emergency calls to
# emergency facility. If you can't do that, don't touch it!
#no-emergency-shutdown
# Write BTS-Link traffic to PCAP file.
#pcapfile pcap
>
> it seems that you hook twice on some interface. are you using
> asterisk also (in conjunction with chan_lcr)?
yes i'm using it also
>
> regards,
>
> andreas
>
> p.s. please discuss this in the mailing list (see
> openbsc.gnumonks.org), so other users may have the same problems in
> the future. there are not many installations with LCR and openbsc.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Fabrice Ismael Poundeu Tchouatieu
> [mailto:fabrice.poundeu@smail.inf.fh-bonn-rhein-sieg.de]
> Gesendet: Mittwoch, 21. April 2010 14:14
> An: Andreas.Eversberg
> Betreff: running lcr with openbsc and nanoBTS
>
> Quoting "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de>:
>
> hye Andreas,
>
> i'm trying to get lcr working with openbsc and nanoBTS. To be able to
> come through this i have some questions:
>
> First when i start lcr i have the following following error-informations:
>
> ** LCR Version 1.7
>
> DB: Database initialized.
> DB: Database prepared.
> ERROR Port 1 already in use by LCR. You can't use a NT port multiple times.
> LCR 1.7 started, waiting for calls...
> ERROR (in main() line 447) LCR was stalling 2.25 seconds
>
> but lcr seems to work actually. Is that the normal way it works or it
> there something wrong? I have nothing else running on LCR.
>
> When i then try to set a call, lcr break out with the following information:
>
> layer3_thread read socket error No space left on device
>
> I don't known how many space is needed therefore, or in which folder
> or directory this space should be available. But the drive is quite
> empty. there is so much space available on it!
>
> Also can you send me an example of a working dialplan and sip.conf to
> enable the routing of gsm calls??
>
> thanks and best regards!!
>
> --
> Fabrice Ismael Poundeu Tchouatieu
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
--
Fabrice Ismael Poundeu Tchouatieu
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Hi!
I've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/)
which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin
from August 21/22 this year.
Before sending a response, I would like to inquire whom of you would actually
have any intention of visiting this conference and spending time in the
developer room to work on OpenBSC or OsmocomBB ?
I think the idea is great to meet some of you guys [again], not only at the
annual CCC congress in winter. But there is little point for me to go there if
there is no interest from the wider project community.
Please provide your feedback ASAP.
--
- 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)
Hello Holger,
On Tue, 20 Apr 2010 10:42:34 +0800, "Holger Freyther" <zecke(a)selfish.org> wrote:
>
> What happens is that the IMMEDIATE ASSIGNMENT does not make it to the
> phone fast enough and the same MS is sending another RA and we assign
> another channel.
>
> The root causes consist of various issues:
> - Our delay in src/input/ipaccess.c does not help, removing it
> is breaking the rugby sized BTS though..
> - Our paging layer sends the paging command in bursts... we
> should have an even distribution of them.
> - We have some NM attributes to play with.
>
> I am going to poke this some more.
I sometimes had the same problem in the past even with a single MS. If
you want to play with the parameters which control sending the RACH
burst, you can try the configuration commands "rach tx integer" for
the number of slots used to spread retransmission or "rach max
transmission" for the number of retransmitted burst. Of course in
a perfect world OpenBSC should work with all possible configurations.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all,
I will implement the following changes on the on-waves/bsc-master branch
and if no one is screaming move them over to master shortly afterwards.
Right now I'm experiencing the following problem. When enabling the RF
on the BTS hordes of MS come to the network for Location Updating
Requests and the SDCCHs are close to 100% loaded, now I want to send a
SMS to every new Subscriber welcoming it (ideally one would do it during
the LU but... well... it does not). To deliver the SMS we need to page
the SMS and currently we are paging 20 MSs during 2 seconds.
The first problem is that the nanoBTS can not handle this load for a
long time, it is sending CPU Overload and as of GSM 08.58 we should
handle it by throttling the transfer but well that is not implemented.
The other problem is with the 20 paging requests every two seconds I'm
creating a RACH DoS for my BTS to a point that I think (didn't bother to
do the easy math, and I don't have the spec here right now) we have two
MS picking the same random number. At least the symptom is that even if
we assign a channel, it gets closed down with a RF Failure.
So here is my problem:
- Remove the notion of paging slots... the nanoBTS is not
even sending the load indication anyway.
- Look at free channels (ignoring the requested channel at
first... something we need to fix later) and have a config
switch like.. only page if the cell is like 50% loaded or
such. I will figure out the details while doing the changes.
The other reason to write this mail is, I think it is pretty interesting
to see how our experiments from the congress look different to what I
was seeing due way more paging going on.
regards
holger