Fórum Ubuntu Linux - PT
Suporte Técnico => Internet, Redes e Segurança => Tópico iniciado por: Leonardo™ em 06 de Setembro de 2010, 09:50
-
Olá! Depois que instalei o firestarter não consigo conectar na internet. Acredito que o firestarter esteja bloqueando alguma porta, pois depois de instala-ló que surgiu este problema...
Atualmente só estou conseguindo ficar online, porque toda vez que inicio o sistema, abro o terminal e digito: poff -a e pon dsl-provider depois de aplicar esses comandos consigo ter acesso a internet normalmente, entretanto sempre que reinicio o sistema preciso refazer esse procedimento.
Utilizo um modem da D-LINK o modelo é DSL-500G e a conexão é feita pelo protocolo PPPOE.
Abraços!
-
Mostre o conteúdo do seu arquivo "/etc/network/interfaces".
-
Uma solução simples:
Coloque os comandos
poff -a
pon dsl-provider
antes da linha exit 0 do arquivo /etc/rc.local
Copie o arquivo rc.local para /usr/bin/rc.local
Reinicie e veja se funciona.
Por default, o arquivo /etc/rc.local não faz nada, até você copiar ele para um binário (path)
-
Uma solução simples:
Coloque os comandos
poff -a
pon dsl-provider
antes da linha exit 0 do arquivo /etc/rc.local
Copie o arquivo rc.local para /usr/bin/rc.local
Reinicie e veja se funciona.
Por default, o arquivo /etc/rc.local não faz nada, até você copiar ele para um binário (path)
Esta informação está equivocada, não é preciso fazer isso de colocar no /usr/bin o arquivo rc.local. Ele foi feito exatamente para isso, ou seja, executar comandos como root localmente (em todos os usuários do sistema) no boot do sistema.
Somente basta colocar os comandos:
poff -a
sleep 5
pon dsl-provider
no arquivo rc.local que fica na pasta /etc e isso antes da linha de texto exit 0
Essa edição deve ser feita como root, portanto no terminal faça assim:
sudo gedit /etc/rc.local
-
Então faça o teste. Eu não seria irresponsável de colocar uma informação dessa aqui no fórum. Gostaria inclusive que você retorne da forma que está falando se teve sucesso. No próprio arquivo /etc/rc.local está explicado.
-
Realmente não é muito usual o que vc sugeriu, libonati. Até pq ainda nem sabemos o que fez com que a rede dele parasse de iniciar automaticamente.
-
Zekkerj meu arquivo "/etc/network/interfaces" esta assim:
auto lo
iface lo inet loopback
auto dsl-provider
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
provider dsl-provider
auto eth0
iface eth0 inet manual
-
Certo, padrãozinho.
O que deve estar acontecendo é que o Firestarter deve estar bloqueando a negociação inicial do PPPoE.
Eu pessoalmente não gosto do Firestarter, acho-o muito complicado de usar. Juro que prefiro a linha de comandos a ele.
Minha sugestão, por enquanto, é que você libere todo o tráfego na interface eth0, já que esse tráfego estará vindo da central. Seu tráfego internet deve estar passando apenas pela interface "ppp0", criada quando vc se conecta à internet.
-
Zekkerj e como faço esse procedimento que você mencionou?
-
Não uso o firestarter, então não posso te dar detalhes da interface. Vamos aguardar alguém que o use pra te ajudar.
-
Então faça o teste. Eu não seria irresponsável de colocar uma informação dessa aqui no fórum. Gostaria inclusive que você retorne da forma que está falando se teve sucesso. No próprio arquivo /etc/rc.local está explicado.
Calma rapaz, qualquer um aqui do fórum está passível de cometer erros, não é por que você se equivocou numa dica que vai deixar de ter seu valor e em nenhum momento falei que você foi ou é irresponsável, apenas falei o que sei e já comprovei não só com esses comandos aí, mas com qualquer outro que já coloquei neste arquivo rc.local, desde que antes do exit 0
Vários outros usuários de mais tempo no fórum já falaram sobre isso, veja neste link aqui:
http://ubuntuforum-br.org/index.php/topic,4731.0.html
principalmente nos últimos post acho que do usuário Alarcon e com sucesso relatado pelos que assim fizeram, inclusive eu.
Só se no Ubuntu 10.04 isso foi mudado, pois até a versão anterior e no qual eu ativava minha conexão com o comando sudo pppoeconf (e que dava este mesmo problema relatado aqui) tinha que fazer exatamente como disse seguindo a dica do Alarcon (acho eu) do link indicado sem nada de colocar o rc.local na pasta /usr/bin, nem faz muito sentido isso.
Sem estresse ok! ;)
-
Certo, padrãozinho.
O que deve estar acontecendo é que o Firestarter deve estar bloqueando a negociação inicial do PPPoE.
Eu pessoalmente não gosto do Firestarter, acho-o muito complicado de usar. Juro que prefiro a linha de comandos a ele.
Minha sugestão, por enquanto, é que você libere todo o tráfego na interface eth0, já que esse tráfego estará vindo da central. Seu tráfego internet deve estar passando apenas pela interface "ppp0", criada quando vc se conecta à internet.
O firestarter não tem nada haver com isso, pois comigo tinha acontecido a mesma coisa, ou seja, minha conexão adsl funcionava bem, depois deixou de funcionar e só voltava a funcionar com os comandos indicados e na época não tinha instalado nenhum firewall.
Se fosse o firewall que tivesse atrapalhando, com os comandos executados nem surtiriam efeito por que o que ele faz é parar qualquer tipo de conexão (comando sudo poff -a) e depois ativar outra vez a conexão adsl ativada pelo sudo pppoeconf (comando sudo dsl-provider).
O que parece é que a conexão ativa com algum defeito e não desativa ficando com a aparência que está ativa, mas não está e aí para voltar a funcionar da forma desejada, tem-se que parar na força e ativar outra vez.
-
Uma solução simples:
Coloque os comandos
poff -a
pon dsl-provider
antes da linha exit 0 do arquivo /etc/rc.local
Copie o arquivo rc.local para /usr/bin/rc.local
Reinicie e veja se funciona.
Por default, o arquivo /etc/rc.local não faz nada, até você copiar ele para um binário (path)
Leonardo, experimente como expliquei acima. Se você quiser voltar as configurações normais é só deletar a cópia do arquivo em /usr/bin/rc.local
-
Por default, o arquivo /etc/rc.local não faz nada, até você copiar ele para um binário (path)
No próprio arquivo /etc/rc.local está explicado.
Se você está falando em relação a esta linha do arquivo rc.local:
# By default this script does nothing.
Interpretei de outra forma que você e talvez esteja aí seu equívoco, pois é lógico que o rc.local, da forma original em que ele está (padrão), não faz nada por que ele só tem o seguinte comando:
exit 0
e tudo o mais que vem antes é linha de comentário, veja o símbolo # no início de cada linha. O exit 0 é só um comando de saída de script terminado corretamente, portanto quando ele quer dizer que por padrão o rc.local não faz nada é por que inicialmente não tem nada nele indicado para ser feito e não que seja preciso colocá-lo na pasta dos binários para só então passar a ter efeito, ok.
-
linuser104. Deixei a muito a teoria para trás. Não quero ficar aqui insistindo em uma coisa que comprovei pessoalmente no ubuntu 10.4. Se é boog ou não, não vai ao caso. O fato é que mesmo você colocando comandos no /etc/rc.local antes do exit 0 sem comentar, ele não vai fazer nada. Experimente aí no seu computador e veja na prática o que acontece.
-
libonati, desculpe mas você está enganado. A função do "rc.local" não é ser executado durante a operação normal da máquina. Ele está lá para ser executado na hora do boot, logo após a inicialização dos serviços de rede.
É o local ideal para você colocar algum comando que precisa ser executado pelo na inicialização, sem ser pelo modo gráfico. Eu também não concordo em criar cópias dele, ainda mais no "/usr/bin". Esse diretório é sagrado: só os aplicativos do sistema devem ficar lá. Se vc tem algum aplicativo que quer adicionar, deve usar o "/usr/local/bin".
Outro motivo pelo qual não se deve colocar o "rc.local" no /usr/bin é pq simplesmente isso não é necessário, para executá-lo. Pra isso, basta usar
. /etc/rc.local
e ele será interpretado no shell local. Se o problema é executá-lo como root,
sudo bash -c /etc/rc.local
dá conta do recado.
-
linuser104. Deixei a muito a teoria para trás. Não quero ficar aqui insistindo em uma coisa que comprovei pessoalmente no ubuntu 10.4. Se é boog ou não, não vai ao caso. O fato é que mesmo você colocando comandos no /etc/rc.local antes do exit 0 sem comentar, ele não vai fazer nada. Experimente aí no seu computador e veja na prática o que acontece.
Mas eu já te falei isso nos primeiros textos aqui e parece que você não viu, ou não quis ver, até disse que não só com estes comandos mas com outros mais que preciso aqui que sejam executados como root no boot e dei até um link onde outros usuários relatam que o simples adicionar de comandos no rc.local resolve o caso da conexão ADSL, agora se você acredita ou não é outra estória.
Talvez quando você testou e não funcionou deva ter sido por que não colocou os comandos antes do exit 0 e sim depois ou alguma falha nos comandos usados, mas repito mais uma vez não é preciso colocar o rc.local no /usr/bin, isso é trabalho em dobro, você está sendo redundante.
Outra coisa que pode ter ocorrido, já que afirma que não funciona só com a edição do rc.local, é você ter alterado as permissões do arquivo rc.local que fica em /etc, pois inicialmente ele é leitura, escrita e execução para o root e apenas leitura e execução para o grupo e outros.
-
Ninguém tem alguma solução para meu problema? Eu até desinstalei o firestarter e o problema continuou, então resolvi reinstala-lo. Mais enfim, sempre que quero utilizar a internet preciso aplicar poff -a e pon dsl-provider :(
-
Ninguém tem alguma solução para meu problema? Eu até desinstalei o firestarter e o problema continuou, então resolvi reinstala-lo. Mais enfim, sempre que quero utilizar a internet preciso aplicar poff -a e pon dsl-provider :(
A solução já foi fornecida que é o seguinte, abra o terminal e digite:
sudo gedit /etc/rc.local
quando o arquivo abrir coloque antes da linha de texto
exit 0
e depois das linhas de comentários, as que iniciam com o símbolo #, os 3 seguintes comandos:
poff -a
sleep 5
pon dsl-provider
salve, saia do arquivo e reinicie o seu PC e veja se agora o problema foi solucionado.
-
Linuser104 fiz o que você indicou e não obtive sucesso....
-
Acho que o mais indicado seria restaurar minha configuração para o padrão quer era antes de ter instalado o firestarter, será que isso é possível? Talvez isso resolva, não vejo mais utilidade de usar o firestarter ele esta dando muita dor de cabeça rsrs.
-
Linuser104 fiz o que você indicou e não obtive sucesso....
Veja as permissões do arquivo rc.local se estão ok.
Esses passos servem para exatamente o caso de a conexão só funcionar com os comandos sudo poff -a e depois sudo pon dsl-provider
Caso as permissões do rc.local estejam ok, tente mudar o sleep 5 para um valor maior, tipo sleep 10
Já fiz esse procedimento no Ubuntu versão anterior no qual minha conexão ADSL só ativava pelo comando sudo pppoeconf e tinha este mesmo problema que você, no Ubuntu 10.04 minha conexão se efetiva usando o NetworkManager (finalmente), mas uso o rc.local para ativar no boot outras coisas tipo um script que corrige a imagem invertida (espelho) de minha webcam.
PS: Você poderia colocar aqui como ficou seu arquivo rc.local?
-
Leonardo:
Passei por este problema quando mexi na configuração do firestarter, mais precisamente em
Preferências, Firewall, Iniciar Firewall ao discar para fora.
Talvez seja este o teu problema.
-
Acho que o mais indicado seria restaurar minha configuração para o padrão quer era antes de ter instalado o firestarter, será que isso é possível? Talvez isso resolva, não vejo mais utilidade de usar o firestarter ele esta dando muita dor de cabeça rsrs.
no tempo que usava o firestarer sempre segui o tutorial do Alarcon - http://wiki.ubuntu-br.org/Firestarter e nunca me deu dor de cabeça
hj uso o padrão do ubuntu - http://wiki.ubuntu-br.org/UFW - que já vem pré-configurado, é só ativar
-
Linuser104 ficou assim:
exit 0
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
poff -a
sleep 5
pon dsl-provider
-
Linuser104 ficou assim:
exit 0
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
poff -a
sleep 5
pon dsl-provider
está aí o erro, deveria ser assim:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
poff -a
sleep 5
pon dsl-provider
exit 0
o exit 0 é a ultima linha do arquivo, sempre.
-
Linuser104 acabei de alterar e desliguei/liguei o computador e não surtiu efeito. O problema continua. :\
-
Linuser104 acabei de alterar e desliguei/liguei o computador e não surtiu efeito. O problema continua. :\
Não estou no Ubuntu agora para dar maiores detalhes sobre as permissões do arquivo rc.local, para saber se no seu por algum motivo foi alterado ou até fornecer outras dicas.
Por enquanto tente aumentar o valor do sleep ele é um comando para esperar alguns segundos antes de usar outros comandos, portanto sleep 5 ele espera 5s e assim por diante.
Vou ter de sair no momento, mas quando puder volto aqui para continuarmos, caso ainda não tenha resolvido com os amigos de fórum.
Já tentou parar o firewall no botão para isso e somente depois removê-lo para ver se é o mesmo que está atrapalhando na conexão? Não acredito muito nisso, pois se você fez as configurações de maneira correta o firewall só bloqueia conexões de fora para dentro e não o contrário e como disse antes se os comando sudo poff -a e sudo pon dsl-provider resolvem o caso, eles só desativam e ativam novamente sua conexão e se fosse o firewall ele continuaria bloqueando.
-
Linuser104 obrigado pelo apoio, espero que possamos resolver este problema. Abraços!
-
linuser, as permissões do arquivo rc.local são indiferentes, ele é interpretado pelo bash durante a inicialização.
Leonardo, tem como você ver se há algum log do PPP no diretório /var/log? Algo como ppp.log, ou então nos arquivos "/var/log/syslog" e "/var/log/messages", alguma coisa sobre o processo ppp.
-
Fiz o firestarter iniciar com o boot e aumentei o sleep para 10 e parece que o problema foi resolvido. Vou ficar monitorando a conexão, se o problema surgir novamente volto aqui e informo os detalhes. ;)
-
linuser, as permissões do arquivo rc.local são indiferentes, ele é interpretado pelo bash durante a inicialização.
Leonardo, tem como você ver se há algum log do PPP no diretório /var/log? Algo como ppp.log, ou então nos arquivos "/var/log/syslog" e "/var/log/messages", alguma coisa sobre o processo ppp.
Como o colega afirmava que as mudanças no rc.local não surtiam efeito e como houve uma dúvida aqui sobre a funcionalidade ou não do rc.local pelo usuário libonati, então fiquei pensando aqui se não teria algum problema com as permissões originais do referido arquivo, por isso a pergunta sobre elas.
Eu penso que pode influir sim, pois o rc.local nada mais é do que um script e como tal é necessário ter a permissão de execução. Aqui o comando:
ls -l /etc/rc.local
retornou como resposta isso:
-rwxr-xr-x 1 root root 364 2010-05-01 17:59 /etc/rc.local
o que deu para perceber que o rc.local tem para o dono as permissões (r=leitura, w= escrita e x= execução), para os grupo (r=leitura e x= execução) e para outros (r=leitura e x= execução). O dono seria o root e o grupo root também.
Agora não sou um especialista nisso, portanto não tenho certeza e posso estar redondamente enganado, mas pelo último post do colega o problema, aparentemente, se resolveu, portanto as permissões do rc.local deveriam estar normais, ou seja, na forma padrão e seu problema era de outra espécie.
-
Fiz o firestarter iniciar com o boot e aumentei o sleep para 10 e parece que o problema foi resolvido. Vou ficar monitorando a conexão, se o problema surgir novamente volto aqui e informo os detalhes. ;)
Humm, que bom. Espero que esteja solucionado definitivamente. ;D
Acho que isso resolve a dúvida sobre o rc.local funcionar ou não sem colocar no /usr/bin para o Ubuntu 10.04
-
Eu penso que pode influir sim, pois o rc.local nada mais é do que um script e como tal é necessário ter a permissão de execução.
Não precisa, pq ele não é executado como um processo separado. Mas isso não vem ao caso agora, melhor a gente focar no problema do Leonardo, pq já se discutiu demais por aqui.
-
Segundo o Leonardo, parece que o problema está resolvido.
É sempre bom tirar a dúvida.
Deletei minha rota para o gateway e fiz todas as possibilidades usando o arquivo rc.local. Ele sozinho não criou rota nenhuma. Foi preciso colocar ele e um script no caminho do PATH. Se colocar o script sem o auxilio do rc.local, nada acontece. Se colocar no rc.local sem o auxilio do script, nada acontece. O rc.local tem as permissões de execução. Gostaria que vocês fizessem essa experiência. Não deixa de ser interessante.
Obs:desativem o módo automático e levem para IP fixo.
-
Não precisa, pq ele não é executado como um processo separado. Mas isso não vem ao caso agora, melhor a gente focar no problema do Leonardo, pq já se discutiu demais por aqui.
Fiz um pequeno teste aqui que foi o seguinte, como eu preciso que um comando rode no boot para que minha webacam fique com a imagem normal, pois inicialmente ele está invertida (espelho), eu acrescentei determinado comando no rc.local. Feito isso ele cumpre o seu papel com sucesso, então com essa dúvida relatada pelo colega zekkerj sobre as permissões do rc.local, eu resolvi retirar a permissão de execução dele para o dono, grupo e outros e reiniciei o PC. Como imaginado por mim, o referido comando que acrescentei no rc.local não surtiu efeito, ficando a imagem de minha webcam em espelho (invertida) como antes.
Moral da estória, pelo que pude constatar, se você retirar a permissão de execução do rc.local, os comandos colocados nele não são executados durante o boot.
-
Segundo o Leonardo, parece que o problema está resolvido.
É sempre bom tirar a dúvida.
Deletei minha rota para o gateway e fiz todas as possibilidades usando o arquivo rc.local. Ele sozinho não criou rota nenhuma. Foi preciso colocar ele e um script no caminho do PATH. Se colocar o script sem o auxilio do rc.local, nada acontece. Se colocar no rc.local sem o auxilio do script, nada acontece. O rc.local tem as permissões de execução. Gostaria que vocês fizessem essa experiência. Não deixa de ser interessante.
Obs:desativem o módo automático e levem para IP fixo.
Veja se a sequencia de comandos colocados no rc.local estão corretas para a finalidade que você deseja, se não seria necessário ter um tempo de espera de um comando para outro (sleep n, onde n seria um valor em segundos), pois pode ser que os comandos que deseja executar precisem ser executados depois de certos arquivos/processos serem carregados/ativados durante o boot e que o rc.local está executando primeiro e portanto não dando certo etc.
A finalidade do rc.local foi justamente essa de passar comandos, em sequencia, que precisam ser carregados durante o boot do sistema como root e para todos os usuários, portanto não teria sentido ter o mesmo no /etc e precisasse de colocar uma cópia dele no /usr/bin. Caso isso fosse necessário, no /usr/bin já teria ele, ou melhor, já teria um link apontando para ele no /etc assim toda mudança que se fizesse no rc.local (em /etc) já seria transmitida no link do /usr/bin, portanto mesmo que sua dica fosse a correta, não precisaria copiar o rc.local para a referida pasta e sim apenas criar um link em /usr/bin apontando para /etc/rc.local ok.
-
Seguindo orientações do zekkerj, retirei o executável de /usr/bin e tinha colocado em /usr/local/bin. Troquei o executável pelo link que você sugeriu apontando para /etc/rc.local e realmente é mais prático, funcionou normalmente. O que está acontecendo é que simplesmente não estou conseguindo usar só o /etc/rc.local.
O comando é:
route add default gw 192.168.1.1 eth0
as permissões do arquivo está tudo ok
-rwxr-xr-x 1 root root 343 2010-09-08 14:31 /etc/rc.local
-
Seguindo orientações do zekkerj, retirei o executável de /usr/bin e tinha colocado em /usr/local/bin. Troquei o executável pelo link que você sugeriu apontando para /etc/rc.local e realmente é mais prático, funcionou normalmente. O que está acontecendo é que simplesmente não estou conseguindo usar só o /etc/rc.local.
O comando é:
route add default gw 192.168.1.1 eth0
as permissões do arquivo está tudo ok
-rwxr-xr-x 1 root root 343 2010-09-08 14:31 /etc/rc.local
Pode ser que este seu comando seja necessário somente depois que determinadas coisas ou processos sejam carregados primeiro durante o boot, então se quiser testar, deixa no rc.local algo do tipo (antes do exit 0, é claro):
sleep 5
route add default gw 192.168.1.1 eth0
e se não funcionar vá aumentando o tempo de espera 5 para 10 e assim por diante, só para tirar a dúvida se seria somente por isso que o seu rc.local não funciona como deveria.
Ou se não quiser, deixe como está, já que para o seu caso está funcionando desta forma. ;)
Atenção: se for tentar fazer o sugerido, desfaça o que você fez no /usr/local/bin para sabermos se o comando sleep 5 faz algum efeito no seu rc.local
-
Antes tentei dar intervalo de 20 segundos, mas não deu certo. Também acho que o rc.local deveria funcionar por sí.
Talvez eu abra um tópico. Obrigado.
-
O comando é:
route add default gw 192.168.1.1 eth0
Deveria ser:
route add -net default gw 192.168.1.1 dev eth0
Mas não tenho certeza se é possível usar ao mesmo tempo "gw" e "dev" no comando route. Se não for possível, use apenas "gw 192.168.1.1", pois "dev eth0" é inferido a partir da rota para 192.168.1.0/24 criada automaticamente pela configuração de endereço de eth0.
-
Ele já verificou a política de conexão do firestarter? Pode ser que ele tenha configurado para restrito por padrão.
É só um pitaco, não quero quebrar o raciocínio de vocês. To acompanhando pra aprender mais sobre o linux.
Abraço.