1405バイトより大きいファイルをコピーするとSCPがハングするのはなぜですか？
ローカルマシンの1つからリモートマシンにファイルをコピーしようとしています。 1405バイトまでのサイズのファイルをコピーしても問題ありません。大きなファイルをscpしようとすると、ファイルはコピーされますが、scpプロセスがハングアップして終了しません。シェルに戻るには、Ctrl-Cを押す必要があります。
FTPでも同じ動作が見られます。これを引き起こしている可能性があるものについてのアイデアはありますか？
これは間違いなくMTUの問題のように聞こえます（@Konerakが指摘したように）。これは、これをテストする方法です。
ip link set eth0 mtu 1400
これにより、ネットワークパケットの許可サイズが一時的にネットワークインターフェースで1400に設定されますeth0（名前を調整する必要がある場合があります）。システムは、このサイズを超えるすべてのパケットをネットワークに送信する前に分割します。これでscpコマンドが修正される場合は、ネットワーク内の問題を見つけるか、この醜い修正を永続的にする必要があります;）
MTUは通常1500 Bであると考えてください（イーサネットの制限のため）。これらの1500 Bのすべてが「データ」に使用されるわけではありません。いわゆるプロトコルオーバーヘッドにより、1500からかなりの量が取り除かれます。
- SCP（非圧縮）には65 Bヘッダーが必要です。
- TCPには20〜60 Bのヘッダーが必要です。
- IPには20〜60 Bのヘッダーが必要です。
これを踏まえると、ペイロードが1405 Bに制限されていることはそれほど驚くべきことではありません。
追伸Wiresharkを試して、IPヘッダーを確認します。パケットの断片化を許可していますか？
関与するソースマシンとターゲットマシンの間で何らかの種類のトンネリングが行われています。 TCPは、接続を開くときにMSSを送信し（ssh/scpに使用されます）、途中のこのトンネル（カプセル化を追加し、使用可能な最大MTUを減らす）が補正する必要があります上記のMSSを目的地への途中で透過的に変更する（およびその逆）。
一部のトンネル（VPN？）はその役割を果たしていません。または、マシンのMSSが正しく構成されていません。
コピー元のマシンにsshし、空のディレクトリでlsを実行すると、同じ動作が見られると思います。それはうまくいくはずです。しかし、 "cd /; ls -lR"（したがって大きなパケットを取得する）の場合、これもハングします。
ハードウェアのように思えます。 LAN上のマシンが1つだけの場合は、イーサネットカードが不良である可能性があります。 LAN上のすべてのマシンの場合は、ハブまたはルーターを確認します。
ルーターの設定が悪いように聞こえます。データパケット転送の制限は、私が思うよりも少ない量でなければなりません。