Failed login generating EOF / socket error #1563
Comments
|
Have you looked at it in the Python debugger? Looking at the code in Netmiko 3.0.0 (which for this code should be very similar to 2.4.2), I don't see anything that would cause us to send an EOF. Probably should be testing only Netmiko 3.0.0 as any issue/fix would be based on that. |
|
@ktbyers Yes, I've stepped through the code in pycharm for 1.4.3, 2.4.2 and 3.0.0. I don't see any significant change in netmiko, and suspect the EOF is coming from paramiko somewhere, but nevertheless it works when I roll back to 1.4.3... Perhaps there's some global timeout difference that I just haven't identified? |
|
Can you post the full stack trace for the Netmiko 3.0.0 error? |
I believe this is on the next login attempt read_channel(), after the EOF is sent / socket closed: |
|
@ktbyers I believe this is the stack trace close to when the EOF is being sent (I set a breakpoint on the paramiko _log() function) |
|
I found the difference: 1.4.3: netmiko/netmiko/base_connection.py Line 430 in 2871816 3.0.0 / develop: Netmiko is forcing a connection close on login failure. |
|
Our code was written with the (previously true) assumption that the transport/channel is managed separately from the login/authentication. Thus, we can try multiple credentials to get a successful login without reconnecting. Is it really the right thing to close the connection because of a failed login, is this expected behavior? |
|
Yes, I think it probably is the right thing to do for the In the typical case the Netmiko, however, has the So I guess we could add an argument into telnet_login() like connection_close=False and pass that in as argument (and then condition that Does that sound reasonable? |
|
@ktbyers yes, I was going to suggest a parameter like close_on_authfail=True and just override it... would you like me to PR that in? |
|
Sounds good.
Kirk
…On Mon, Feb 10, 2020 at 6:34 PM John Arnold ***@***.***> wrote:
@ktbyers <https://github.com/ktbyers> yes, I was going to suggest a
parameter like close_on_authfail=True and just override it... would you
like me to PR that in?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1563?email_source=notifications&email_token=AAG3VBH2HXYXLDSNUSPUVBLRCIFDHA5CNFSM4KR4HWMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELLBK6Q#issuecomment-584455546>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAG3VBHM2X4WVPGYGMZ6UYLRCIFDHANCNFSM4KR4HWMA>
.
--
*Kirk Byers*
*ktbyers@twb-tech.com <ktbyers@twb-tech.com>*
*Simplify through Automation*
|
|
I don't think this was ever done. I am going to close as there isn't any active work on the issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Netmiko version 2.4.2 and 3.0.0
I'm connecting to a cisco OOB/console router via ssh, to get serial console access to a juniper router. Using redispatch to flip drivers after connecting successfully. I don't think any of that matters... I'm erroring out inside base_connection.telnet_login()... The problem i'm seeing is when we cycle through credentials to get the correct local credential for the juniper router.
In netmiko 1.4.3 it works fine -- get a login prompt, send credentials, login fails, send again, , repeat until a NetMikoAuthenticationException is raised, catch it, try the next credential.
In netmiko 2.4.2, we send an EOF after the login failure:
The code for telnet_login is structured such that it should catch an EOFError:
... however, no EOFError is ever raised. Instead, its an OSError "socket is closed" when we try the next telnet_login with new credential / send on the channel.
Help wanted...
Why is an EOF being sent from the client?
Are we hitting a channel receive timeout? I have the same max_loops value for 1.4.3 as for 2.4.2.
Thanks,
John
The text was updated successfully, but these errors were encountered: