napalm-opengear incompatible with NAPALM 4.x / Netmiko 4.x

[mirceaulinic]

With NAPALM 4.0.0 recently released, there's a requirement for Netmiko to be on a newer version. 4.x has introduced some backwards incompatible changes that are causing the following error in napalm-opengear:

  File "/usr/local/lib/python3.9/site-packages/napalm_opengear/opengear.py", line 61, in open
    self.device.enable()
  File "/usr/local/lib/python3.9/site-packages/netmiko/linux/linux_ssh.py", line 147, in enable
    raise ValueError(msg)
ValueError:
Netmiko failed to elevate privileges.
Please ensure you pass the sudo password into ConnectHandler
using the 'secret' argument and that the user has sudo
permissions.

[mirceaulinic]

In fact, this seems a little deeper, caused by ktbyers/netmiko#2866. Keeping this issue open in the meantime.

[mirceaulinic]

Temporary workaround: #12.

[FragmentedPacket]

Are we able to add support for the force_no_enable option?

We have an account that has "sudo" privs on opengear already that does not prompt for a password as the code in #12 changed.

        if not self.device.base_prompt:
            # If Netmiko fails to detect the prompt due to OpenGear not setting
            # anything before the pound sign, we set the base_prompt attribute
            # so Netmiko is able to read (either # when the username is root, or
            # $ for anything else)
            self.base_prompt = "#" if self.username == "root" else "$"
        if self.username != "root" and not self.force_no_enable:
            self.device.enable()

[tyler-8]

Presumably this was fixed in netmiko with ktbyers/netmiko#2891

I was able to use several getters with the following setup:

napalm==5.0.0
napalm-opengear==0.3.6
netmiko==4.5.0

[tyler-8]

Adding... I don't know if it's strictly related to this issue or not but in some cases (maybe where the Opengear is responding very slowly) I'm getting raw output back as interface names. A couple examples:

• config.system.name cm7132-2-dac
• # ip link|awk '/^[0-9]: / {print $2}'|tr -d

I increased the hardcoded global_delay_factor from 2 to 3 and still receive the output on occasion. Going to keep tinkering to see if I can sus out what's going on.