Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates to Huawei Login issue fix #2728

Merged
merged 6 commits into from Apr 14, 2022
Merged

Updates to Huawei Login issue fix #2728

merged 6 commits into from Apr 14, 2022

Conversation

ktbyers
Copy link
Owner

@ktbyers ktbyers commented Apr 12, 2022

No description provided.

@ktbyers
Copy link
Owner Author

ktbyers commented Apr 12, 2022

@fharbe First thanks for the fix.

I read through your comments on the PR and I believe the original issue must have been this code here

        password_change_prompt = r"((Change now|Please choose))|([\]>]\s*$)"
        output = self.read_until_pattern(password_change_prompt)
        if re.search(password_change_prompt, output):
            self.write_channel("N\n")
            self.clear_buffer()

coupled with the _test_channel_read() call.

In other words, since that password_change_prompt pattern was incorrectly defined and would cause the initial prompt to be read (so the above would ONLY work if the special password change prompting was present).

I made a few updates to your PR.

  1. I moved the code back to special_login_handler() as that is the standard location in Netmiko for that type of code and I didn't see any reason it would work there.
  2. I moved this special_login_handler() method to be in HuaweiBase as that code should apply to both SSH and telnet (as far as I could see).
  3. I got rid of your try / except ReadTimeout and of the 3 second read_timeout. Basically, one of those conditions should always apply (either "Change now|Please choose" or the standard prompt) and Netmiko should keep reading until one of those happens.

From a Netmiko perspective it is bad for the program to continue onward if the prompt is not successfully read. So if this doesn't happen it should raise an exception.

Basically, Netmiko would fail later in a hard to diagnose way if the prompt isn't read (i.e. we are fully logged in and the device should be responsive).

Do you see any issues with the updated PR?

Can you test that it still works properly?

Regards, Kirk

@ktbyers ktbyers merged commit b3119c5 into develop Apr 14, 2022
@ktbyers ktbyers deleted the fharbe-fix_huawei_login branch February 28, 2024 18:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants