Desculpe não ter explicado direito.
Mas me deparei com esse problema quando liguei o roteador com o mac clonado na minha rede e as tudo funcionou perfeitamente, nem conflito de ip.

O Caso do ip imagino que seja devido o DHCP entregar a mascara 255.255.255.255.
Não sei se falei besteira.

Grato.
----- Original Message ----- From: "Max Miorim" <[email protected]>
To: <[email protected]>
Sent: Monday, May 10, 2010 4:43 PM
Subject: Re: [slack-users] MAC CLONADO.


On 5/10/10, Renato <[email protected]> wrote:
Mesmo assim, as implementações de servidor DHCP do linux que eu conheço
(dnsmasq e dhcpd3) não fazem isso e um dos motivos é bem
simples: se o cliente perder o link por algum motivo, não vai haver o
"release" de forma adequada, para o servidor o IP continua alocado e em uso.

Ao reestabelecer o link, se houvesse tal bloqueio na hora da liberação, este
cliente seria incapaz de utilizar o mesmo endereço e isso poderia resultar
numa série de problemas (falta de endereços disponíveis, ter que forçar o
cliente a dar o "release" e depois "renew" e etc.)

Eu não concordo. Se o cliente perder o link não haverá problemas em
restabelecer o IP, já que ele vai estar amarrado ao MAC do cliente, não
haverá falta de endereços porque o MAC já estará amarrado e o DHCP não vai
liberar outro IP para aquele MAC. O cliente por sua vez não vai precisar de dar o release nem o renew, já que o DHCP ainda está autenticando aquele MAC amarrado. Mas o que aconteceria é que o DHCP não iria liberar a conexão para
o cliente de jeito nenhum, o que levaria o administrador a encontrar o
problema no olho e solucionar manualmente.

Do ponto de vista lógico eu concordo contigo. Mas o cliente não fica
permanentemente em contato com o servidor DHCP: ele conecta, solicita
o IP, recebe e desconecta.

Por causa disso tu não consegue diferenciar casos onde o cliente
desconectou por um motivo como desligar ou cabo de rede do switch ou
onde o cliente simplesmente manda um request sem dar um release antes
e isso abre potencial para ataques de DOS, uma vez que um cliente pode
mandar vários requests até que o servidor deixe de responder (ou pior,
um cliente pode pegar todos os endereços de uma rede).

O exemplo da falta de endereços não foi exatamente uma boa idéia,
considerando o caso onde tu tem uma reserva para um mac. Era mais algo
num sentido geral (afinal, este tipo de verificação deveria ser feita
sempre ou na maioria dos escopos e não só no host).

--
GUS-BR - Grupo de Usuários de Slackware Brasil
http://www.slackwarebrasil.org/
http://groups.google.com/group/slack-users-br

Antes de perguntar:
http://www.istf.com.br/perguntas/

Para sair da lista envie um e-mail para:
[email protected]

--
GUS-BR - Grupo de Usuários de Slackware Brasil
http://www.slackwarebrasil.org/
http://groups.google.com/group/slack-users-br

Antes de perguntar:
http://www.istf.com.br/perguntas/

Para sair da lista envie um e-mail para:
[email protected]

Responder a