Project

General

Profile

Actions

Feature #5631

open

vty: Allow using hex and octal representations in cmd numeric ranges

Added by pespin 20 days ago. Updated 19 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
libosmovty
Target version:
-
Start date:
07/25/2022
Due date:
% Done:

0%

Spec Reference:

Description

Some time ago, I submitted a patch to allow submitting number ranges not only as decimal, but also as hexadecimal or octal:
https://gerrit.osmocom.org/c/libosmocore/+/19422
However, it was never merged.

Today a similar topic was raised again due to SMSCB Message IDs being printed in the vty "show messages" command as hexadecimal (and without 0x prefix) while the "show message ID" only accepted decimal numbers, which makes the user experience really confusing (I even spent some time debugging why "show message ID" was saying no message existing and I was seeing it in the list).

It was also raised that cisco console seems to also support hex numbers, see for instance "lac" in https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-1/CLI/books/R-Z/21-1_R-Z_CLI_Reference/21-1_R-Z_CLI_Reference_chapter_0100001.html
Supporting ranges in hexadecimal would also us to set stuff like lac as hexadecimal, and even store the config that way, because the vty would be able to read it back.

Similary, supporting octal would allow us to easily specify file permissions bitmaks in the VTY.

I see 2 main options to support those:
1- Specify range parameters as decimal ranges (ex: <0-200>) but allowing passing any format of integer (dec, hex, oct) by specifying the format prefix. That's what the libosmocore patch above adds support for.
For instance:
  • cmd definition: "lac <0-6534324>"
  • cmd write: "lac 0x30"

2- Specify accepted range formats explicitly. This means each param needs to be more detailed but also allows accepting specific formats on specific parameters. For instance, one would allow only decimal and hex in lac cmd: "lac (<0-6534324>|<0x0-0x4352>), or only accept hex: "lac <0x0-0x4352>"

I'm happy with any of the two above. Let's see what others want to say about it.

Actions #1

Updated by pespin 20 days ago

  • Description updated (diff)
Actions #2

Updated by laforge 20 days ago

pespin wrote:

Similary, supporting octal would allow us to easily specify file permissions bitmaks in the VTY.

do we actually do that anywhere? I would guess most people who're not unix sysadmins or C programmers wouldn't know that 01234 is != 1234 and hence I would really avoid that notation. And 0/O is just so close in terms of "hamming distance of the character".... so I fear more danger than benefit.

I see 2 main options to support those:
1- Specify range parameters as decimal ranges (ex: <0-200>) but allowing passing any format of integer (dec, hex, oct) by specifying the format prefix. That's what the libosmocore patch above adds support for.
For instance:
  • cmd definition: "lac <0-6534324>"
  • cmd write: "lac 0x30"

For the input, I think that is the best

2- Specify accepted range formats explicitly. This means each param needs to be more detailed but also allows accepting specific formats on specific parameters. For instance, one would allow only decimal and hex in lac cmd: "lac (<0-6534324>|<0x0-0x4352>), or only accept hex: "lac <0x0-0x4352>"

it could also be both:
  • if a decimal range is specified, allow decimal or hex input (I'd avoid octal)
  • if a hexadecimal range is specified in the command, allow only hexadecimal input
Actions #3

Updated by pespin 20 days ago

laforge wrote in #note-2:

pespin wrote:

Similary, supporting octal would allow us to easily specify file permissions bitmaks in the VTY.

do we actually do that anywhere? I would guess most people who're not unix sysadmins or C programmers wouldn't know that 01234 is != 1234 and hence I would really avoid that notation. And 0/O is just so close in terms of "hamming distance of the character".... so I fear more danger than benefit.

https://gitea.osmocom.org/osmocom/osmo-pcap/src/branch/master/src/osmo_server_vty.c#L138
https://gitea.osmocom.org/osmocom/osmo-pcap/src/branch/master/src/osmo_server_vty.c#L91

it could also be both:
  • if a decimal range is specified, allow decimal or hex input
  • if a hexadecimal range is specified in the command, allow only hexadecimal input

That's a bit confusing at first but I see your point. I'm fine with either this solution (let's call it "3") or any of the 2 I presented before.

(I'd avoid octal)

Bear in mind allowing octal makes it actually easier implementation, because (see presented libosmocore patch before) one can simply pass 0 to the base to stroul and let it parse properly whatever base it is thrown at it.

Actions #4

Updated by laforge 19 days ago

On Mon, Jul 25, 2022 at 05:22:31PM +0000, pespin wrote:

Bear in mind allowing octal makes it actually easier implementation, because (see presented libosmocore patch before) one can simply pass 0 to the base to stroul and let it parse properly whatever base it is thrown at it.

I'd rather invest a few more dozens of minutes of R&D time rather than sending our users
into a trap.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)