TUNNEL Connection Does not "Re-acquire" after reboot #31
Comments
|
Is it possible to obtain support dumps from both sides of the fence and upload? |
|
Yes, I will endeavor to get that information for you. (Got tied up with some other issues here - still working on getting the data gathered - please keep this open and hopefully there will be other contributors as well 3/3/19 @16:54) |
|
Still experiencing this issue - observed with HAP AC Lite on both ends - client unit running production 3.19.3.0, the server was running an earlier nightly version 705. The tunnel server still had a Blue Cloud indicated on the non-functioning client connection and was answering Putty SSH calls from the problem Client end but would not connect (no blue cloud) to the far end (server) node via tunnel - several reboot attempts on client end first to no avail while the Server unit still had a blue cloud.. There were 4 other clients still connecting to the tunnel server and functional. Rebooted tunnel server and all connections resumed, including the "troubled" one. Have since upgraded to Production 3.19.3.0 on the Tunnel Server unit after this occurred (forgot to get a support dump) - will observe and gather Support dumps when it happens again. Please keep this issue alive as we gather more data. |
|
I observed this last week as well. Made a minor change on the config of the client end that resulted in a reboot of the client. The tunnel did not come back up. As I recall, disabling the tunnel and re-enabling it brought it back up. Fortunately I had left a PC connected to the client that I could access via TeamViewer to make the change. Both ends were Rocket M5 radios with 3.19.3.0 firmware. I will plan on setting up the laptop again this evening so I can attempt to replicate the condition and get the support dumps. |
|
Figures. Tried it again this evening and the tunnel re-connected every time without any intervention... |
|
Suspecting that the Tunnel Server isn't "letting go" of the connection after the client connection is disrupted. Maybe there could be some connection verification watchdog procedure that can monitor the status of tunnel connections and reset the connection if trouble is detected on the server end. There may already be something like this in the firmware and we just aren't giving it enough time to reset. |
|
At least the tunnel active indication on the server showed the tunnel inactive. I have no idea if there is something on the back end that was still hung. I was quite surprised last night when I tried it, that the tunnel active indication on the server went to inactive almost immediately when I rebooted the client end. I did not try a reboot of the server end. I did just try a reboot of the server, and the tunnel did not connect. However it's not related. The hAP at home is in a continuous reboot state. I saw this once before. Not practical to walk my wife through troubleshooting that so it will have to wait until I get home this evening. |
|
Running TOP on the server node shows active connection from the client even after rebooting the server. I have obtained support dump from the server end. Working on getting a support dump from the client once I gain access. |
|
Support files e-mailed to AE6XE June 19 @ 19:30 CDT |
|
no longer needed. PR#302 fixed this in nightly builds 1049+ |
Tunnel connection does not automatically "reconnect" after reboot of Client unit Nightly 713. Tunnel server still has a "blue cloud" even though the links are not shown and there is no blue cloud on the rebooted tunnel client side. Must either reboot the tunnel server or disable/re-enable server port for that node to reconnect.
There should be some sort of "activity" checking and automatic restart procedure for non-functioning tunnel connections on the server end.
This particular case is a UBNT AirRouter Client Nightly 713 and Tunnel Server Microtik hAP AC Lite Nightly 705. This has been a problem for quite some time and is not a "new" issue.
The text was updated successfully, but these errors were encountered: