Forum Linux.général Configuration DHCP

Posté par sygirard le 24 mars 2015 à 11:56. Licence CC By‑SA.

Étiquettes :

mar.

2015

Bonjour,

j'ai actuellement configuré mon serveur DHCP, il fonctionne correctement, je n'ai pas de soucis.
C'est un DHCP local puisqu'un seul appareil est branché dessus en direct.

Mon problème étant qu'après une erreur de manipulation des câbles Ethernet sur mon serveur, mon DHCP s'est retrouvé sur le réseau entreprise, où il y a déjà un serveur DHCP.

Certaines machines ont détecté mon serveur en premier, ont reçu une réponse négative de mon serveur et donc pas d'IP, et sont tombées.

Existe-t-il un moyen de configurer mon serveur DHCP pour qu'il réponde uniquement à certaines machines (adresse MAC par exemple) et ne réponde rien (ni OK, ni KO, ni rein) pour les autres machines ?

Merci
Sylvain

# Configuration basée sur l'adresse MAC

Posté par Ellendhel (site web personnel) le 24 mars 2015 à 12:44. Évalué à 4. Dernière modification le 08 juin 2015 à 14:06.
Existe-t-il un moyen de configurer mon serveur DHCP pour qu'il réponde uniquement à certaines machines (adresse MAC par exemple) (…) ?

Oui, on peut créer un bloc de configuration par client, en spécifiant l'adresse MAC. Extrait de la page de manuel de ISC dhcpd :
```
host haagen {
              hardware ethernet 08:00:2b:4c:59:23;
              fixed-address 239.252.197.9;
              filename "/tftpboot/haagen.boot";
            }
```
Cela permet d'attribuer une adresse IPv4 (et d'autres options au besoin) pour un client particulier.

