NPT disconnect/closes durin Filezilla SFTP session.

[kimdimick]

Describe the bug

The npt session on macOS Sequoia 15.0.1 with an M1 processor, disconnects during a SFTP session when using Filezilla. I not have done any testing on my old MacBook Pro with the Intel processor.

Steps to reproduce

I used Filezilla and sftp - ssh file transfer protocol over port 65229 when I see the failure. Port 65229 is the local port and the remote port is 22. Also, a normal ssh session to localhost port 65229 and a command line scp works fine. Also, cyberduck worked fine.

If I run the following npt commands with the verbose flag I can not reproduce the failure.

Command line entris used to reproduct the failure plus the quiet flag.

/Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_am --device cos9 --remote-port 22 --local-port 65229 --timeout 1h --quiet & ; /Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_am --device t420s --remote-port 3389 --local-port 33894 --timeout 1h --quiet &

Command line entrie used to reproduct the failure plus the quiet flag removed.

/Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_am --device cos9 --remote-port 22 --local-port 65229 --timeout 1h & ; /Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_am --device t420s --remote-port 3389 --local-port 33894 --timeout 1h &

----npt test using a different rvs "rv_am and rv_eu" plus quiet flag removed----

Command line for the npt connection on localport 65229 for host cos9 and rv "rv_am".

/Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_am --device cos9 --remote-port 22 --local-port 65229 --timeout 1h

Command line for the npt connection on localport 33894 for host t420s and rv "rv_eu".

/Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_eu --device t420s --remote-port 3389 --local-port 33894 --timeout 1h

----npt test using a different rvs "rv_am and rv_eu"----

Command line for the npt connection on localport 65229 for host cos9 and rv "rv_eu".

/Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_eu --device cos9 --remote-port 22 --local-port 65229 --timeout 1h

Command line for the npt connection on localport 33894 for host t420s and rv "rv_am".

/Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_am --device t420s --remote-port 3389 --local-port 33894 --timeout 1h

Note there were no errors reported in the terminal windows. the session just disconnected.

----npt test using the rv "rv_am" and adding the verbose flag----

Command line for the npt connection on localport 65229 for host cos9 and rv "rv_eu".

/Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_am --device cos9 --remote-port 22 --local-port 65229 --timeout 1h --verbose

Command line for the npt connection on localport 33894 for host t420s and rv "rv_am".

/Users/kdimick/.local/bin/npt --from @intense56 --to @55commercial --srvd @rv_am --device t420s --remote-port 3389 --local-port 33894 --timeout 1h --verbose

I was able to get a sshnpd log file that displayed an error. none of the other log files displayed any error message like the log file srv.18183.log.

Expected behavior

Not to disconnect during the SFTP sessions.

Screenshots

Smartphones

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Were you using an atApplication when the bug was found?

I waas using NPT.

Additional context

The log file srv.18183.log that displaued some error information.

srv.18183.log

[gkc]

May be resolved by #1509 ... once that PR has been merged we will publish another noports release candidate against which this ticket can be retested

[gkc]

@kimdimick Can you retest this using latest alpha release https://github.com/atsign-foundation/noports/releases/tag/v5.7.0-alpha-8 please?

[gkc]

PS use @stream as relay, and you will need to use the newer versions of both the sshnpd and npt binaries

[kimdimick]

I have run a few tests using FileZilla to transfer 26.34 GB of data or approximately 1527 files of various sizes without a disconnect.

The Filezilla issue looks to be fixed in the 5.7.0-alpha-8 release.

[gkc]

Great! Thank you @kimdimick