OpenBSC

openbsc@lists.osmocom.org

4315 discussions

[PATCH] osmo-pcap[master]: Rename osmo_pcap_{client_server} executables to osmo-pcap-{c...
by Harald Welte 21 Jul '17

21 Jul '17

Review at https://gerrit.osmocom.org/3322 Rename osmo_pcap_{client_server} executables to osmo-pcap-{client,server} This naming is more in line with what all the other osmocom programs are doing (e.g. osmo-pcu, osmo-bts-sysmo, osmo-bsc, ...). We don't generally use osmo_ anywhere else, so I suggest to change it for more uniformity. Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 --- M src/Makefile.am 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/22/3322/1 diff --git a/src/Makefile.am b/src/Makefile.am index 0532acf..17ed4e3 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,7 +1,7 @@ AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir)/ AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(PCAP_CFLAGS) $(LIBGNUTLS_CFLAGS) -bin_PROGRAMS = osmo_pcap_client osmo_pcap_server +bin_PROGRAMS = osmo-pcap-client osmo-pcap-server osmo_pcap_client_SOURCES = osmo_client_main.c osmo_common.c \ osmo_client_core.c osmo_client_vty.c \ -- To view, visit https://gerrit.osmocom.org/3322 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1 Gerrit-PatchSet: 1 Gerrit-Project: osmo-pcap Gerrit-Branch: master Gerrit-Owner: Harald Welte <laforge(a)gnumonks.org>

2 5

Can't connecto NanoBTS (More and Better Info)
by Alejandro Aguila 20 Jul '17

20 Jul '17

Hi there! LaF0rge made me some suggestions for a better troubleshooting, so here are the logs in .log format, since the previous email wasn't readable. I'm attaching the RSL+OML pcap file. Please let me know if someone knows how to connect this nanobts =) Cheers!

2 1

Can't connect NanoBTS
by Alejandro Aguila 20 Jul '17

20 Jul '17

