Antes de mais nada, tentarei ver se é possível tornar a conexão mais estável. Transferência de arquivos à parte, não acho que seja saudável trabalhar com uma conexão que cai a cada 90 segundos.
Um dongle USB WiFi simples pode fazer milagres lá (primeiro, investigar qual dispositivo está realmente causando a desconexão: host A, host B ou o ponto de acesso?
Possivelmente, o Linux não tem nada a ver com a perda de sinal, mas é mais uma questão de instabilidade WiFi per se . Tente bloquear o ponto de acesso para uma velocidade menor. Mesmo 11 Mbps insignificantes, se forem sólidos, superarão uma conexão escamosa de 54 Mbps. E muitas vezes, as cartas tentarão aumentar a velocidade mesmo que, dada a situação, elas não possam entregar .
Se você está preso a uma conexão que cai e renegocia a cada 90 segundos, sua melhor aposta pode ser rsync ou dividir os arquivos em pedaços pequenos o suficiente para filtrar entre as renegociações:
split -b 10000000 file.mp4
dividirá o arquivo em N partes de (digamos) 10 MiB cada, chamadas xaa , xab , xac ... Quando a cópia estiver completa, você poderá remontar os fragmentos do outro lado usando cat .
Outra possibilidade seria abandonar completamente o TCP e usar um protocolo baseado em UDP, por exemplo, UDT ou UFTP .
Por fim, você pode configurar um servidor Web simples em uma máquina e usar wget ou qualquer cliente HTTP que suporte integridade de recuperação, intervalo de bytes e nova tentativa para baixar o conjunto inteiro de arquivos (que, se não forem já seria melhor comprimir).
Isso é mais demorado para configurar, mas deve continuar automaticamente e usar & software comprovado (apache, wget).
Venha de novo - vá embora de novo - Finnegan
Se você tiver certeza de que os scripts estão sincronizados ou se perderá muito tempo de conexão, provavelmente poderá jogar com iwconfig ou ifup/ifdown para forçar o ponto de acesso para se comportar:
while true; do ifdown wlan0; ifup wlan0; sleep 90; done
ou se você quiser executá-lo como um script (ele exigirá acesso root de qualquer maneira, para executar os comandos *):
#!/bin/sh
while true; do
echo "Going down..."
ifdown wlan0
echo "Coming up..."
ifup wlan0
echo "Ready"
sleep 90
done
A (espero) melhor caminho
O problema com o "intervalo de 90 segundos" é que, a menos que algo esteja realmente errado no roteador, o tempo de permanência não será exatamente de 90 segundos. Então, estamos perdendo muito tempo ou ficando acordados quando a operadora de Wi-Fi está em baixo, ou indo para baixo quando a operadora de Wi-Fi pode ter ficado para cima.
Então, digamos que o roteador tenha o IP 192.168.0.1, nos dois hosts Linux que executamos
#!/bin/sh
IP=192.168.0.1
while true; do
if ( ping -f -c 3 -w 1 $IP | grep "0 received" > /dev/null ); then
ifdown wlan0
ifup wlan0
# Extra time: we MUST be sure the network is up!
sleep 5
fi
sleep 2
done
Este script irá disparar três pacotes em direção ao roteador. Os pacotes são muito pequenos e não afetarão muito a largura de banda. Um pacote descartado pode ser uma coincidência, dois uma coincidência - três pacotes descartados disparam um ciclo de energia da WLAN. Esperançosamente, isso deve desperdiçar no máximo dois segundos de tempo por ciclo (em vez de até 90 segundos), e nunca disparar um ciclo de energia a menos que haja necessidade.
Escusado será dizer que a funcionalidade PING deve ser verificada no roteador - se o roteador não responder aos pings, ou interromper o ICMP quando sob carga TCP / UDP (por exemplo, devido à priorização de protocolo), então a segunda versão do roteador roteiro poderia fazer muito mais mal do que bem.
Mas agora que penso nisso, você tentou mexer nos parâmetros iwconfig ? Por exemplo, o limite de sensibilidade:
sens Set the sensitivity threshold. This define how sensitive is the card to poor operating conditions (low signal, interference).
Positive values are assumed to be the raw value used by the hardware
or a percentage, negative values are assumed to be dBm.
Depending on the hardware implementation, this parameter may control
various functions.
On modern cards, this parameter usually control handover/roaming
threshold, the lowest signal level for which the hardware remains
associated with the current Access Point. When the signal level goes
below this threshold the card starts looking for a new/better Access
Point. Some cards may use the number of missed beacons to trigger
this. For high density of Access Points, a higher threshold make sure
the card is always associated with the best AP, for low density of
APs, a lower threshold minimise the number of failed handoffs.
On more ancient card this parameter usually controls the defer threshold, the lowest signal level for which the hardware
considers the channel busy. Signal levels above this threshold make
the hardware inhibits its own transmission whereas signals weaker than
this are ignored and the hardware is free to transmit. This is usually
strongly linked to the receive threshold, the lowest signal level
for which the hardware attempts packet reception. Proper setting of
these thresholds prevent the card to waste time on background noise
while still receiving weak transmissions. Modern designs seems to
control those thresholds automatically.
Example :
iwconfig eth0 sens -80
iwconfig eth0 sens 2