June 2013 - OpenBSC - lists.osmocom.org

Re: Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite

by Sipos Csaba

Hi Holger, I was able to narrow it down, and it seems this is the patch that causing the problem: http://cgit.osmocom.org/libosmocore/commit/?id=f5a079f739c57d8be7c59149fd45… Up to that patch it works (more or less), but after I applied it, I got this seg faults. I don't know how to do back traces but I try to get some info about this topic and will send the results. Csaba

10 years, 8 months

3
12
0 0

Nokia InSite configuration check

by Sipos Csaba

Dear members, In connection with the problem I found, I kindly ask someone, to please check my configuration, because I want to rule out any configuration related issue, don't want to waste anyones time with sending false bug reports. Currently I am using a GSM1800 Nokia InSite unit with a Dahdi E1 card and OpenBSC, the DAHDI card is the timing source. /etc/dahdi/system.conf span=1,0,0,ccs,hdb3,crc4 bchan=2-31 dchan=1 OpenBSC conf: password foo line vty no login e1_input e1_line 0 driver dahdi network network country code 1 mobile network code 1 short name OpenBSC long name OpenBSC mm info 1 timer t3101 10 timer t3113 60 bts 0 type nokia_site band GSM1800 cell_identity 1 location_area_code 1 base_station_id_code 63 training_sequence_code 7 ms max power 40 periodic location update 10 oml e1 line 0 timeslot 5 sub-slot full oml e1 tei 1 trx 0 arfcn 885 nominal power 22 max_power_red 0 rsl e1 line 0 timeslot 4 sub-slot full rsl e1 tei 1 timeslot 0 phys_chan_config CCCH+SDCCH4 e1 line 0 timeslot 2 sub-slot 0 timeslot 1 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 3 My main concern is about the OML and RSL TEI addresses. If I understand it correctly, OML TEI identifies the BTS, RSL TEI identifies the TRX of that BTS. So if I have 2 BTSs and 2-2 TRXs, then the correct configuration would be looking like this: BTS0: oml: te1 1 trx0: tei 1 trx1: tei 2 trx2: tei 3 .... BTS1: oml: tei 2 trx0: tei 1 trx1: tei 2 trx2: tei 3 ... ? Even the Nokia BTS commissioning documentation is unclear about the specifics: sapi =Service access point identifier. (62 for OMUSIG, 0 for TRXSIG.) tei =Terminal end point identifier. Must the same as defined in the BTS. Usually the same as the TRX number. For OMU link, the value is 1. According to this, every OML TEI of every BTS should be "1" ? The other funny part is, that it sais it must be the same as defined in the BTS, but Nokia BTS Manager does not have any parameter for TEI or SAPI to set. My other concerns are BSIC and Training Sequence Code (TSC). As I know, BSIC identifies the BTS in a location and/or routing area, it means that a location/routing area can have 64 BTSs at top (BSIC=0-63), and every BTS have to use unique BSIC in the same LAC? TSC is another mystery. Nokia Docs sais: train_seq = Training sequence code. (eg. BCC value of the BSIC, eg. 7) This has to be 7 all the time, or if I have more than one BTS (in the same LAC and on the same E1)I have to change this? Finally, DAHDI configuration: How many D channels should I specify? For example if I have 2 BTSs on the same E1, I have to specify two D channels for every OMUSIG timeslots? Or I have to specify D channels for every timeslots I use for signalling (OMUSIG and TRXSIG for all BTSs)? Or maybe I don't have to allocate even one D channel, because I dedicate separate signalling and TCH timeslots for every BTS? I searched a lot about this topic, but the information available is limited, not specific and most of the time lead to more questions... I hope someone can enlighten me in this topic. BR, Csaba

10 years, 9 months

1
0
0 0

[PATCH] contrib: A shell script to send command(s) to osmo-nitb/osmo-bts live instances.

by Alexander Chemeris