Hi there! I just got a nanobts, this if my first time using openBSC. Here is some info: System: gsm@debian:~/osmo_src/bin$ uname -a Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux SETTING IP's: /gsm@debian:~/osmo_src/bin$ ./ipaccess-config -o 10.1.121.1 10.1.121.151// //ipaccess-config (C) 2009-2010 by Harald Welte and others// //This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY/ /Trying to connect to ip.access BTS ...// //<0005> ../../../src/libbsc/abis_nm.c:381 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //OML link established using TRX 0// //setting primary OML link IP to '10.1.121.1'// //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=GPRS-CELL(f1) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:381 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Not installed(07) ADM=Locked // //<0005> ../../../src/libbsc/abis_nm.c:2599 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xf0): SET NVATTR ACK// //Set the NV Attributes.// //gsm@debian:~/osmo_src/bin$ / FINDING BTS: /gsm@debian:~/osmo_src/bin$ sudo ./abisip-find enp0s3// //abisip-find (C) 2009 by Harald Welte// //This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY/ /Trying to find ip.access BTS by broadcast UDP...// //MAC_Address='00:02:95:00:41:2a' IP_Address='10.1.121.151' Unit_ID='20800/0/0' Location_1='' Location_2='BTS_NBT131G' Equipment_Version='140_029_59' Software_Version='120a002_v200b24d0' Unit_Name='nbts-00-02-95-00-41-2A' Serial_Number='00073914' / CONFIG: ! ! OpenBSC configuration saved from vty ! ! password foo ! line vty no login ! e1_input e1_line 0 driver ipa network network country code 334 mobile network code 020 short name AlgoOpenBSC long name OpenBSC auth policy accept-all location updating reject cause 13 encryption a5 0 neci 1 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 4 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3141 0 bts 0 type nanobts band DCS1800 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id 20800 0 oml ip.access stream_id 255 line 0 gprs mode none trx 0 rf_locked 0 arfcn 514 nominal power 23 max_power_red 20 rsl e1 tei 0 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/F timeslot 7 phys_chan_config TCH/F OUTPUT: /gsm@debian:~/osmo_src/bin$ ./osmo-nitb// //<001e> ../../../src/vty/telnet_interface.c:102 telnet at 127.0.0.1 4242// //<0005> ../../../src/libbsc/bsc_init.c:465 // //WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage!// // //<0020> ../../src/input/ipaccess.c:846 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports// //<0017> ../../../src/libmsc/smpp_smsc.c:1001 SMPP at 0.0.0.0 2775// //<0025> ../../../src/ctrl/control_if.c:788 CTRL at 127.0.0.1 4249// //DB: Database initialized.// //DB: Database prepared.// //<0020> ../../src/input/ipa.c:263 accept()ed new link from 10.1.121.151 to port 3002// //Getting attributes from BTS0 type nanobts is not supported.// //Getting attributes from BTS0 type nanobts is not supported.// //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM:ULM_FIFODRV:fifodrv.c#1864 (6082). // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0TxQueue full. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM ra=080036ae sp=40017a38. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [400179e8] |4000b518|00000000|08000af0|08000998|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [400179f8] |20000093|080007e8|00000000|00000093|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a08] |40017b58|40003c64|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a18] |80380000|00000000|40003c64|08002d8b|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a28] |00000000|40017a38|40004a7c|40017a90|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a38] |00000000|40017ab0|080595b8|00000002|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a48] |40006fbc|0800762f|40017ac4|08059a78|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a58] |0000000d|40007098|400047d8|40017a88|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a68] |00000001|00000000|080417f8|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULM [40017a78] |0800c321|40017b58|08007c45|40000093|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS:ULS_FIFODRV:fifodrv.c#1864 (7540). // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0TxQueue full. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS ra=08011da8 sp=4000c7c8. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c778] |4000c784|08000af0|080012d8|000000b3|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c788] |c0000000|00001950|00000050|00000040|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c798] |00000000|00000001|40000093|400032c0|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7a8] |00000000|00000000|80380000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7b8] |60000093|4000c7c8|08011da9|08011da8|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7c8] |40003b10|4000c7e0|400000d3|08000c14|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7d8] |0800a900|55555555|40003b40|4000d288|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7e8] |50036300|400049c4|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c7f8] |00000000|00000000|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0ULS [4000c808] |00000000|00000000|08011d8b|4000c77c|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP:L2_BCH:l2_bch.c#1065 (2586). // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0BCHbcchSItypeValid( prim_p->infoType ). // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP ra=0801446c sp=4000d724. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d6d4] |4000d6e0|08000af0|080012d8|000000b3|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d6e4] |c0000000|00001950|00000050|00000040|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d6f4] |00000000|00000001|40000093|40003bb8|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d704] |00000000|00000000|80380000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d714] |60000093|4000d724|0801446d|0801446c|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d724] |400049d8|4000d73c|400000d3|08000c14|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d734] |0800a900|55555555|40004a08|4000e1e4|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d744] |50036300|4000588c|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d754] |00000000|00000000|00000000|00000000|. // //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=(Logged). :0DLP [4000d764] |00000000|00000000|0801444f|4000d6d8|. // //<0020> ../../src/input/ipa.c:263 accept()ed new link from 10.1.121.151 to port 3003// //<0004> ../../../src/libbsc/bsc_init.c:311 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC=334 MNC=20 LAC=1 CID=0 BSIC=63// //BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Process stopped, Additional Text=lme_manage_fsm_actions.c:636IPC Ping timeout - DLP FAILED. // //BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=38454:WARN:OAM_RES:res_trx_status.c#209:TRX is not responding - reinitialising . // //BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Baseband Transceiver inst=0 ev="DISABLED RSP" st=ini. // //BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Radio Carrier inst=0 ev="DISABLED RSP" st=initial// //. // //BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Baseband Transceiver inst=0 ev="CLEAR I REQ" st=init. // //<0020> ../../src/input/ipaccess.c:241 Sign link vanished, dead socket// //<0020> ../../src/input/ipaccess.c:69 Forcing socket shutdown with no signal link set/

