SSH / SCP file transfer issue


I have several OpenWrt devices, from which I usually have set up a solution to dump the configuration regualrly via cron, to a remote server. Using a command like this:

sysupgrade -b - | ssh user@192.168.11 'cat > ~/openwrt/wrt_cfg_bak/name.of.device.lan-$(date +%F)-wrt-cfg-bak.tar.gz'

Authentication is via private-public keypairs, this does work (can connect to remote server with ssh user@server, no password is required)

However, since 21.02.1 the transfer seem to hang, the transfer never completes, on the remote server side I can see the resulting .tar.gz files are of 0 bytes. I have to terminate the command with CTRL+C. On previous versions of OpenWrt I haven't experienced this issue.

I have tried the same with the SCP command:, something like, but with the same issue. Command hangs, does not complete transfer:

scp name.of.device.lan-$(date +%F)-wrt-cfg-bak.tar.gz user@

Was something changed in the latest 21.02.1 with regards to dropbear?

1 Like

try adding the -v option with scp and inspect the output from that. You could also post the output to this thread and perhaps others may help you spot the issue.

I recently ran into similar ssh/scp/sftp issues myself (not just openwrt related) which turned out to be related to login scripts running on server side that assumed interactive usage (i.e. ssh/scp/sftp works for an interactive login like you observe, but not for non-interactive commands). Inspect the "/root/.profile" file or any other init script you have on the openwrt device for commands that expect interactive usage.


1 Like

Check your ip addresses for typos (could be in your script or just as written here, not sure). In one place you are doing scp to and in another to

I take it you are running this command in the router and sending it to a remote system? Have you tried any other files?

1 Like

Have you tried to split the command? First create the backup and verify that it is created completely and it is correct. Then try to upload the file.

1 Like

It is only a typo, I redacted the IP addresses.

I have tried with a test file. that uploads well. It seems that there is an issue with uploading the resulting .tar.gz files generated with sysupgrade -b. Tried also by omitting the $(date +%F) and just with backup-file.tar.gz, same issue.

Tried with a binary file:

Same issue, it hangs at transfer progress:

root@redmi-ap2:/usr/bin# scp iwinfo abcd@
iwinfo                                                                                                 100%   16KB  16.2KB/s   00:00

Strangely this issue is only ony my recently updated devices (21.02.1). Previous versions work ok.

Did you use scp or cp? You should be using scp.

There is an extra argument here. That may be the problem.

Hello, yes, redacted the commend. I was indeed using scp as above. Same thing, but as I mentioned, with doing just normal ssh to the same host with the same user, it does connect properly. The issue seems to be with the file transfers.

I just tried using scp to copy the exact same file you're specifying in your tests (/usr/bin/iwinfo). I successfully scp'd it to both the same host (openwrt device) as well as to another (external host).

There is likely an issue with your specific configuration.

What was the previous version you were using before you upgraded to 21.02.1? Did you keep settings from any prior major relese (19.07, 18.06, etc.) when you upgraded to 21.02.x? Are you able to successfully backup your current configuration via the LuCI web interface? Do you have a backup of a previous configuration?

Sounds like incorrect MTU, or missing MSS clamping rule, or packet loss due to flow offloading, etc.


Spot on! The culprits were the MTU settings on the brdige device, I tweaked them previously, but set them back to default 1500.
The devices were in "dumb" AP mode, so no firewall, routing.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.