Hi all, Attached is a shell script I found useful for monitoring a live installation of OsmoNITB. I hope it'll be useful for someone else and propose to check it into the 'contrib' directory of the OpenBSC repository. Actually I believe that Holger's zecke/features/nitb-ctrl-interface branch should be merged into the master, as it makes such monitoring much easier and failsafe. PS I think it would be useful create a wiki-page with cheat-sheet of useful commands during the OpenBSC operation. I could start putting something together if there are no objections to that. I would appreciate recommendations for the wiki page name and location too. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

10 years, 9 months

2
1
0 0

Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite

by Sipos Csaba

Dear members, It seems that the latest Osmo-nitb (0.13.0.48-9e22) broke compatibility with Nokia InSite. I am using a GSM1800 unit with an E1 dahdi card, and with the following config it was working fine with a previous version (osmo-nitb v.0.13.0.33-e152a4): openbsc.cfg: ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! e1_input e1_line 0 driver dahdi network network country code 1 mobile network code 1 short name OpenBSC long name OpenBSC mm info 1 timer t3101 10 timer t3113 60 bts 0 type nokia_site band GSM1800 cell_identity 1 location_area_code 1 base_station_id_code 63 training_sequence_code 7 ms max power 40 periodic location update 10 oml e1 line 0 timeslot 5 sub-slot full oml e1 tei 1 trx 0 arfcn 885 nominal power 22 max_power_red 0 rsl e1 line 0 timeslot 4 sub-slot full rsl e1 tei 1 timeslot 0 phys_chan_config CCCH+SDCCH4 e1 line 0 timeslot 2 sub-slot 0 timeslot 1 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 1 timeslot 2 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 2 timeslot 3 phys_chan_config TCH/F e1 line 0 timeslot 2 sub-slot 3 timeslot 4 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 0 timeslot 5 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 1 timeslot 6 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 2 timeslot 7 phys_chan_config TCH/F e1 line 0 timeslot 3 sub-slot 3 /etc/dahdi/system.conf span=1,0,0,ccs,hdb3,crc4 bchan=2-31 dchan=1 Error message with the most recent verion: root@openbsc:~# osmo-nitb -c /root/1800_nokia.cfg <0018> input/lapd.c:212 LAPD Allocating SAP for SAPI=62 / TEI=1 <0018> input/lapd.c:223 k=1 N200=3 N201=260 T200=1.0 T203=10.0 <0018> input/lapd.c:485 LAPD DL-ESTABLISH request TEI=1 SAPI=62 <0018> input/lapd.c:212 LAPD Allocating SAP for SAPI=62 / TEI=1 <0018> input/lapd.c:223 k=1 N200=3 N201=260 T200=1.0 T203=10.0 <0018> input/lapd.c:485 LAPD DL-ESTABLISH request TEI=1 SAPI=62 DB: Database initialized. DB: Database prepared. <001d> sms_queue.c:220 Attempting to send 20 SMS <0018> input/lapd.c:624 LAPD DL-ESTABLISH confirm TEI=1 SAPI=62 <0005> bts_nokia_site.c:58 bootstrapping OML for BTS 0 <0005> bts_nokia_site.c:1679 ABIS_OM_MDISC_FOM <0005> bts_nokia_site.c:1507 (0x81) NOKIA_BTS_ACK <0005> bts_nokia_site.c:1539 ACK = 1 <0018> input/lapd.c:513 LAPD DL-RELEASE request TEI=1 SAPI=62 <0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1 SAPI=62 <0018> input/lapd.c:513 LAPD DL-RELEASE request TEI=1 SAPI=62 <0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1 SAPI=62 Segmentation fault (core dumped) root@openbsc:~# I have to admit that even with the previous versions I had issues, like a lot of radio link failures, unstable voice calls (lasting only 1-2 minutes), but now it wont start at all. Thanks in advance! Csaba

10 years, 9 months

2
1
0 0

OpenBSC unsubscribe notification

by mailman-bounces＠lists.osmocom.org

situsaja(a)bshellz.net has been removed from OpenBSC.

10 years, 10 months

1
0
0 0

Slow database access at OpenBSC

by Andreas Eversberg

