Reiniciando o ponto de acesso via SSH com pexpect… trava. Alguma ideia?

2

Quando eu quero reiniciar meu ponto de acesso D-Link DWL-3200-AP do meu shell bash, eu conecto ao AP usando ssh e apenas digito reboot na interface CLI. Após cerca de 30 segundos, o AP é reinicializado:

# ssh [email protected]
[email protected]'s password: ********

Welcome to Wireless SSH Console!! ['help' or '?' to see commands]


Wireless Driver Rev 4.0.0.167
D-Link Access Point wlan1 -> reboot

O som é ótimo? Bem, infelizmente o processo do cliente ssh nunca sai, por alguma razão (talvez o AP mate o servidor ssh um pouco rápido demais, eu não sei). O processo do meu cliente ssh está completamente bloqueado (mesmo que eu espere vários minutos, nada acontece). Eu sempre tenho que esperar o AP reiniciar, então abrir outro shell, encontrar o ID do processo do cliente ssh (usando ps aux | grep ssh ) e então matar o processo ssh usando kill <pid> . Isso é muito chato.

Então eu decidi escrever um script python para reiniciar o AP. O script se conecta à interface CLI do AP via ssh, usando python-pexpect, e tenta iniciar o comando "reboot". Veja como o script se parece:

#!/usr/bin/python
# usage: python reboot_ap.py {host} {user} {password}

import pexpect
import sys
import time

command = "ssh %(user)s@%(host)s"%{"user":sys.argv[2], "host":sys.argv[1]}
session = pexpect.spawn(command, timeout=30) # start ssh process
response = session.expect(r"password:") # wait for password prompt
session.sendline(sys.argv[3]) # send password
session.expect(" -> ")  # wait for D-Link CLI prompt
session.sendline("reboot") # send the reboot command
time.sleep(60) # make sure the reboot has time to actually take place
session.close(force=True) # kill the ssh process

O script conecta-se corretamente ao AP (tentei executar alguns outros comandos além de reboot , eles funcionam bem), envia o comando reboot , aguarda um minuto e depois mata o processo ssh. O problema é: desta vez, o AP nunca reinicia! Não faço ideia do porquê.

Alguma solução, alguém?

    
por MiniQuark 15.11.2010 / 16:14

3 respostas

1

No seu primeiro cenário (reiniciando do login ssh): Se o seu dispositivo está realmente reinicializando, então todos os processos são eliminados, incluindo aquele conectado ao seu cliente ssh. Você não precisa fazer o login após uma reinicialização para matar processos antigos, já que eles não podem existir! Eu suspeito que seu cliente ssh não esteja manipulando gentilmente o fechamento forçado da conexão no lado remoto, e por isso ele trava. Você deve poder apenas fechar / matar em seu sistema local.

Desculpe, não sei muito sobre expect , então não tenho conselhos sobre seus problemas específicos. No entanto, se você quiser fazer o script de uma reinicialização remota, pode ser possível configurar o login do ssh sem senha por meio de um arquivo de chaves e, em seguida, fazer apenas ssh root@mydevice reboot .

    
por 15.11.2010 / 17:36
1

Se você estiver usando o cliente OpenSSH, sugiro ler a seção "ESCAPE CHARACTERS" nas páginas man ssh (1) e ssh_config (5) - você pode encerrar a sessão a qualquer momento no cliente digitando o caractere de escape seguido por um ponto.

Quanto ao núcleo do problema, o daemon ssh no roteador provavelmente não é notificado sobre o encerramento, portanto, ele nunca fecha a sessão e deixa o cliente aguardando um tempo limite do TCP. A configuração de ServerAliveInterval é bastante razoável nesse caso (você também deve poder definir isso no arquivo de configuração ssh por host).

Você também pode estar interessado em OpenWRT .

    
por 03.09.2012 / 16:48
0

Eu brinquei com opções ssh, e acho que encontrei uma solução.

Basta adicionar a opção ServerAliveInterval ssh ao comando do cliente ssh da seguinte forma:

command = "ssh -o ServerAliveInterval=10 %(user)s@%(host)s"%{"user":sys.argv[2], "host":sys.argv[1]}

O que acontece então é que o processo bloqueia completamente (sem reinicializar o AP) por cerca de 10 segundos, então o AP é reinicializado, e após os 60 segundos de suspensão, o script termina apropriadamente.

Eu ainda apreciaria uma solução melhor ou uma explicação do porque isso resolve o problema!

Obrigado

    
por 15.11.2010 / 16:20