Netshot
Netshot copied to clipboard
netfishers-onl
Driver is sending \n before correct actual command needs to be sent
Hi,
I'm trying to create a own driver for equipment currently having a driver. The problem i'm facing (and i tried almost every option) is that the driver seems to be sending \n before the actual command (in this case the password)
from wireshare perspective: telnet data \n data password\r
Anyone know a solution for this? this issue causes i never can login succesfully, since the \n is seen as a password, and the login fails then.
Config in driver : password: { prompt: /^RADIUS Password:$/, macros: { auto: { cmd: "$$NetshotPassword$$", options: [ "usernameAgain", "user" ] } } },
When running against a device using telnet, the driver's snapshot function is called with CLI mode set to telnet. How does your CLI.telnet look like and what's the beginning of your snapshot function?
Hello,
var CLI = {
telnet: {
macros: {
user: {
options: [ "username", "password", "user" ],
target: "user"
},
}
},
username: {
prompt: /^Login:$/,
macros: {
auto: {
cmd: "$$NetshotUsername$$",
options: [ "password" ]
}
}
},
password: {
prompt: /^Password:$/,
macros: {
auto: {
cmd: "$$NetshotPassword$$",
options: [ "user" ]
}
}
},
user: {
prompt: /^([A-Za-z\-_0-9\.\/]+# )$/,
pager: {
avoid: "term length 0",
match: /to single step/,
response: ""
},
},
};
function snapshot(cli, device, config) {
cli.macro("user");
var currentConfig = cli.command("show run verbose");
};
Everthing in the login sequence goes ok, but before the password is being sent, a \n is beeing sent, which causes the login fails (the devices recognizes it as a empty password)
I'm not seeing the reason for that. I'll have a detailed look if you can provide me with a full snapshot trace (see https://github.com/netfishers-onl/Netshot/wiki/Snapshot-troubleshooting but remove sensitive information from the trace).
Hello,
Attached the tracelog. We can also supply a wireshark trace if needed.
Netshot sends the username right after having received the banner, so it must be detecting the username prompt regexp (^Login:$) in the banner. By the way, are you sure the last version of the driver file is properly loaded (compare the version displayed in the Admin tab and the version in your JS file)? And that the snapshot is indeed using your driver?
Hello,
Yes, i've updated the driver, and checked the version in NetShot, even restarted NetShot to make sure there was no cashing.
The problem with sending a \n before the first username attempt is no problem, since the devices just gives a new Login prompt then, but after the correct username is sent by NetShot, the devices expects a password to be sent (password prompt), but NetShot sends a \n first before sending the password (causing the device to think (after the \n) a empty password is given, and starts login procedure again). So it seems somewhere in de code \n is sent before the usernames/passwords are being sent, but i did not find where yet..
If needed i can provide a wireshark trace where the behavior is also clearly visible.
Thanks
Hi, actually it is almost, i only removed the banner part, the login part is completed correctly, but the behavior is visible in the trace in packet number 18 (the \n is sent before the password)
I've attached a complete wireshark trace now. I cannot find a cause why a \n before the actual password is beeing sent by NetShot, the macro is executing, since the password is beeing sent, but only after the \n first beeing sent. netshot2.zip
Have you changed anything to the prompts you pasted in this comment https://github.com/netfishers-onl/Netshot/issues/61#issuecomment-583990358? In the trace the prompt for login is RADIUS Login: while your regexp is /^Login:$/, thus I'm not seeing how there can be a match at all. And the debug trace indicated that the username was posted right after the banner, just as if Netshot was matching the login regexp in the banner already.
I'm seeing the \n in the password and have no explanation for that... except the password itself contains the new line. You can try to replace temporary $$NetshotPassword$$ by the testing password in the driver to see whether it makes a difference.
Yes, if i disable RADIUS on the device the RADIUS part is dropped from the login prompt, sorry about that, i just tested the device with RADIUS enabled, but it made no difference in the behavior of NetShot (ofcourse i changed the regexp in the driver to have the login prompt match)
Today i copied the driver to another type of device and tried logging in there, this was working fine using the same settings in driver (i also see the \n there in trace)
Thanks for you time until now, much appreciated
Since i cannot get it to work with telnet because of this bug, we switched to using SSH, where we have no problems. But still the behavior needs checking / fixing i guess.
OK, I spent a bit of time looking deeper into this issue, and it seems that this additional line feed comes from the underlying Apache Commons Telnet library. Unfortunately they didn't expose the property to change this behavior. https://github.com/apache/commons-net/blob/ab90a71cf2b43792799866c9ed78823bf34b6298/src/main/java/org/apache/commons/net/telnet/TelnetOutputStream.java#L69
I just ran into the same issue. The driver is sending a newline before the password, and this causes my Huawei devices to reject the login credentials.
It's odd that this doesn't cause issues for more devices.
Yes,
But we switched to SSH for the remaining devices and that works fine. Some devices reject the \n as input and give the prompt again, that might be the reason some devices are working.
I've managed to workaround this issue by sending newlines myself instead of the carriage returns that netshot adds automatically.
username: {
prompt: /^Username:$/,
macros: {
auto: {
cmd: "$$NetshotUsername$$\n",
noCr: true,
options: ["password"]
}
}
},
The telnet library only reacts to a CR, not on a LF.
I also had to modify my cli.commands like this:
var cli_command = function (command) {
return cli.command(command + "\n", {noCr: true})
}
A better fix would be to not use that java library, or by allowing to specify the newline character that netshot is using. This is currently hardcoded to CR, but it might be a nice idea to allow this to change to LF.