- OpenBSC - lists.osmocom.org

Thoughts on a next generation MIB/VTY replacement
by Harald Welte 26 Apr '17

26 Apr '17

Hi All, Using zebra/quagga VTY code was a great idea back then and has served us nicely in all those years. I like the general style of the command-line based interface with its various nodes, the strict syntax checking, the tab completion and the interactive context-sensivive help. However, it feels a bit 20ieth-century-ish to have to manually write code to parse and to save the respective values. This is not a productive way to spend our development resources, and it is error prone. The "save" can be forgotten, resulting in non-saveable config parameters. The save can store values that the "parse" function will not be able to read again, etc. Furthermore, the VTY is inherently a human user interface, not intended for programmatic consumption. For programmatic access, we have developed the control interface. In reality though, only 1% of the parameters available in the VTY are exported via the control interface. And rather than adding all the missing bits and pieces with hand-crafted code to the control interface, we should have a generic way to define a new configuration value, and that value should then be automatically parse- and storable via VTY as well as a programmatic interface. The next "problem' is that the current telnet connections live within the process of the application. This means that a user can effectively "stall" the main application by performing I/O intensive operation on the VTY, or even on as many VTY/telnet sessions as he wants. There shouldn't be any need for this, at least not for something as mundane as performing configuration changes. Of course the VTY has different use cases such as runtime introspection of system state as well as logging. But still. Yet another concern is "VTY and telnet port proliferation". Particularly with the conversion from NITB to BSC+MSC+HLR, we are yet again getting more network elements with their own telnet ports. Remembering the port numbers is clumsy. It would be more convenient if a single command line interface could provide access to the configuration and the state of multiple different processes / network elements. Last, but not least, the current implementation is fixed to telnet, without any form of authentication, and without a path to migrate e.g. to something like SSL or SSH. I don't think it is a major concern (you can always SSH to the system and then telnet locally). So what I had in mind for quite some time (actually since netconf 1.2 about one year ago), is to have some kind of an external "VTY/MIB daemon" (or even separate daemons for each) which maintains a hierarchical database of configuration values. The MIB deamon simply offers an API (via client library) to GET or SET the individual values, or to NOTIFY an application about a changed value. This API is both used by the actual Osmocom programs to obtain their configuration (and obtain updates to it during runtime), as well as by the "VTY daemon" providing interactive shell access to it. Finally, other external applications could use the same interface/client library to do the same. A proxy to SNMP or REST interfaces can be imagined, for even more interfacing with the outside world. What I don't like about many existing MIBs I've used (as a sysadmin/user, not a developer) is their simple type system. You can often specify any random value to such a MIB, even one that is completely useless. A simple INT or STRING type is not sufficient, we really want the ability to have ENUM types, to have integers with ranges, etc. - just like we have in the VTY. Also, the MIBs I've used typically are nothing more than a hierarchical key-value store. They do not contain the information required for interactive, context-sensitive help needed for the "VTY" feel :( This is btw also the problem I have with OpenWRT's uci: It just has keys and values, with no way to constrain those values to something that's reasonable to the given program/context that is being configured, and there's no help or other information associated with those keys and values. So what I would like to see in this context, is some way to have a machine-parseable description of a "MIB/config item", together with syntax, ranges, enum values, help texts, etc (ideally in the C source code, possibly in comments?) which is used by some kind of MIB compiler to build up the hierarchical structure of the MIB and all of its keys as well as their permitted values and syntax reference. This information is then available to the VTY/telnet connections, irrespective of whether a given application [using those values] is running at all. Once an application starts, it can query for the configuration values it is interested in and populate its internal data structures from it. Ideally, one would even be able to generate a 'struct' from the MIB compiler, so that there is no need to explicitly call a "get" function on each single configuration value, but one simply gets a C-language 'struct' with all the values filled in by the client library. As stated above, there should be some way how he MIB can notify applications about changes to certain nodes in the MIB tree, so the application[s] can react to that. I don't have a clear picture yet how transaction logic (like changing multiple values and then committing them at once) would work, or whether applications should even be able to reject/revert a modification? In either case, I just wanted to share my thoughts on this. I know it sounds rather complex, but I think the investment in some kind of unified configuration database system would save us of a lot of boilerplate code and subtle bugs and inconsistencies. I've created https://osmocom.org/issues/1975 with above text to keep track of it, but I think at this point it's more of a mailing list discussion rather than something we can put into an issue. I guess the progress would rather be * first discuss it here and/or at OsmoDevCon * create something like a specification in the wiki * then follow-up with actual tickets on the work items All of this is brainstorming and vaporware, but I can't help to think of better ways of doing this. If somebody has experience with any existing systems and wants to share if and how they might fit, or what other ideas are useful to borrow: Please share! 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)