Par contre je ne suis pas certain que le serveur ne réponde "rien" aux clients non autorisés.
- [^] # Re: Configuration basée sur l'adresse MAC
  
  Posté par sygirard le 24 mars 2015 à 14:12. Évalué à 2.
  
  Merci pour ta réponse.
  
  J'avais noté les "host" pour gérer les IP en fonction des adresses MAC comme tu le présente.
  J'ai même trouvé cet exemple qui me convient car je veux autoriser tous les appareils similaires d'une même marque :
  class "host_name" {
  match if substring (hardware, 1, 3) = 00:0B:AB;
  }
  subnet 10.0.0.0 netmask 255.255.255.0 {
  pool {
  range 10.0.0.16 10.0.0.32;
  allow members of "host_name";
  }
  }
  
  Par contre cette histoire de ne "rien" répondre est la plus importantes ….
  - [^] # Re: Configuration basée sur l'adresse MAC
    
    Posté par gouttegd (site web personnel) le 25 mars 2015 à 17:00. Évalué à 2. Dernière modification le 25 mars 2015 à 17:01.
    
    Par contre cette histoire de ne "rien" répondre est la plus importantes ….
    
    Peut-être pas tant que ça.
    
    Il ne me paraît pas normal que les machines « tombent » simplement parce que ton serveur leur envoie une réponse négative.
    
    A priori, ce qui se passe est que ces machines se souviennent de l’ancienne adresse IP que leur avait attribué le serveur légitime, et envoient donc directement un message DHCPREQUEST pour demander que l’on leur ré-attribue cette adresse. Ton serveur refuse (DHCPNAK), ce qui est normal (l’adresse demandée n’est pas dans la plage d’adresse qu’il est configuré pour distribuer). Mais à ce moment-là, au lieu de « tomber », les clients devraient se rabattre automatiquement sur un cycle DHCP « complet » (DHCPDISCOVERY → DHCPOFFER → DHCPREQUEST → DHCPACK), qui devrait leur permettre de recevoir une bonne configuration de la part du serveur DHCP légitime.
    
    Si malgré tout les machines « tombent », je dirais qu’il se passe le scénario suivant :
    
    ① Le client envoie un DHCPREQUEST avec l’ancienne IP (correcte).
    
    ② Ton serveur répond DHCKNAK.
    
    ③ Le client envoie un DHCPDISCOVER.
    
    ④ Ton serveur répond un DHCPOFFER avec une adresse IP incorrecte (valable sur ton réseau local, mais pas sur le réseau entreprise).
    
    ⑤ Le serveur DHCP légitime du réseau entreprise envoie DHCPACK (en réponse au DHCPREQUEST du ①), mais il est trop tard.¹
    
    ⑥ Le client envoie un DHCPREQUEST avec l’adresse IP reçue en ④.
    
    ⑦ Ton serveur renvoie DHCPACK ; le client se retrouve configurée avec une IP incorrecte, donnant l’impression qu’il est « tombé » du point de vue du réseau entreprise.
    
    ⑧ Le serveur DHCP légitime envoie un DHCPOFFER en réponse au DHCPDISCOVER du ③, mais encore une fois, trop tard.¹
    
    En supposant que c’est bien ce qui se passe, il n’est pas particulièrement gênant que ton serveur réponde DHCKNAK en ②. Tout au plus, cela oblige le client à renvoyer un DHCPDISCOVER dont il pourrait autrement se passer. Le vrai problème, c’est que ton serveur ne devrait pas envoyer de DHCPOFFER en ④. Et pour ça, configurer ton serveur comme dans l’exemple que tu donnes (pour ne répondre positivement qu’à des machines précises) devrait être suffisant.
    
    ¹ L’ordre exact d’arrivée des messages du serveur DHCP légitime peut être un peu différent, mais ce qui est sûr c’est qu’ils arrivent après la bataille.
    - [^] # Re: Configuration basée sur l'adresse MAC
      
      Posté par sygirard le 26 mars 2015 à 08:01. Évalué à 1.
      
      Bien, il y a des choses que je n'ai pas testé car je me suis peut être lancé un peu vite dans cette idée de "ne rien répondre du tout". Et pour moi iptables était la meilleure solution.
      Disons que mon responsable IT n'était pas spécialement prêt à avoir une nouvelle fois les pannes.
      
      Et que pour expliquer plus clairement le projet, ce PC, n'est autre qu'un clone qui se retrouvera dans une machine, comme les autres, chez des clients. Et on voudrait absolument éviter le problème que l'on a eu ici dans nos locaux.
      Cela serait gênant que notre serveur DHCP, suite à une mauvaise manipulation, fasse "tomber" toute une ligne de production et fasse perdre beaucoup de billets.
      Même si on peut espérer que leur réseau est plus solide que le notre …
      
      D'après toi, ce type de configuration pour le serveur :
      class "host_name" {
      match if substring (hardware, 1, 3) = 00:0B:AB;
      }
      subnet 10.0.0.0 netmask 255.255.255.0 {
      pool {
      range 10.0.0.16 10.0.0.32;
      allow members of "host_name";
      }
      }
      
      Est suffisante pour mon besoin ?
      
      Je vais me poser sur cette configuration, lancer wireshark pour voir ce qu'il se passe et je fais un retour.
      
      Si ça fonctionne comme je le souhaite, désolé pour toute la discussion qui a du vous prendre du temps alors que la solution était sous mes yeux.
      - [^] # Re: Configuration basée sur l'adresse MAC
        
        Posté par Anonyme le 26 mars 2015 à 19:10. Évalué à 2.
        
        mais non, ici on adore les problèmes ainsi que leur solutions pour les prochains :)
# Commentaire supprimé