2 1

Documentation on how to use virtual Um between BTS + MS
by Harald Welte 19 Jul '17

19 Jul '17

Hi! Next to the announcement (http://osmocom.org/news/75) I've put together some guide in the wiki as to how the Virtual Um interface can be used with the osmo-bts-virtual, virtphy and mobile programs running all on your local PC: https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um Feel free to try it out and/or improve the wiki page and/or let me know if something is not sufficintly clear. I intentionally don't want to repeat general information about configuring OsmoNITB or using OsmocomBB. The above-mentioned page should only document those aspects that are different from the classic setup with real hardware. I'm now investigating some more of the bugs I'm starting to find with using the VirtualUm interface from my related TTCN-3 testsuite, at this time particularly https://osmocom.org/issues/2380 Will document that testsuite once it can actually run as expected. 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

GSMTAP based Virtual PHY merged in OsmocomBB and OsmoBTS
by Harald Welte 19 Jul '17

19 Jul '17

Hi all! Some of you will have alrady noticed, over the last few days I reviewed, cleaned up, submitted and merged the virtual Um interface support on both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS). Thanks to Sebastian Stumpf for working out most of the related code, after my initial attempt on this got stalled more than 1.5 years ago. This means that you can now run a complete circuit-switched GSM network without posession of any real hardware or use of any radio waves. While that takes away almost all the fun for some of us (I would typically agree), it opens up possibilities, particularly in terms of testing. If anyone wants to play with it, it's actually very easy: * build osmo-bts and the rest of the network-side code (I don't think osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry) * run osmo-bts-virtual with a config file (example included in osmo-bts.git) * make sure you have matching unit_id, band, ... between BTS and BSC/NITB, just like with real hardware OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729. If you don't have any specific multicast routing set up, this will be visible with TTL=1 on the network device of your default route. You should see the GSMTAP frames in wireshark. On the OsmocomBB side, simply start the virt_phy binary. It replaces your calypso based phoen and its firmware and offers the L1CTL socket to the "layer23" programs like "mobile". Once virt_phy is running, you can start "mobile" just like with real hardware. The phone will scan the multicast frames for BCCH messages, build up a list of currently received BTSs and then perform normal cell selection followed by location update. Everything from this point on is just normal. You cannot make voice calls, but any signaling related transactions (LU, SMS, USSD, even call signalling) should work. Voice is missing as there is no format specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet. If somebody plays with this, I would really appreciate if they could update the Osmocom wiki with a guide/howto on how to use such a setup. My personal plans are to use this for verification/testing of those bits that are difficult in a true end-to-end setup like osmo-gsm-tester. That includes: * simulation of massive amount of phones, more than one can easily set up in a lab and connect to USB + RF cabling. * verification of SYSTEM INFORMATION messages, particularly in response to different config files, ensuring that all related bits are set correctly at all times, even after making dynamic updates * verification of the PAGING code, i.e. that paging load is correctly reported, paging messages are structured correctly, ... * exhausting all channels using simulated phones, verification of IMM.ASS.REJECT being sent ins such cases * verification of TA loop * verification of uplink power control loop * verification of radio link timeout * testing of emergency calls, which is very critical with real phones as there's always some possible leakage into real networks * verification of correct CBCH messages * verification of LAPDm contention resolution (two phones selecting same RACH value and going both on same dedicated channel) * verification of measurement reporting (Um vs. RSL) * verification of downlink RF power ramping This will of course take some time, but I'm already making good progress implementing some SYSTEM INFORMATION test code. In case somebody wants to join in on any of the above topics (or has even more ideas on what kind of tests he would want to implement), feel free to follow up so we can coordinate. 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)

