- OpenBSC - lists.osmocom.org

ipaccess-config changes in master
by Holger Freyther 12 May '10

12 May '10

Hi all, I have done various changes to the ipaccess-config application to work with a multi-trx setup. I think I have tested everything on both single-trx and multi-trx setup. If something with ipaccess-config does not work anymore please shout and I will have a look. z.

1 0

network originated handover
by Open Bsc 12 May '10

12 May '10

Hi, Does anyone know how to create a network originated handover for a selected subscriber on an Ericsson network? Thanks for your answers.. Alper

3 3

OpenGGSN git repository with fixes
by Harald Welte 04 May '10

04 May '10

Hi! I've created a git repository for OpenGGSN, and imported the apparently abandoned openggsn code using git cvsimport. You can clone the repo via "git clone git://openbsc.gnumonks.org/openggsn.git Please note: This is not meant as an attempt to fork or openggsn. I just wanted to add all the fixed that had been contributed to the sourceforge bug tracker to the latest released openggsn code (including a DoS fix from 6 years ago)... so I might as well make this available to others. I'm still hoping to get in touch with the original author and see what we can do to bring those fixes back into mainline and help openggsn's future. 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)

1 0

OpenBSC gprs-sgsn branch merged into master !
by Harald Welte 04 May '10

04 May '10

Hi all! Since the SGSN was now built as a separate program, the modifications to OpenBSC specific files are none, and the modifications to some shared files were minimal (e.g. adding a new debug category). Thus, I have decided it is no longer useful to keep the gprs-sgsn branch as a separate branch. The GPRS code can now be found in the master branch. Also, all gprs related code is moved to src/gprs to make the distinction more clear. I don't expect any of my upcomign work on the GPRS side to touch the regular BSC codebase in src/ The ipaccess-* executables are now also built in src/ipaccess and I think we should gradually give the code more structure. Too many source file in one directory make things complicated and make it too easy to have strange dependencies. 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)

1 0

GPRS SGSN status update
by Harald Welte 03 May '10

03 May '10

Hi! The gprs-sgsn branch has seen quite a number of changes during the last week, most of them are related to the gb-proxy that I'm currently implementing. The Gb-proxy can multiplex several Gb connections (each to one BTS) and present them as one NS-VC with many BSSGP-VC (one for each BTS) to the SGSN. The proxy is not needed for most users OpenBSC operation. However, I have now also adapted the SGSN support inside OpenBSC to the modified NS and BSSGP code for the proxy. Furthermore, I've fixed many of its limitations and it should now be fairly generic, working with multiple BTSs, etc. Also, the SGSN is now a standalone program called osmo_sgsn. A lot of the legacy cruft has been eliminated, i.e. the SGSN code does no longer need the gsm_network/bts/trx/... data structures that are not applicable to the GPRS network model anyway. As a result, GPRS ATTACH and RA UPDATE are working again, like they did months ago. I'm now still stuck somewhere in PDP context activation, and am confident that this will be solved tomorrow. After that point, the actual data plane can be worked on, i.e. flow control and fragmentation, as well as somehow actually routing IP packets into the LLC connection. 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)

1 2

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