Posté par Anonyme le 24 mars 2015 à 12:59. Évalué à 3.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Configurer le pare-feu
  
  Posté par sygirard le 24 mars 2015 à 14:55. Évalué à 2.
  
  Le PC contenant ce serveur DHCP est dans une machine (eth0 va vers le réseau usine, eth1 va vers un automate).
  C'est sur eth1 que tourne mon serveur DHCP.
  
  Pour des raisons de simplification d'utilisation entre notre application et toutes les données qui transites, j'ai désactivé le firewall.
  
  Va donc falloir que je le réactive et fasse toute la configuration si je ne trouve pas une autre solution.
  
  Pour info, je suis sous OpenSuse 12.1
  
  Vais voir avec les règles "iptables".
  
  Merci
  - [^] # Re: Configurer le pare-feu
    
    Posté par Ellendhel (site web personnel) le 24 mars 2015 à 15:54. Évalué à 2.
    
    Vais voir avec les règles "iptables".
    
    Pour information, il existe un autre outil qui travaille au niveau Ethernet : ebtables (que je n'ai jamais utilisé cela dit). iptables est aussi une bonne solution.
    
    Site officiel d'ebtables
    - [^] # Re: Configurer le pare-feu
      
      Posté par Ellendhel (site web personnel) le 24 mars 2015 à 16:02. Évalué à 3.
      
      Et si ton serveur DHCP a deux interfaces réseau distinctes, il est aussi possible de modifier le script de démarrage pour que le daemon ne s'attache qu'à une des interfaces et ignore l'autre.
      
      D'après la page de manuel (qui n'est pas très explicite) :
      dhcpd (...) [ if0 [ ...ifN ] ]
      
      The names of the network interfaces on which dhcpd should listen for broadcasts may be specified on the command line.
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 24 mars 2015 à 16:30. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Configurer le pare-feu
        
        Posté par sygirard le 24 mars 2015 à 17:19. Évalué à 3.
        
        Oui c'est ce que j'ai paramétré dans le fichier /etc/sysconfig/dhcpd :
        
        DHCPD_INTERFACE="eth1"
- [^] # Re: Configurer le pare-feu
  
  Posté par LaBienPensanceMaTuer le 25 mars 2015 à 12:34. Évalué à 0.
  
  Non, tout faux.
  Il suffit de ne pas définir de pool d'adresse par défaut et juste des fixed-adress pour tes clients, et rulez …
  - [^] # Re: Configurer le pare-feu
    
    Posté par LaBienPensanceMaTuer le 25 mars 2015 à 12:40. Évalué à 1.
    
    Je rajouterai un extrait de la page de man:
    
    Declarations about network topology include the shared-network and the subnet declarations. If clients on a subnet are to be assigned addresses dynamically, a range declaration must appear within the subnet declaration.
    For clients with statically assigned addresses, or for installations where only known clients will be served, each such client must have a host declaration.
    
    If parameters are to be applied to a group of declarations which are not related strictly on a per-subnet basis, the group declaration can be used.
    
    Et je rajouterai un conseil: il ne faut pas hésiter à lire la page de man ;-)
    
    Pour celle-ci c'est dhcpd.conf(5).
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 25 mars 2015 à 12:59. Évalué à 1.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# Configuration iptables

Posté par sygirard le 24 mars 2015 à 15:48. Évalué à 2.

Bon j'ai bien trouvé comment faire ce que je voulais avec les iptables.

Quelque chose du genre :

iptables -A INPUT -i eth1 -m mac --mac-source AA:BB:CC:DD:EE:FF -j ACCEPT

Maintenant, est-ce que quelqu'un a une idée pour que le filtre s'applique sur toutes les MAC commençant par "AA:BB:CC" par exemple ?
C'est ça qu'il me faudrait ..