hi, i experienced audio glitches while another phone does location updating: <0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x18 to MS. <0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=0 RXL-FULL-ul=-110dBm RXL-SUB-ul=-47dBm R Q-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 NOT VALID NUM_NEIGH=0 <0003> bsc_api.c:615 CLASSMARK CHANGE CM2(len=3) CM3(len=4) dbi access time 95ms Stalled 96ms <0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=1 RXL-FULL-ul=-66dBm RXL-SUB-ul=-47dBm RX -FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dB RXQ-FULL-dl=0 RXQ-SUB-dl=0 NUM_NEIGH=7 dbi access time 50ms dbi access time 0ms dbi access time 49ms dbi access time 58ms dbi access time 83ms dbi access time 0ms dbi access time 0ms dbi access time 0ms dbi access time 72ms <0003> gsm_04_08_utils.c:315 TX CIPHERING MODE CMD Stalled 319ms <0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=2 RXL-FULL-ul=-65dBm RXL-SUB-ul=-47dBm RX -FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dB RXQ-FULL-dl=0 RXQ-SUB-dl=0 NUM_NEIGH=7 <0003> osmo_msc.c:105 CIPHERING MODE COMPLETE dbi access time 0ms dbi access time 69ms <0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x02 to MS. <0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x32 to MS. dbi access time 66ms dbi access time 0ms dbi access time 0ms <0003> gsm_04_08.c:1249 TX APPLICATION INFO id=0x00, len=4 <0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 06) Sending 0x38 to MS. dbi access time 0ms Stalled 140ms the total time that openbsc was stalling is 555ms in this case. there are only 4 subscribers in hlr and counter writing is disabled. is there any trick to make database access faster? speeding up the db access does not solve the problem. an async db access is one solution, but there is other code at openbsc that might require some time. (e.g. handling of many measurement reports) one solution is to have an own thread for the audio processing. this thread must access different interfaces independently from the rest of the openbsc code: - RTP sockets - MNCC socket - TRAU sockets of E1 timeslots MNCC socket could be split into two sockets: one for signalling, one for audio traffic. this way it is not required to use queues and signals between main thread and audio thread. a problem in case of multithreading is osmo_select_main(). it uses global list of file descriptors and global rb-tree for timers. one solution would be having multiple lists and trees for each thread id. this way it is not required to change timer and file descriptor api. another solution could be a seperate process, which handles audio only. i don't really like a sepeate process, since it requires some interface to openbsc and makes everything more complex. even though i don't like threads, multithreading seems to be the best solution to me at the moment. was there any effort to solve the problem or to handle audio? are there any suggestions about it? regard, andreas

10 years, 10 months

2
2
0 0

SGSN Crash Report

by Caleb Pal

