NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Admin page keeps refreshing...time off after 6.10.5 hotfix
I just applied the 6.10.4->6.10.5 hotfix. The files are accessible from Windows Explorer, but I cannot do any maintenance via the web page (I tried in various browsers) because the admin page keeps...
It seems like it's associated with a timeout parameter and/or the GUI's knowlege of time. Since the timeout doesn't seem to be in any of the HTML code (I looked some time back to see if it could be disabled completely), somebody at Netgear is going to either have to find it or give us knowlege of where to start looking to see how they differ on units with the problem vs. those without.
Sandshark wrote:
It seems like it's associated with a timeout parameter and/or the GUI's knowlege of time. Since the timeout doesn't seem to be in any of the HTML code ...
It sounds like it's not just the web ui, as ssh connections are also being rejected. The ReadyNAS application isn't involved in those connections at all.
ssh -vvv might give some more clues (though it is extremely verbose)
StephenB wrote:
It sounds like it's not just the web ui, as ssh connections are also being rejected. The ReadyNAS application isn't involved in those connections at all.ssh -vvv might give some more clues (though it is extremely verbose)
This is the pertinent output.
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.71 ([192.168.1.71]:22).
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug1: ENABLE_VIRTUAL_TERMINAL_INPUT is supported. Reading the VTSequence from console
debug3: This windows OS supports conpty
debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING is supported. Console supports the ansi parsing
debug3: Successfully set console output code page from:65001 to 65001
debug3: Successfully set console input code page from:437 to 65001
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 87380
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i0 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: chan_shutdown_read (i0 o3 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug3: Successfully set console output code page from 65001 to 65001
debug3: Successfully set console input code page from 65001 to 437
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1)debug3: send packet: type 1
debug3: Successfully set console output code page from 65001 to 65001
debug3: Successfully set console input code page from 65001 to 437
Connection to 192.168.1.71 closed.
Transferred: sent 1916, received 1700 bytes, in 0.1 seconds
Bytes per second: sent 14406.0, received 12781.9
debug1: Exit status 1FWIW, the same segment of my (successful) login to a 6.10.5 system looks like this:
debug2: we sent a password packet, wait for reply debug3: receive packet: type 52 debug1: Authentication succeeded (password). Authenticated to 10.0.0.13 ([10.0.0.13]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessions@openssh.com debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: network debug1: ENABLE_VIRTUAL_TERMINAL_INPUT is supported. Reading the VTSequence from console debug3: This windows OS supports conpty debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING is supported. Console supports the ansi parsing debug3: Successfully set console output code page from:65001 to 65001 debug3: Successfully set console input code page from:437 to 65001 debug3: receive packet: type 91 debug2: channel_input_open_confirmation: channel 0: callback start debug2: fd 3 setting TCP_NODELAY debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug3: send packet: type 98 debug2: channel 0: request shell confirm 1 debug3: send packet: type 98 debug2: channel_input_open_confirmation: channel 0: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 87380 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Welcome to ReadyNASOS 6.10.5
It diverges with yours at
...
debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 87380 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i0 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: chan_shutdown_read (i0 o3 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd closewhere I receive Welcome to ReadyNASOS 6.10.5, but you receive SSH_MSG_CHANNEL_EOF (packet type 96) followed by SSH_MSG_CHANNEL_REQUEST (packet type 98) and a SSH_MSG_CHANNEL_CLOSE (packet type 97).
Not clear to me what's going on, other than that the ReadyNAS is choosing to close the channel.
I was able to get into the UI and it has not kicked me out. However, the SSH connection still fails. I expect that the problem will return when I close my browser.
Same here, I have it on fixed IP and it just reboots after about 30 seconds, the windows share is not effected though? I have tried DHCP and still the same, and if I get in long enough to open one of the apps in a seperate tab, such as the qbit**** client program, that stays open and connected so seems to be just the admin page? App seems to stay connected on my phone though?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