Merci
- [^] # Re: Configuration iptables
  
  Posté par Anonyme le 24 mars 2015 à 15:57. Évalué à 4.
  
  essaye --mac-source AA:BB:CC:*
  ou --mac-source AA:BB:CC:
  
  j'ai une préférence pour le premier, sinon les deux devraient fonctionner, sinon man iptables
  - [^] # Re: Configuration iptables
    
    Posté par sygirard le 24 mars 2015 à 15:59. Évalué à 2.
    
    Vais essayer.
    
    Merci
    
    Pensais pas que ça serait aussi simple que ça … j'ai rien trouvé sur le net.
    
    Merci encore
    - [^] # Re: Configuration iptables
      
      Posté par Marotte ⛧ le 24 mars 2015 à 19:41. Évalué à 4.
      
      Hésite pas à revenir ici nous dire si ça fonctionne.
      - [^] # Re: Configuration iptables
        
        Posté par sygirard le 25 mars 2015 à 10:56. Évalué à 1.
        
        J'ai essayé les commandes suivantes :
        => iptables -A INPUT -i eth1 -m mac --mac-source aa:bb:cc:* -j ACCEPT
        => iptables -A INPUT -i eth1 -m mac --mac-source aa:bb:cc: -j ACCEPT
        
        Aucune des deux ne fonctionne, et me retourne :
        iptables v1.4.12.1: ether
        Try `iptables -h' or 'iptables --help' for more information.
        
        Je continue mes recherches …
        
        [^] # Re: Configuration iptables
        
        Posté par gouttegd (site web personnel) le 25 mars 2015 à 12:31. Évalué à 3.
        
        Aucune des deux ne fonctionne
        
        Normal, ce que tu cherches à faire n’est pas supporté.
        
        La page de manual iptables-extensions(8) dit clairement :
        
        --mac-source address
        Match source MAC address. It must be of the form XX:XX:XX:XX:XX:XX.
        
        Rien ne permet de laisser supposer que l’utilisation de « wildcard » est possible.
        
        Et un coup d’œil au code du module xt-mac achève de lever le doute, ce module ne travaille qu’avec des adresses complètes et pas avec des plages d’adresses :
        
        static bool mac_mt(const struct sk_buff *skb, struct xt_action_param *par) { const struct xt_mac_info *info = par->matchinfo; bool ret; if (skb->dev == NULL || skb->dev->type != ARPHRD_ETHER) return false; if (skb_mac_header(skb) < skb->head) return false; if (skb_mac_header(skb) + ETH_HLEN > skb->data) return false; ret = ether_addr_equal(eth_hdr(skb)->h_source, info->srcaddr); ret ^= info->invert; return ret; }
        
        [^] # Re: Configuration iptables
        
        Posté par Anonyme le 25 mars 2015 à 12:40. Évalué à 2.
        
        dommage, et désolé, tu vas être condamner a faire un script avec l'ensemble des adresse MAC que tu souhaite.
        
        [^] # Re: Configuration iptables
        
        Posté par sygirard le 25 mars 2015 à 16:13. Évalué à 1.
        
        Juste que je voudrais toutes les IP commençant par AA:BB:CC soit un total de 16 777 215 adresse MAC possible …
        Je me vois mal ajouté autant de règle via iptables … il va me jeter ^{^}
        
        J'ai pensé essayer les "-m string --string " et "-m string --hex-string " mais ça ne fonctionne que pour la partie "Data" de la trame, et non pas pour les headers.
        
        Après il y a aussi les "-m u32" mais c'est pareil, ne remonte pas jusqu'au header contenant la MAC.
        Ou alors j'ai pas pigé comment faire.
- [^] # Re: Configuration iptables
  
  Posté par LaBienPensanceMaTuer le 25 mars 2015 à 12:42. Évalué à 0.
  
  Oublie iptables, c'est la massue pour chasser le microbe !
  
  Tu peux répondre à ta problématique seulement via de la config de ton service DHCP.
  
  Va donc lire la page de man au lieu d'écouter les aneries des gens mal informés. …
  - [^] # Re: Configuration iptables
    
    Posté par Zylabon le 25 mars 2015 à 16:02. Évalué à 2.
    
    Tu peux répondre à ta problématique seulement via de la config de ton service DHCP.
    
    En fait il peut répondre à la problématique en ne faisant rien du tout, simplement en le branchant correctement, mais les erreurs sont humaines. Dans les branchements comme dans les fichiers de conf.
    
    Personnellement le « oui, je branche un second serveur DHCP sur le réseau mais il est configuré pour ne pas marcher sur les pieds du premier » je ne le trouverais pas satisfaisant.
    
    Please do not feed the trolls
# Nouvelle configuration

Posté par sygirard le 08 juin 2015 à 13:32. Évalué à 1.
Bonjour,

je reviens vers vous comme convenu.

Je rappellle que mon serveur DHCP me sert uniquement pour réaliser la mise à jour en automatique d'un automate dans une machine.

J'ai fait des tests de configuration DHCP, et il semble que celle qui suit soit la meilleure pour ce que je cherche à faire.
```
ddns-update-style none;

