NetBox is hanging on "Reconnect (5 s)" dialog box (the counter is frozen on 5 s)

[ms2048]

Far Manager version

3.0.6172.0 x64, 3.0.6161 x64, 3.0.6116 x64

OS version

6.1.7601

Other software

ConEmu 22.12.18

Steps to reproduce

I'm connecting to the Linux Mint 21.1 (sftp-server with default config, physical workstation) over a wired 1 Gigabit LAN and uploading files to the server.

Expected behavior

The transfer should go smoothly

Actual behavior

After some time of transferring files (quite randomly), two problems occur:

1. the dialog box pops up: "Network error: Software caused connection abort" and two buttons: "Abort" and "Reconnect (5 s)"
2. the counter on the dialog box does not decrease - this effectively hangs the transfer until I manually select the button and reconnect

The first problem might be another bug in itself on the NetBox side (as other software like FileZilla never had any disconnects while transferring there) but this would be harmless in itself, as the transfer would continue after 5 seconds break and reconnecting.

Also, I remember that the disconnects were there for a long time (5395 x64 version had them but the timer worked correctly there).

[ms2048]

I was just able to reproduce this without ConEmu.

[rohitab]

I just looked at the code for the NetBox plugin. It's not really hung. The issue is that the plugin expects to receive the FE_IDLE event in src/NetBox/WinSCPFileSystem.cpp which causes TFarMessageDialog::Idle() to be called, which in turn updates the timer on the dialog and clicks the Reconnect button when it's expired. Since the FE_IDLE event is never received, the counter remains at 5 s and is never updated.

You can easily reproduce the issue by establishing a SFTP connection, disconnecting the network, and then trying to access a file on the server. You will get the same dialog as seen here.

   ╔═════════════════════ Error ══════════════════════╗
   ║ Network error: Software caused connection abort  ║
   ║             Abort   Reconnect (5 s)              ║
   ╚══════════════════════════════════════════════════╝

The FE_IDLE event was removed from Far in 7af0fd7. The plugin needs to be updated to account for that change.

[ms2048]

Thanks for the detailed analysis!

Will going back to 5837 fix this? I'll try soon...

Looks like this has also been reported in similar way ages ago and promptly ignored: FarGroup/Far-NetBox#14

From the POV of the casual user this looks really strange: someone introduced, on purpose(!), incompatibility that crippled NetBox - a very important plugin that is also distributed with Far and then call it a day. Also, seems like almost no one noticed this.

[ms2048]

I can confirm that going back to 5837, even with newest NetBox release fixes the counter (it only shows 5s, then 4s and then disappears but this is good enough for me). Hopefully there aren't any dangerous bugs in such an old version, as I will have to stick to it for now.

@rohitab this is really a life saver for me, thanks!

[rohitab]

@ms2048 glad I could help.

Lua Script to fix Issue

I've written a script that fixes the issue. You can use this with the latest version of Far and NetBox. Here are the steps required to install it.

1. Extract NetBox.ReconnectTimer.lua from the attached archive NetBox.ReconnectTimer.lua.zip
2. Copy NetBox.ReconnectTimer.lua to %FARPROFILE%\Macros\scripts
3. Restart Far or run macro:load to reload macros

The NetBox timer should now countdown as expected and automatically reconnect when it reaches zero.

Please note that I just wrote this script and haven't had time to test it thoroughly. I've tested it with Far version 3.0.6172.0 x64 only. If you find any issues, please let me know.

Attached Files

• NetBox.ReconnectTimer.lua.zip

[ms2048]

I've successfully switched to this an hour ago. Seems to be working fine so far, thank you!

I will report here later in case of any problems with this fix.

Still, I think this bug should remain opened, as a proper fix should be done in the future.

[rohitab]

@ms2048 You're very welcome! Thanks for letting me know it worked.

Still, I think this bug should remain opened, as a proper fix should be done in the future.

Absolutely, you should leave the ticket open since the issue has not yet been fixed. The script I wrote should only be used util an official fix is out.

Looks like this has also been reported in similar way ages ago and promptly ignored: FarGroup/Far-NetBox#14

Please keep in mind that Far is an open-source project and the people contributing to its development, and the ones fixing the bugs are doing so on their own time. Most of the issues that I have reported get fixed almost immediately. Sometimes it may take a while for an issue to get fixed.

As you pointed out, this issue was first reported back in 2021. Since it's not been fixed yet, I am assuming it's either not high priority for the project maintainers, or they just haven't had time to look at it yet. Either way, I figured I would release a quick fix to resolve this issue until an official fix is out. It might help others as well.