Versão Imprimível
Pessoal, encontrei várias opções de script para reboot no mikrotik
A maioria é por agendamento.
Mas encontrei este script e não entendi bem como ele age. Como não é por agendamento, ele vai rebootar em que situações?
Quando falhar algumas das situações relacionadas em 'policy"?
#SCRIPT PARA REBOOTAR AUTOMATICAMENTE
/system script add name="reboot" source="/system reboot" policy=ftp,reboot,read,write,policy,test,winbox,password
Citação:
Postado originalmente por 1929
é apenas um reboot,
o que vc precisa?
eu estou com uma RB que do nada para de transmitir. Dou um scan e ela não aparece.
Os clientes que estão nela, ficam sem conseguir navegar. As vezes consigo entrar pelo winbox remotamente e reiniciar ela.
Mas se isso demorar muito para ser detectado, acaba nem mais aparecendo no winbox. Daí tem que ir lá e só desconectar no poe que ela volta.
Acontece sem a menor previsão . Pode ocorrer duas , três vezes no dia ou então passar muitos dias sem ocorrer.
Não é energia, por que já troquei a fonte original por bateria. Tem outras na mesma torre e não faz isso.
Estive pesquisando sobre agendamente de reboot automático, mas não é isso ainda que preciso. Não adianta fazer agendameno para dar um reboot a 3 ou 4 horas. Precisa dar o reboot no momento que o evento ocorre.
Seria algo como o watchdog. Só que a rede é em bridge, então não tem como a RB pingar para o servidor e ativar o watchdog.
Como encontrei esta regra de reboot automático, queria entender como ela realmente trabalha.
A regra ta certa para ativar o reboot, agora vc faz um scheduler e nele vc coloca o nome a data para iniciar e o horario, e apos o intervalo que ele vai executar seu script que vc ira colocar no evento
O problema é que por agendamento continua imprevisível. A RB para vários dias sem problemas ou pode ocorrer aleatoriamente várias vezes no dia.Citação:
Postado originalmente por ultralaser
Wachtdog não deu.
Precisava algo que rebotasse ela quando parasse de transmitir o wireless.
Logo que surge o problema o SSID ainda aparece no scan, mas sem tráfego. Daí passado algum tempo, some o SSID mas continua dando acesso pelo winbox. Daí é só reiniciar e pronto.
Mas se ficar mais tempo, nem no winbox dá mais acesso.
- - - Atualizado - - -
O problema é que por agendamento continua imprevisível. A RB para vários dias sem problemas ou pode ocorrer aleatoriamente várias vezes no dia.Citação:
Postado originalmente por ultralaser
Wachtdog não deu.
Precisava algo que rebotasse ela quando parasse de transmitir o wireless.
Logo que surge o problema o SSID ainda aparece no scan, mas sem tráfego. Daí passado algum tempo, some o SSID mas continua dando acesso pelo winbox. Daí é só reiniciar e pronto.
Mas se ficar mais tempo, nem no winbox dá mais acesso.
Primeiro vou te passar o Script para reiniciar:
Segundo, agendamento para reiniciar:Citação:
/system script
add name=reboot policy=\
ftp,reboot,read,write,policy,test,winbox,password,sniff source=\
"/system reboot"
Travamento, podem ser varias coisas, configuracoes, componentes desgastados... Pelo menos atualize para a versão que seja mais util para as suas necessidades e não esqueça que tem que atualizar a "BIOS" da routerboard.Citação:
/system scheduler
add comment="" disabled=no interval=1d5h name=reboot on-event=reboot \
policy=read,write,test start-date=jan/01/1970 start-time=05:30:00
Já que não tem jeito de outra forma, vamos então pelo agendamento.
Eu queria evitar o agendamento pois o ocorrido não tem dia nem hora. Já houve um período de quase duas semanas sem ocorrer.
Mas também já houve um dia que pelo menos 4 vezes ocorreram.
RB nova, com a versão 5.21. Uso dela só como AP bridge. Não tem nada mais de exigência nela. Processamento baixissimo.
configuração já fiz de tudo. Tenho outras RB , mais de 20 instaladas e configuração de wireless nestas RBs é que não tem mistério.
Já tentei alterar todos os parâmetros, Data-rates, ACK, HW Retries, On Fail retray Time, Mtu, potencia baixa, potencia alta, nada resolve. A conclusão é que tem problema na RB.
Quando esta normal, todos clientes estão com no máximo -65dbm. A maioria com -48 a -60dbm
Tem ao todo 20 clientes pendurados nesta RB. E nunca estão todos online.
Data rates agora está novamente em default. Mas se eu habilitar só 36,48 e 54, todos vão conectar nestes data rates.
Já deixei só em modo B, ou em B/G. Em B/G monitorando já vi chegar a 8 mega de tráfego de down.
Definitivamente não é configuração e não é energia pois está com bateria nova. Cabo novo, conector novo. etc etc.
Isso é o BugOs aqui tbm acontece igualzinho,com Rbs em lugares distintos e por acaso nao segue um padrão de tempo,mas notei que é so da versão 5.x pra cima se voce tiver acesso a ela via porta lan é só desabilitar e habilitar o cartão que ela volta a transmitir.Citação:
Postado originalmente por 1929
Agora não entendi por que o watchdog nao funcionou aí pra vc aqui a rede tbm é bridge e usamos o watchdog pra contornar esse problema por enquanto.
Citação:
Postado originalmente por Fernandols
O watchdog foi a primeira opção que pensei.
Mas em todas as RBs quando entro nelas e pingo para o servidor dá timeout.
As únicas que não dão timeout são as que estão na base, que não precisam passar pelos enlaces 5.8. Elas vão direto ao Switch e daí ao servidor centralizado.
Po estranho cara se vc tem acesso as rbs eram pra elas pingarem no servidor passa mais detalhes da configuração ai pra gente ter uma ideia,de repente pode ser algum errinho na rota.
Abs.
E solução via hardware, que tal?
Se for RB com configuração de led, acho que system > leds, dá pra adicionar um wireless status num interface wlan específica, e determinar um dos leds pra acender. Não sei se nesse caso de travamento o led ficaria aceso quando a interface trava (É a praxe, se não tem processamento pra interface, vai ter pros leds?), mas enfim, se o led apagar, é só colocar um fotoresistor ou fotodiodo, que ligado num amplificador operacional poderia desligar um rele, dá pra colocar uma temporização tipo 2 ou 3 segundos tanto pro led apagado quando pro rele ficar aberto (Desligar a RB por 0,5s não é muito útil, precisaria desligar por 3s eu diria).
A algum tempo eu ia implementar isso, mas aí ví o system > routerboard > settings, baixei o clock de 680 pra 400MHz e tudo se resolveu, RB435 alimentando 5 cartões pelo visto não tinha ripple baixo o suficiente pro processamento a 680MHz, isso em bancada, que dirá em torre!
Caraca rapaz vc foi longe hein! rsrsrsCitação:
Postado originalmente por rubem
Acho que nesse caso um watchdog da Cianet se sairia bem,muito eficiente.
Mas vou testar essa dica de baixar o clock nao tinha pensado nisso.
Abs.
/ system routerboard print
ve o que aparece e posta aqui
coloque no shedule onstart intervalo de 30 segundos
Código ::if ([/ping 8.8.8.8 count=5 routing-table=turbo-8M] = 0) do={ [COLOR=#333333][FONT=Arial]/system reboot[/FONT][/COLOR] }
ele vai ficar pingando o 8.8.8.8 (substitua o ip conforme sua necessidade) e caso ele falhe 5 pings ele reseta.
tive esse mesmo problema com dois ap diferentes era um cliente saturando com sinal mto bom -25 em media