ignore client-updates;
allow booting;
allow bootp;

class "ma_classe" {
   match if substring (option dhcp-client-identifier, 0, 9) = "\000MON_UID";
   option vendor-encapsulated-options "/NAME=config.xml /ADDRESS=192.168.1.1 /PROTOCOL=ftp";
}

subnet 192.168.1.0 netmask 255.255.255.0 {
   option routers                192.168.1.1;
   option subnet-mask            255.255.255.0;
   option time-offset            -18000;
   option broadcast-address      192.168.1.255;
   pool {
      allow members of "ma_classe";
      range 192.168.1.2 192.168.1.2;
   }
}
```
Je dois attribuer une adresse IP fixe à l'automate. L'utilisation de "range" dans "pool" ne me plait pas. Surtout pour un "range" d'une IP.
Je sais qu'on peut utiliser fixed-address, mais dans un "pool" ça marche pas, et dans "class" je sais pas si on peut l'utiliser.
Dans un "host" oui à ce que j'ai vu mais je pense pas que ça me soit utile.

Mon fichier de conf est-il bon, ou est-ce que c'est mal fait ? Il fonctionne bien, mais si c'est pas propre, je vois pas trop l'utilité de le garder comme ça.

Ensuite, comme je l'expliquais, si un jour en rebranchant les cables, l'opérateur les inverse, je me retrouve avec mon serveur DHCP sur le réseau du client, où il y a déjà un serveur DHCP. Et je ne veux pas que le miens mette la pagaille sur leur réseau.

Ma configuration suffit-elle à éviter des problèmes ?

Sinon, quelqu'un connaitrait-il le moyen de bloquer les trames venant des autres machines n'ayant pas l'UID "dhcp-client-identifier" que j'ai choisi ?

J'ai beau chercher sur le net, j'ai pas trouvé ce que je voulais. Ou alors j'ai horriblement mal cherché.

Merci pour votre aide.

Sylvain
- [^] # Re: Nouvelle configuration
  
  Posté par NeoX le 08 juin 2015 à 14:11. Évalué à 2. Dernière modification le 08 juin 2015 à 14:13.
  dans la doc de dhcp on trouve l'exemple suivant, qui devrait faire ce que tu souhaites :
```
deny unknown-clients;

