Existe uma maneira rápida e confiável de usar o endereço MAC de um dispositivo para determinar se ele está atualmente conectado a uma rede a partir de um PC/servidor Windows? Se não, então de um servidor Ubuntu?
- arp -a não funciona sozinho porque os itens permanecem no cache por muito tempo.
- arp -a combinado com a limpeza do cache a cada 5 minutos pode funcionar, mas parece ineficiente e só funciona se o cache for totalmente preenchido novamente em 5 minutos. Seria?
Histórico: cansei de chegar no trabalho e escrevi um aplicativo rápido que funciona como um serviço do Windows, verifica se meu telefone está presente na rede da empresa periodicamente, registra isso em um banco de dados e hospeda um site que permite você pudesse ver quando eu estava no escritório, somando os dados em um determinado intervalo (incrível o que você pode fazer com as bibliotecas certas em poucas horas).
Demorou cerca de uma semana até que a empresa decidisse que gostaria que todos usassem o aplicativo no lugar do nosso sistema de ponto, sempre que possível.
Originalmente, eu estava usando uma reserva DHCP e executando ping periodicamente em meu telefone Android para detectá-la. Ao expandir, no entanto, rapidamente me deparei com o problema de os iPhones não responderem aos pings. Além disso, os pings são lentos. Demora cerca de um segundo por telefone para confirmar de forma confiável via ping que ele está lá.
Tentei executar arp -a e vasculhar o resultado em busca de correspondências MAC, mas os itens permanecem no cache arp praticamente indefinidamente. Pensei em ler o cache e depois liberá-lo, mas não sei se ele será repovoado de maneira confiável a tempo. Essa é uma solução potencial, embora eu não goste da ideia de liberar o cache arp a cada cinco minutos.
Minha solução atual é fazer uma pesquisa SNMP em nossos pontos de acesso para reunir seus clientes conectados e, em seguida, analisar isso para ver se consigo encontrar correspondências de MAC. É rápido e confiável, mas é muito específico para os pontos de acesso em questão. Se trocarmos os pontos de acesso, os próximos poderão não listar seus clientes conectados via SNMP. Mesmo que isso aconteça, precisarei reconfigurar as pesquisas snmp.
Estou pensando que se houver uma porta conhecida que aceite conexões em qualquer telefone, eu poderia abrir uma conexão TCP para ela e fechá-la no lugar de um ping, mas sinto que deve haver uma solução rápida de camada 2 aqui em algum lugar .
Responder1
Não use arp
. Usar arping
.
https://en.wikipedia.org/wiki/Arping
Arping é uma ferramenta de software de computador para descobrir e sondar hosts em uma rede de computadores. Arping investiga hosts no link de rede conectado, enviando quadros da camada de link usando o método de solicitação do protocolo de resolução de endereço (ARP) endereçado a um host identificado por seu endereço MAC da interface de rede.
O programa utilitário pode usar ARP para resolver um endereço IP fornecido pelo usuário. A função de arping é análoga ao utilitário ping para sondar a rede com o Internet Control Message Protocol (ICMP) na camada de Internet do Internet Protocol Suite.
É basicamente o que arp
acontece, mas sem todo o negócio de cache ARP do sistema operacional, ou seja, apenas envia solicitações ARP literais e únicas na rede.
PS Lembre-se de que todo esse negócio de ARP funcionará apenas em uma única sub-rede local; se você precisar de um alcance mais amplo, terá que executá-lo no (s) roteador (es).
PPS Você poderia usar apenas concessões curtas de DHCP (por exemplo, 1 minuto a 5 minutos). É verdade que os dispositivos Apple são conhecidos por desobedecer às especificações DHCP no passado, mas isso não deveria ser tão ruim hoje em dia. Espero.
O PPPS Even arping
não será 100% confiável (embora deva ser superior a 99%). Alguns dispositivos ignoram solicitações arp de entrada não solicitadas, assim como alguns dispositivos ignoram pings. Sim, viola o IETF, mas ignorar os pings também...
Uau.
Responder2
Você estava certo ao usar o ARP. Como você não quer depender do dispositivo informando que está na rede, o que é outra maneira, você pode fazer isso sozinho. O ARP pode facilitar isso, e não apenas fornecerá o endereço MAC, mas também o endereço IP que eles estão usando na rede. Quando você limpa o arpcache, ele será preenchido novamente conforme necessário. Ou seja, ele preencherá o cache apenas com os endereços com os quais teve que se comunicar na rede.
Uma solução melhor, se você já conhece os endereços MAC dos clientes, pode atribuir-lhes endereços IP estáticos na rede. Isso resolverá seu problema de cache até certo ponto, pois o cache fica obsoleto periodicamente. O que significa que da próxima vez que sua interface de rede precisar se comunicar com o dispositivo, ela fará outra pesquisa. Agora, como você tem o problema de os dispositivos Apple não retornarem, ia sugerir, você sempre pode fazer ping na transmissão de suas redes. então, por exemplo, se o seu gateway for 192.168.1.1, a transmissão será 192.168.1.255 e se você enviou um ping para ele, todos os dispositivos que aceitam pings responderão a você.
Então, para recapitular, você pode simplesmente continuar limpando o cache arp, pois ele será repovoado de forma confiável conforme necessário para o protocolo TCP/IP para a troca de pacotes entre computadores e roteadores, etc. . Ou no aplicativo, faça com que ele detecte quando ele se conecta à rede da empresa e envie um ping para o seu servidor em uma porta diferente do icmp padrão, faça com que seu servidor ouça esses pings e você poderá documentar tudo o que precisa. Ou apenas faça com que o aplicativo execute ping em seu servidor de vez em quando. Só porque o dispositivo não aceita pings, não significa que não possa enviar um.
Responder3
Existe um aplicativo Android chamado Fing que basicamente verifica e exibe informações (incluindo IPs e MACs) sobre todos os dispositivos em uma rede.
Não sei quais protocolos ele usa, mas detecta dispositivos Apple. Você poderia usar algo como o Wireshark para tentar fazer engenharia reversa do aplicativo e usar a mesma técnica em sua ferramenta. (Alguém já tentouem um site relacionado do Stack Exchange)