Fix for SROS SAR 7705 Hmc

[Schouwenburg]

Pre-Request Checklist

• Passes rubocop code analysis (try rubocop --auto-correct)
• Tests added or adapted (try rake test)
• Changes are reflected in the documentation
• User-visible changes appended to CHANGELOG.md
• I have no dev environment where I can run the rubocon and rake test, although I tested the fix

Description

The Nokia SROS model did not work on the SAR 7705 HMC due to an unexpected prompt at the end of two commands. With this small patch, a new correct command line is enforced, which makes Oxidized finish correctly on all SROS models.

[Schouwenburg]

Not sure why the CI tests fail on unchanged files. Is this a CI bug?

[raunz]

The "\n" in the end of admin display-config lines causes empty configurations to be commited on SAS M devices.
Removing the newlines makes it fine again.

78c78
<   cmd "admin display-config index\n" do |cfg|
---
>   cmd "admin display-config index" do |cfg|
85c85
<   cmd "admin display-config\n" do |cfg|
---
>   cmd "admin display-config" do |cfg|

[Schouwenburg]

The "\n" in the end of admin display-config lines causes empty configurations to be commited on SAS M devices. Removing the newlines makes it fine again.

Hi Raunz, I also encountered this on some devices. It is a pity as it was an elegant solution to get the HMC working. So I think I have to add the 7705HMC as a separate device (i.e. sroshmc) and revert the change for sros. I will test and try a bit more.

[ytti]

There are also other options

1. detect or user variable to communicate which it is
   and
2. cmd = cmd + type ? "\n" : ""

or scrub the excess empty line from output.

But we'd really need to understand what the actual problem is. What does the CLI session look like for 1 affected command on working and non-working platform?

[Schouwenburg]

The reason this patch was made in the first place, is that for the SAR-Hmc the output of the commands "admin display-config index" and "admin display-config" does not end with a new line. Because of that, the prompt does not match anymore, as it is behind the last row of the output.

<omitted output>
    system
        time
            ntp
                server x.x.x.x prefer
                server y.y.y.y
            exit
        exit
    exit

exit all

# Finished SAT AUG 03 14:10:00 2024 UTC
#A:ROUTERNAME#

While on all the other sros devices you should see:

<omitted output>
    system
        time
            ntp
                server x.x.x.x prefer
                server y.y.y.y
            exit
        exit
    exit

exit all

# Finished SAT AUG 03 14:10:00 2024 UTC
#
A:ROUTERNAME#

The idea was to just add an extra \n in the command, so you would get an extra newline pressed and a new prompt on a separate line.

<omitted output>
    system
        time
            ntp
                server x.x.x.x prefer
                server y.y.y.y
            exit
        exit
    exit

exit all

# Finished SAT AUG 03 14:10:00 2024 UTC
#A:ROUTERNAME#
A:ROUTERNAME#

This seemed to work for both the Hmc and the other sros devices. But it also seems to lead to issues for @raunz with the SAS-M, and I encounter myself an issue with IXR-e devices. What I see happening is:

<omitted output>
# BGP Configuration
# Log all events for service vprn Configuration
# System Time NTP Configuration
#                       Executed 893 lines in 0.6 seconds from file cf3:\config.cfg
#
#
# ===============================================================================
# # COMMAND: show debug
# debug
# exit
# # COMMAND: file type config.dbg
# MINOR: CLI Could not access "cf3:\config.dbg".^G
# # COMMAND: admin display-config index\n
#                                     ^
# Error: Invalid parameter. detail|index
# COMMAND: admin display-config\n
                     ^
Error: Invalid parameter. 

I find it strange that these devices interpret the \n as backslash+n instead of a real newline.

Is this also what you see on the SAS-M @raunz ? I ask this because if we see the same issue, I know which issues to resolve.

And @ytti, is there a way to send a real new line with the cmd command?

[ytti]

I'm pretty sure this is not desired behaviour and Nokia will eventually change this , so any work to deal with this has to assume it'll also go away.

Is there some command you can before that command, which terminates correctly and communicates which type of device it is?
If so, then we can do something like this, not valid code, just for example:

cmd "something_to_detectg_device" do |cfg|
  @cmd_prefix = cfg..match /foo/ ? "\n" : "" 
  ""
end

post do
  # rest of stuff
 cmd "whatever" + @cmd_prefix do |cg|
     ...
 end
end

However, considering this is going to be fixed, once someone opens case to Nokia, should we even bother about this, or should people run local copies of the model, until fixed by Nokia.

[Schouwenburg]

I think you are right, this might ever change, but it could well be years or never for this to be fixed. Worst case, this issue could pop up on other new sros versions.
I did find another way that should work on all sros devices:

• admin display-config index | match ".*\n" expression
• admin display-config | match ".*\n" expression

This would filter out all rows without a new line on the end. Effectively, this filters out only the last troubled row on the HMC router (containing only a #), and for other device types, it does not remove anything.

[ytti]

It will change, just open ticket to Nokia. We had few similar issues when going to MD-CLI, all were addressed in timely manner.
And of course there might be this and other issues in future, but should we really support CLI behaviour that vendor accepts broken in main-branch?

And if we should, should we change the prompt to allow ^#? at the beginning?

Also have you verified that SROS does not support exec mode in ssh? In which case we don't rely on prompt detection at all.

[Schouwenburg]

Allowing a #A:ROUTERNAME# was the first thing I tired, but I ran into many unwanted side effects. I will reach out to Nokia and see if they think this is a bug. Would not surprise me if they don't see it as a bug, then its something to either work around or accept as not working.

[ytti]

If you have problems with Nokia let me know the ticket number, and I can use backchannels to ecalate.

Also, did you try to use ssh exec mode? Then you do not depends on prompt detection, and it should work fine for you.

[raunz]

I did some debugging with oxidized and "\n" are at the end of commands.
The software on nokia is honestly a little old.

# TiMOS-B-5.0.R8 both/hops ALCATEL-LUCENT SAR 7705
# Built on Tue Jan 29 15:54:38 EST 2013 by csabuild in /rel5.0/b1/R8/panos/main

What I notice, that the backup interval has to be at least 1hour to trigger. The debug output of oxidized process is basically identical on both sequential runs. The telnet output differs only by missing entire "admin display-config" block. Not a single error message or anything. Full backup telnet log is 876 lines, partial is only 345.
I've no idea, why the admin display-config output disappears every 2nd run.

[ytti]

I would encourage to test with ssh with exec mode turned on

cfg :ssh do
  exec true
end

This way we won't do any prompt detection, as we progrmamatically know when command has finished.

Note, not all SSH implementation support exec mode, or support it correctly. But if it works, it is much more dependable than screenscraping for prompt.