osmocom
/
libosmocore
mirror of https://gerrit.osmocom.org/libosmocore
11
0
Fork 0
Code Issues Releases Wiki Activity
libosmocore/tests/vty/vty_test.ok

372 lines
11 KiB
Plaintext
Raw Normal View History

vty: Fix misusage of snprintf in vty/utils.c Compiled with ubuntu 1204 (precise), where -Wformat-security is enabled by -Wall. Test yields ok, but the current implementation doesn't properly support multi-character separators and end strings. So the test output is truncated. Addresses: utils.c: In function 'vty_cmd_string_from_valstr': utils.c:84:2: warning: format not a string literal and no format arguments [-Wformat-security] utils.c:84:2: warning: format not a string literal and no format arguments [-Wformat-security] utils.c:108:2: warning: format not a string literal and no format arguments [-Wformat-security] utils.c:108:2: warning: format not a string literal and no format arguments [-Wformat-security]
2013-08-06 12:29:14 +00:00
Going to test vty_cmd_string_from_valstr()
vty: Support multi-char separators and end strings In vty_cmd_string_from_valstr() include the real string lengths of the sep and end arguments into the buffer size calculation.
2013-08-06 12:29:15 +00:00
Tested with %s-strings, resulting cmd = '[prefix%s%s%s%s%s][foo%s%s%s%s%s][sep%s%s%s%s%s][bar%s%s%s%s%s][end%s%s%s%s%s]'
vty: Add vty_install_default() and use for the vty nodes This adds the vty_install_default() function that is basically the install_default() function plus the registration of the commands 'exit' and 'end'. The latter is only provided in subnodes of ENABLED_NODE and CONFIG_NONE. The VTY test program is extended to check these commands. Ticket: OW#952
2013-09-06 14:52:00 +00:00
Going to test VTY node tree structure
Going to execute 'enable'
Returned: 0, Current node: 3 '%s# '
Going to execute 'configure terminal'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'exit'
Returned: 0, Current node: 3 '%s# '
Going to execute 'configure terminal'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'end'
Returned: 0, Current node: 3 '%s# '
Going to execute 'configure terminal'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'log stderr'
Returned: 0, Current node: 7 '%s(config-log)# '
Going to execute 'exit'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'log stderr'
Returned: 0, Current node: 7 '%s(config-log)# '
Going to execute 'end'
Returned: 0, Current node: 3 '%s# '
Going to execute 'configure terminal'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'line vty'
stats/vty: Add stats configuration This commit provides stats configuration similar to the log configuration. The following vty commands are added to the config node: stats reporter statsd Create/Modify a statsd reporter no stats reporter statsd Remove a statsd reporter To actually configure a reporter, the config-stats node is entered when the "stats reporter" command has succeeded. The following new vty commands are available there: local-ip ADDR Set the IP address to which we bind locally no local-ip Do not bind to a certain IP address remote-ip ADDR Set the remote IP address to which we connect remote-port <1-65535> Set the remote port to which we connect prefix PREFIX Set the item/counter name prefix no prefix Do not use a prefix enable Enable the reporter disable Disable the reporter Sponsored-by: On-Waves ehf
2015-10-20 17:05:52 +00:00
Returned: 0, Current node: 9 '%s(config-line)# '
vty: Add vty_install_default() and use for the vty nodes This adds the vty_install_default() function that is basically the install_default() function plus the registration of the commands 'exit' and 'end'. The latter is only provided in subnodes of ENABLED_NODE and CONFIG_NONE. The VTY test program is extended to check these commands. Ticket: OW#952
2013-09-06 14:52:00 +00:00
Going to execute 'exit'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'line vty'
stats/vty: Add stats configuration This commit provides stats configuration similar to the log configuration. The following vty commands are added to the config node: stats reporter statsd Create/Modify a statsd reporter no stats reporter statsd Remove a statsd reporter To actually configure a reporter, the config-stats node is entered when the "stats reporter" command has succeeded. The following new vty commands are available there: local-ip ADDR Set the IP address to which we bind locally no local-ip Do not bind to a certain IP address remote-ip ADDR Set the remote IP address to which we connect remote-port <1-65535> Set the remote port to which we connect prefix PREFIX Set the item/counter name prefix no prefix Do not use a prefix enable Enable the reporter disable Disable the reporter Sponsored-by: On-Waves ehf
2015-10-20 17:05:52 +00:00
Returned: 0, Current node: 9 '%s(config-line)# '
vty: Add vty_install_default() and use for the vty nodes This adds the vty_install_default() function that is basically the install_default() function plus the registration of the commands 'exit' and 'end'. The latter is only provided in subnodes of ENABLED_NODE and CONFIG_NONE. The VTY test program is extended to check these commands. Ticket: OW#952
2013-09-06 14:52:00 +00:00
Going to execute 'end'
Returned: 0, Current node: 3 '%s# '
Going to execute 'configure terminal'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'log stderr'
Returned: 0, Current node: 7 '%s(config-log)# '
Going to execute 'line vty'
VTY: interactive: never look for matching commands on parent node For interactive telnet VTY, remove the implicit move up to the parent node when a command did not succeed on the current node level. When reading config files, this behavior was useful to allow skipping explicit 'exit' commands. (A different patch deals with that.) In the telnet VTY, this behavior was never necessary. Explicit 'exit' commands can move to the parent node, and typically uninformed users expect to require that. On a telnet VTY, counting indents like for reading config files is not an option: a user will always type from the first column or may paste some leading spaces without intended meaning. After this patch, it is thus no longer possible to paste a complete config across several node levels directly to a telnet session, unless it contains 'exit' commands. Change-Id: Id73cba2dd34676bad8a130e9c45e67a272f19588
2017-09-07 02:52:05 +00:00
Returned: 2, Current node: 7 '%s(config-log)# '
vty: Add vty_install_default() and use for the vty nodes This adds the vty_install_default() function that is basically the install_default() function plus the registration of the commands 'exit' and 'end'. The latter is only provided in subnodes of ENABLED_NODE and CONFIG_NONE. The VTY test program is extended to check these commands. Ticket: OW#952
2013-09-06 14:52:00 +00:00
Going to execute 'end'
Returned: 0, Current node: 3 '%s# '
Going to execute 'exit'
Returned: 0, Current node: 3 '%s# '
stats/test: Add tests to check VTY configuration This commit adds tests to verify the stats related VTY configuration commands. Sponsored-by: On-Waves ehf
2015-11-03 14:21:34 +00:00
Going to test VTY configuration of the stats subsystem
Going to execute 'enable'
Returned: 0, Current node: 3 '%s# '
Going to execute 'configure terminal'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'stats reporter foobar'
Returned: 2, Current node: 4 '%s(config)# '
Going to execute 'stats interval 42'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'stats reporter log'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'prefix myprefix'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'no prefix'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'level peer'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'level subscriber'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'level global'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'level foobar'
Returned: 2, Current node: 8 '%s(config-stats)# '
Going to execute 'enable'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'disable'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'exit'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'stats reporter statsd'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'prefix myprefix'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'no prefix'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'level peer'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'level subscriber'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'level global'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'level foobar'
Returned: 2, Current node: 8 '%s(config-stats)# '
Going to execute 'remote-ip 127.0.0.99'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'remote-ip 678.0.0.99'
Returned: 1, Current node: 8 '%s(config-stats)# '
Going to execute 'remote-port 12321'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'local-ip 127.0.0.98'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'no local-ip'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'mtu 987'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'no mtu'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'enable'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'disable'
Returned: 0, Current node: 8 '%s(config-stats)# '
Going to execute 'exit'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'no stats reporter log'
Returned: 0, Current node: 4 '%s(config)# '
Going to execute 'no stats reporter statsd'
Returned: 0, Current node: 4 '%s(config)# '
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
reading file ok.cfg, expecting rc=0
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level1 child cmd a
called level2 node a
called level2 child cmd a
called level3 node a
called level3 child cmd a
called level1 node b
called level1 child cmd b
called level2 node b
called level2 child cmd b
called level1 node c
called level1 child cmd c
called level2 node c
called level2 child cmd c
called level3 node c
called level3 child cmd c
called level2 node d
called level2 child cmd d
called level1 node e
called level1 child cmd e
called level2 node e
called level2 child cmd e
called level2 node f
called level2 child cmd f
called level1 node g
called level1 child cmd g
called level1 node h
called level1 child cmd h
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=0
reading file ok_more_spaces.cfg, expecting rc=0
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level1 child cmd a
called level2 node a
called level2 child cmd a
called level3 node a
called level3 child cmd a
called level1 node b
called level1 child cmd b
called level2 node b
called level2 child cmd b
called level1 node c
called level1 child cmd c
called level2 node c
called level2 child cmd c
called level3 node c
called level3 child cmd c
called level2 node d
called level2 child cmd d
called level1 node e
called level1 child cmd e
called level2 node e
called level2 child cmd e
called level2 node f
called level2 child cmd f
called level1 node g
called level1 child cmd g
called level1 node h
called level1 child cmd h
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=0
reading file ok_tabs.cfg, expecting rc=0
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level1 child cmd a
called level2 node a
called level2 child cmd a
called level3 node a
called level3 child cmd a
called level1 node b
called level1 child cmd b
called level2 node b
called level2 child cmd b
called level1 node c
called level1 child cmd c
called level2 node c
called level2 child cmd c
called level3 node c
called level3 child cmd c
called level2 node d
called level2 child cmd d
called level1 node e
called level1 child cmd e
called level2 node e
called level2 child cmd e
called level2 node f
called level2 child cmd f
called level1 node g
called level1 child cmd g
called level1 node h
called level1 child cmd h
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=0
reading file ok_tabs_and_spaces.cfg, expecting rc=0
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level1 child cmd a
called level2 node a
called level2 child cmd a
called level3 node a
called level3 child cmd a
called level1 node b
called level1 child cmd b
called level2 node b
called level2 child cmd b
called level1 node c
called level1 child cmd c
called level2 node c
called level2 child cmd c
called level3 node c
called level3 child cmd c
called level2 node d
called level2 child cmd d
called level1 node e
called level1 child cmd e
called level2 node e
called level2 child cmd e
called level2 node f
called level2 child cmd f
called level1 node g
called level1 child cmd g
called level1 node h
called level1 child cmd h
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=0
reading file ok_ignore_comment.cfg, expecting rc=0
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node
called level1 child cmd
called level2 node
called level2 child cmd
called level1 node
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=0
reading file ok_ignore_blank.cfg, expecting rc=0
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node
called level2 node
called level2 child cmd
called level3 node
called level3 child cmd
called level1 node
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=0
reading file fail_not_de-indented.cfg, expecting rc=-22
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level1 child cmd a
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=-22
reading file fail_too_much_indent.cfg, expecting rc=-22
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level1 child cmd a
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=-22
reading file fail_tabs_and_spaces.cfg, expecting rc=-22
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level1 child cmd a
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=-22
reading file ok_indented_root.cfg, expecting rc=0
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level1 child cmd
called level2 node
called level2 child cmd
called level1 node b
VTY: implicit node exit by de-indenting, not parent lookup Note: This will break users' config files if they do not use consistent indenting. (see below for a definition of "consistent".) When reading VTY commands from a file, use indenting as means to implicitly exit child nodes. Do not look for commands in the parent node implicitly. The VTY so far implies 'exit' commands if a VTY line cannot be parsed on the current node, but succeeds on the parent node. That is the mechanism by which our VTY config files do not need 'exit' at the end of each child node. We've hit problems with this in the following scenarios, which will show improved user experience after this patch: *) When both a parent and its child node have commands with identical names: cs7 instace 0 point-code 1.2.3 sccp-address osmo-msc point-code 0.0.1 If I put the parent's command below the child, it is still interpreted in the context of the child node: cs7 instace 0 sccp-address osmo-msc point-code 0.0.1 point-code 1.2.3 Though the indenting lets me assume I am setting the cs7 instance's global PC to 1.2.3, I'm actually overwriting osmo-msc's PC with 1.2.3 and discarding the 0.0.1. *) When a software change moves a VTY command from a child to a parent. Say 'timezone' moved from 'bts' to 'network' level: network timezone 1 2 Say a user still has an old config file with 'timezone' on the child level: network bts 0 timezone 1 2 trx 0 The user would expect an error message that 'timezone' is invalid on the 'bts' level. Instead, the VTY finds the parent node's 'timezone', steps out of 'bts' to the 'network' level, and instead says that the 'trx' command does not exist. Format: Consistent means that two adjacent indenting lines have the exact same indenting characters for the common length: Weird mix if you ask me, but correct and consistent: ROOT <space>PARENT <space><tab><space>CHILD <space><tab><space><tab><tab>GRANDCHILD <space><tab><space><tab><tab>GRANDCHILD2 <space>SIBLING Inconsistent: ROOT <space>PARENT <tab><space>CHILD <space><space><tab>GRANDCHILD <space><tab><tab>GRANDCHILD2 <tab>SIBLING Also, when going back to a parent level, the exact same indenting must be used as before in that node: Incorrect: ROOT <tab>PARENT <tab><tab><tab>CHILD <tab><tab>SIBLING As not really intended side effect, it is also permitted to indent the entire file starting from the root level. We could guard against it but there's no harm: Correct and consistent: <tab>ROOT <tab><tab>PARENT <tab><tab><tab><tab>CHILD <tab><tab>SIBLING Implementation: Track parent nodes state: whenever a command enters a child node, push a parent node onto an llist to remember the exact indentation characters used for that level. As soon as the first line on a child node is parsed, remember this new indentation (which must have a longer strlen() than its parent level) to apply to all remaining child siblings and grandchildren. If the amount of spaces that indent a following VTY command are less than this expected indentation, call vty_go_parent() until it matches up. At any level, if the common length of indentation characters mismatch, abort parsing in error. Transitions to child node are spread across VTY implementations and are hard to change. But transitions to the parent node are all handled by vty_go_parent(). By popping a parent from the list of parents in vty_go_parent(), we can also detect that a command has changed the node without changing the parent, hence it must have stepped into a child node, and we can push a parent frame. The behavior on the interactive telnet VTY remains unchanged. Change-Id: I24cbb3f6de111f2d31110c3c484c066f1153aac9
2017-09-07 01:08:06 +00:00
got rc=0
fix vty regression: empty parent node The recent exit-by-indent patch breaks a VTY case where a node is entered but directly followed by a sibling or ancestor without listing any child nodes. Regression introduced by I24cbb3f6de111f2d31110c3c484c066f1153aac9. An example is a common usage in osmo-bts, where 'phy N' / 'instance N' is a parent node that is commonly left empty: phy 0 instance 0 bts 0 band 1800 Before this patch, this case produces the error: There is no such command. Error occurred during reading the below line: bts 0 Fix indentation parsing logic in command.c to accomodate this case. Add a unit test for empty parent node. Change-Id: Ia0880a17ae55accb092ae8585cc3a1bec9986891
2017-09-19 21:54:01 +00:00
reading file ok_empty_parent.cfg, expecting rc=0
vty_test: add artificial node levels for better testing In vty_test, add three levels of parent nodes (level1, level2, level3) with each having a leaf child (child1, child2, child3). Use these to enhance the vty_test cfg files and test more diverse situations. The current VTY code expects a go_parent_cb() to be present, otherwise it will bump right back to the CONFIG_NODE, which will not work with more than one node level below the CONFIG_NODE. Hence provide a minimal go_parent_cb(). Change-Id: Ib9bcf58b655fbd85e196f363fb7d8305d7dfc997
2017-09-19 23:49:11 +00:00
called level1 node a
called level2 node a
called level3 node a
called level1 node b
called level2 node b
called level1 node c
called level1 node d
called level2 node e
called level2 node f
called level3 node f
called level3 node g
called level2 node g
called level2 node h
called level1 node h
called level1 node i
called level1 node j
called level2 node j
called level1 child cmd j
called level1 node k
called level2 node k
called level3 node k
called level1 child cmd k
fix vty regression: empty parent node The recent exit-by-indent patch breaks a VTY case where a node is entered but directly followed by a sibling or ancestor without listing any child nodes. Regression introduced by I24cbb3f6de111f2d31110c3c484c066f1153aac9. An example is a common usage in osmo-bts, where 'phy N' / 'instance N' is a parent node that is commonly left empty: phy 0 instance 0 bts 0 band 1800 Before this patch, this case produces the error: There is no such command. Error occurred during reading the below line: bts 0 Fix indentation parsing logic in command.c to accomodate this case. Add a unit test for empty parent node. Change-Id: Ia0880a17ae55accb092ae8585cc3a1bec9986891
2017-09-19 21:54:01 +00:00
got rc=0
vty: Return error if cmd returns CMD_WARNING while reading cfg file Otherwise bad configurations can easily sneak in and produce unexpected behavior. Change-Id: Ic9c1b566ec4a459f03e6319cf369691903cf9d00
2019-10-22 16:38:01 +00:00
reading file fail_cmd_ret_warning.cfg, expecting rc=-22
Called: 'return-success'
Called: 'return-warning'
got rc=-22
logging/vty: fix: actually ignore deprecated logging commands We shall not prevent programs from starting if their configuration files contain deprecated 'logging level ...' commands. Just print a warning and return CMD_SUCCESS instead of CMD_WARNING. While writing a unit test, another funny bug has been uncovered. Parsing of a deprecated command indeed triggers a deprecation warning, originated from libosmovty's log_deprecated_func(). This function simply calls vty_out(), but... Since the invocation of the vty_out() happens _before_ the VTY is initialized, the process is actually writing that warning to its own stdin! Most likely, because we use talloc_zero() to allocate a new instance of struct 'vty'. As a side effect, the evil warning magically appears in the output of 'make check', breaking the test statistics. Let's work around this bug for now by redirecting stdin to /dev/null. Change-Id: Ia934581410cd41594791d4e14ee74c16abe1009a Fixes: Ic9c1b566ec4a459f03e6319cf369691903cf9d00
2019-11-20 17:19:36 +00:00
reading file ok_deprecated_logging.cfg, expecting rc=0
got rc=0
vty: fix use-after-free and memleaks in is_cmd_ambiguous() vty_test: add test against ambiguous cmd causing use-after-free and memory leaks. Add this test along with the fix, because the new test triggers the memory use-after-free and leaks, causing build failures. Add cmd_deopt_with_ctx() to allow passing a specific talloc ctx. is_cmd_ambiguous(): keep all cmd_deopt() allocations until the function exits. Add a comment explaining why. Before this, if a command matched an optional "[arg]" with square brackets, we would keep it in local var 'matched', but we would free the string it points to at the end of that loop iteration; upon encountering another match, we would attempt to strcmp against the freed 'matched'. Instead of adding hard-to-read and -verify free/alloc dances to keep the 'matched' accurately freed/non-freed/..., just keep all cmd_deopt() string allocated until done. Needless to say that this should have been implemented on a lower level upon inventing optional args, but at least this is fixing a program crash. Related: OS#33903390 Change-Id: Ia71ba742108b5ff020997bfb612ad5eb30d04fcd
2018-07-09 21:22:21 +00:00
Going to test is_cmd_ambiguous()
Going to execute 'ambiguous_nr'
Called: 'ambiguous_nr [<0-23>]' (argc=0)
Returned: 0, Current node: 1 '%s> '
Going to execute 'ambiguous_nr 23'
Called: 'ambiguous_nr [<0-23>]' (argc=1)
Returned: 0, Current node: 1 '%s> '
Going to execute 'ambiguous_nr 23 keyword'
Called: 'ambiguous_nr <0-23> keyword'
Returned: 0, Current node: 1 '%s> '
Going to execute 'ambiguous_str'
Called: 'ambiguous_str [ARG]' (argc=0)
Returned: 0, Current node: 1 '%s> '
Going to execute 'ambiguous_str arg'
Called: 'ambiguous_str [ARG]' (argc=1)
Returned: 0, Current node: 1 '%s> '
Going to execute 'ambiguous_str arg keyword'
Called: 'ambiguous_str ARG keyword'
Returned: 0, Current node: 1 '%s> '
tests: vty: Extend test to do some numeric range validations As per current status, the numeric tests are expected to fail due to a couple bugs which will be fixed in next commits. Change-Id: Id5b17bd96d7af4ed9a77ebbea0e6be4b0fcbde6c
2020-07-30 12:55:49 +00:00
Going to test test_numeric_range()
Going to execute 'numeric-range 0'
vty: Allow 64 bit values in numeric ranges if system supports it This fixes commands not being matched due to providing a range with more than 10 digits. The last case (passing -4000 matching 0-ULONG_MAX) shows a different bug which will be fixed in next commit. Change-Id: I0afa0caabffe36083c36b92ba90696ded00bb7be
2020-07-30 12:56:38 +00:00
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
tests: vty: Extend test to do some numeric range validations As per current status, the numeric tests are expected to fail due to a couple bugs which will be fixed in next commits. Change-Id: Id5b17bd96d7af4ed9a77ebbea0e6be4b0fcbde6c
2020-07-30 12:55:49 +00:00
Going to execute 'numeric-range 40000'
vty: Allow 64 bit values in numeric ranges if system supports it This fixes commands not being matched due to providing a range with more than 10 digits. The last case (passing -4000 matching 0-ULONG_MAX) shows a different bug which will be fixed in next commit. Change-Id: I0afa0caabffe36083c36b92ba90696ded00bb7be
2020-07-30 12:56:38 +00:00
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
tests: vty: Extend test to do some numeric range validations As per current status, the numeric tests are expected to fail due to a couple bugs which will be fixed in next commits. Change-Id: Id5b17bd96d7af4ed9a77ebbea0e6be4b0fcbde6c
2020-07-30 12:55:49 +00:00
Going to execute 'numeric-range -400000'
vty: Don't match negative values on purely positive ranges Without this patch, for instance having a range 0-ULONG_MAX would match if someones types value -3, which would be converted to unsigned but that's clearly what is expected here from user point of view. Change-Id: Ia95f6314a2dd3f94d21fc219cf69bb8d39b8e7f0
2020-07-28 15:44:48 +00:00
Returned: 2, Current node: 1 '%s> '
vty: Allow using hex representations in cmd numeric ranges Ranges can now be specified in hexadecimal notation. In this case, only hexadecimal values are accepted (prefixed with "0x"). In order to allow using a hexadecimal value as an input argument, the command must specify the range in hexadecimal form. This way all existing commands (decimal) won't get an hexadecimal value unless they are further extended in the future, avoiding hard to notice breakage due to use of stroul() without using base=0 or even worse, using atoi() directly (which only understands decimal and provides no error checking mechanism). A command argument can be expanded to accept both decimal and hex in a range by means of specifying both, example: "mycmd (<0-255>|<0x0-0xff>)". Related: OS#5631 Change-Id: Ia2b7fbbf5502c28374c21dbff548232680da27d4
2020-07-28 13:37:02 +00:00
Going to test test_ranges()
test range-base10
Going to execute 'range-base10 0'
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
Going to execute 'range-base10 40000'
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
Going to execute 'range-base10 -400000'
Returned: 2, Current node: 1 '%s> '
Going to execute 'range-base10 0x0'
Returned: 2, Current node: 1 '%s> '
Going to execute 'range-base10 0x343'
Returned: 2, Current node: 1 '%s> '
Going to execute 'range-base10 -0x343'
Returned: 2, Current node: 1 '%s> '
test range-base16
Going to execute 'range-base16 0'
Returned: 2, Current node: 1 '%s> '
Going to execute 'range-base16 40000'
Returned: 2, Current node: 1 '%s> '
Going to execute 'range-base16 -400000'
Returned: 2, Current node: 1 '%s> '
Going to execute 'range-base16 0x0'
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
Going to execute 'range-base16 0x343'
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
Going to execute 'range-base16 -0x343'
Returned: 2, Current node: 1 '%s> '
test range-baseboth
Going to execute 'range-baseboth 0'
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
Going to execute 'range-baseboth 40000'
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
Going to execute 'range-baseboth -400000'
Returned: 2, Current node: 1 '%s> '
Going to execute 'range-baseboth 0x0'
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
Going to execute 'range-baseboth 0x343'
Called: 'return-success'
Returned: 0, Current node: 1 '%s> '
Going to execute 'range-baseboth -0x343'
Returned: 2, Current node: 1 '%s> '
vty: Fix misusage of snprintf in vty/utils.c Compiled with ubuntu 1204 (precise), where -Wformat-security is enabled by -Wall. Test yields ok, but the current implementation doesn't properly support multi-character separators and end strings. So the test output is truncated. Addresses: utils.c: In function 'vty_cmd_string_from_valstr': utils.c:84:2: warning: format not a string literal and no format arguments [-Wformat-security] utils.c:84:2: warning: format not a string literal and no format arguments [-Wformat-security] utils.c:108:2: warning: format not a string literal and no format arguments [-Wformat-security] utils.c:108:2: warning: format not a string literal and no format arguments [-Wformat-security]
2013-08-06 12:29:14 +00:00
All tests passed