6 8

openbsc 3G supoort with octasic phy
by Snehasish Kar 26 Apr '17

26 Apr '17

Hi I just wanted to know has anyone tried to use openbsc 3G with octasic 3G phy. BR Snehasish

3 4

gerrit trouble "Change is New"
by Harald Welte 25 Apr '17

25 Apr '17

I want to merge the patchset from my libosmo-sccp sigtran branch to master, but gerrit doesn't allow me to. I've re-pushed the patch set already multiple times, the last time also doing a minor cosmetic change to the commit log message of the first patch in the series (https://gerrit.osmocom.org/#/c/2191/) gerrit refuses to merge even that very first patch in the series with "change is new". What should I do to get this merged? -- - 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)

4 7

osmocom-bb moved to gerrit
by Neels Hofmeyr 24 Apr '17

24 Apr '17

The osmocom-bb git repository has now moved to gerrit. For patch submission to osmocom-bb, see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit ~N

1 0

FSM for lchan release handling -- release indication after SACCH deactivation timeout
by Holger Freyther 23 Apr '17

23 Apr '17

Good Evening, this is a bit of speculation but Keith showed me a trace with some network delay that makes a case for using FSM for the lchan itself. It seems the following can happen: * LU REJECT * Start Channel Release ** Send RR Release to the MS ** Deactivate SACCH ** Start Timer ... network transmission issues... at least 5s * SACCH deactivate timeout ** Start error release procedure.. ... * LATE RELEASE INDICATION arrives triggering other release procedure? So with a proper FSM we would have transitioned into the error path and would just ignore the RELEASE INDICATION. The question is if someone has budget to do a FSM transition here? I will try to build a simulated testcase for that. The other part that seems to happen (and I don't understand yet): * Allocating a lchan before it is fully freed?! * The BTS sending us RF Channel Releasse ACK twice cheers holger

1 0

Control interface introspection of FSMs
by Harald Welte 19 Apr '17

19 Apr '17

Good News, everyone [tm] Some may have already played with it: The osmo_fsm's already have gained a VTY interface (see http://git.osmocom.org/libosmocore/tree/src/vty/fsm_vty.c) some time ago, which is nice for manual debugging and the like. However, for automatic testing one would normally want to do something like the following: 1) send a packet to the implementation under test (IUT) 2) then check if a given FSM has been created, a state has changed, a timer is running, etc. 3) go to '1' for the next packet, or wait for a timeout and then re-check, ... I've just introduced a generic CTRL interface for programmatic access to osmo_fsm. See https://gerrit.osmocom.org/#/c/2377 for details. The general idea is that you can send a CTRL command like GET 1 fsm.FSM_NAME.id.INSTANCE_ID.state GET 1 fsm.FSM_NAME.id.INSTANCE_ID.timer GET 1 fsm.FSM_NAME.id.INSTANCE_ID.parent-name GET 1 fsm.FSM_NAME.id.INSTANCE_ID.dump Where FSM_NAME is the name of the osmo_fsm (class) and INSTANCE_ID is the identity of the instance (e.g. the IMSI of a subscriber in the VLR code). So in OsmoMSC, something like GET 1 fsm.vlr_lu_fsm.id.901700123456789.state would return the string name of the state for the location update FSM of the given IMSI, e.g. "VLR_ULA_S_WAIT_LU_COMPL_STANDALONE" I presume Neels will like this. Could be used from osmo-gsm-tester to not just do "black box testing" from MS to MS or MS to MNCC, but to actually verify individual states/transitions on all osmo_fsm enabled elements. It's of course questionable if an end-to-end test should care, but I can think of all kinds of other testing (particularly of my new SIGTRAN work) where it is absolutely useful. Once the above-mentioned patches are merged, applications with a control inteface will have this functionality enabled automatically. I think this makes osmo_fsm even more useful. I can imagine use cases not only related to testing, but also use cases of e.g. user interfaces or visualization. Regards, Harald p.s.: In German we say "self praise stinks", but I really think osmo_fsm is one of the best things happening to the Osmocom cellular projects in recent years. Now we just need to convert more code to use it. -- - 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 1

OpenBSC
by Bizhan Changizi 19 Apr '17

19 Apr '17

Dear Sipos Csaba Hi firstly my english languages is not good, and excuse me. i find Your contact info from blow link. http://lists.osmocom.org/pipermail/openbsc/2015-September/000413.html dear Sips i need to help to run OsmoNITB <https://osmocom.org/projects/osmonitb/wiki> but i have a problem when compile the source. but i can’t resolve it, can you help me to to run OpenBSC plz, tnx. Problem : CC abis_om2000_vty.o CC abis_rsl.o CC bsc_rll.o CC paging.o CC bts_ericsson_rbs2000.o CC bts_ipaccess_nanobts.o In file included from bts_ipaccess_nanobts.c:39:0: /usr/local/include/osmocom/abis/ipaccess.h:7:8: error: redefinition of ‘struct ipaccess_unit’ struct ipaccess_unit { ^ In file included from bts_ipaccess_nanobts.c:38:0: /usr/local/include/osmocom/gsm/ipa.h:11:8: note: originally defined here struct ipaccess_unit { ^ make[3]: *** [bts_ipaccess_nanobts.o] Error 1 make[3]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc/src/libbsc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc' make: *** [all] Error 2 telecom@OpenBCS:~/osmo/src/osmonitb$ best regurds

2 1

UMTS-Stick on nano3G?
by Andreas Mueller 19 Apr '17

19 Apr '17

Hello, I tried to use a Huawei E1823 UMTS-Stick on a debian8-laptop with wvdial and pppd to connect to a nano3G for getting an IP/Internet-connection via UMTS/HSDPA. The setup is mainly as described on http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_wi…. When using an android-Smartphone with the same configuration of the ggsn and the other components the IP/Internet-connection is working. After pppd is started from wvdial it receives his local IP-address from the "net 192.168.99.0/24" parameter of ggsn.conf and also the configured DNS-Server, but no remote-IP, so 10.64.64.64 is used by pppd as a default value: ... --> local IP address 192.168.99.5 --> pppd: ï¿½[7f] --> remote IP address 10.64.64.64 --> pppd: ï¿½[7f] --> primary DNS address 8.8.8.8 --> pppd: ï¿½[7f] ..which results in an unusable ppp0-device: ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.99.5 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 Has anybody successfully used an UMTS-Stick with ggsn? How can I tell ggsn to send his IP-Adress, which can be used by pppd as "remote IP address"? Are there special options for pppd which I have to use? thanks and greetings, Andreas

4 7

OpenBSC TCH/H
by robert 17 Apr '17

17 Apr '17

Hello, I have set all the traffic channels to TCH/H and started the BTS but I was not able to perform a call. Is there something else that should be done ? Best regards,

2 1

Control Interface related testing
by Harald Welte 16 Apr '17

16 Apr '17

Dear all, I have just submitted some patches which allow test cases to use the Control Interface internally, without binding to a TCP port. See https://gerrit.osmocom.org/#/c/2375/ and https://gerrit.osmocom.org/#/c/2376/ Using this, one can now write unit tests for control commands, without having to go for a multi-process setup with an external control client connected to the control TCP port (which is not easily possible in CI as the port might be used by another test case, ...) -- - 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