RFC: generic CTRL interface for VTY config settings

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Thu Feb 18 12:17:53 UTC 2021


On Tue, Feb 16, 2021 at 04:23:12PM +0100, Harald Welte wrote:
> 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 at 0.trx@1.timeslot at 0.training_sequence_code 3

We also have numerous commands where there are spaces that would look weird
when written as e.g. # or @:

network
 handover1 power budget hysteresis (<0-999>|default)

We have commands where the values are interleaved with keyword tokens, i.e.
where there is no clean name -> value relation:

  neighbor lac <0-65535> arfcn <0-1023> bsic (<0-63>|any)

We have commands that are additive:

  si2quater neighbor-list add earfcn <0-65535> thresh-hi <0-31> thresh-lo <0-32> prio <0-8> qrxlv <0-32> meas <0-8>
  si2quater neighbor-list del earfcn <0-65535>

Commands without a value part:

  allow-attach
  no periodic location update

Trying to translate all of these cases into CTRL-like name->value feels very
hacky to me, with many quirks and pitfalls waiting on us around numerous
corners. We'll run into ambiguities, escaping issues, and unreadable commands.

A cleaner approach seems to me to have a CTRL command that invokes VTY lines,
with a defined line separator, with VTY commands as-is in the "value" part of
the CTRL command. E.g.:

  SET config network;bts 0;trx 1;timeslot 0;training_sequence_code 3

Then we don't need to worry about translating VTY commands to valid CTRL
identifiers, and except for concatenating multiple lines the VTY commands can
be run 1:1 without translation mangling in-between. Many problems gone.

As line separator, ';' comes to mind from common programming languages, or '%'
or '#' since those two are otherwise used for comments in the VTY and will not
likely cause ambiguities. We could even send LF as line separator like:

  SET config network
  bts 0
  trx 1
  timeslot 0
  training_sequence_code 3

so that the "value" part of the CTRL command is *exactly* the same as we would
feed to a telnet client.

At this point I'm asking myself again, what is the aim here -- an external
program that can connect to CTRL might as well also connect to VTY and can
already issue these config commands there. Is the aim to save one connection?

I still have the impression that this idea is well meant but in reality misses
practicality and usefulness. It's just a one-shot telnet client piped through
CTRL, in the worst case with lots of mangling involved. where is the benefit?

Would be nice if it made sense and things would fall into place, but AFAICT it
unfortunately simply doesn't work out. VTY as we implemented it is too
free-format and unstructured, we won't be able to tame it well.

~N



More information about the OpenBSC mailing list