Como evitar o tempo limite de conexão TCP ao enviar arquivos grandes via FTP?

Question

Não consigo FTP (recuperar) um arquivo grande da Internet para minha VM do Linux. Isso acaba depois de um tempo.

O erro real é " Não foi possível ler a resposta da conexão de controle - expirou. " Este erro ocorre após alguns minutos, depois que um bom pedaço do arquivo já foi transferido.

A configuração é:

FTP Client:  ncftpget running in Linux on VMWare Player 3.0
FTP Server:  somebody else's machine out on the Internet, configuration unknown
Guest OS:    Ubuntu 8.10 Linux 32-bit, with vmxnet and vmware tools installed.
Host OS:     Vista 64-bit
Network:     Linux VM connects to the Internet via Bridged NIC (also tried NAT)
FTP Mode:    PASV

Eu encontrei alguns posts no fórum mencionando um tempo limite de 2 minutos em algum lugar. Mas exatamente onde e como consertar isso não ficou claro. Algumas etapas de solução de problemas já foram tentadas:

• Eu mudei do VMWare Player 3.0 para o VirtualBox 3.0.x, mas não tive sorte.
• também mudei de NAT para NICs virtuais em ponte, mas sem sorte

UPDATE O Netstat na VM Linux e a página de administração equivalente no roteador DIR-655 mostram que a conexão está ativa e bem (status tcp 'ESTABLISHED'). O Vista não vê a conexão, o que eu acho normal se o estado da conexão for gerenciado apenas dentro da VM.

Aqui está a saída da netsh interface tcp show global no Vista, caso seja útil:

C:\Users\alex>netsh interface tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
Receive Window Auto-Tuning Level    : highlyrestricted
Add-On Congestion Control Provider  : none
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled
** The above autotuninglevel setting is the result of Windows Scaling heuristics
overriding any local/policy configuration.

    

Answer 1

Para fins de solução de problemas, tente fazer o download do mesmo arquivo via wget ou curl . Eu suspeito que o PERA esteja correto, os comandos do NOOP irão impedir isso e possivelmente wget ou curl os enviariam.

    

Answer 2

Se você está passando por NAT, é provável que os temporizadores NAT estejam desconectando você. Eu vejo isso em quartos de hotel onde eu ssh em uma máquina e não consigo fazer algo por algum tempo (tão curto quanto 5 minutos, às vezes!)

# echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time
# echo 60 > /proc/sys/net/ipv4/tcp_keepalive_intvl
# echo 20 > /proc/sys/net/ipv4/tcp_keepalive_probes

Tente isso. Isso fará com que um keepalive seja enviado em todos os fluxos TCP a cada minuto, independentemente da atividade no soquete.

Observe que o cliente ftp não pode, na verdade, USE keepalives. É algo que o aplicativo deve solicitar. Se isso falhar, talvez a instalação de outro cliente FTP funcione melhor. O cliente de FTP do NetBSD (lukemftp) pode estar disponível e é o melhor cliente de FTP de linha de comando que já vi até hoje.

Também é possível que o terminal remoto esteja fechando a conexão devido à inatividade. Se for, tem uma idéia bastante rompida da realidade. Se esses hacks TCP keepalive acima não resolverem o problema, o cliente terá que enviar algum comando periodicamente (NOOP, etc) ou os administradores do servidor FTP terão que alterar seu final.

    

Answer 3

Pode ser qualquer dispositivo de filtragem no caminho entre sua VM e o servidor FTP. A maioria dos firewalls (incluindo roteadores domésticos) tem uma tabela de estados em que as sessões TCP ociosas são redefinidas após determinado tempo limite.

Você pode alterar a NIC das VMs para o modo em ponte (em vez de NAT) para classificar o sistema operacional host. Então, certifique-se de que seu cliente FTP envie comandos NOOP periodicamente para manter o canal de comando aberto. Existem firewalls em torno dos quais fecham a conexão de dados, se eles virem que a sessão de comando está fechada. Independentemente se a conexão de dados está ociosa ou transportando tráfego ...

HTH,
PEra

    

Answer 4

Se você estiver fazendo isso a partir da linha de comando, tente ativar o 'hash' ('binary' é outro que eu sempre ligo). Isso pode gerar tráfego suficiente na porta de controle para evitar que o tempo limite seja atingido.

    

Answer 5

O FTP usa dois soquetes - um para controle e outro para dados.

É provável que sejam as tabelas de estado NAT na VM que estão causando o tempo limite da conexão de controle devido à inatividade nesse soquete.

Você pode conseguir contornar isso ativando o "FTP Ativo" no sistema da VM, o que, esperamos, fará com que o VMware assista ativamente a sessões de FTP e mantenha o soquete de controle ativo enquanto os dados ainda estiverem fluindo.

    

Answer 6

Se o servidor FTP for o Vista, vá para as propriedades do site FTP e aumente o tempo limite de 15 minutos (padrão). Qual é o tamanho do arquivo que você está tentando transferir?