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)
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)
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...*
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