2 2

osmo-nitb enable SMS delivery reports
by Anonim Stefan 18 Jul '17

18 Jul '17

Hi, I'm using osmo-nitb in a testing environment and I've soon received a request to enable SMS delivery reports. After looking on the user manual, I couldn't find anything related to this. I've also enabled debug logging and tried to grep for something like that when sending a SMS between two handsets that have SMS delivery reports enabled, without finding out anything. (SMS delivery reports tested and worked on a public telephony system, for those two handsets) Is there such an option available in osmo-nitb to enable delivery reports? --- Thank you, Stefan

4 3

legacy codecs / mixing rates and versions
by Neels Hofmeyr 18 Jul '17

18 Jul '17

Today I checked the new AoIP core network using an old Nokia 1100 handset, which confronted me with codecs. The Nokia 1100 says it is capable of FR2, FR1, HR1: Channel Type - (Speech) Element ID: 0x0b Length: 5 0000 .... = Spare bit(s): 0x00 .... 0001 = Speech/Data Indicator: Speech (1) Channel Rate and Type: Full rate TCH channel Bm. Prefer full rate TCH (8) 1... .... = Extension: Additional Octet .001 0001 = Permitted speech version indication: GSM speech full rate version 2 (GSM EFR) (0x11) 1... .... = Extension: Additional Octet .000 0001 = Permitted speech version indication: GSM speech full rate version 1 (GSM FR) (0x01) 0... .... = Extension: Last Octet .000 0101 = Permitted speech version indication: GSM speech half rate version 1 (GSM HR) (0x05) The "stock" osmo-bsc.cfg I was using so far had only HR3 configured. So I naively thought, let's do: codec-list hr3 fr2 hr1 But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is that a hard limitation? I'm not at all familiar with the reasons. Will we never be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist? Then I picked: codec-list hr3 hr1 That worked, but no audio: the Samsung Galaxy got HR3 and the Nokia HR1 (the BTS was configured for only TCH/F channels, so instead the Nokia actually got assigned an FR1 channel). The call was established but no audio worked. I believe in the OsmoNITB we used to complain in the log that we don't transcode in such a situation, and the call was aborted... When I pick codec-list hr1 then the call works between the handsets. Again both get assigned FR1 on TCH/F; if I configure the BTS to use TCH/H instead, both indeed get assigned HR1 as expected. All in all an interesting situation, which appears to mean that we practically can't allow the newer codecs alone because older handsets would not work, and we can't allow both because each side may pick a different one. Should we wait until we know both sides' codecs and consolidate with each other to pick matching ones before assigning? Is that a "late assignment" as in issue "avoid mismatching TCH/F vs TCH/H pchan types"? https://osmocom.org/issues/1778 But what if no match can be found? only MGW transcoding will solve all situations I guess. Are we planning to do that, also with IuUP in mind? https://osmocom.org/issues/1936 https://osmocom.org/issues/1937 ~N

3 4

new osmo-msc repository
by Neels Hofmeyr 13 Jul '17

13 Jul '17