Hello, I just updated my machine with the latest OpenBSC code from git. In the past under heavy data load (EDGE), the BTS would crash. Now, after updating the code, the BTS stays up, but the SGSN crashes. Below are a few details about my setup and debugging output. BTS: NanoBTS 165BU 1900 PC: Atom Z530 1GB ram, Running Debian (Wheezy) Output from gdb: <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=52 <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xc3123cCMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xac6064CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xdc7cc7CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x18af79CMD=UI DATA <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x84caf1CMD=UI DATA <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xf1f6b6CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xd9e63bCMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xbadc11CMD=UI DATA <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=64 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=197 <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xb7e07cCMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x987e00CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xf386aaCMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x38700eCMD=UI DATA <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x62743eCMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x1cba00CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x6e4346CMD=UI DATA <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xb20578CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x49f5d0CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x760e46CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xc839b5CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xacd5a3CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xdaf317CMD=UI DATA <0011> gprs_bssgp.c:747 BSSGP BVCI=3 Rx Flow Control BVC <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x7d7a91CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x1eef1aCMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xd83b65CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0xf6a775CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x855a58CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x18aa6fCMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x167b76CMD=UI DATA <0011> gprs_bssgp.c:376 BSSGP TLLI=0xce3dde6f Rx UPLINK-UNITDATA <0012> gprs_llc.c:502 LLC SAPI=3 C FCS=0x55d812CMD=UI DATA <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 <000f> sgsn_libgtp.c:425 GTP DATA IND from GGSN, length=1500 Program received signal SIGFPE, Arithmetic exception. fc_queue_timer_cfg (fc=fc@entry=0x808def0) at gprs_bssgp.c:596 596 msecs = (fcqe->llc_pdu_len * 1000) / fc->bucket_leak_rate; (gdb) OpenBSC Console Output: Fri Jun 21 16:36:19 2013 <0005> abis_nm.c:315 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=quality of service failure Severity=warning level failure Probable cause= 03 05 01 Additional Text=UDP overflow alarm on port 23000 (1 occurences) Fri Jun 21 16:36:20 2013 <0005> abis_nm.c:315 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=quality of service failure Severity=warning level failure Probable cause= 03 05 01 Additional Text=UDP overflow alarm on port 23000 (1 occurences) Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:315 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Failed(01) Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:315 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:1757 OC=GPRS-NSE(f0) INST=(00,ff,ff) Sending OPSTART Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:315 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:1757 OC=GPRS-CELL(f1) INST=(00,00,ff) Sending OPSTART Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:315 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:315 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:2418 OC=GPRS-NSE(f0) INST=(00,ff,ff) IPACCESS(0xf6): SET ATTR ACK Fri Jun 21 16:38:00 2013 <0005> abis_nm.c:2418 OC=GPRS-CELL(f1) INST=(00,00,ff) IPACCESS(0xf6): SET ATTR ACK Fri Jun 21 16:38:42 2013 <0005> abis_nm.c:315 OC=GPRS-NSVC(f2) INST=(00,00,ff) Failure Event Report Type=communication failure Severity=critical failure Probable cause= 03 03 11 Additional Text= Let me know if you need any further information. Regards, Caleb

10 years, 10 months

4
4
0 0

NanoBTS 139 PCS1900 for sale

by Pierre Kim

Hello, I have a nanoBTS 139 unit for sale. It is from the united states, it operates on PCS1900. I'd sell it for 1200 euro. Please contact me if you are interested. Thank you.

10 years, 10 months

1
0
0 0

[PATCH] BSSGP: prevent divide-by-zero in flow control

by Harald Welte

