catch-22 VTY error

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
Mon May 8 22:15:12 UTC 2017


I'd like to share a VTY config error analysis that has a tricky solution:

I started osmo-bsc -c osmo-bsc.cfg with, according to
openbsc/doc/examples/osmo-bsc:

	net
	 [...]
	 bts 0
	  [...]
	  periodic location update 30
	  trx 0
	   [...]

and get this error:

	There is no such command.
	Error occurred during reading below line:
	  trx 0

what? 'net / bts / trx' is no command??

Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on
this branch, I've actually moved the 'periodic location update N' command a
level up, from net / bts / periodic to net / periodic (background: assuming
that OsmoMSC does not have individual BTS info, we moved some settings up to
network level; whether this makes sense for osmo-bsc is a different question,
it's just what happens to be on the vlr_3G branch now).

So there is no net / bts / periodic command.
Why do I get an error for net / bts / trx instead?

two reasons:

1. 'trx 0' was the line following the 'periodic' command,
2. since 'periodic' exists one level above, the vty code goes to the parent
   node automatically.

About 2: we tend to indent our VTY config files, but in fact the indentation
has no effect whatsoever, it is just eye candy (very useful eye candy).

The code in question: If a command does not exist, try 'vty_go_parent()' and
see if the command exists there. That's what allows us to omit 'exit' in our
config files to go to the parent node explicitly:

libosmocore/src/vty/command.c:

int config_from_file(struct vty *vty, FILE * fp)
{
        int ret;
        vector vline;

        while (fgets(vty->buf, VTY_BUFSIZ, fp)) {
                vline = cmd_make_strvec(vty->buf);

                /* In case of comment line */
                if (vline == NULL)
                        continue;
                /* Execute configuration command : this is strict match */
                ret = cmd_execute_command_strict(vline, vty, NULL);

                /* Try again with setting node to CONFIG_NODE */
                while (ret != CMD_SUCCESS && ret != CMD_WARNING
                       && ret != CMD_ERR_NOTHING_TODO
                       && is_config_child(vty)) {
HERE ----->             vty_go_parent(vty);
                        ret = cmd_execute_command_strict(vline, vty, NULL);
                }

                cmd_free_strvec(vline);

                if (ret != CMD_SUCCESS && ret != CMD_WARNING
                    && ret != CMD_ERR_NOTHING_TODO)
                        return ret;
        }
        return CMD_SUCCESS;
}


In this case the 'periodic...' command does in fact now exist one level above,
so the vty_go_parent() is successful and running that command works.  But, the
vty config parsing then sits above on the 'network' level, is no longer in 'bts
0' and hence refuses to accept the following bts-level command, in this case
'trx 0'. Confusing!

So it's not a bug, it's a feature. But it's a feature we might see quite often
if we move the 'periodic' command up to network level and users attempt to use
their old config files.

Same goes for the 'timezone' command, BTW, so we might want to rename commands,
or re-consider moving commands one level up in the first place. Maybe we should
leave backward compat catchers in place that print a warning.

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170509/4c5a4b95/attachment.bin>


More information about the OpenBSC mailing list