SSH Access - Login delay

[JohnG0GCD]

BiPAC 8800AXL R2, Firmware 2.52.d15

I am trying to capture the ADSL line performance stats regularly, to pin down the reason why the ISP seems to be varying my speeds a lot.
I have used a simple routine using AutoIT, on Windows 10, to TelNet into the 8800 every 5 minutes and capture WAN SHOW and ADSL INFO --STATS results as strings and parse the required data I need. All good (and helped me find an LED lamp which increased the noise on my line by 6dB when on!).

I am concerned about the network carrying main router login credentials in clear text every 5 minutes over WiFi, so switched the routine to use SSH. I have utilised a function block written to support SSH access but I don't fully understand how it works, unfortunately.

The 8800 always rapidly responds to the SSHConnect() request to open a socket. It suffers, however, from the variable delay that the 8800 has between entering the valid password and the return of the command prompt, which is " > ". This delay is usually 3 to 4 seconds but can be up to several minutes. This delay is also visible when using PuTTY to test the commands manually. As far as I can tell, the router does always come back eventually but it misses reporting points if over the 5 minute cycle time.

Once logged in, the commands 'wan show', 'adsl info --stats' and 'syslog dump' respond immediately, as does 'logout'. Searching the AutoIT forums suggests that I may have a problem with reverse DNS timeouts (?) and that the solution is to turn 'DNS off' in the SSH server. Am I on the right track?

I also discovered (RTFM?) that there is a setting within the 8800 for setting Remote Access on. During my experiments, HTML was the only option enabled (SSH still worked, however) but enabling SSH made no difference. I should add that I am only considering doing this over my network, not over the web.

Is there any other way to securely access the router to extract these stats?

Thanks
John

Extract of code ==>
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

; PART ONE - Interrogate Modem/Router

;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

_Log("Reset Log/Report files")
FileDelete($LogFilename)
;FileDelete($OutFilename) ; Need to set a report file management regime

$WAN = "Not Defined"
$ADSL = "Not Defined"
$LoggedIn = "No"

; Start the service and register OnAutoItExit to be called when the script is closed, to ensure that the session is closed correctly.
_Log("Opening Communications")
_SSHStartup()
OnAutoItExitRegister("OnAutoItExit")

;Connect to modem/router telnet port
_Log("Connecting")
Local $hTimer = TimerInit()
Local $RouterIP = _SSHConnect($DeviceIP, "22", $DeviceUserName, $DevicePassword)

;Check that modem/router is responding
If $RouterIP = 0 Then
$Connected = "No"
_Log("Failed to connect")
Else
$Connected = "Yes"
_Log("Connected: (" & $RouterIP & ")")

; Wait for prompt
$i = 0
Do
Sleep(3000)
$TCPRecv = _SSHRecv($RouterIP, "5000")
_Log($TCPRecv)
$i = $i + 1
Until $TCPRecv = " > " or $i = 10

If $TCPRecv = " > " Then
$LoggedIn = "Yes"
_Log("Logged in")

; Send WAN SHOW command
Sleep(1000)
_SSHSend($RouterIP, "wan show" & @CRLF)
Sleep(100)
$TCPRecv = _SSHRecv($RouterIP, "5000")

Extract ends ==>

[JohnG0GCD]

And, as luck would have it, it's been responding within 30 seconds for the last 18 hours!
Technology, eh?

[JohnG0GCD]

And back, as bad as ever.

I considered another approach - telnet (which I know works well) but to a non-admin account on the 8800.
But the modem rejects my advances on anything other than the admin account. I was hoping that to use TelNet to the support or user account would allow access to the reporting but prevent anyone who had intercepted the login details from interfering with the config.

Is TelNet only available to the admin account?

- My current thinking is to use a raspberry Pi on a wired connection to the 8800 to fetch the reports and then save the reports to a shared network resource. I'm hoping that the communication between Pi/8800, particularly the credentials, will be contained within the wired link and not copied all over the WiFi network/s. I have no problem with anyone intercepting the reports themselves. It's just that I am reluctant to let my network admin account credentials out.

So
TelNet reveals the admin credentials and that's unacceptable because the client device is linked by WiFi
TelNet only appears to work with the Admin account
FTP/HTTP is insecure for the same reason and there doesn't appear to be any implementation of SFTP, FTPS or HTTPS
SSH doesn't respond to login reliably
I am not sure if anything on a wired link within a subnet is also broadcast over WiFi links in the same subnet

This is getting too complicated.... I must have missed something obvious.

Any ideas/thoughts/guidance, please?

[JohnG0GCD]

OK. I think I'm there. Here's a summary of my findings:

TelNet reveals the admin credentials and that's unacceptable because the client device is linked by WiFi
TelNet only appears to work with the Admin account
FTP/HTTP is insecure for the same reason and there doesn't appear to be any implementation of SFTP, FTPS or HTTPS
SSH doesn't respond to login reliably
A Raspberry Pi on a wired link to the 8800 is not visible on the WiFi

I tried to use the Pi to TelNet into the 8800 but it kept switching to SSH (logical, I guess) giving me the same delay problems, so I abandoned that approach.

Back to the SSH connection. I found that the cipher '3des-cbc' requested by the 8800 was not configured in my PuTTY client. After configuring this, and coding a timeout plus retry loop, I now have a client which attempts connection and waits 10 seconds for a prompt. If this times out, it disconnects and tries again up to 5 times. I now have 24 hours of continuous connections, every 5 minutes, with response times of under 6 seconds and under 4 tries. I'm still convinced that this is a brute force solution to an unidentified configuration error, but it seems to work.

In my back pocket (it came to me overnight) is a solution whereby I read the home page and /statsadsl.html using straightforward HTTP to extract the info I seek but logging on with the 'user' credentials to protect my admin account. Much easier than the pain that SSH has been !

Take care, stay safe
John

[JohnG0GCD]

I knew that I shouldn't have said anything. Stopped working completely just after I posted.
Have given up on this project now. Have solved my line speed problem - will just go back to occasionally checking the dashboard by hand...
Have fun
John