If the BTS tells us to not send any data at all anymore (bucket leak rate of 0 bits per second), then we should respect this and not run into a divide-by-zero. However, as this indicates complete overload, we print a log message to that regard. --- src/gb/gprs_bssgp.c | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-) diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c index e41c7ef..5ef1887 100644 --- a/src/gb/gprs_bssgp.c +++ b/src/gb/gprs_bssgp.c @@ -590,16 +590,20 @@ static int fc_queue_timer_cfg(struct bssgp_flow_control *fc) fcqe = llist_entry(&fc->queue.next, struct bssgp_fc_queue_element, list); - /* Calculate the point in time at which we will have leaked - * a sufficient number of bytes from the bucket to transmit - * the first PDU in the queue */ - msecs = (fcqe->llc_pdu_len * 1000) / fc->bucket_leak_rate; - /* FIXME: add that time to fc->time_last_pdu and subtract it from - * current time */ - - fc->timer.data = fc; - fc->timer.cb = &fc_timer_cb; - osmo_timer_schedule(&fc->timer, msecs / 1000, (msecs % 1000) * 1000); + if (fc->bucket_leak_rate != 0) { + /* Calculate the point in time at which we will have leaked + * a sufficient number of bytes from the bucket to transmit + * the first PDU in the queue */ + msecs = (fcqe->llc_pdu_len * 1000) / fc->bucket_leak_rate; + /* FIXME: add that time to fc->time_last_pdu and subtract it from + * current time */ + fc->timer.data = fc; + fc->timer.cb = &fc_timer_cb; + osmo_timer_schedule(&fc->timer, msecs / 1000, (msecs % 1000) * 1000); + } else { + /* If the PCU is telling us to not send any more data at all, + * there's no point starting a timer. */ + } return 0; } @@ -742,6 +746,8 @@ int bssgp_fc_ms_init(struct bssgp_flow_control *fc_ms, uint16_t bvci, static int bssgp_rx_fc_bvc(struct msgb *msg, struct tlv_parsed *tp, struct bssgp_bvc_ctx *bctx) { + uint32_t old_leak_rate = bctx->fc->bucket_leak_rate; + uint32_t old_r_def_ms = bctx->r_default_ms; DEBUGP(DBSSGP, "BSSGP BVCI=%u Rx Flow Control BVC\n", bctx->bvci); @@ -769,6 +775,23 @@ static int bssgp_rx_fc_bvc(struct msgb *msg, struct tlv_parsed *tp, bctx->r_default_ms = 100 * ntohs(*(uint16_t *)TLVP_VAL(tp, BSSGP_IE_R_DEFAULT_MS)) / 8; + if (old_leak_rate != 0 && bctx->fc->bucket_leak_rate == 0) + LOGP(DBSSGP, LOGL_NOTICE, "BSS instructs us to bucket leak " + "rate of 0, stopping all DL GPRS!\n"); + else if (old_leak_rate == 0 && bctx->fc->bucket_leak_rate != 0) + LOGP(DBSSGP, LOGL_NOTICE, "BSS instructs us to bucket leak " + "rate of != 0, restarting all DL GPRS!\n"); + + if (old_r_def_ms != 0 && bctx->r_default_ms == 0) + LOGP(DBSSGP, LOGL_NOTICE, "BSS instructs us to MS default " + "bucket leak rate of 0, stopping DL GPRS!\n"); + else if (old_r_def_ms == 0 && bctx->r_default_ms != 0) + LOGP(DBSSGP, LOGL_NOTICE, "BSS instructs us to MS default " + "bucket leak rate != 0, restarting DL GPRS!\n"); + + /* reconfigure the timer for flow control based on new values */ + fc_queue_timer_cfg(bctx->fc); + /* Send FLOW_CONTROL_BVC_ACK */ return bssgp_tx_fc_bvc_ack(msgb_nsei(msg), *TLVP_VAL(tp, BSSGP_IE_TAG), msgb_bvci(msg)); -- 1.8.3.1 --wac7ysb48OaltWcw--

10 years, 10 months

1
0
0 0

OpenBTS with GPRS....trouble with SGSN and PCU

by altaf sk

Hello everybody. I was successful in running the calypso BTS by using the openBTS (without gprs). Now I am trying to setup a GPRS N/w with the guide provided at http://wush.net/trac/rangepublic/wiki/GPRS and by using the same Calypso BTS. Want to know whether if this can work out. If not I want to do some minimal implementation (GPRS attach or just activate a PDP context). I followed the tutorial and I am here with logs from PCU and SGSN. LOG from Osmo-PCU # ./osmo-pcu -n 06 -m 234 <0001> pcu_l1_if.cpp:375 BTS available <0001> pcu_l1_if.cpp:91 Sending activate request: trx=0 ts=6 <0001> pcu_l1_if.cpp:502 PDCH: trx=0 ts=6 <0001> pcu_l1_if.cpp:91 Sending activate request: trx=0 ts=7 <0001> pcu_l1_if.cpp:502 PDCH: trx=0 ts=7 <0009> gprs_bssgp_pcu.cpp:508 NS-VC 4 is unblocked. <0008> gprs_bssgp_pcu.cpp:549 Sending reset on BVCI 0 <0008> gprs_bssgp_pcu.cpp:557 Sending reset on BVCI 7 <0008> gprs_bssgp_pcu.cpp:565 Sending unblock on BVCI 7 <0001> pcu_l1_if.cpp:296 RACH request received: sapi=1 qta=1, ra=120, fn=961674 <0002> gprs_rlcmac_data.cpp:1901 Got IMM.ASS confirm, but rest octets do not start with bit sequence 'HH01' (Packet Downlink Assignment) 0002> gprs_rlcmac_data.cpp:564 TBF T3169 timeout during transsmission <0002> gprs_rlcmac_data.cpp:82 - Assignment was on CCCH <0002> gprs_rlcmac_data.cpp:88 - No uplink data received yet <0001> pcu_l1_if.cpp:296 RACH request received: sapi=1 qta=1, ra=124, fn=963005 <0002> gprs_rlcmac_data.cpp:1901 Got IMM.ASS confirm, but rest octets do not start with bit sequence 'HH01' (Packet DownlinkAssignment) 0002> gprs_rlcmac_data.cpp:564 TBF T3169 timeout during transsmission <0002> gprs_rlcmac_data.cpp:82 - Assignment was on CCCH <0002> gprs_rlcmac_data.cpp:88 - No uplink data received yet After a successful GSM attach procedure the phone is accessing the BTS on RACH for a GPRS attach. This set of statements repeats as long as the phone trying to do a GPRS attach send requests on RACH. It seems like the phone BTS receives RACH and a channel is assigned (IMM ASS, I can see this TBF assignment in Wireshark), but I doubt whether this IMM ASS has reached the phone that is trying to GPRS attach. Log from SGSN #./osmo-sgsn <0010> gprs_ns.c:171 NSVCI=65534 Creating NS-VC <0010> gprs_ns.c:171 NSVCI=65535 Creating NS-VC <0010> gprs_ns.c:806 Creating NS-VC for BSS at 192.168.111.144:5948 <0010> gprs_ns.c:679 NSEI=65535 Rx NS RESET (NSVCI=0, cause=O&M intervention) <0010> gprs_ns.c:538 NSEI=8 Tx NS RESET ACK (NSVCI=4) <0010> gprs_ns.c:679 NSEI=4 Rx NS RESET (NSVCI=8, cause=PDU not compatible with protocol state) <0010> gprs_ns.c:538 NSEI=8 Tx NS RESET ACK (NSVCI=4) <0010> gprs_ns.c:865 NSEI=8 Rx NS UNBLOCK <0010> gprs_ns.c:865 NSEI=8 Rx NS UNBLOCK <0011> gprs_bssgp.c:249 BSSGP BVCI=0 Rx RESET cause=O&M intervention <0011> gprs_bssgp.c:249 BSSGP BVCI=7 Rx RESET cause=O&M intervention <0011> gprs_bssgp.c:272 Cell 234-6-1000-0 CI 0 on BVCI 7 <0011> gprs_bssgp.c:344 BSSGP BVCI=7 Rx BVC-UNBLOCK <0011> gprs_bssgp.c:747 BSSGP BVCI=7 Rx Flow Control BVC <0011> gprs_bssgp.c:747 BSSGP BVCI=7 Rx Flow Control BVC and The last statement repeats......... the statement Cell 234-6-1000-0 CI 0 on BVCI 7 The RAI and Cell ID are 0 and 0.... But when I read the code gprs_bssgp.c it says these parameters will be received from BSS. If I set these parameters in OpenBTS.db similar to LAC=RAC but still there is no effect. I am running ./ggsn, ./osmo-sgsn, ./osmo-pcu, ./openbts Is osmo-nitb needed along with SGSN and PCU. I fail to do GPRS attcach in this situation. Can someone please give your comments and guide me with some suggestions. regards, Altaf

10 years, 10 months

4
12
0 0

osmocom-bb: [PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

This is the patch for osmocom-bb

10 years, 10 months

2
2
0 0

Updates for automake 1.13

by Alexander Huemer

Hi, automake 1.13 appeared on my system lately. As with every version bump of auto* some directives are no more 'en vogue'. This time it's INCLUDES in Makefile.am files. AM_CPPFLAGS should be used now, INCLUDES will be removed in some future release. I created trivial patches for the osmo projects using autotools of which I already had clones. These are: libosmo-abis libosmocore libosmo-dsp libosmo-sccp openbsc osmo-bts osmocom-bb osmo-gmr The patches are for the master branch of the respective repository, current HEAD. I'll send the patches individually. Feel free to apply the patches if they seem useful. Otherwise, feedback is appreciated. Kind regards, -Alexander Huemer

10 years, 10 months

2
2
0 0

osmo-gmr: [PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

This is the patch for osmo-gmr

10 years, 10 months

1
1
0 0

osmo-bts: [PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

This is the patch for osmo-bts

10 years, 10 months

1
1
0 0

openbsc: [PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

This is the patch for openbsc

10 years, 10 months

1
1
0 0

libosmo-sccp: [PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

This is the patch for libosmo-sccp

10 years, 10 months

1
1
0 0

libosmo-dsp [PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

This is the patch for libosmo-dsp

10 years, 10 months

1
1
0 0

libosmocore: [PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

This is the patch for libosmocore

10 years, 10 months

1
1
0 0

libosmo-abis: [PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

This is the patch for libosmo-abis

10 years, 10 months

1
1
0 0

[PATCH] Makefile.am: Use AM_CPPFLAGS

by Alexander Huemer

Since automake 1.13 INCLUDES is depricates and causes a warning --- Makefile.am | 2 +- src/Makefile.am | 2 +- tests/Makefile.am | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index 4ba09f4..9c82f09 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,6 +1,6 @@ ACLOCAL_AMFLAGS = -I m4 -INCLUDES = $(all_includes) -I$(top_srcdir)/include +AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include SUBDIRS = include src tests pkgconfigdir = $(libdir)/pkgconfig diff --git a/src/Makefile.am b/src/Makefile.am index 01f0913..41804d0 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -3,7 +3,7 @@ ABIS_LIBVERSION=1:0:0 TRAU_LIBVERSION=0:0:0 -INCLUDES = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) +AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir) AM_CFLAGS= -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(COVERAGE_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) COMMONLIBS = $(LIBOSMOCORE_LIBS) $(LIBOSMOGSM_LIBS) $(LIBOSMOVTY_LIBS) diff --git a/tests/Makefile.am b/tests/Makefile.am index 11b605f..fea78fc 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -1,4 +1,4 @@ -INCLUDES = $(all_includes) -I$(top_srcdir)/include +AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include AM_CFLAGS=-Wall -g $(LIBOSMOCORE_CFLAGS) $(LIBOSMOGSM_CFLAGS) $(COVERAGE_CFLAGS) AM_LDFLAGS = $(COVERAGE_LDFLAGS) -- 1.7.10.4

10 years, 10 months

1
0
0 0

Re: Any interest for Osmocom meetings in Bavaria ?

by Dieter Spaar

So far three persons have indicated their interest to join a meeting at my place. Considering the time it takes to drive to my place, it probably makes sense to have the meeting at the weekend (either Saturday or Sunday) so that there is more time for the meeting itself. I can suggest one of the following dates for the first meeting, somewhere between 10:00 to 18:00 on each day: 25.8. (Sa) or 26.8. (Su) 1.9. (Sa) or 2.9. (Su) 8.9. (Sa) or 9.9. (Su) So please let me know when you have time and also make suggestions in which Osmocom topic you are interested in so that we can have some sort of agenda for the meeting to make best use of the time. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

10 years, 10 months

10
40
0 0

Testing OpenBSC with FakeBTS

by Priyanka Behl

Hi again, I am trying to test OpenBSC with FakeBTS, it is getting initialized: st> bts connect: 'localhost'; waitForBTSReady. Stop OML Connected SWActivation for SiteManagerOML Opstarted SiteManagerOML SWActivation for BTSOML "Global garbage collection... done, heap grown" Opstarted BTSOML SWActivation for BasebandTransceiverOML SWActivation for RadioCarrierOML Opstarted BasebandTransceiverOML RSL Connected Opstarted RadioCarrierOML BTS is fully initialized. OML-Init exited a BTS but I am getting the following errors: root@server:~/openbsc/openbsc/src/osmo-nitb# ./osmo-nitb -c ~/openbsc/openbsc/doc/examples/osmo-nitb/nanobts/openbsc.cfg <0019> input/ipaccess.c:925 enabling ipaccess BSC mode DB: Database initialized. DB: Database prepared. <001d> sms_queue.c:220 Attempting to send 20 SMS <0019> input/ipa.c:322 accept()ed new link from 127.0.0.1 to port 3002 <0019> input/ipa.c:322 accept()ed new link from 127.0.0.1 to port 3003 <0004> bsc_init.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC=404 MNC=1 LAC=1 CID=0 BSIC=63 TSC=7 <0004> abis_rsl.c:2050 unknown RSL message discriminator 0x01 <0019> input/ipaccess.c:458 Bad signalling message,sign_link returned error can somebody kindly help me eliminating this.. Thanks and regards Priyanka

10 years, 10 months

2
1
0 0

Unable to enter correct values for classmarks in the database

by Priyanka Behl

Hi everyone, I have been able to start Osmo-nitb and have authenticated some subscribers in the HLR database but I am stuck while entering values in the EIR table. I have tried using different values but no success, can someboy please provide me with an example of classmark 1, 2 and 3 values. This will be a great help. Thanks and regards Priyanka

10 years, 10 months

1
0
0 0

Bs11 problem on startup.

by choukoumoun

Hello list, I have a problem with BS11 at startup: When I put the BS11 voltage and that I connect in serial and I run: ./bs11_config-p / dev/ttyUSB0 query I like the result: PHASE 1: unknown Abis-link: Down PHASE 1: unknown Abis-link: Down PHASE 1: unknown Abis-link: Down PHASE 1: unknown Abis-link: Down PHASE 1: unknown Abis-link: Down PHASE 1: unknown Abis-link: Down PHASE 1: unknown Abis-link: Down constantly and eternally ...... Any idea?? thank you

10 years, 10 months

1
0
0 0

OpenBSC meeting in India

by Priyanka Behl

Hi everyone, I have observed that there are a lot of meetings being organized (relating to OpenBSC) so, I was wondering if it is possible to organize one such meeting/session in India because there are a lot of people here who are asociated with the project and I am sure they all will be hoping for the same. Please think over it, it's worth giving a shot.. Looking for a positive reply Thanks and regards Priyanka

10 years, 10 months

2
1
0 0

OpenBSC CDMA Support

by Nick Khamis

Hello Everyone, We just purchased a Nokia wcdma unit, and probably a unit missing many parts... And was wondering if OpenBSC has support or even partial support for cdma air interface? Kind Regards, Nick from Montreal.

10 years, 10 months

1
0
0 0

Bounce action notification

by mailman＠lists.osmocom.org

This is a Mailman mailing list bounce action notice: List: OpenBSC Member: situsaja(a)bshellz.net Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

10 years, 10 months

1
0
0 0

SimpleHLR: A web interface for OpenBSC

by Peter Caprioli

Hello everyone, I've just finnished writing together a small web interface for the OpenBSC HLR. It allows you to modify various parameters in the database and also provides a set of functions to modify the HLR or sending SMSes in your own scripts. The project is still very alpha but it seems to work reasonably good. Feel free to give any feedback! Screenshots and source code is available on my website: https://stormhub.org/simplehlr/ -- *Best regards, Peter Caprioli*

10 years, 10 months

3
6
0 0

Hello from Montreal

by Nick Khamis

Hello Everyone, Random weekend googling brought my attention to the very interesting projects of OpenBSC, Osmocom etc.. My background started off on a good foot in EE, and quickly spiraled downwards into the uninteresting world of information system or business applications with many lines of code written etc.. I still don't know how that happened, but lets blame it on demand.... Upon completing my research as a masters student, my specializations veered towards Natural Language Processing, Machine Learning, Semantic Web etc.. which was a little more interesting with formal concepts and so on. Manage to published papers, and even a book: http://scholar.google.ca/citations?user=lh6e3q0AAAAJ&hl=en http://www.amazon.com/Applying-Computational-Linguistics-API-Documentation/… Moving forward, and the PURPOSE for my email is I would really like to sink my teeth into the mysterious world of GSM, be it at the node side (i.e., cell phone, bank or via rail train) and the base station side or whatever... Maybe even devise a possible PhD topic funded by a research lab here in Canada. Security topics and exploitations are heavily funded here by DoD and so on, the trick really comes down to wording.... Anyhow, I am afraid that any more chatter may be perceived as "noise" so let's just call this the hello world of emails, and hope it's welcomed and not scrutinized for taking away from valuable development time, at which point I do apologize! Kind Regards, Ninus from the land of 1900Mhz and T1 networks

10 years, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2013