subnet 192.168.1.0 netmask 255.255.255.0 {
    host client1 {
        hardware ethernet DD:GH:DF:E5:F7:D7;
        fixed-address 192.168.1.20;
    }
    host client2 {
        hardware ethernet 00:JJ:YU:38:AC:45;
        fixed-address 192.168.1.21;
    }
}
```
  le deny unknown-clients ne distribue pas d'IP si le client n'est pas specifiquement precisé.
  le host client1 ... fixe l'adresse du client par rapport à l'adresse MAC de la machine.
  - [^] # Re: Nouvelle configuration
    
    Posté par sygirard le 08 juin 2015 à 15:23. Évalué à 1.
    
    Oui cette partie là comme je disais je l'avais vu, mais je suis pas sur que je puisse l'utiliser sans "hardware ethernet"
    
    Car, j'explique, j'aurai un serveur DHCP par machine (partie mécanique, le PC, l'automate), et que sur chaque machine, je veux le même fichier de conf.
    
    Donc une adresse MAC spécifique dans le fichier de conf ne me convient pas.
    
    Désolé, j'avais pas spécifié cette subtilité.
    - [^] # Re: Nouvelle configuration
      
      Posté par NeoX le 08 juin 2015 à 16:32. Évalué à 2.
      
      Car, j'explique, j'aurai un serveur DHCP par machine (partie mécanique, le PC, l'automate), et que sur chaque machine, je veux le même fichier de conf.
      
      un DHCP pour gerer 3 machines,
      qui auront toujours la meme IP dans ce reseau (la meca, le pc, l'automate).
      
      l'idée derriere c'est de pouvoir remplacer l'une ou l'autre sans se prendre la tete sur la config reseau ?
      
      je crois que tu peux faire le deny unknown-clients
      et utiliser une class pour definir les machines en fonction des vendors-string.
      - [^] # Re: Nouvelle configuration
        
        Posté par sygirard le 09 juin 2015 à 08:17. Évalué à 1.
        
        Je me suis mal exprimé.
        
        Pour moi une machine c'est une partie mécanique, la carcasse si tu préfères, un PC avec mon serveur DHCP, et un automate qui recevra l'IP fixe.
        
        Des machines j'en aurai 50, 100 voir plus qui vont partir chez des clients chaque année.
        
        Tu comprends donc que pour une question de maintenance j'ai besoin que cette configuration soit la même sur toutes les machines.
        
        Donc oui j'ai utilisé une class (voir code que j'ai copié au dessus) que je rappelle ici :
        
        class "ma_classe" { match if substring (option dhcp-client-identifier, 0, 9) = "\000MON_UID"; option vendor-encapsulated-options "/NAME=config.xml /ADDRESS=192.168.1.1 /PROTOCOL=ftp"; }
        
        Ma question était surtout sur l'utilisation de mon pool. Est-ce que c'est bon l'utilisation que j'en fait, ou pas ?
        
        Après j'ai vu que pour une seule IP il vaut mieux mettre "range 192.168.1.2;" plutôt que "range 192.168.1.2 192.168.1.2;"
        
        Mise à part ça, je voulais surtout qu'on me dise si ma configuration était perfectible ou non ?
        
        Je note le "deny unknown-clients" que tu m'as donné.
        
        [^] # Re: Nouvelle configuration
        
        Posté par NeoX le 09 juin 2015 à 09:22. Évalué à 2.
        
        Pour moi une machine c'est une partie mécanique, la carcasse si tu préfères, un PC avec mon serveur DHCP, et un automate qui recevra l'IP fixe.
        
        donc tu as 2 morceaux, dans une 'carcasse'
        - le PC
        - l'automate
        
        et tu as besoin d'un DHCP pour gerer un reseau avec 2 elements dedans ?
        c'est pas un peu sortir le char pour enculer une mouche ?
        
        parce que autant tu aurais 1 PC, et 50 automates,
        je comprend le besoin du dhcp pour ne pas avoir à gerer la config IP de chacun des automates
        
        mais pour 2 appareils qui vont communiquer ensemble,
        et sur lesquels tu interviendras car c'est dans "une seule carcasse"
        
        si tu changes la carte reseau, tu notes la nouvelle mac, tu changes dans le dhcp,
        et hop
        
        evidemment quand tu prepares ta maquette qui sera dupliquer dans 50 ou 100 automates, ca semble compliquer,
        mais on en revient à la question, pourquoi utiliser un DHCP,
        une config en IP fixe sur l'automate, la meme sur tous les automates qui communiquent avec le PC qui se trouve dans leur carcasse.
        
        si ca pose un probleme à l'usine pour la maintenance quand il y a plusieurs automates à preparer, mettre 2 cartes reseaux.
        une pour l'interne, avec une IP fixe,
        une pour l'usine en dhcp client.
        
        [^] # Re: Nouvelle configuration
        
        Posté par sygirard le 09 juin 2015 à 09:45. Évalué à 1.
        
        c'est pas un peu sortir le char pour enculer une mouche ?
        
        MDR :-D !!! oui c'est un peu ça.
        
        J'ai déjà deux cartes réseaux sur le PC. Une pour le réseau usine, et une pour le réseau interne à la machine.
        Avant on mettait à jour l'automate par clé USB, et j'étais donc dans la configuration que tu me conseilles, c'est à dire une interface en DHCP client, et une autre en IP fixe, et l'automate en IP fixe également.
        
        Donc comme tu vois, j'avais déjà eu cette idée.
        
        Sauf qu'aujourd'hui on a besoin du DHCP pour des mise à jour automatique de version de firmware de l'automate via ftp au moment du démarrage de ce dernier. C'est à dire que lorsqu'il fait sa requête pour une IP, avant de démarrer le soft complétement, il regarde si une mise à jour est disponible et l'applique si c'est le cas.
        
        Voilà pourquoi j'ai un serveur DHCP sur le PC.
        
        Et je cherche seulement à faire en sorte que mon serveur n'impacte pas le réseau usine d'un client si un opérateur inverse les cables réseau dans la machine.
        
        [^] # Re: Nouvelle configuration
        
        Posté par NeoX le 09 juin 2015 à 11:17. Évalué à 2.
        
        J'ai déjà deux cartes réseaux sur le PC
        
        Et je cherche seulement à faire en sorte que mon serveur n'impacte pas le réseau usine d'un client si un opérateur inverse les cables réseau dans la machine.
        
        ah ben alors oui, il ne reste que les options suivantes :
        
        1°) bind uniquement sur l'interface INTERNE
        2°) deny unknow-client;
        3°) jouer de la classe pour rendre certaines machines connues du dhcp (en esperant que tes clients n'ai pas des machines similaires)
        
        pour ton histoire de mise à jour, en gros tu veux mettre en place un boot sur le reseau (dhcp/tftp) plutot qu'un boot sur le disque interne de l'automate ?
        
        ainsi pour faire la mise à jour de l'automate, il suffit de pousser la nouvelle version sur le PC qui gere le DHCP.
        
        ou c'est le firmware de l'automate qui vient se connecter au 'serveur (PC)' pour voir s'il a une mise à jour ?
        
        parce que dans ces cas, les problematiques sont differentes.
        
        [^] # Re: Nouvelle configuration
        
        Posté par sygirard le 09 juin 2015 à 15:31. Évalué à 1. Dernière modification le 09 juin 2015 à 15:33.
        
        1°) bind uniquement sur l'interface INTERNE
        
        Tu entends par là que mon serveur DHCP doit être uniquement sur le port Ethernet interne ? Si oui, c'est déjà le cas (eth1 dans fichier /etc/sysconfig/dhcpd)
        
        2°) deny unknow-client;
        
        On est d'accord que cette option se met au même niveau que "default-lease-time 7200;" par exemple ?
        
        3°) jouer de la classe
        
        Ce que j'ai fais.
        
        Je veux juste me garantir comme je te disais que la méthode "pool" dans mon "subnet" est la bonne méthode à appliquer.
        Si oui, c'est bon j'ai fini ^{^}
        
        On copie les mises à jour sur le PC dans un répertoire destiné au ftp, mais c'est le firmware qui vient voir à l'acquisition de l'IP s'il a une mise à jour à télécharger et appliquer.
        Voir ma classe dans la conf du serveur pour ça.
        
        Je la remet complète ici :
        
        ddns-update-style none; deny unknow-client; ignore client-updates; allow booting; allow bootp; class "ma_classe" { match if substring (option dhcp-client-identifier, 0, 9) = "\000MON_UID"; option vendor-encapsulated-options "/NAME=config.xml /ADDRESS=192.168.1.1 /PROTOCOL=ftp"; } subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option subnet-mask 255.255.255.0; option time-offset -18000; option broadcast-address 192.168.1.255; pool { allow members of "ma_classe"; range 192.168.1.2; } }
        
        [^] # Re: Nouvelle configuration
        
        Posté par NeoX le 09 juin 2015 à 18:22. Évalué à 2.
        
        On copie les mises à jour sur le PC dans un répertoire destiné au ftp, mais c'est le firmware qui vient voir à l'acquisition de l'IP s'il a une mise à jour à télécharger et appliquer.
        
        si le firmware vient regarder en FTP,
        alors ton DHCP ne te sert à rien sauf à avoir des emmerdes comme tu as eu lors de l'inversion des cables.
        
        une IP fixe dans la config de l'automate est suffisante, et ca t'evitera les problemes.
        
        le DHCP aurait eu son interet pour faire du boot PXE.
        ex : l'automate n'a pas de disque memoire, ni d'OS, il demarre, cherche un DHCP/PXE, charge son firmware depuis le reseau (donc forcement le dernier) et tourne ainsi, en RAM.
        
        le seul interet actuel serait que tu prepares 25 automates à l'usine, en client DHCP aussi.
        et que tu as juste à les brancher dans le chassis, derriere le PC, avant la livraison.
        
        et encore dans ce cas là, il doit etre possible de faire un firmware pour l'automate qui cherche un DHCP (celui de l'usine) et si le DHCP ne repond pas, applique une config IP par defaut (celle pour la communication entre ton PC et l'automate)
        
        [^] # Re: Nouvelle configuration
        
        Posté par sygirard le 10 juin 2015 à 07:36. Évalué à 1.
        
        si le firmware vient regarder en FTP, alors ton DHCP ne te sert à rien sauf à avoir des emmerdes
        
        Tu conseillerais quoi alors comme méthode dans ce cas ?
        
        [^] # Re: Nouvelle configuration
        
        Posté par sygirard le 10 juin 2015 à 07:59. Évalué à 1.
        
        Car c'est la seule méthode préconisée par le constructeur de l'automate.
        
        Qui dit ceci :
        
        Each remote install client (Automation Runtime) receives an IP address from the DHCP server
        
        In addition, they try to query the B&R-specific parameters from DHCP server
        
        If B&R-specific parameters are provided by a DHCP server, the received data is used to try to establish a connection to the remote install server and to read the remote install configuration file. If no connection to the remote install server is possible, then AR boots.
        
        The remote install configuration file is evaluated on the remote install client (Automation Runtime), and the version of the BR modules to be installed corresponds to the node number or MAC address. The application and/or the operating system is stored on the remote install client's Compact Flash. The next time it's booted, the installed software will be used.
        
        [^] # Re: Nouvelle configuration
        
        Posté par NeoX le 10 juin 2015 à 09:10. Évalué à 2.
        
        que ton automate fait des trucs bizarres, mais que du coup, tu n'as pas le choix.
        
        il te faut un DHCP, car c'est lui qui donne l"URL" de la mise à jour à l'automate (B&R specific parameters)
        
        l'ip n'a visiblement pas besoin d'etre fixe, ca c'est pour ton confort, pour pouvoir verifier que l'automate est en marche, ou te connecter dessus depuis le PC d'administration.
        
        [^] # Re: Nouvelle configuration
        
        Posté par sygirard le 10 juin 2015 à 10:02. Évalué à 1.
        
        Ce qui est le cas. On communique beaucoup entre notre application sur le PC et l'automate.
        Ce dernier permet de piloter les parties mécanique de al machine.
        
        Donc est-ce que ma configuration DHCP est propre et suffisante pour éviter tout problème si inversion de cable ?
        
        Si ce n'est pas le cas, faut-il que j'ajoute des règles iptables ? Si oui, pourrais-tu m'aider à trouver la règle qui fera que seul les trames venant de mon automate puissent passer par le port eth1 .. car comme je le disais, j'ai déjà essayé de trouver une règle qui détecte une certaine chaine dans l'entête, mais j'ai l'impression que c'est possible uniquement pour le corps de la trame. Mais j'ai peut-être pas tout compris
        
        Merci pour ton aide
        
        [^] # Re: Nouvelle configuration
        
        Posté par NeoX le 10 juin 2015 à 11:10. Évalué à 2.
        
        ta config est bonne puisque :
        1°) globalement tu refuses les clients inconnus avec le deny unknown-client
        2°) tu identifies ton client dans une classe, à l'aide du vendor-string
        
        si tu as vraiment un doute, le mieux c'est de brancher ton DHCP sur un switch isolé du reste du reseau.
        de brancher ton PC perso sur ce meme switch.
        
        s'il recuperes une adresse IP de ce DHCP c'est que ca ne fonctionne pas comme prevu.
        si ton PC perso ne recoit pas d'adresse, alors c'est que le DHCP fonctionne comme prevu.
        
        [^] # Re: Nouvelle configuration
        
        Posté par sygirard le 10 juin 2015 à 13:37. Évalué à 1.
        
        Bon ça me va.
        
        Merci à toi

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.