OpenBSC February 2021

openbsc@lists.osmocom.org

16 participants
26 discussions

Introducing ntt. Modern tools for TTCN-3
by Simon, Matthias (Nokia - DE/Ulm) 22 Feb '21

22 Feb '21

Hi, I am Matthias, a TTCN-3 tool developer from Nokia. Thank you for opening your work. Your repository osmo-ttcn3-hacks helped me to understand how other developers use TTCN-3 for testing. This gave me valuable insights for tool development. I hope I can give something back by opening up our internal TTCN-3 tools as well. Harald suggested to introduce them on this list. I'd appreciate your feedback. Our project is called ntt and it provides various tools for working with TTCN-3 [1]. For example, you can create a tags file: $ ntt tags ./osmo-ttcn3-hacks/bts >TAGS Or you can list things. To filter cyclic imports, for example: $ ntt list imports ./osmo-ttcn3-hacks/bts | tsort 1>/dev/null But the most interesting piece is probably the TTCN-3 language server: ntt implements the language server protocol. This makes ntt a universal TTCN-3 language plugin for virtually any editor or IDE [2]. It's still very much beta, but we are finishing the Go to Definition feature (as replacement for ctags files). The next feature would be adding various diagnostics. It would be great if you could give ntt a try and share your experience or editor configuration with me. This is my first open source project and we still have to figure some stuff out. So please excuse if there are still some rough edges. Cheers, Matthias [1] https://nokia.github.io/ntt/ [2] https://nokia.github.io/ntt/editors/

3 4

RFC: generic CTRL interface for VTY config settings
by Harald Welte 18 Feb '21

18 Feb '21

Dear all, we always had said the VTY is a human CLI, while the CTRL interface is for interfacing with other software. This was primarily related to asking users to not parse the VTY output of "show" commands or the like. For configuration via VTY, we have to provide a stable interface anyway, as otherwise loading config files would not be possible across [non-major] software upgrades. While that is right in principle, the fact that we don't have a generic configuration store / API / MIB means that one would explicitly have to add CTRL command for all relevant settings, which may have been realistic in 2010, but is unrealistic with the hundreds of VTY configuration parameters today. I was thinking wither it might make sense to add a generic CTRL interface GET/SET for "configuration" mode VTY settings. This would mean we write code once, and immediately expose all our VTY nodes to CTRL. Thinking of the following example done via VTY: ----------------------------------- OsmoBSC> enable OsmoBSC# configure terminal OsmoBSC(config)# network OsmoBSC(config-net)# bts 0 OsmoBSC(config-net-bts)# trx 1 OsmoBSC(config-net-bts-trx)# timeslot 0 OsmoBSC(config-net-bts-trx-ts)# training_sequence_code 3 ----------------------------------- We could have something like the following CTRL command: SET network.bts.0.trx.1.timeslot.0.training_sequence_code 3 The devil is a bit in the details of the syntax * the normal '.' as separator looks generally OK, I think we have [almost?] no VTY commands that include a ',' * we somehow need some kind of separator to tell where individual VTY commands are separated, like SET network."bts 0"."trx 1"."timeslot 0".training_sequence_code 3 or SET network|bts.0|trx.1|timeslot.0|training_sequence_code 3 or SET network#bts.0#trx.1#timeslot.0#training_sequence_code 3 or SET network.bts#0.trx#1.timeslot#0.training_sequence_code 3 SET network.bts@0.trx@1.timeslot@0.training_sequence_code 3 I think the last examples would be more "natural" for existing CTRL interface code, as the dot separat separates tokens, and we simply expand the '#' or '@' to spaces in the context of VTY commands The generic vty-cfg-via-CTRL code then would basically emulate a user entering the sequence of commands - including the "exclusion" of not allowing multiple concurrent VTY or vty-cfg-via-CTRL users at the same time What do you guys think? Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

5 7

testing TTCN3 test stability
by Harald Welte 14 Feb '21

14 Feb '21

I think this might be of interest to some of the other developers. Soemtimes we have a problem that the test suite itself is not 100% stable, and it's not easy to reproduce a test that fails sporadically every Nth time. As the "execute" statement in the "control" section actually returns a verdict type, you can use the following construct in a control section: control { for (var integer i := 0; i < 10000; i := i+1) { var verdicttype v; v := execute( TC_paging_ps_ptp_lac() ); if (v != pass) { break; } } } This way you keep running the test suite until the given test fails for the first time. Then go do something else for some hour(s) and by the time you get back, hopefully you will have reproduced the problem. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 2

Inexpensive Huawei GSM Picocells
by Saturn Rocket 13 Feb '21

13 Feb '21

4 6

Question about OsmoGGSN project
by morteza ali Ahmadi 10 Feb '21

10 Feb '21

Hi, osmocom team members We have run OsmoGGSN project using the attached config file in this email and the following command: osmo-ggsn As you can see in the config file, we have set IP 127.0.0.2 for GGSN. After executing the above command, a tunnel named tun4 is created. To communicate with SGSN, we use the SGSN emulator in OsmoGGSN as follow: sgsnemu -l 127.0.0.1 -r 127.0.0.2 After executing the above command, we see that 2 packets are sent from SGSN to GGSN. These packets are "Echo request" and "Create PDP context request" and GGSN responses to SGSN with the packets "Echo response" and "Create PDP context response". To test tun4, we send a GTP <DNS> packet containing an arbitrary query to GGSN and we see that this GTP <DNS> packet is received in Loopback (lo) interface and also, the DNS packet is received in tun4 interface. But there is no DNS response to our query neither in tun4 interface nor lo interface. A screenshot of the lo interface and tun4 interface in the wireshark is attached in this email (right is lo and left is tun4). How can we receive DNS responses to our DNS query? (Does tun4 require routing or something else?) -- *When there is much light, The shadow is deep...*

2 2

Ettus USRP E100 usage for current osmo-trx
by Ivan Babanov 09 Feb '21

09 Feb '21

Hello all! Does anybody have any actual information about the possibility to run osmo-trx on Ettus E100 board? I see some references in manuals about the possibility of running it, but I can't find details on how to do it. I tried several ways: 1. Build from source on target HW. Unfortunately "autoreconf" crashes with some perl module dependency. 2. Install binaries. Binaries for arm available only for Debian 9, so I built an image and installed Debian 9.0 on SD-card. Installation of binaries was unsuccessful because of some unmet dependencies. 3. Build from scratch on Debian 9.0. I was partially successful in it. I was able to build osmocore and osmo-trx. The problem was to run it because now, uhd_find_devices shows an empty list. It looks like that kernel module usrp_e.ko should be loaded, but I have no idea where to find its sources. And one more question: Is it a proper place to ask questions related to BTS and TRX? Should I move my question to some other mail list? Thank you Ivan

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2021