Protocolo (ou publicação / descoberta de serviço) para detectar dispositivos na rede

4

conectamos alguns dispositivos incorporados em uma rede. O que eu estou procurando agora, é uma maneira de encontrar o IP dos dispositivos e identificá-los. Trabalhamos com PCs com Windows e estou prestes a escrever uma ferramenta em C # que deve fazer isso.

  1. Eu pensei em enviar uma transmissão do udp e no ack, ou seja, o ip do dispositivo, o que significa que o dispositivo precisa de um daemon runnig para atribuir um próprio ip.

  2. Como executar um serviço (como uma impressora) no dispositivo e no PC, basta procurar o serviço.
    Eu li sobre algumas coisas como apipa, zeroconf, link local ipv4, bonjour, dns-sd, mdns, bonjour; Eles podem designar ip automaticamente e publicar serviços em uma rede.

Minha pergunta é: alguém pode me recomendar o que seria bom para minha tarefa? -O protocolo ou serviço deve ter baixo uso de recursos (uso de memória / CPU).
-Existem alguns protocolos padrão para usar?
-O DNS é uma boa ideia ou seria ressornar o consumo apenas para encontrar o IP de um dispositivo?
-Deve também funcionar quando não houver servidores dhcp por perto.

edit: Para esclarecer um pouco: A configuração do IP é automática. O problema a ser enfocado é como dizer ao PC qual IP na rede (ou uma conexão direta neste vaso só haveria um) pertence ao dispositivo (identidade).

    
por Gobliins 26.09.2012 / 12:45

2 respostas

2

My Question is, can someone recommend me what would be good for my task? -The protocol or Service should be low on ressource (memory/cpu usage) use. -Are there some standard protocolls to use?

A maneira padrão de detectar dispositivos (e seus atributos, como endereço IP de gerenciamento) em uma rede ethernet é usar LLDP .

Você pode encontrar uma lista de daemons lldp aqui

Todos os hosts em uma ethernet Vlan verão anúncios LLDP, já que eles são enviados para um endereço MAC multicast; isso também significa que os anúncios do LLDP são definidos para um Vlan. Se você precisar de registro e detecção de dispositivos em Vlans, precisará criar seu próprio protocolo de anúncio IP ... O UDP seria uma boa opção para o transporte.

Is DNS a good idea or would it be to ressource consumpting just for finding a device´s IP?

Se você está apenas procurando por um endereço IP, e não se importa se você pode dizer se o dispositivo é um dos seus sistemas embarcados, você pode usar mDNS ; no entanto, isso é mais arriscado, pois você não tem garantia contra colisões de namespace em uma LAN do cliente.

How should the OP's embedded systems get an IPv4 address, if the customer does not have a DHCP server?

RFC 3330 aloca 169.254.0.0/16 para comunicação em um único link, se um servidor DHCP não estiver disponível. Após a reflexão, esse é provavelmente o bloco de endereços mais seguro a ser usado; no entanto, sua empresa deve incentivar seus clientes a alocar endereços com o DHCP em vez de alguma forma de configuração automática na sub-rede 169.254.0.0/16.

Como você atribui endereços IP individuais dentro de 169.254.0.0/16 é uma questão que não podemos decidir por você ... algumas possibilidades são:

  • Atribua os endereços específicos em 169.254.0.0/16, codificando seus valores de endereço MAC de forma que seja improvável que obtenha colisões para o número máximo esperado de seus sistemas na vlan de qualquer cliente
  • Ouça um pouco do intervalo de saudação LLDP do seu sistema e aloque um endereço de 169.254.0.0/16 que ainda não tenha sido usado
por 26.09.2012 / 12:53
1

O utilitário nmap é muito bom em determinar quais endereços IP em uma rede (de sua escolha!) estão ocupados. Se o host responder a qualquer solicitação para verificar sua presença, o nmap mostrará isso.

Caso contrário, você pode mexer com o ARP. Existem vários utilitários para todos os principais sistemas operacionais que farão isso (no Win32 procure por Cain, no Linux existem muitos). Esses utilitários enviarão uma transmissão ARP / "ping" para cada endereço perguntando se há um dispositivo conectado e, em caso afirmativo, qual é o IP.

    
por 26.09.2012 / 13:02