I have created a fresh osmo-msc repository as a copy of openbsc.git, and pushed the first few patches for gerrit review to move to our "new" Osmocom CN: https://gerrit.osmocom.org/#/q/topic:vlr As suggested before, osmo-msc will see code review and patches merged for VLR, 3G and AoIP, and so will form the basis for creating osmo-bsc, osmo-mgw and osmo-sgsn, as distinct repositories replacing the current openbsc.git. All further development happening in openbsc.git from now on will have to be applied to the new repositories later. Keep that in mind, and maybe postpone larger conflict prone efforts for later. The review process could take some effort. Some of the commits are one collapsed commit of fairly large development efforts. Normally, commits should be small, but in the case of completely refactoring an entire section of the code (VLR) or adding a completely new feature (IuCS, AoIP), it doesn't really help to see incremental back-and-forth changes with intermediate errors and fixes. I decided to collapse the errors with their fixes, and to save the effort of logically plucking apart the large commits, since they anyway only make sense as a whole. If necessary for review, we can still do so. Despite the mass of changes, please do look closely. Parts of the new code have possibly been hacked up in a preliminary fashion and were forgotten to implement properly later -- this will become our new Osmocom master branches, the stable releases and our main development arena, so do apply your scrutiny and let's fix early what we can fix now. The other repositories (osmo-{bsc,mgw,sgsn}) also exist already, and I am preparing to make them work as separate entities after the code review, on respective neels/split branches. Each fresh repository contains the *full* openbsc.git history. The option of relying on grafts to include the old openbsc.git history when needed has been mentioned, but so far was more or less turned down. It is still possible to change that. The openbsc.git history is about 9 Mb -- not too large, so IMHO best to keep it with each separate repos to ease log browsing, git blame and so forth. OTOH, we have it four times, which makes 36 Mb of duplicated history. If anyone still prefers a flat snapshot migration with a wiki page describing how to graft in the old history, we may discuss and change that. No branches have been migrated except the current aoip development branch that is going to become the new master. All tags are included, except: the signed '0.1.2' openbsc version tags are replaced by 'openbsc/0.1.2' tags pointing at the same revisions, so that we don't confuse them with the new version tags in each new project. Preliminarily, the last openbsc.git master has been tagged as version 0.0.1 in order to get *something* out from git-version-gen, useful for referencing a version of the new libosmo-mgcp library in osmo-{msc,bsc} configure.ac. We still need to decide whether to start versioning afresh or continue from the openbsc.git version scheme. openbsc.git ended with 0.15.0. My personal choice would be to bump the major and start from 1.0.0 in each new repository. ~N

2 2

Question about activate GPRS
by Marcus Dias 13 Jul '17

13 Jul '17

Dear all, I have one sysmo2050, with the GSM running fine. However, i would like to test GPRS data transmission, I was following this setup page ( https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS#Open…), but i couldnt make it work. Anyone has done it before / can help me? Thanks beforehand, Marcus Dias UFPA - Lasse - LaPS

3 4

[RFC] rework location update request
by Alexander Couzens 12 Jul '17

12 Jul '17

Hi, recently my modem with an already known SIM got a location update reject, because the procedure timed out. So I looked more into the location updates. How openbsc location update works: MS Network LOC REQ -> <- Identity Req IMSI Identity Resp IMSI -> <- Identity Req IMEI Identity Resp IMEI -> <- LOC ACCEPT OpenBSC is using a Timeout (5 sec) for the completion of location update. So let's say we trigger for unknown reason the timeout (e.g. RF problem). MS Network LOC REQ -> <- Identity Req IMSI (No response) <- LOC Reject! cause 13 / No roaming allowed. If the MS receive it, it will put our network on it's blacklist and won't try it again until power cycled. We could change reject cause to something different [1], but we might want to reject foreign SIMs not to try our network again. The problem here is that openBSC use the same configuration to reject unknown SIMs as well for timeouts. But I think this timeout should be removed. 04.08 doesn't describe a timeout on location update request on network side. But it describes other timeouts: 04.08 describes: - T3260 auth req. sent, wait until response (12 sec) - T3270 identity req. sent, wait until response (12 sec) I think we should implement both timers and drop the RR connection if it fires. I'm unsure if it's needed: But OpenBSC could count un-successful location update req. Reset counter if it's succeeded. After a certain amount of failures we send a location update reject. (unsure which cause) best, lynxis Related Specs: GSM 04.08 [1] Chapter 4.4 describing location update GSM 04.08 [1] Chapter 11.2 Timers GSM 04.08 [1] Chapter Annex G Reject Causes [0] nitb.cfg: network: location updating reject cause [1] ETSI TS 100 940 -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC