April 2010 - OpenBSC - lists.osmocom.org

Proposed OpenBSC application interface
by Harald Welte 15 Feb '11

15 Feb '11

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)

3 9

[PATCH 0/1] Add bport0/1 support for bs11_config
by Daniel Willmann 14 Dec '10

14 Dec '10

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(-)

4 5

Inter-layer state / references / control buffer
by Harald Welte 30 Apr '10

30 Apr '10

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)

2 2

AW: AW: running lcr with openbsc and nanoBTS
by Andreas.Eversberg 29 Apr '10

29 Apr '10

>> 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.

2 1

FYI: Difference between on-waves/bsc-master
by Holger Freyther 26 Apr '10

26 Apr '10

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.

1 0

Re: Changes to the paging subsystem
by Dieter Spaar 26 Apr '10

26 Apr '10

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

3 3

Re: AW: running lcr with openbsc and nanoBTS
by Fabrice Ismael Poundeu Tchouatieu 22 Apr '10

22 Apr '10

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.

1 0

Who would attend a developer room / meeting at FrOSCon ?
by Harald Welte 20 Apr '10

20 Apr '10

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)

1 0

Re: Changes to the paging subsystem
by Dieter Spaar 20 Apr '10

20 Apr '10

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

1 0

Changes to the paging subsystem
by Holger Freyther 19 Apr '10

19 Apr '10

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

3 3